Agora ping é ótimo para testar como um exemplo se
eu pingar 10. 1 1 2 o ping é
bem-sucedido porque o primeiro ping falhou é devido ao ARP
que o roteador precisa para o ARP para o endereço MAC do roteador 2,
mas observe se eu pingar 10. 1 2 2, que é o endereço
IP do roteador 3, os pings falham porque essa rota não está na tabela de roteamento.
10 1 2 0 não está na tabela de roteamento do roteador local.
10 1 1 0 está na tabela de roteamento local.
para que o roteador possa
rotear adequadamente agora os debugs são muito úteis para testes e
solução de problemas e neste exemplo, vou usar um comando debug
ip icmp no roteador 2 e no roteador 3 apenas para provar que o tráfego está
chegando como esperado nos roteadores corretos .
então pingue 10. 1 1 2 este aviso de endereço IP, vemos
as respostas de eco ICMP enviadas de volta para 10. 1 1 1 vamos fazer
isso então 10. 1 2 2 o tráfego não alcança esse roteador, não
vemos nenhuma saída na tela do roteador 3, onde é só
fazer novamente para 10. 1 1 2 vemos o
debuga porque o tráfego está sendo enviado do roteador 1 para o roteador 2 e está sendo recebido pelo
roteador 2 que, por sua vez, está respondendo de volta.
Então, no roteador 1, podemos usar o comando debug ip packet, tenha
cuidado com este comando em um ambiente ao vivo.
Em um ambiente ao vivo, você deseja usar uma lista
de controle de acesso para limitar o tráfego que está depurando em um ambiente de
produção ou ao vivo, pode matar seu roteador se executar este comando.
Mas neste ambiente ao vivo, tudo bem.
Então, de um ponto de vista de teste e solução de problemas, vamos trabalhar
com a lógica no roteador 1, tentamos
fazer o ping 10. 1 2 2 nós não
estamos recebendo uma resposta nós executamos um depurador IP ICMP no roteador
3 para ver se o tráfego está realmente chegando
ao roteador 3 e não é, isso é útil porque pings enviam tráfego e
então esperam responder e isso
permitiria checar se o problema está no caminho R1 para R3 ou se o
problema está no retorno R3 para R1, então este
é um ótimo comando para
testar so ping 10. 1 2 2 aviso na saída que estamos ficando irromper o roteador local está nos
dizendo que o endereço IP de origem 10. 1 1 1 indo para o
destino 10. 1 2 2 não pode ser
roteado, por isso não sabe para onde encaminhar o tráfego.
Outra grande coisa na saída aqui é que
sabemos qual interface o roteador está usando para enviar pacotes tipicamente
um roteador usa a interface de saída como
a fonte em pacotes e você pode ver isso aqui.
então a fonte do ping é 10. 1 1 1 porque
essa é a interface de saída para chegar a um destino
como 10. 1 2 2 como
exemplo, se pingarmos 10. 1 1 2 o ping é bem-sucedido,
obtemos bastante saída, rolando de volta,
há o ping, são as mensagens de sucesso que podemos ver que o endereço IP de
origem é 10. 1 1 1 destino
é 10. 1 1 2 este
endereço IP e este foi encaminhado através da base de informações de encaminhamento ou FIB de F0 / 0 para o pacote
foi enviado e, em seguida, recebemos
uma resposta de 10. 1 1 2 indo para 10. 1 1 1 então aqui
podemos ver que o pacote foi encaminhado para
fora do roteador ou enviado pelo roteador e aqui podemos ver uma resposta do roteador 2.
Então, um comando muito útil, mas mais uma vez, tenha cuidado ao usá-lo na produção. Sh ip route me mostra
que eu não tenho uma rota na
tabela de roteamento para 10. 1 2 0 e eu também
não tenho um gateway de última instância, em outras
palavras, eu não tenho um gateway padrão ou uma
rota padrão configurada neste roteador.
Portanto, o roteador não sabe o que
fazer com o tráfego e, portanto, quando fazemos o ping no roteador, informamos que o tráfego não é roteável.
O roteador não sabe para onde
encaminhar o tráfego, por isso precisamos configurar rotas estáticas.