👦🏾 🤸🏿 🎮 Como o BGP funciona 🍯 🧝🏿 🍹

Hoje analisamos o protocolo BGP. Não falaremos por muito tempo por que é e por que é usado como o único protocolo. Muita informação está sobre este assunto, por exemplo aqui .

Então, o que é BGP? O BGP é um protocolo de roteamento dinâmico que é o único protocolo EGP (External Gateway Protocol). Este protocolo é usado para criar roteamento na Internet. Considere como a vizinhança entre dois roteadores BGP é construída.

Considere a vizinhança entre o Roteador1 e o Roteador3. Vamos configurá-los usando os seguintes comandos:

router bgp 10 network 192.168.12.0 network 192.168.13.0 neighbor 192.168.13.3 remote-as 10 router bgp 10 network 192.168.13.0 network 192.168.24.0 neighbor 192.168.13.1 remote-as 10

A vizinhança em um sistema autônomo é AS 10. Depois de inserir dados em um roteador, por exemplo, no roteador1, este roteador tenta estabelecer um relacionamento de vizinhança com o roteador3. O estado inicial quando nada acontece é chamado de inativo . Assim que o bgp estiver configurado no roteador1, ele começará a escutar a porta TCP 179 - entrará no estado Connect e, quando tentar abrir uma sessão com o roteador3, entrará no estado ativo .

Depois que a sessão é estabelecida entre o Roteador1 e o Roteador3, ocorre uma troca de mensagens aberta. Quando esta mensagem é enviada pelo Roteador1, esse estado será chamado de Aberto Enviado . E quando receber uma mensagem de abertura do roteador3, entrará no estado de confirmação de abertura . Considere a publicação aberta com mais detalhes:

Esta mensagem transmite informações sobre o protocolo BGP que o roteador usa. Ao trocar mensagens abertas, o Roteador1 e o Roteador3 comunicam informações sobre suas configurações entre si. Os seguintes parâmetros são passados:

Versão : inclui a versão BGP que o roteador está usando. A versão atual do BGP é a versão 4, descrita na RFC 4271. Dois roteadores BGP tentarão negociar uma versão compatível, quando houver uma incompatibilidade, não haverá sessão BGP.
Meu AS : inclui o número AS do roteador BGP, os roteadores terão que concordar com o (s) número (s) AS e também define se eles estarão executando o iBGP ou o eBGP.
Tempo de espera : se o BGP não receber nenhuma mensagem de keepalive ou atualização do outro lado durante o tempo de espera, ele declarará o outro lado 'morto' e interromperá a sessão do BGP. Por padrão, o tempo de espera é definido como 180 segundos nos roteadores Cisco IOS, a mensagem de manutenção da atividade é enviada a cada 60 segundos. Ambos os roteadores precisam concordar com o tempo de espera ou não haverá uma sessão BGP.
Identificador BGP : este é o ID do roteador BGP local, eleito exatamente como o OSPF:
Use o ID do roteador que foi configurado manualmente com o comando bgp router-id.
Use o endereço IP mais alto em uma interface de loopback.
Use o endereço IP mais alto em uma interface física.
Parâmetros opcionais : aqui você encontrará alguns recursos opcionais do roteador BGP. Este campo foi adicionado para que novos recursos pudessem ser adicionados ao BGP sem a necessidade de criar uma nova versão. As coisas que você pode encontrar aqui são:

suporte para MP-BGP (Multi Protocol BGP).
suporte para atualização de rota.
suporte para números AS de 4 octetos.

Para estabelecer um bairro, as seguintes condições devem ser atendidas:

Número da versão Versão atual 4.
O número do AS deve corresponder ao número configurado como vizinho 192.168.13.3 remoto como 10 .
O ID do roteador deve ser diferente do vizinho.

Se algum dos parâmetros não atender a essas condições, o roteador enviará uma mensagem de notificação onde indica um erro. Depois de enviar e receber mensagens abertas, o relacionamento de vizinhança entra no estado ESTABELECIDO . Depois disso, os roteadores podem trocar informações sobre rotas e fazer isso usando as mensagens de atualização . Aqui está uma mensagem de atualização que envia o roteador1 para o roteador3:

