nesse caso, há dois saltos vizinhos na mesma sub-rede em uma saída de traceroute? Como eu sei, devem ser apenas endereços de origem e cada interface do roteador deve estar em uma 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
Deveria 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 Router2 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?
Responder1
cada interface do roteador deve estar em uma sub-rede diferente?
O erro na sua lógica reside na suposição de que as topologias de rede sempre envolvem roteadores que passam estritamente os 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 SOHO comuns e de médias empresas, não é o casoapenaspossível modo de implantação disponível. Os engenheiros de rede podem ter motivos para adotar outra abordagem ou, por sorte e alterações na configuração, podem fazer com que uma seja adotada acidentalmente.
Existem vários cenários em que um roteador pode receber pacotes que são posteriormente roteados de volta para a mesma rede em que foram recebidos. É importante como e com referência a qual dispositivo definimos nossas sub-redes. Por exemplo, é totalmente legal que um roteador tenha uma interface de 10.0.0.1/16, enquanto os dispositivos localizados atrás dele usam endereços na sub-rede 10.0.x.y/24. Da perspectiva do dispositivo, os pacotes de 10.0.1.x a 10.0.2.x precisariam passar por um ou mais roteadores, mas o roteador sabe disso. Este fenômeno detrombonagem em 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 VPN, que encapsula seu tráfego pela VPN para o dispositivo remoto. Se supormos que esta foi a causa da saída do traceroute, o .14dispositivo provavelmente seria o concentrador conectado à LAN corporativa na extremidade remota. O .15dispositivo é o roteador da rede à qual o concentrador está conectado. Os pacotes são recebidos (encaixados em túnel) na .14interface e retornados pela mesma interface para serem roteados até seu destino. Não há nada de errado com isso e traceroutemostra legitimamente as identidades de todos os dispositivos responsáveis por tocar os pacotes na camada IP.
Sem um conhecimento mais preciso da topologia da rede e, em particular, da configuração do(s) roteador(es) intermediário(s), é impossível entender precisamente o que está acontecendo no seu caso.
Responder2
O Traceroute funciona enviando efetivamente um ping com um TTl (time to live) de 1. Ele atinge o primeiro roteador que responde com uma mensagem ICMP Time Exceeded. Ele repete isso, no seu caso um total de 3 vezes.
Em seguida, ele envia 3 pings com TTL de 2, depois 3, etc. Ele exibe a resposta de cada roteador como uma rota para o host.
https://en.wikipedia.org/wiki/Traceroute
Meu primeiro palpite é que, se o seu sistema estiver configurado corretamente, seu primeiro roteador (que está configurado para não enviar a mensagem Time Exceeded) terá um caminho padrão para 10.10.0.14, que possui uma rota estática declarada para a sub-rede 194.221.100.49.