BGP: o que é, como funciona, ASN, peering e critérios de projeto

Entenda o que é BGP, como funcionam ASN, eBGP, iBGP, atributos, políticas, multihoming, filtros, redundância e critérios de projeto e aceite.

Confira!

O BGP (Border Gateway Protocol) é o protocolo de roteamento usado para trocar informações de alcance entre Sistemas Autônomos (Autonomous Systems — AS). Em vez de procurar apenas o caminho de menor custo interno, como fazem protocolos IGP, o BGP transporta prefixos IP acompanhados de atributos que permitem aplicar políticas de roteamento, selecionar caminhos, controlar anúncios e decidir por quais conexões o tráfego deve entrar ou sair de uma organização.

Na prática, o BGP é utilizado principalmente na borda entre redes administrativas diferentes: provedores de Internet, operadoras, data centers, redes acadêmicas, grandes empresas e organizações que possuem múltiplos links WAN ou conexão com mais de um provedor. Sua função não é substituir OSPF, IS-IS ou outro protocolo interno, mas controlar a troca de rotas entre domínios de roteamento distintos e dar previsibilidade à conectividade externa.

O BGP opera sobre TCP, tradicionalmente na porta 179, e estabelece sessões entre roteadores chamados peers ou vizinhos BGP. Depois de estabelecida a sessão, os equipamentos trocam informações de alcance e atributos como AS_PATH, NEXT_HOP, LOCAL_PREF, MED e comunidades. A decisão final de rota depende da política configurada e do processo de seleção implementado pelo equipamento.

Um projeto com BGP exige muito mais do que habilitar o protocolo. É necessário definir ASN, prefixos próprios ou recebidos, modelo de multihoming, políticas de importação e exportação, filtros, sumarização, capacidade da tabela de rotas, redundância, convergência, segurança, monitoramento, documentação e critérios de teste. Configurações permissivas ou sem engenharia podem causar perda de conectividade, rotas assimétricas, route leaks e propagação indevida de prefixos.

BGP dentro da arquitetura de redes

O BGP deve ser entendido como uma peça da arquitetura de redes, e não como uma configuração isolada do roteador de borda. A necessidade do protocolo nasce dos requisitos de conectividade, disponibilidade, autonomia administrativa e relacionamento com provedores.

Em uma rede corporativa convencional com um único link de Internet, rota default estática ou aprendida do provedor costuma atender à necessidade. BGP começa a fazer sentido quando a organização precisa controlar múltiplos caminhos, anunciar seus próprios prefixos, operar com ASN próprio, participar de peering, receber rotas específicas ou manter conectividade independente de um único provedor.

A arquitetura de rede corporativa organiza camadas, domínios, redundância e fronteiras de falha. O BGP normalmente aparece na borda WAN/Internet, enquanto protocolos internos cuidam da distribuição das rotas dentro do ambiente.

BGP não substitui o IGP

Dentro do mesmo AS, a rede ainda precisa de mecanismos para alcançar loopbacks, enlaces, gateways e demais prefixos internos. É comum utilizar OSPF ou IS-IS como IGP e reservar o BGP para rotas externas e políticas entre domínios.

Misturar funções sem um modelo claro aumenta a complexidade. O IGP precisa convergir rapidamente e manter a infraestrutura interna alcançável; o BGP precisa aplicar política e controlar anúncios. A redistribuição indiscriminada entre os dois planos pode introduzir loops, rotas excessivas e dependências difíceis de diagnosticar.

O que é um Sistema Autônomo e para que serve o ASN

Um Sistema Autônomo é um conjunto de redes IP e roteadores sob uma administração comum que apresenta uma política de roteamento coerente perante outros sistemas autônomos. O ASN (Autonomous System Number) identifica esse domínio no BGP.

O RFC 4271 originalmente descreveu o ASN em dois octetos. A expansão definida pelo RFC 6793 permite ASNs de quatro octetos, ampliando o espaço disponível. Em projetos atuais, a engenharia deve considerar compatibilidade de plataforma, formato de representação, integração com provedores e registros oficiais aplicáveis.

Nem toda empresa precisa de ASN próprio. Em muitos contratos, o provedor pode entregar uma sessão BGP utilizando ASN privado ou um modelo controlado por ele. ASN público passa a ser relevante quando existe necessidade de identidade de roteamento independente, anúncio de prefixos próprios, multihoming com provedores distintos ou participação formal em ecossistemas de interconexão.