Aqui, indique as redes relatadas pelos atributos Router1 e Path, que são análogas às métricas. Falaremos sobre os atributos do caminho em mais detalhes. Além disso, as mensagens keepalive são transmitidas dentro da sessão TCP. Eles são transmitidos, por padrão, a cada 60 segundos. Este é um temporizador Keepalive. Se a mensagem Keepalive não for recebida durante o Hold Timer, isso significará perda de comunicação com o vizinho. Por padrão, é igual a - 180 segundos.

Prato útil:

Parece ter descoberto como os roteadores transmitem informações um para o outro, agora vamos tentar descobrir a lógica do protocolo BGP.

Para anunciar uma rota para a tabela BGP, como nos protocolos IGP, o comando network é usado, mas a lógica da operação é diferente. Se no IGP, depois de especificar uma rota no comando de rede, o IGP examina quais interfaces pertencem a esta sub-rede e as inclui em sua tabela, o comando de rede no BGP procura na tabela de roteamento e procura uma correspondência exata com a rota no comando de rede. Se estes forem encontrados, essas rotas cairão na tabela BGP.

Procure uma rota na tabela de roteamento IP atual do roteador que corresponda exatamente aos parâmetros do comando network; se a rota IP existir, coloque o NLRI equivalente na tabela BGP local.

Agora, aumentaremos o BGP para todos os demais e veremos como a rota é selecionada dentro de um AS. Depois que o roteador BGP recebe rotas do vizinho, a seleção da rota ideal começa. Aqui você precisa entender que tipo de vizinhos pode ser - interno e externo. O roteador de configuração entende se o vizinho configurado é interno ou externo? Se em uma equipe:

 neighbor 192.168.13.3 remote-as 10

como o parâmetro remote-as, o AS é especificado, configurado no próprio roteador no comando router bgp 10. As rotas que vêm do AS interno são consideradas internas e as rotas do AS externo são consideradas externas. E com relação a cada uma, uma lógica diferente de recebimento e envio de obras. Considere a seguinte topologia:

Cada roteador possui uma interface de loopback configurada com ip: xxxx 255.255.255.0 - em que x é o número do roteador. No roteador9, temos uma interface de loopback com o endereço - 9.9.9.9 255.255.255.0. O anunciaremos no BGP e veremos como é distribuído. Essa rota será transmitida ao roteador8 e ao roteador12. Com o Router8, essa rota irá para o Router6, mas no Router5 não estará na tabela de roteamento. Além disso, no roteador12, essa rota entra na tabela, mas no roteador11 também não será. Vamos tentar descobrir. Considere quais dados e parâmetros estão sendo transmitidos pelo roteador9 para seus vizinhos, relatando esta rota. O pacote abaixo será enviado do roteador9 para o roteador8.

As informações da rota consistem em atributos do caminho.

Os atributos do caminho são divididos em 4 categorias:

Obrigatório conhecido - Todos os roteadores BGP devem reconhecer esses atributos. Deve estar presente em todas as atualizações.
Bem conhecido discricionário - Todos os roteadores BGP devem reconhecer esses atributos. Eles podem estar presentes nas atualizações, mas sua presença não é necessária.
Transitivo opcional - pode não ser reconhecido por todas as implementações de BGP. Se o roteador não reconhecer o atributo, ele marcará a atualização como parcial e a enviará ainda mais aos vizinhos, preservando o atributo não reconhecido.
Não transitivo opcional - pode não ser reconhecido por todas as implementações de BGP. Se o roteador não reconhecer o atributo, ele será ignorado e descartado durante a transmissão aos vizinhos.

Exemplos de atributos BGP:

Obrigatório conhecido :
- Caminho do sistema autônomo
- Próximo salto
- Origem
Bem conhecido discricionário :
- Preferência local
- Agregado atômico
Transitivo opcional :
- Agregador
- Comunidades
Não transitivo opcional :
- Discriminador de múltiplas saídas (MED)
- ID do originador
- Lista de clusters

Nesse caso, estaremos interessados em Origin, Next-hop, AS Path. Como a rota passa entre o Roteador8 e o Roteador9, ou seja, dentro do mesmo AS, ela é considerada interna e prestaremos atenção ao Origin.

Atributo de origem - indica como a rota foi recebida na atualização. Possíveis valores de atributo:

0 - IGP: NLRI obtido dentro do sistema autônomo original;
1 - EGP: NLRI aprendido pelo Exterior Gateway Protocol (EGP). Predecessor BGP, não usado
2 - Incompleto: a NLRI foi aprendida de outra maneira

No nosso caso, como pode ser visto no pacote, é 0. Quando essa rota é transmitida ao roteador12, esse código terá o código - 1.

Próximo, salto seguinte. Atributo do próximo salto

Este é o endereço IP do roteador eBGP através do qual o caminho para a rede de destino percorre.
O atributo muda quando o prefixo é passado para outro AS.

No caso do iBGP, ou seja, dentro de um AS, o salto seguinte será indicado aquele que aprendeu ou contou sobre essa rota. No nosso caso, será 192.168.89.9. Mas quando ele transferir essa rota do roteador8 para o roteador6, o roteador8 irá alterá-lo e substituí-lo pelo seu. O próximo salto será - 192.168.68.8. Isso nos leva a duas regras:

Se o roteador passa a rota para seu vizinho interno, ele não altera o parâmetro Next-hop.
Se o roteador envia a rota para seu vizinho externo, ele altera o salto seguinte para o ip da interface da qual esse roteador envia.

Isso nos leva a entender o primeiro problema - Por que não haverá rota na tabela de roteamento no Router5 e Router11. Vamos considerar em mais detalhes. Portanto, o Router6 recebeu as informações de rota 9.9.9.0/24 e as adicionou à tabela de roteamento com segurança:

 Router6#show ip route bgp Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is not set 9.0.0.0/24 is subnetted, 1 subnets B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25

Agora o Router6 passou a rota do Router5 e não alterou a primeira regra do Próximo salto. Ou seja, o roteador5 deve adicionar 9.9.9.0 [20/0] via 192.168.68.8 , mas não possui uma rota para 192.168.68.8 e, portanto, essa rota não será adicionada, embora as informações sobre essa rota sejam armazenadas na tabela BGP:

 <b>Router5#show ip bgp BGP table version is 1, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>

A mesma situação ocorrerá entre o roteador11-roteador12. Para evitar tal situação, é necessário configurar para que o Roteador6 ou o Roteador12, passando a rota para seus vizinhos internos, substituam seu endereço IP como Próximo salto. Isso é feito usando o comando:

 neighbor 192.168.56.5 next-hop-self

Após esse comando, o roteador6 enviará uma mensagem de atualização, onde para as rotas como salto seguinte será indicado o ip da interface Gi0 / 0 do roteador6 - 192.168.56.6, após o qual essa rota já estará na tabela de roteamento.

Vamos em frente e ver se esta rota aparece no roteador7 e no roteador10. Ele não aparecerá na tabela de roteamento e podemos pensar que o problema é como o primeiro com o parâmetro Next-hop, mas se observarmos a saída do comando show ip bgp, veremos que a rota não foi recebida, mesmo com o Next-hop errado, o que significa que a rota nem foi transmitida. E isso nos levará à existência de outra regra:

As rotas recebidas de vizinhos internos não são transferidas para outros vizinhos internos.

Como o Router5 recebeu a rota do Router6, ele não será transmitido ao seu outro vizinho interno. Para que a transferência ocorra, você deve configurar a função Route Reflector ou configurar as relações de vizinhança totalmente conectadas (malha completa), ou seja, o roteador5-7 será vizinho de cada um. Usaremos o refletor de rota neste caso. No Router5, você deve usar este comando:

 neighbor 192.168.57.7 route-reflector-client

O Refletor de Rota altera o comportamento do BGP ao transmitir uma rota para um vizinho interno. Se o vizinho interno for especificado como cliente-refletor de rota , as rotas internas serão anunciadas para esses clientes.

A rota não apareceu no Router7? Não se esqueça do Next-hop também. Após essas manipulações, a rota também deve ser feita no roteador7, mas isso não acontece. Isso nos leva a outra regra:

A regra do próximo salto funciona apenas para rotas externas. Para rotas internas, o atributo do próximo salto não é substituído.

