Hoje, discutiremos o protocolo BGP. Não vamos nos alongar sobre sua finalidade e por que ele é utilizado como o único protocolo. Existem muitas informações sobre isso, por exemplo .
Então, o que é BGP? BGP é um protocolo de roteamento dinâmico, sendo o único protocolo EGP (External Gateway Protocol). Este protocolo é usado para construir roteamento na internet. Vamos analisar como a vizinhança é formada entre dois roteadores BGP.
Vamos considerar a vizinhança entre o Router1 e o Router3. Vamos configurá-los com 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 10Vizinhança dentro de um único sistema autônomo — AS 10. Após a introdução dos dados no roteador, por exemplo, no Router1, esse roteador tentará estabelecer relações de vizinhança com o roteador Router3. O estado inicial, quando nada acontece, é chamado de Idle. Assim que o BGP for configurado no Router1, ele começará a escutar a porta TCP 179 — mudará para o estado Conectar, e quando tentar abrir uma sessão com o Router3, mudará para o estado Active.
Depois que a sessão for estabelecida entre Router1 e Router3, ocorrerá a troca de mensagens Open. Quando essa mensagem for enviada pelo Router1, esse estado será chamado de Open Sent. E quando receber a mensagem Open do Router3, ele mudará para o estado Open Confirm. Vamos analisar mais detalhadamente a mensagem Open:
Nesta mensagem, são transmitidas informações sobre o próprio protocolo BGP que o roteador está utilizando. Ao trocar mensagens Open, Router1 e Router3 informam um ao outro sobre suas configurações. Os seguintes parâmetros são transmitidos:
- Versão: isso inclui a versão do BGP que o roteador está usando. A versão atual do BGP é a versão 4, que é descrita na RFC 4271. Dois roteadores BGP tentarão negociar uma versão compatível; quando há uma incompatibilidade, não haverá sessão BGP.
- My AS: isso inclui o número AS do roteador BGP. Os roteadores terão que concordar sobre o(s) número(s) AS e também define se eles estarão executando iBGP ou eBGP.
- Hold Time: se o BGP não receber nenhuma mensagem de keepalive ou update do outro lado durante a duração do hold time, então declarará o outro lado como 'morto' e encerrará a sessão BGP. Por padrão, o hold time é definido como 180 segundos em roteadores Cisco IOS, e a mensagem de keepalive é enviada a cada 60 segundos. Ambos os roteadores devem concordar com o hold time ou não haverá sessão BGP.
- BGP Identifier: este é o ID do roteador BGP local, que é eleito como o OSPF faz:
- Use o router-ID que foi configurado manualmente com o comando bgp router-id.
- Use o maior endereço IP em uma interface de loopback.
- Use o maior endereço IP em uma interface física.
- Optional Parameters: aqui você encontrará algumas capacidades opcionais do roteador BGP. Este campo foi adicionado para que novos recursos possam ser incorporados ao BGP sem a necessidade de criar uma nova versão. Coisas que você pode encontrar aqui são:
- suporte para MP-BGP (Multi Protocol BGP).
- suporte para Route Refresh.
- suporte para números AS de 4 octetos.
Para estabelecer vizinhança, é necessário atender às seguintes condições:
- Número da versão. A versão atual é 4.
- O número AS deve coincidir com aquele que você configurou neighbor 192.168.13.3 remote-as 10.
- O Router ID deve ser diferente do do vizinho.
Se algum dos parâmetros não atender a essas condições, o roteador enviará Notification uma mensagem indicando o erro. Após o envio e recebimento das mensagens Open, a relação de vizinhança muda para o estado ESTABELECIDO. Após isso, os roteadores podem trocar informações sobre rotas, fazendo isso através de Atualizar mensagens. Esta é a mensagem de Update que o Router1 envia para o Router3:
Aqui são especificadas as redes que o Router1 informa e os Path attributes, que são análogos a métricas. Discutiremos os Path attributes com mais detalhes. Também dentro da sessão TCP, são enviados mensagens Keepalive. Elas são enviadas, por padrão, a cada 60 segundos. Este é o Keepalive Timer. Se durante o Hold Timer não for recebido um Keepalive, isso significa perda de conexão com o vizinho. Por padrão, ele é igual a 180 segundos.
Tabela útil:
Parece que entendemos como os roteadores trocam informações entre si, agora tentaremos entender a lógica de funcionamento do protocolo BGP.
Para anunciar uma rota em uma tabela BGP, assim como nos protocolos IGP, usa-se o comando network, mas a lógica de funcionamento é diferente. Se no IGP, após a especificação da rota no comando network, o IGP verifica quais interfaces pertencem a essa sub-rede e inclui-as na sua tabela, o comando network no BGP verifica a tabela de roteamento e procura uma correspondência exata com a rota no comando network. Se uma correspondência for encontrada, essas rotas serão adicionadas à 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 equivalente NLRI na tabela BGP local.
Agora vamos ativar o BGP em todos os demais e ver como a escolha de rotas ocorre dentro de um único AS. Depois que o roteador BGP receber as rotas do vizinho, começa a seleção da rota otimizada. É preciso entender que tipos de vizinhos podem existir — internos e externos. O roteador, pela configuração, entende se o vizinho configurado é interno ou externo? Se no comando:
neighbor 192.168.13.3 remote-as 10 o parâmetro remote-as especifica o AS que está configurado no próprio roteador no comando router bgp 10. As rotas recebidas do AS interno são consideradas internas, enquanto as rotas do externo são, por sua vez, externas. E, em relação a cada uma, uma lógica diferente de recebimento e envio é aplicada. Vamos considerar a seguinte topologia:
Em cada roteador, uma interface loopback está configurada com ip: x.x.x.x 255.255.255.0 — onde x é o número do roteador. No Router9, temos uma interface loopback com o endereço — 9.9.9.9 255.255.255.0. Nós iremos anunciar isso pelo BGP e veremos como ele se propaga. Esta rota será enviada para o Router8 e Router12. Do Router8, essa rota chegará ao Router6, mas não aparecerá na tabela de roteamento do Router5. Da mesma forma, no Router12, essa rota aparecerá na tabela, mas no Router11 também não estará. Vamos tentar entender isso. Vamos ver que dados e parâmetros o Router9 envia aos seus vizinhos informando sobre esta rota. O pacote abaixo será enviado do Router9 para o Router8.
As informações sobre a rota consistem em atributos de caminho (Path attributes).
Os atributos de caminho são divididos em 4 categorias:
- Well-known mandatory — todos os roteadores que operam com o protocolo BGP devem reconhecer esses atributos. Devem estar presentes em todas as atualizações (update).
- Well-known discretionary — todos os roteadores que operam com o protocolo BGP devem reconhecer esses atributos. Podem estar presentes nas atualizações (update), mas a presença deles não é obrigatória.
- Optional transitive — podem não ser reconhecidos por todas as implementações do BGP. Se um roteador não reconhecer um atributo, ele marca a atualização como parcial (partial) e a envia para os vizinhos, mantendo o atributo não reconhecido.
- Optional non-transitive — podem não ser reconhecidos por todas as implementações do BGP. Se um roteador não reconhecer um atributo, o atributo é ignorado e descartado ao ser enviado para os vizinhos.
Exemplos de atributos BGP:
- Well-known mandatory:
- Caminho do sistema autônomo
- Próximo salto
- Origem
- Well-known discretionary:
- Preferência local
- Agregado atômico
- Optional transitive:
- Agregador
- Comunidades
- Optional non-transitive:
- Discriminador de múltiplas saídas (MED)
- ID do Originador
- Lista de clusters
Neste caso, estaremos interessados em Origin, Next-hop, AS Path. Como a rota é transmitida entre Router8 e Router9, ou seja, dentro de uma mesma AS, ela é considerada interna e chamamos a atenção para o Origin.
O atributo Origin indica como a rota foi obtida na atualização. Os possíveis valores do atributo são:
- 0 — IGP: NLRI obtido dentro da AS original;
- 1 — EGP: NLRI aprendido pelo protocolo Exterior Gateway Protocol (EGP). Precursor do BGP, não é mais utilizado
- 2 — Incomplete: NLRI foi aprendida de outra forma
No nosso caso, como pode ser visto no pacote, é igual a 0. Quando essa rota for retransmitida para Router12, esse código terá o valor — 1.
Em seguida, Next-hop. O atributo Next-hop
- É o endereço IP do roteador eBGP, através do qual vai o caminho para a rede de destino.
- O atributo muda ao transferir o prefixo para outra AS.
No caso do iBGP, ou seja, dentro de uma mesma AS, o Next-hop será aquele que aprendeu ou informou sobre essa rota. No nosso caso, será 192.168.89.9. Mas quando essa rota for transmitida de Router8 para Router6, Router8 irá alterá-la e substituí-la pelo seu próprio. O Next-hop será — 192.168.68.8. Isso nos leva a duas regras:
- Se o roteador transmite a rota para seu vizinho interno, ele não altera o parâmetro Next-hop.
- Se o roteador transmite a rota para seu vizinho externo, ele altera o Next-hop para o IP da interface pela qual esse roteador transmite.
Isso nos leva à primeira questão: por que não haverá rota na tabela de roteamento no Router5 e Router11. Vamos considerar mais detalhadamente. Portanto, Router6 recebeu informações sobre a rota 9.9.9.0/24 e a adicionou à tabela de roteamento com sucesso:
Router6#show ip route bgp
Códigos: L - local, C - conectado, S - estático, R - RIP, M - móvel, B - BGP
D - EIGRP, EX - EIGRP externo, O - OSPF, IA - OSPF inter área
N1 - OSPF NSSA externo tipo 1, N2 - OSPF NSSA externo tipo 2
E1 - OSPF externo tipo 1, E2 - OSPF externo tipo 2
i - IS-IS, su - resumo IS-IS, L1 - IS-IS nível 1, L2 - IS-IS nível 2
ia - IS-IS inter área, * - candidato a padrão, U - rota estática por usuário
o - ODR, P - rota estática baixada periodicamente, H - NHRP, l - LISP
a - rota de aplicativo
+ - rota replicada, % - sobrescrever próximo salto, p - sobrescrever do PfR
O gateway de última instância não está configurado
9.0.0.0/24 está segmentado, 1 sub-rede
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Agora o Router6 passou a rota para o Router5 e a primeira regra de Next-hop não foi alterada. Ou seja, o Router5 deve adicionar <b>9.9.9.0 [20/0] via 192.168.68.8</b> , mas ele não tem uma rota até 192.168.68.8 e, portanto, esta rota não será adicionada, embora as informações sobre esta rota sejam armazenadas na tabela BGP:
<source><b>Router5#show ip bgp
A versão da tabela BGP é 1, o ID do roteador local é 5.5.5.5
Códigos de status: s suprimido, d amortecido, h histórico, * válido, > melhor, i - interno,
r falha no RIB, S Obsoleto, m multipath, b caminho de backup, f Filtro RT,
x melhor-externo, a caminho adicional, c RIB-comprimido,
Códigos de origem: i - IGP, e - EGP, ? - incompleto
Códigos de validação RPKI: V válido, I inválido, N Não encontrado
Rede Próximo Salto Métrica LocPrf Peso Caminho
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>A mesma situação ocorrerá entre Router11-Router12. Para evitar essa situação, é necessário configurar para que Router6 ou Router12, ao transmitir rotas para seus vizinhos internos, insiram seu próprio endereço IP como Next-hop. Isso é feito com o comando:
neighbor 192.168.56.5 next-hop-selfApós este comando, Router6 enviará uma mensagem de Update, onde para as rotas o endereço IP da interface Gi0/0 Router6 — 192.168.56.6 será indicado como Next-hop, depois disso essa rota já estará na tabela de roteamento.
Vamos em frente e vejamos se essa rota aparecerá no Router7 e no Router10. Ela não estará na tabela de rotas e poderíamos pensar que o problema é igual ao primeiro com o parâmetro Next-hop, mas se olharmos a saída do comando show ip bgp, veremos que essa rota não foi recebida mesmo com um Next-hop incorreto, o que significa que a rota não foi transmitida. E isso nos leva a existência de mais uma regra:
As rotas recebidas de vizinhos internos não são transmitidas a outros vizinhos internos.
Assim, como o Router5 recebeu a rota do Router6, essa informação não será passada a outro vizinho interno. Para que a transmissão aconteça, é necessário configurar a função , ou configurar relacionamentos de vizinhança totalmente conectados (Full Mesh), ou seja, Router5-7 cada um será vizinho de todos. Neste caso, vamos usar Route Reflector. No Router5 é necessário usar este comando:
neighbor 192.168.57.7 route-reflector-clientO Route Reflector altera o comportamento do BGP ao transmitir rotas a um vizinho interno. Se um vizinho interno for definido como route-reflector-client, essas rotas internas serão anunciadas para esses clientes.
A rota não apareceu no Router7? Não nos esqueçamos também do Next-hop. Após essas manipulações, a rota deveria estar no Router7, mas isso não ocorre. Isso nos leva a mais uma regra:
A regra next-hop aplica-se apenas a rotas externas. Para rotas internas, a substituição do atributo next-hop não ocorre.
E chegamos a uma situação em que é necessário criar um ambiente usando roteamento estático ou protocolos IGP para informar os roteadores sobre todas as rotas dentro do AS. Vamos definir rotas estáticas no Router6 e no Router7 e, depois disso, obteremos a rota desejada na tabela do roteador. No AS 678 faremos um pouco diferente – definiremos rotas estáticas para 192.168.112.0/24 no Router10 e 192.168.110.0/24 no Router12. Em seguida, estabeleceremos relações de vizinhança entre o Router10 e o Router12. Também configuraremos no Router12 para enviar seu next-hop para o Router10:
neighbor 192.168.110.10 next-hop-selfComo resultado, o Router10 receberá a rota 9.9.9.0/24, que será recebida tanto do Router7 quanto do Router12. Vamos ver qual escolha o Router10 fará:
Router10#show ip bgp
Versão da tabela BGP é 3, ID do roteador local é 6.6.6.6
Códigos de status: s suprimido, d amortecido, h histórico, * válido, > melhor, i - interno,
r falha RIB, S obsoleto, m multipath, b caminho de backup, f RT-Filter,
x melhor-external, a caminho-adicional, c RIB-comprimido,
Códigos de origem: i - IGP, e - EGP, ? - incompleto
Códigos de validação RPKI: V válido, I inválido, N Não encontrado
Rede Próximo Salto Métrica LocPrf Peso Caminho
*>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, existem duas rotas e a seta ( > ) indica que a rota através de 192.168.112.12 foi selecionada.
Vamos observar como ocorre o processo de seleção de rota:
- Primeiramente, ao receber uma rota, a disponibilidade de seu próximo salto é verificada. É por isso que, quando recebemos a rota no Router5 sem configurar o Next-hop-self, essa rota não foi encaminhada para processamento.
- Em seguida, vem o parâmetro Peso. Este parâmetro não é um Atributo de Caminho (PA) e não é transmitido nas mensagens BGP. Ele é configurado localmente em cada roteador e é utilizado apenas para manipular a escolha da rota no próprio roteador. Vamos considerar um exemplo. Um pouco acima, mostramos que o Router10 escolheu a rota para 9.9.9.0/24 através do Router12 (192.168.112.12). Para alterar o parâmetro Weight, pode-se usar route-map para definir para rotas específicas ou atribuir um peso ao vizinho com o comando:
neighbor 192.168.107.7 weight 200Agora todas as rotas desse vizinho terão esse peso. Vamos ver como a escolha da rota mudará após essa manipulação:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Configurado a partir da console pela console Versão da tabela BGP é 2, ID do roteador local é 6.6.6.6 Códigos de status: s suprimido, d amortecido, h histórico, * válido, > melhor, i - interno, r falha RIB, S obsoleto, m multipath, b caminho de backup, f RT-Filter, x melhor-external, a caminho-adicional, c RIB-comprimido, Códigos de origem: i - IGP, e - EGP, ? - incompleto Códigos de validação RPKI: V válido, I inválido, N Não encontrado Rede Próximo Salto Métrica LocPrf Peso Caminho *> 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iComo você pode ver, agora a rota escolhida é através do Router7, mas isso não terá efeito nos outros roteadores.
- Na terceira posição, temos a Preferência Local. Este parâmetro é um atributo discrecionário bem conhecido, o que significa que sua presença não é obrigatória. Este parâmetro só tem efeito dentro de uma única AS e influencia a escolha do caminho apenas para vizinhos internos. É por isso que ele é transmitido apenas em mensagens Update destinadas a vizinhos internos. Em mensagens Update para vizinhos externos, ele não está presente. Portanto, ele foi classificado como bem conhecido e discrecionário. Vamos tentar aplicá-lo no Router5. No Router5, devemos ter duas rotas para 9.9.9.0/24 — uma através do Router6 e outra através do Router7.
Vamos ver:
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 iMas como vemos, há uma rota através do Router6. E onde está a rota através do Router7? Será que não há nada no Router7? Vamos conferir:
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 iEstranho, parece que está tudo certo. Por que então não está sendo transmitido para o Router5? O motivo é que o BGP tem uma regra:
O roteador transmite apenas as rotas que ele mesmo utiliza.
O Router7 usa a rota através do Router5, portanto a rota através do Router10 não será transmitida. Vamos voltar à Preferência Local. Vamos configurar a Preferência Local no Router7 e ver como o Router5 reage 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 route-map que captura todas as rotas e dissemos ao Router7 para alterar o parâmetro Preferência Local para 250, que por padrão é 100. Vamos ver o que aconteceu no Router5:
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 iComo podemos ver, agora o Router5 prefere a rota através do Router7. A mesma situação ocorrerá no Router6, embora seja mais vantajoso para ele escolher a rota através do Router8. Também devemos acrescentar que a alteração desse parâmetro requer a reinicialização da vizinhança para que a modificação entre em vigor. Ler . Entendemos o Local Preference. Vamos para o próximo parâmetro.
- Preferência de rota com o parâmetro Next-hop 0.0.0.0, ou seja, rotas locais ou agregadas. Essas rotas recebem automaticamente, após o comando network, 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 parâmetro AS_Path mais curto é escolhido. Quanto menos AS um caminho atravessa, melhor ele é. Vamos considerar o caminho para 9.9.9.0/24 no Router10:
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 iComo você pode ver, o Router10 escolheu a rota através de 192.168.112.12 porque, para essa rota, o parâmetro AS_Path contém apenas 45, enquanto no outro caso contém 123 e 45. É intuitivo.
- O próximo parâmetro é o Origin. IGP (rota recebida através do BGP) é melhor que o EGP (rota recebida através do predecessor do BGP, atualmente não utilizado), e EGP é melhor que Incomplete? (recebida de outra forma, como, por exemplo, redistribuição).
- O próximo parâmetro é o MED. Tínhamos o Weight, que funcionava apenas localmente no roteador. Havia o Local Preference, que funcionava apenas dentro de um sistema autônomo. Como não é difícil de adivinhar, o MED é um parâmetro que será transmitido entre sistemas autônomos. É muito bom sobre esse parâmetro.
Mais atributos não serão usados, mas se duas rotas tiverem os mesmos, aplicam-se as seguintes regras:
- Escolher o caminho através do vizinho IGP mais próximo.
- Escolher a rota mais antiga para o caminho eBGP.
- Escolher o caminho através do vizinho com o menor BGP router ID.
- Escolher o caminho através do vizinho com o menor endereço IP.
Agora vamos considerar a questão da convergência do BGP.
Vamos ver o que acontece se o Router6 perder a rota 9.9.9.0/24 através do Router9. Desconectaremos a interface Gi0/1 do Router6, que imediatamente entenderá que a sessão BGP com o Router8 foi encerrada e o vizinho desapareceu, o que significa que a rota recebida dele não é mais válida. O Router6 enviará imediatamente mensagens Update, indicando a rede 9.9.9.0/24 no campo Withdrawn Routes. Assim que o Router5 receber essa mensagem, ele a enviará para o Router7. Mas como o Router7 tem uma rota através do Router10, ele responderá imediatamente com um Update contendo a nova rota. Se não for possível detectar a queda do vizinho pelo estado da interface, teremos que esperar pelo acionamento do Hold Timer.
Confederação.
Se você se lembra, falamos sobre como frequentemente precisamos usar uma topologia totalmente conectada. Com um grande número de roteadores em um único AS, isso pode criar grandes problemas, e para evitar isso, precisamos usar confederações. Um AS é dividido em vários sub-AS, o que permite que eles funcionem sem a necessidade de uma topologia totalmente conectada.
Aqui está o link para essa , e configuração para GNS3.
Por exemplo, com essa topologia, teríamos que conectar todos os roteadores no AS 2345 entre si, mas usando a Confederação, podemos estabelecer relações de vizinhança apenas entre os roteadores que estão diretamente conectados uns aos outros. Vamos falar sobre isso em detalhes. Se tivéssemos apenas o AS 2345, então laForge ao receber uma rota de Picard ele contaria aos seus roteadores Dados e Worf, mas eles não contariam ao roteador Crusher . Além disso, as rotas que o próprio roteador laForge, propaga não teriam sido transmitidas Crusher nem Worf-o, nem Dados.
Teríamos que configurar Route-Reflector ou relações de vizinhança totalmente conectadas. Dividindo um AS 2345 em 4 sub-AS (2, 3, 4, 5) para cada roteador, acabamos obtendo outra lógica de operação. Tudo isso está muito bem explicado .
Fontes:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Site
- Site .
Fonte: habr.com