ASN público e ASN privado

ASNs públicos são coordenados no sistema global e utilizados para anúncios que precisam aparecer além do domínio privado. ASNs privados servem a cenários internos ou relacionamentos em que o número não precisa ser propagado globalmente.

A decisão deve fazer parte do projeto de rede, juntamente com plano de endereçamento, topologia, contratos de telecomunicações, rotas esperadas e responsabilidade operacional.

eBGP e iBGP: qual é a diferença

eBGP (External BGP) estabelece sessões entre AS diferentes. É o caso típico da conexão entre uma empresa e seu provedor ou entre duas redes em peering.

iBGP (Internal BGP) estabelece sessões entre roteadores pertencentes ao mesmo AS para distribuir internamente as rotas BGP e preservar atributos necessários às políticas da borda.

Aspecto	eBGP	iBGP
Relação administrativa	AS diferentes	Mesmo AS
Uso típico	Provedor, trânsito, peering	Distribuição interna de rotas BGP
Papel principal	Troca de alcance entre domínios	Propagação de rotas BGP dentro do AS
Política	Importação e exportação explícitas	Política interna e propagação controlada
Escala	Relações externas	Pode exigir route reflectors em ambientes grandes

Em redes pequenas, dois roteadores de borda podem trocar informações diretamente. Em ambientes com muitos roteadores BGP, uma malha completa de iBGP deixa de escalar, e arquiteturas com route reflectors podem ser necessárias.

Como uma sessão BGP funciona

A sessão BGP depende inicialmente de conectividade IP entre os peers. Depois disso, os equipamentos estabelecem uma conexão TCP e percorrem a máquina de estados do protocolo até a sessão atingir o estado Established.

Os principais tipos de mensagem definidos pela especificação base incluem:

• OPEN: inicia a relação BGP, informa ASN, identificador e capacidades;
• UPDATE: anuncia novos prefixos ou retira rotas anteriormente anunciadas;
• KEEPALIVE: mantém a sessão ativa e confirma a recepção de informações;
• NOTIFICATION: sinaliza erros e encerra a sessão quando necessário.

O fato de a sessão estar Established não significa que o roteamento esteja correto. Uma sessão pode permanecer operacional enquanto recebe rotas indesejadas, anuncia prefixos errados ou seleciona caminhos incompatíveis com o objetivo de negócio. Por isso, estado de sessão é apenas um dos critérios de aceite.

RIBs e processo de decisão

Conceitualmente, o BGP trabalha com conjuntos de informações recebidas, selecionadas e destinadas à exportação. Políticas de importação determinam quais anúncios podem participar do processo de decisão; o processo de seleção determina o melhor caminho; políticas de exportação controlam o que será enviado a cada peer.

Essa separação é essencial para projeto e troubleshooting. Um prefixo pode ser recebido do provedor, porém rejeitado pelo filtro; pode ser aceito, mas perder na seleção; ou pode ser selecionado e ainda assim não ser exportado para determinado vizinho.

Principais atributos do BGP

O BGP é frequentemente descrito como um protocolo path-vector porque transporta informações sobre o caminho de AS e outros atributos usados para aplicar políticas.

AS_PATH

O AS_PATH registra a sequência de sistemas autônomos percorrida por um anúncio. Além de ajudar na prevenção de loops, é um atributo central para política e seleção de caminho.

Uma organização pode utilizar técnicas como AS-path prepending para tornar determinado anúncio menos atraente a redes externas. Isso, porém, não garante de forma absoluta a engenharia de tráfego de entrada: cada rede remota aplica sua própria política.

NEXT_HOP

O NEXT_HOP indica o próximo salto associado ao prefixo. Em projetos com iBGP, a alcançabilidade do NEXT_HOP precisa ser garantida pelo IGP ou por decisões explícitas de desenho. Problemas nessa relação são uma causa recorrente de rotas presentes na tabela BGP, porém inutilizáveis para encaminhamento.

LOCAL_PREF

O LOCAL_PREF é amplamente utilizado dentro de um AS para influenciar qual saída deve ser preferida. Valores maiores costumam representar maior preferência nos equipamentos que seguem o comportamento tradicional.