E temos uma situação em que você precisa criar um ambiente usando roteamento estático ou IGP para informar os roteadores sobre todas as rotas dentro do AS. Registraremos as rotas estáticas no Router6 e Router7 e, depois disso, obteremos a rota desejada na tabela do roteador. No AS 678, agiremos de maneira um pouco diferente - escreveremos as rotas estáticas para 192.168.112.0/24 no roteador10 e 192.168.110.0/24 no roteador12. Em seguida, estabelecemos o relacionamento de vizinhança entre o roteador10 e o roteador12. Também configuramos o Router12 para enviar o próximo salto para o Router10:

 neighbor 192.168.110.10 next-hop-self

O resultado será que o roteador10 receberá a rota 9.9.9.0/24, será recebido do roteador7 e do roteador12. Vamos ver que escolha o Router10 faz:

 Router10#show ip bgp BGP table version is 3, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.112.12 0 100 0 45 i 192.168.107.7 0 123 45 i

Como podemos ver, duas rotas e uma seta (>) significam que a rota através de 192.168.112.12 está selecionada.
Vamos ver como o processo de seleção de rota ocorre:

Antes de mais nada, após o recebimento da rota, a disponibilidade do seu salto seguinte é verificada. É por isso que, quando recebemos uma rota no Roteador5 sem definir o Next-hop-self, essa rota não foi enviada mais para processamento.
Em seguida é o parâmetro Weight. Este parâmetro não é um atributo de caminho (PA) e não é transmitido em mensagens BGP. Ele é configurado localmente em cada roteador e é usado apenas para manipular a seleção de rota no próprio roteador. Considere um exemplo. É mostrado acima que o Router10 escolheu a rota para 9.9.9.0/24 via Router12 (192.168.112.12). Para alterar o parâmetro Wieght, você pode usar o mapa de rotas para definir rotas específicas ou atribuir peso ao seu vizinho usando o comando:
```
  neighbor 192.168.107.7 weight 200 
```
Agora todas as rotas deste vizinho terão esse peso. Vamos ver como a escolha da rota muda após esta manipulação:
```
 Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Configured from console by console BGP table version is 2, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 i 
```
Como você pode ver, a rota através do roteador7 agora está selecionada, mas isso não terá nenhum efeito nos outros roteadores.
Em terceiro lugar, temos - Preferência Local. Este parâmetro é um atributo discricionário conhecido, o que significa que sua presença é opcional. Este parâmetro é válido apenas dentro de um AS e afeta a escolha do caminho apenas para vizinhos internos. Por isso, ele é transmitido apenas nas mensagens de Atualização destinadas ao vizinho interno. Em Mensagens de atualização para vizinhos externos, ele está ausente. Portanto, ele foi designado para o bem conhecido discricionário. Vamos tentar aplicá-lo no Router5. No roteador 5, devemos ter duas rotas para 9.9.9.0/24 - uma através do roteador6 e a segunda através do roteador7.

Nós olhamos:
```
 Router5#show bgp BGP table version is 2, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 
```
Mas como você pode ver uma rota através do roteador6. E onde é a rota através do Router7? Talvez nem exista no Router7? Nós olhamos:
```
 Router#show bgp BGP table version is 10, local router ID is 7.7.7.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 i 
```
Estranho, tudo parece estar em ordem. Por que não está sendo transmitido para o Router5? A questão é que o BGP tem uma regra:
O roteador transmite apenas as rotas que ele próprio usa.

O roteador7 usa a rota através do roteador5; portanto, a rota através do roteador10 não será transmitida. Voltar para a preferência local. Vamos definir a preferência local no roteador7 e ver como o roteador5 responde a isso:
```
 route-map BGP permit 10 match ip address 10 set local-preference 250 access-list 10 permit any router bgp 123 neighbor 192.168.107.10 route-map BGP in</b> 
```
Então, criamos um mapa de rota no qual todas as rotas se enquadram e pedimos ao Router7 para alterar o parâmetro de preferência local para 250 após o recebimento, por padrão, é 100. Vemos o que aconteceu no roteador5:
```
 Router5#show bgp BGP table version is 8, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 i 
```
Como vemos agora, o roteador5 prefere a rota pelo roteador7. A mesma imagem estará no roteador6, embora seja mais lucrativo para ele escolher uma rota através do roteador8. Também adicionamos que uma alteração nesse parâmetro requer uma reinicialização do bairro para que a alteração entre em vigor. Leia aqui . Com a preferência local resolvida. Vá para o próximo parâmetro.

