Traceroute pula na mesma sub-rede

Question

em qual caso há dois saltos vizinhos na mesma sub-rede em uma saída traceroute? Como eu sei, deve ser apenas endereços de origem e cada interface de roteador deve estar em sub-rede diferente?

Por exemplo:

1     *        *        *     Request timed out.
2     2 ms     3 ms    <3 ms  10.10.0.14
3     5 ms     4 ms     3 ms  10.10.0.15
4     21 ms    22 ms    25 ms  194.221.100.49

Deve ser algo assim.

(PC) 192.168.1.2 --- 192.168.1.1 (Router1) 10.10.0.X --- 10.10.0.14 (Router2) 10.10.0.x --- 10.10.0.15 (Router3) 192.221.100.X --- 192.221.100.49 (Router4) X.X.X.X

Mas no Roteador2 existem 2 interfaces na mesma sub-rede, o que não deveria ser possível?

Que tipo de configuração pode ser? Talvez Frame Relay?

    

Answer 1

each router interface should be in different subnet?

O erro em sua lógica reside no pressuposto de que as topologias de rede sempre envolvem roteadores que transmitem estritamente pacotes recebidos em uma interface em uma sub-rede por meio de uma interface definida em uma sub-rede diferente. Embora isso seja verdade em ambientes comuns de SOHO e de médias empresas, não é o apenas possível modo de implementação disponível. Engenheiros de rede podem ter razões para adotar outra abordagem, ou por sorte e churn de configuração, eles podem fazer com que um seja adotado acidentalmente.

Existem vários cenários nos quais um roteador pode receber pacotes que são subsequentemente roteados de volta para a mesma rede em que foram recebidos. Importa como e com referência a qual dispositivo definimos nossas sub-redes. Por exemplo, é totalmente legal para um roteador ter uma interface de 10.0.0.1/16 , enquanto os dispositivos sentados por trás dele usam endereços na sub-rede 10.0.x.y/24 . Do ponto de vista do dispositivo, os pacotes de 10.0.1.x a 10.0.2.x precisariam atravessar um ou mais roteadores, mas o roteador sabe melhor. Esse fenômeno de tromboneamento de rede é comumente encontrado no núcleo das redes corporativas. Embora não seja necessariamente eficiente, funciona e o roteador está fazendo seu trabalho corretamente.

Outra ocorrência comum ocorre ao executar um traceroute a partir de um dispositivo conectado a um concentrador de VPN, que encapsula seu tráfego pela VPN para o dispositivo remoto. Se supusermos que essa foi a causa de sua saída de traceroute, o dispositivo .14 provavelmente seria o concentrador conectado à LAN corporativa no terminal remoto. O dispositivo .15 é o roteador da rede à qual o concentrador está conectado. Os pacotes são recebidos (tunnelled) na interface .14 e retornam a mesma interface para serem roteados para o destino. Não há nada de errado com isso e traceroute está mostrando legitimamente as identidades de todos os dispositivos responsáveis por tocar os pacotes na camada IP.

Sem mais conhecimento preciso da topologia da rede e, em particular, a configuração do (s) roteador (es) intermediário (s), é impossível entender precisamente o que está ocorrendo no seu caso.

    

Answer 2

O traceroute funciona enviando um ping com um TTl (time to live) de 1. Ele atinge o primeiro roteador que responde com uma mensagem ICMP Time Exceded. Repete isso, no seu caso, um total de 3 vezes.

Em seguida, ele envia 3 pings com um TTL de 2, depois 3 etc. Ele exibe a resposta de cada roteador como uma rota para o host.

link

Meu primeiro palpite é que, se seu sistema estiver configurado corretamente, seu primeiro roteador (que está configurado para não enviar a mensagem de Tempo Excedido) tem um caminho padrão para 10.10.0.14 que tem uma rota estática declarada para a sub-rede 194.221.100.49