Ele é especialmente útil em redes multihomed, onde a organização deseja que o tráfego de saída utilize prioritariamente um provedor e mantenha outro como contingência ou caminho secundário.

MED

O MED (Multi-Exit Discriminator) pode sinalizar preferência entre múltiplos pontos de entrada para um AS vizinho. Seu efeito depende da política do peer; portanto, não deve ser tratado como mecanismo universal ou garantido de engenharia de tráfego.

Communities

BGP Communities permitem classificar rotas e transportar marcações utilizadas por políticas. Provedores podem oferecer comunidades específicas para alterar preferência, controlar propagação regional, acionar blackhole ou definir comportamentos de anúncio. Essas convenções precisam ser documentadas e validadas com o provedor, pois não são iguais entre operadores.

Seleção de caminho não é apenas escolher a menor rota

Protocolos IGP normalmente trabalham com métricas diretamente associadas ao custo interno. BGP combina atributos e política. Por isso, duas rotas para o mesmo prefixo podem ser avaliadas de maneira diferente mesmo que uma delas tenha menos saltos físicos.

Uma política corporativa pode preferir um link por contrato, capacidade, custo, latência, região, segurança ou criticidade. A lógica configurada precisa traduzir esses requisitos em atributos BGP de forma previsível.

Em projetos multioperadora, a decisão deve separar dois problemas:

1. tráfego de saída, sobre o qual a organização possui maior controle;
2. tráfego de entrada, que depende também das políticas das redes externas.

Essa diferença evita promessas de projeto impossíveis, como garantir determinado caminho de entrada apenas com uma alteração local.

Políticas de importação e exportação

Uma das regras mais relevantes do BGP moderno é não tratar a troca de rotas como implicitamente confiável. O RFC 8212 atualiza o comportamento esperado para eBGP e estabelece que rotas não devem ser utilizadas nem anunciadas quando não existe política explícita de importação ou exportação.

Em engenharia, isso se traduz em um princípio claro: cada sessão externa precisa saber exatamente o que pode receber e o que pode anunciar.

Filtros de prefixos

Filtros devem limitar anúncios aos blocos efetivamente esperados. Em uma sessão com cliente, por exemplo, o provedor deve conhecer os prefixos autorizados. Em uma sessão corporativa, a empresa precisa controlar quais rotas aceita e qual nível de tabela recebe.

Aceitar 0.0.0.0/0 pode ser correto quando o requisito é receber apenas default route. Aceitar tabela completa pode ser correto quando existem requisitos de seleção avançada, mas aumenta exigências de memória, CPU, convergência e operação.

Limites de prefixos

Maximum-prefix ou mecanismo equivalente reduz o impacto de uma quantidade inesperada de anúncios. O valor não deve ser escolhido arbitrariamente: precisa refletir a quantidade normal, margem de crescimento e comportamento planejado em contingência.

Políticas de anúncio

A exportação precisa impedir que a rede corporativa se transforme, por erro, em trânsito entre dois provedores. Em multihoming, uma configuração equivocada pode aprender rotas de um operador e anunciá-las ao outro, caracterizando route leak.

Multihoming: quando o BGP entrega valor real

O multihoming conecta uma organização a mais de um caminho externo. Entretanto, possuir dois links não garante alta disponibilidade. Os enlaces podem compartilhar operadora, rota física, duto, POP, energia, equipamento, AS de trânsito ou até o mesmo ponto de falha.

Um levantamento técnico e Due Diligence ajuda a verificar a condição real existente antes de projetar a arquitetura alvo, especialmente em ambientes onde documentação, contratos e topologia não representam mais a rede instalada.

Um provedor, dois enlaces

Dois circuitos do mesmo provedor podem melhorar disponibilidade local, mas a independência depende da arquitetura do operador. BGP pode ser utilizado para controlar caminhos, porém não corrige falta de diversidade física ou lógica.

Dois provedores diferentes

Com provedores distintos, BGP permite políticas independentes e reduz dependência de um único AS externo. Ainda assim, é necessário avaliar fibras, entradas prediais, POPs, last mile e upstreams compartilhados.

Prefixo próprio e independência de endereçamento

Quando a organização anuncia prefixos próprios por múltiplos provedores, a continuidade pode ser melhor do que em modelos dependentes de endereçamento fornecido pelo ISP. Isso exige governança de ASN, prefixos, filtros, registros e política de anúncios.