Preferência de rota com o parâmetro 0.0.0.0 do próximo salto, ou seja, rotas locais ou agregadas. Após inserir o comando de rede, essas rotas recebem automaticamente o parâmetro Weight igual ao máximo - 32678:

 Router#show bgp BGP table version is 2, local router ID is 9.9.9.9 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 9.9.9.0/24 0.0.0.0 0 32768 i

O caminho mais curto através do AS. O menor parâmetro AS_Path está selecionado. Quanto menos a rota passar, melhor será. Considere a rota para 9.9.9.0/24 no roteador10:

 Router10#show bgp BGP table version is 2, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 9.9.9.0/24 192.168.107.7 0 123 45 i *>i 192.168.112.12 0 100 0 45 i

Como você pode ver, o Router10 escolheu a rota através de 192.168.112.12 porque o parâmetro AS_Path contém apenas 45 para esta rota e 123 e 45 no outro caso.

O próximo parâmetro é Origem. O IGP (rota obtida usando o BGP) é melhor que o EGP (rota obtida usando o BGP predecessor, agora não usado) e o EGP é melhor que o Incompleto? (recebido de alguma outra maneira, por exemplo, por redistribuição).
O próximo parâmetro é MED. Tínhamos o Wieght, que só funcionava localmente no roteador. Havia uma preferência local que funcionava apenas dentro de um sistema autônomo. Como você pode imaginar, o MED é um parâmetro que será transmitido entre sistemas autônomos. Muito bom artigo sobre esta opção.

Mais atributos não serão usados, mas se as duas rotas tiverem os mesmos atributos, as seguintes regras serão usadas:

Escolha um caminho através do vizinho IGP mais próximo.
Selecione a rota mais antiga para o caminho do eBGP.
Escolha um caminho através do vizinho com o menor ID do roteador BGP.
Escolha um caminho através do vizinho com o menor endereço IP.

Agora considere a questão da convergência BGP.

Vamos ver o que acontece se, por exemplo, o roteador6 perder a rota 9.9.9.0/24 através do roteador9. Desligamos a interface Gi0 / 1 Router6, que imediatamente entende que a sessão BGP com o Router8 está desconectada e o vizinho desapareceu, o que significa que a rota recebida dele não é válida. O roteador6 envia imediatamente as mensagens de atualização onde indica a rede 9.9.9.0/24 no campo Rotas retiradas. Assim que o Router5 receber uma mensagem semelhante, envie-a para o Router7. Mas como o Router7 possui uma rota através do Router10, ele envia imediatamente a Atualização com uma nova rota em resposta. Se a queda do vizinho não puder ser detectada pelo estado da interface, é necessário aguardar o tempo de espera para disparar.

Confederação.

Se você se lembra, falamos sobre o fato de você frequentemente precisar usar uma topologia totalmente conectada. Com um grande número de roteadores em um AS, isso pode causar grandes problemas; para evitar isso, é necessário usar confederações. Um AS é dividido em vários sub-ASs, o que permite que ele funcione sem a necessidade de uma topologia totalmente conectada.

Aqui está um link para este laboratório , e aqui está a configuração para o GNS3.

Por exemplo, com essa topologia, teríamos que conectar todos os roteadores no AS 2345, mas, usando a Confederação, podemos estabelecer relações de vizinhança apenas entre os roteadores conectados diretamente um ao outro. Vamos falar sobre isso em detalhes. Se tivéssemos apenas o AS 2345, laForge faria uma marcha de Picard para contar aos roteadores Data e Worf , mas eles não contariam a Crusher sobre isso . Além disso, as rotas que o próprio roteador rasprastranyaet Laforge , não seria transferida Crusher ouWorf , nem Data .

Eu teria que estabelecer um roteador-refletor ou um relacionamento de vizinhança totalmente conectado. Ao dividir um AS 2345 em 4 sub-ASs (2,3,4,5) para cada roteador, acabamos com uma lógica de operação diferente. Tudo está perfeitamente descrito aqui .

Fontes:

Guia Oficial de Certificação e Roteamento CCIE v5.0, Volume 2, Quinta Edição, Narbik Kocharians, Terry Vinson.
Site xgu.ru
Site GNS3Vault .

Como o BGP funciona

More articles: