Neste tutorial, utilizaremos o cenário onde o Router R9 não consegue pingar o destino 10.4.4.4. Veja um resumo da topologia relevante:

• R9 (AS 819): O roteador que inicia o ping, com interface 68.0.0.1 conectada ao R6.

• R6 (AS 600): Roteador de trânsito, conectado ao R9 via 68.0.0.2 e ao R4 via 46.0.0.2. É um roteador de borda entre o AS 819 e o AS 12345.

• R4 (AS 12345): Roteador onde reside o destino 10.4.4.4 (interface Loopback0). Conectado ao R6 via 46.0.0.1.

O Problema Inicial:

Apesar de ter uma rota BGP válida apontando para o Router R6 como Next Hop, o R9 não conseguia pingar 10.4.4.4. Curiosamente, o R6 conseguia pingar o destino sem problemas. Isso nos diz que o problema não é a rota em si no R6, mas algo no caminho entre R9 e 10.4.4.4 que passa por R6, ou no caminho de retorno.

Vamos aos comandos!

Passo 1: Verificação Inicial no Roteador com Falha (R9)

O ponto de partida é sempre o roteador que está apresentando a falha de conectividade.

1. Verificar a Conectividade Básica ao Next Hop:

   • Comando: R9# ping <ip_do_next_hop>

   • No nosso caso: R9# ping 68.0.0.2 (IP da interface do R6 conectada ao R9)

   • Para que serve: Este comando verifica a conectividade IP básica (camada 3) entre o R9 e o seu Next Hop para a rota em questão. Uma falha aqui indica um problema de conectividade direta que precisa ser resolvido antes de investigar o BGP.

   • Exemplo de Saída (Sucesso):

R9# ping 68.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 68.0.0.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

1. • • Interpretação: Sucesso. R9 consegue se comunicar com R6.

2. Verificar a Tabela de Roteamento IP para o Destino:

   • Comando: R9# show ip route <ip_de_destino>

   • No nosso caso: R9# show ip route 10.4.4.4

   • Para que serve: Este comando exibe a entrada na tabela de roteamento IP para o destino que não está sendo alcançado. Ele mostra como o roteador pretende alcançar esse destino.

   • Exemplo de Saída (Sucesso):

R9#show ip route 10.4.4.4

Routing entry for 10.4.4.4/32

  Known via "bgp 819", distance 20, metric 0

  Tag 600, type external

  Last update from 68.0.0.2 00:00:23 ago

  Routing Descriptor Blocks:

  * 68.0.0.2, from 68.0.0.2, 00:00:23 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

2. • • Interpretação: R9 tem uma rota BGP (bgp 819) para 10.4.4.4/32, apontando para 68.0.0.2 (R6) como Next Hop. A rota é válida e externa.

3. Verificar a Tabela BGP para o Destino:

   • Comando: R9# show ip bgp <ip_de_destino>

   • No nosso caso: R9# show ip bgp 10.4.4.4

   • Para que serve: Este comando detalha a entrada BGP para o destino, incluindo o AS Path, o Next Hop, o Origin e outros atributos BGP.

   • Exemplo de Saída (Sucesso):

R9#show ip bgp 10.4.4.4

BGP routing table entry for 10.4.4.4/32, version 14