Rota default, rotas parciais ou tabela completa

A quantidade de rotas recebidas precisa ser uma decisão de projeto.

Modelo	Característica	Uso típico
Default route	Menor complexidade	Empresa com requisitos simples de saída
Rotas parciais	Visibilidade seletiva	Políticas específicas por destino/operadora
Tabela completa	Máxima informação de alcance	Redes com engenharia avançada e capacidade adequada

Receber tabela completa apenas porque a plataforma suporta BGP é um erro de especificação. A tabela amplia memória necessária, tempo de processamento, impacto de atualizações e complexidade de troubleshooting.

O requisito deve nascer de objetivos claros: escolha de trânsito por destino, operação como provedor, peering amplo, otimização multicarrier ou outra necessidade verificável.

Sumarização e agregação de rotas

CIDR permite representar blocos contíguos por prefixos e reduzir estado de roteamento por agregação. O RFC 4632 destaca a importância da agregação para escalabilidade do sistema global.

No projeto corporativo, sumarização precisa ser tratada desde o endereçamento IP e roteamento. Um plano de endereçamento fragmentado pode impedir agregações futuras e multiplicar anúncios desnecessários.

Agregar sem verificar alcance também é perigoso: o roteador pode anunciar um bloco maior do que os prefixos realmente disponíveis e atrair tráfego que será descartado internamente.

Segurança operacional do BGP

BGP depende de confiança explícita entre peers e de política. Segurança deve ser tratada em diferentes camadas: sessão, anúncios, origem, plataforma e gestão.

Proteção da sessão

A engenharia deve restringir quem pode estabelecer sessão, proteger o plano de controle, aplicar ACLs quando pertinente, limitar TTL em cenários compatíveis e utilizar os mecanismos de autenticação suportados pelas plataformas e pelo provedor.

Validação de anúncios

Filtros de prefixo, ASN esperado, maximum-prefix e política de importação/exportação compõem a barreira básica. Em ambientes conectados à Internet global, mecanismos de validação de origem e práticas de segurança de roteamento podem ampliar a proteção contra anúncios indevidos.

Gestão e hardening

A segurança do BGP não substitui o hardening dos equipamentos de rede. AAA, gestão segregada, SNMPv3, logs, backups de configuração, sincronismo, controle de mudanças e atualização de software continuam necessários.

Capacidade, convergência e desempenho

O projeto deve verificar se os roteadores suportam a quantidade de peers, rotas, atributos e políticas previstas. A capacidade nominal de encaminhamento não representa, sozinha, a capacidade do plano de controle.

Parâmetros importantes incluem:

• quantidade de rotas IPv4 e IPv6 suportadas;
• memória disponível para RIB/FIB;
• quantidade de peers;
• capacidade de processamento de atualizações;
• tempo de convergência em falha;
• suporte a BFD ou mecanismos equivalentes quando aplicáveis;
• comportamento durante manutenção e reinicialização;
• redundância de fontes, supervisores e enlaces;
• recursos de telemetria e logging.

O artigo sobre desempenho em redes de computadores complementa a análise ao tratar throughput, latência, perdas e comportamento da infraestrutura sob carga.

BGP e redundância: falhar rápido não é suficiente

Uma arquitetura redundante precisa detectar a falha, recalcular o caminho e manter os serviços dentro do tempo aceitável para a aplicação. Se a sessão BGP permanece estabelecida enquanto o caminho de dados falhou em outro ponto, a simples existência de dois peers não resolve o problema.

O desenho deve avaliar falha de interface, perda do circuito, falha do equipamento, falha do upstream, manutenção programada e perda parcial de serviços. Cada cenário precisa indicar estado esperado de sessão, mudança de rota, caminho resultante e impacto para usuário.

Protocolos, timers e mecanismos de detecção não devem ser reduzidos indiscriminadamente. Valores agressivos aumentam sensibilidade a instabilidades e podem gerar flapping. O critério correto nasce do SLA, do comportamento da operadora, das capacidades das plataformas e do perfil das aplicações.

Assimetria de tráfego e engenharia de entrada e saída

Em multihoming, o caminho de ida pode ser diferente do caminho de volta. Assimetria não é necessariamente uma falha, mas pode afetar firewalls stateful, NAT, inspeção de segurança, troubleshooting e medição.