Paths: (1 available, best #1, table default)

  Advertised to update-groups:

    3

  Refresh Epoch 1

  600 12345

    68.0.0.2 from 68.0.0.2 (6.0.0.1)

    Origin IGP, localpref 100, valid, external, best

    rx pathid: 0, tx pathid: 0x0

3. • • Interpretação: Confirma que a rota 10.4.4.4/32 é recebida de 68.0.0.2 (R6, Router ID 6.0.0.1), tem AS-Path 600 12345, e é considerada a melhor (best).

4. Realizar um Traceroute para o Destino:

   • Comando: R9# traceroute <ip_de_destino>

   • No nosso caso: R9# traceroute 10.4.4.4

   • Para que serve: O traceroute rastreia o caminho que os pacotes tomam até o destino, mostrando cada "salto" (roteador) pelo qual passam. Isso ajuda a identificar em qual ponto a comunicação está falhando.

   • Exemplo de Saída (Problema Detectado):

R9# traceroute 10.4.4.4

Tracing the route to 10.4.4.4

  1 68.0.0.2 0 msec 0 msec 0 msec

  2  * * *

4. • • Interpretação: Pista Crucial! O traceroute alcança 68.0.0.2 (R6) com sucesso no primeiro salto, mas depois falha (* * *), indicando que o problema está no R6 ou após ele.

Passo 2: Investigação no Roteador de Trânsito (R6)

Como o traceroute parou no R6, o próximo passo é investigar este roteador.

1. Verificar a Conectividade ao Destino a partir do R6:

   • Comando: R6# ping <ip_de_destino>

   • No nosso caso: R6# ping 10.4.4.4 (vamos testar com a interface de saída para o R4)

   • Para que serve: Confirmar se o roteador de trânsito que anuncia a rota consegue alcançar o destino final.

   • Exemplo de Saída (Sucesso):

R6#ping 10.4.4.4 source 46.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:

Packet sent with a source address of 46.0.0.2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

1. • • Interpretação: Outra pista crucial! O R6 consegue pingar o destino 10.4.4.4. Isso sugere que o problema não é a rota do R6 para o destino, nem a conectividade com o R4. O problema está na comunicação via R6 do R9 para o destino, ou no retorno.

2. Verificar a Tabela de Roteamento IP do R6 para o Destino:

   • Comando: R6# show ip route <ip_de_destino>

   • No nosso caso: R6# show ip route 10.4.4.4

   • Para que serve: Verificar se o R6 tem uma rota ativa para o destino em sua tabela de roteamento IP e qual o Next Hop.

   • Exemplo de Saída (Sucesso):

R6#show ip route 10.4.4.4

Routing entry for 10.4.4.4/32

  Known via "bgp 600", distance 20, metric 0

  Tag 12345, type external

  Last update from 46.0.0.1 00:39:34 ago

  Routing Descriptor Blocks:

  * 46.0.0.1, from 46.0.0.1, 00:39:34 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

2. • • Interpretação: O R6 tem a rota BGP (bgp 600) para 10.4.4.4/32, apontando para 46.0.0.1 (R4). A rota está instalada na RIB (tabela de roteamento IP). Isso descarta o problema de synchronization ou a falta da rota na tabela IP do R6.

3. Verificar ACLs (Access Control Lists) nas Interfaces do R6:

   • Comando: R6# show ip access-lists

   • Para que serve: ACLs podem bloquear o tráfego. É importante verificar se há alguma ACL configurada globalmente.

   • Exemplo de Saída (Vazia):

R6#show ip access-lists

R6#

3. • • Interpretação: Nenhuma ACL globalmente configurada.

   • Comando: R6# show running-config interface <interface> (para as interfaces conectadas ao R9 e ao R4)

   • No nosso caso: R6# show running-config interface Ethernet0/2 e R6# show running-config interface Ethernet0/1

   • Para que serve: Verificar se alguma ACL está aplicada (ip access-group <nome_acl> in ou out) nas interfaces relevantes.

   • Exemplo de Saída (Sem ACLs):

R6#show running-config interface Ethernet0/2

interface Ethernet0/2

 ip address 68.0.0.2 255.255.255.252

end

R6#show running-config interface Ethernet0/1

interface Ethernet0/1

 ip address 46.0.0.2 255.255.255.252

end

3. • • Interpretação: Nenhuma ACL aplicada nas interfaces. Isso elimina ACLs no R6 como causa direta do problema.

Passo 3: Investigando o Roteamento de Retorno

Até agora, sabemos que:

• R9 consegue falar com R6.

• R6 consegue falar com 10.4.4.4.

• R6 tem a rota para 10.4.4.4 na sua RIB.

• Não há ACLs bloqueando o tráfego no R6.
  A falha do traceroute do R9 que parava em R6, e o sucesso do ping do R6 para o destino, fortemente indicam um problema no roteamento de retorno. Ou seja, os pacotes chegam ao destino, mas a resposta não sabe como voltar para o R9.

1. Verificar a Conectividade do Roteador do Destino (R4) de Volta para a Rede do R9:

   • Comando: R4# ping <ip_da_interface_do_R9>

   • No nosso caso: R4# ping 68.0.0.1

   • Comando: R4# ping <ip_da_interface_do_R6_conectada_ao_R9>

   • No nosso caso: R4# ping 68.0.0.2

   • Para que serve: Este é o teste crucial. Ele verifica se o roteador onde o destino está localizado (R4) consegue alcançar a rede de onde o ping original foi enviado (68.0.0.0/30, onde R9 está).

   • Exemplo de Saída (Falha - Problema Encontrado!):

R4#ping 68.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 68.0.0.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R4#ping 68.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 68.0.0.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

1. • • Interpretação: ACHAMOS O PROBLEMA! O R4 não consegue pingar a rede 68.0.0.0/30 (nem R9, nem R6 nessa interface). Isso significa que, mesmo que o ping do R9 chegue a 10.4.4.4 (no R4), o R4 não sabe para onde enviar a resposta para que ela volte para o R9.

2. Verificar a Tabela de Roteamento do Roteador do Destino (R4) para a Rede do R9:

   • Comando: R4# show ip route 68.0.0.0 255.255.255.252

   • Para que serve: Confirmar a ausência da rota de retorno.

   • Resultado Esperado: Nenhuma entrada para 68.0.0.0/30 na tabela de roteamento do R4.

Passo 4: Solução - Anunciando a Rede de Retorno via BGP

O problema é que o R4 (AS 12345) não tem conhecimento de como chegar à rede 68.0.0.0/30 (AS 819). A solução é instruir o R6 (AS 600) a anunciar essa rede diretamente conectada via BGP para seus vizinhos (incluindo R4).

• Comando no R6:

R6(config)# router bgp 600

R6(config-router)# network 68.0.0.0 mask 255.255.255.252

R6(config-router)# end

R6# write memory

• • Para que serve: O comando network dentro da configuração BGP instrui o roteador a anunciar a rede especificada (se estiver em sua tabela de roteamento IP como diretamente conectada ou via um IGP) para todos os vizinhos BGP configurados nesse roteador. Ao anunciar a rede 68.0.0.0/30 (que está diretamente conectada ao R6) pelo R6, o R4 (que é um vizinho eBGP do R6) aprende essa rota.

Passo 5: Verificação Final - A Solução em Ação!

Após aplicar a configuração no R6, volte aos roteadores para verificar a conectividade e o roteamento.

1. Verificar se R4 agora conhece a Rota de Retorno:

   • Comando: R4# ping 68.0.0.2

   • Exemplo de Saída (Sucesso):

R4#ping 68.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 68.0.0.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

1. • Interpretação: R4 agora consegue se comunicar com a interface de R6 na rede 68.0.0.0/30. Isso significa que ele tem uma rota para lá.

   • Comando: R4# show ip route 68.0.0.0 255.255.255.252

   • Resultado Esperado: Uma entrada BGP para a rede 68.0.0.0/30.

R4#show ip route 68.0.0.0 255.255.255.252

Routing entry for 68.0.0.0/30

  Known via "bgp 12345", distance 20, metric 0

  Tag 600, type external

  Last update from 46.0.0.2 00:00:15 ago

  Routing Descriptor Blocks:

  * 46.0.0.2, from 46.0.0.2, 00:00:15 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

1. • • Interpretação: Confirmado! R4 aprendeu a rota para 68.0.0.0/30 via BGP do R6 (46.0.0.2).

2. Verificar a Conectividade Final do R9:

   • Comando: R9# ping 10.4.4.4

   • Exemplo de Saída (Sucesso!):

R9#ping 10.4.4.4 repeat 10

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 1/1/1 ms

2. • • Interpretação: SUCESSO! O ping de R9 para 10.4.4.4 agora funciona perfeitamente.

   • Comando: R9# traceroute 10.4.4.4

   • Resultado Esperado: O traceroute agora deve alcançar o destino, mostrando todos os saltos.

Conclusão:

Este tutorial demonstrou a importância de uma abordagem sistemática para diagnosticar problemas de conectividade em redes BGP. Começando pelo roteador com falha, investigando o caminho do tráfego com o traceroute e, crucialmente, verificando o roteamento de retorno, conseguimos identificar e solucionar um problema que parecia ter várias causas. A chave para o sucesso muitas vezes reside em analisar todas as partes envolvidas no caminho da comunicação, garantindo que o tráfego possa fluir em ambas as direções.

Esperamos que este tutorial detalhado, com exemplos de comandos e saídas, seja útil para você em suas futuras atividades de troubleshooting BGP! Compartilhe suas experiências e dúvidas nos comentários abaixo!