Ao utilizar múltiplos firewalls ou bordas, a arquitetura precisa garantir que estados, rotas e políticas sejam compatíveis com os possíveis caminhos. A segmentação de rede e as zonas de segurança também precisam refletir a topologia externa.

Como documentar uma implementação BGP

A documentação deve permitir que outro profissional entenda não apenas a configuração, mas a intenção de cada política.

Um pacote técnico adequado costuma registrar:

1. diagrama lógico com ASNs, peers, interfaces e prefixos;
2. endereços das sessões e loopbacks;
3. prefixos autorizados para importação e exportação;
4. política de preferência por provedor;
5. atributos manipulados e objetivo de cada alteração;
6. comunidades recebidas ou enviadas;
7. limites de prefixos;
8. estratégia de sumarização;
9. dependências com IGP, firewall e NAT;
10. cenários de contingência;
11. plano de testes;
12. procedimento de rollback;
13. contatos e responsabilidade de cada operadora.

Essa documentação deve fazer parte do projeto de rede lógica e redes corporativas quando BGP for requisito da arquitetura.

Como testar e aceitar uma solução BGP

Aceite não deve se limitar ao comando que mostra a sessão Established. O teste precisa provar comportamento funcional e de contingência.

Teste	Evidência esperada
Estabelecimento de peer	Sessão correta, ASN e capacidades esperadas
Importação	Somente prefixos autorizados são aceitos
Exportação	Somente prefixos próprios/autorizados são anunciados
Preferência de saída	Tráfego utiliza o provedor previsto
Failover	Mudança para caminho alternativo dentro do critério definido
Retorno	Caminho principal é restaurado sem instabilidade indevida
Route leak	Rotas aprendidas de um provedor não são propagadas ao outro
Maximum-prefix	Proteção reage conforme política prevista
Logging	Eventos de sessão e política são registrados
Backup	Configuração e versão ficam preservadas

Em ambientes críticos, esses testes podem integrar atividades de comissionamento de equipamentos e recebimento técnico, com critérios previamente definidos no projeto.

Erros recorrentes em projetos BGP

Algumas falhas aparecem repetidamente porque o protocolo é tratado como tarefa de configuração, e não como decisão de arquitetura.

• habilitar BGP sem definir política de importação/exportação;
• anunciar prefixos mais amplos do que a rede consegue atender;
• receber tabela completa sem necessidade ou capacidade;
• não prever maximum-prefix;
• depender de um único ponto físico apesar de contratar dois links;
• usar prepending como se garantisse tráfego de entrada;
• não documentar comunidades do provedor;
• redistribuir BGP e IGP de forma indiscriminada;
• esquecer alcançabilidade de NEXT_HOP no iBGP;
• testar apenas estado de sessão;
• alterar timers sem plano de teste;
• não manter rollback e backup da configuração.

O efeito pode variar de uma simples preferência incorreta a indisponibilidade ampla ou propagação de rotas indevidas.

Quando usar BGP e quando evitar complexidade desnecessária

BGP é adequado quando existe uma necessidade de política entre domínios. Alguns sinais objetivos são:

• dois ou mais provedores independentes;
• ASN e prefixos próprios;
• necessidade de anunciar o mesmo bloco por caminhos distintos;
• peering com outras redes;
• necessidade de receber rotas além da default;
• engenharia de tráfego inter-AS;
• atuação como ISP, carrier, data center ou rede de grande porte.

Por outro lado, uma pequena empresa com um único provedor e sem requisitos de autonomia pode obter maior confiabilidade com uma arquitetura simples, rota default e redundância corretamente implementada. Complexidade sem requisito aumenta superfície de erro e custo operacional.

Como contratar um projeto de rede que envolve BGP

O escopo deve contratar resultado de engenharia, não apenas “configuração BGP”. O documento de contratação precisa indicar contexto, interfaces, entregáveis e critérios de aceite.

Um escopo robusto deve contemplar, quando aplicável:

• levantamento da topologia atual;
• análise dos contratos e handoffs dos provedores;
• requisitos de disponibilidade e desempenho;
• ASN e blocos IP;
• arquitetura alvo;
• desenho lógico e físico;
• política de importação e exportação;
• critérios de seleção de caminho;
• integração com IGP, firewall e NAT;
• filtros e segurança;
• dimensionamento dos roteadores;
• matriz de falhas;
• plano de migração;
• plano de testes;
• procedimento de rollback;
• documentação As-Built e backup de configuração.

Quando a implantação depende de plataformas Cisco ou de uma modernização mais ampla do ambiente, uma Consultoria Cisco para diagnóstico, projeto e modernização de redes pode apoiar a validação da arquitetura, capacidades das plataformas, políticas e estratégia de migração.

Considerações finais

BGP é um protocolo de política entre sistemas autônomos. Seu valor aparece quando a organização precisa controlar conectividade externa, operar múltiplos provedores, anunciar prefixos próprios ou participar de relações de trânsito e peering. A sessão BGP é apenas o mecanismo de troca; o projeto está nas decisões sobre o que aceitar, o que anunciar, qual caminho preferir, como limitar falhas e como provar o comportamento em contingência.

Uma implementação confiável combina arquitetura, endereçamento, capacidade, filtros, segurança, documentação e testes. Quanto maior a autonomia desejada pela organização, maior também a responsabilidade sobre governança e operação do roteamento.

Referências técnicas

[1] REKHTER, Y.; LI, T.; HARES, S. RFC 4271 — A Border Gateway Protocol 4 (BGP-4). IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4271.html

[2] MAUCH, J.; SNIJDERS, J.; HANKINS, G. RFC 8212 — Default External BGP (EBGP) Route Propagation Behavior without Policies. IETF, 2017. Disponível em: https://www.rfc-editor.org/rfc/rfc8212.html

[3] VOHRA, Q.; CHEN, E. RFC 6793 — BGP Support for Four-Octet Autonomous System (AS) Number Space. IETF, 2012. Disponível em: https://www.rfc-editor.org/rfc/rfc6793.html

[4] CISCO SYSTEMS. Campus LAN and Wireless LAN Solution Design Guide. Cisco Design Zone. Disponível em: https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-campus-lan-wlan-design-guide.html

Perguntas frequentes

O que é BGP?

BGP é o protocolo de roteamento usado para trocar informações de alcance entre Sistemas Autônomos. Ele permite anunciar prefixos IP e aplicar políticas para controlar quais rotas são aceitas, anunciadas e preferidas.

Qual é a diferença entre BGP e OSPF?

OSPF é um IGP usado principalmente dentro de um mesmo domínio administrativo. BGP é usado para política de roteamento entre Sistemas Autônomos e também pode distribuir internamente rotas externas via iBGP.

Uma empresa precisa de ASN próprio para usar BGP?

Não necessariamente. Há cenários em que a sessão é entregue com ASN privado ou modelo definido pelo provedor. ASN público torna-se relevante quando a organização precisa de identidade de roteamento própria, multihoming independente, prefixos próprios ou peering.

Ter dois links com BGP garante alta disponibilidade?

Não. Os links podem compartilhar operadora, fibra, POP, energia ou upstream. Alta disponibilidade exige diversidade física e lógica, políticas corretas, equipamentos redundantes e testes de falha.

É necessário receber a tabela completa da Internet?

Não. Muitas empresas operam adequadamente apenas com rota default ou conjunto parcial de rotas. Tabela completa só deve ser adotada quando houver requisito de engenharia e capacidade compatível no plano de controle.

O que deve ser testado no aceite de BGP?

Além da sessão Established, devem ser testados filtros de importação e exportação, preferência de caminhos, failover, retorno ao caminho principal, prevenção de route leak, limites de prefixos, logging e documentação.

Materiais técnicos complementares

Conteúdos principais sobre o tema

• Guia Completo sobre Arquitetura de Redes: topologias, projeto e infraestrutura
• Projeto de Rede: etapas, arquitetura e documentação técnica
• Arquitetura de Rede Corporativa: camadas, modelos e critérios de projeto
• Estruturas de Endereçamento e Roteamento em Redes IP

Conteúdos técnicos correlatos

• Segmentação de Rede: fundamentos, modelos e boas práticas
• Spanning Tree: STP, RSTP e MSTP
• LACP e Link Aggregation
• Hardening de switches Cisco

Serviços relacionados

• Projeto de Rede Lógica e Redes Corporativas
• Projeto de Telecomunicações
• Due Diligence Técnica de Engenharia
• Consultoria Cisco
• Comissionamento de Equipamentos