What addresses do we see in traceroute
Hey. This is a short note about exactly what IP we see in your favorite tracert / traceroute, and how it depends on the label on the boxes in the hardware of your ISP and its upstream.
I think everyone knows that the router, as a rule, has multiple IP addresses (or at least more than 1). In the face of such diversity, the router is faced with a difficult choice: which of its IP addresses must be chosen as the source of the ICMP TTL Exceeded message, which is the basis for the trace output?
If you have never thought about this issue before, then here are some options that may come to mind first:
')
1. The IP address of the interface that was inbound for the original packet.
2. The IP address of the interface that should be outgoing for the original packet.
3. The IP address of the interface that will be outgoing for the ICMP message.
4. Lupback IP address.
If you still thought about this before, then do not rush to give a definite answer :)
To answer the question from the title of the publication, I put together such a lab in GNS3:
Some explanations for the topology:
1. Tracing will be done from PC1 to PC2.
2. Each router has a loopback type XXXX
3. OSPF Area 0 is running on all routers and all interfaces.
4. OSPF Interface Cost is distributed in such a way that traffic from any router to 60.0.0.0/24 (PC2 network) goes “vertically”, i.e. through the chain of remaining routers. Conversely, traffic up to 10.0.0.0/24 (PC1 network) from any router other than Cisco1 will go through SW1 (which corresponds to the network 123.0.0.0/24). Thus, we achieve a situation in which the incoming interface of the original packet and the outgoing interface of the ICMP message do not match.
Someone will say: why do we need such a far from reality topology, in my company all traffic goes in both directions strictly symmetrically.
Answer: For OSPF, this is really not the most typical situation, it was used solely to simplify the configuration. In reality, BGP is mainly responsible for the asymmetry of your traffic paths.
As you can see, Cisco and Juniper responded from the IP of the incoming interface, whereas Debian Linux and Mikrotik (having the same Linux in the roots of their operating system) responded from the IP interface that was outgoing for the ICMP packet (123.0.0.X).
Record Route for comparison:
The behavior of Linux and Mikrotik is explained in the RFC 1812 clause. This clause indicates that the source address of the ICMP message must be the address of the interface through which the ICMP packet is to be sent.
At the same time, industry giants such as Cisco and Juniper allow themselves to ignore the RFC directive, apparently relying on their not a lot of experience. Indeed, to observe in the trace the IP addresses of the interfaces through which the original packet must pass, in my opinion, seems to be a better solution than to detect in the same IP trace from subnets that, strictly speaking, have no direct relationship to the actual packet path.
I think everyone knows that the router, as a rule, has multiple IP addresses (or at least more than 1). In the face of such diversity, the router is faced with a difficult choice: which of its IP addresses must be chosen as the source of the ICMP TTL Exceeded message, which is the basis for the trace output?
If you have never thought about this issue before, then here are some options that may come to mind first:
')
1. The IP address of the interface that was inbound for the original packet.
2. The IP address of the interface that should be outgoing for the original packet.
3. The IP address of the interface that will be outgoing for the ICMP message.
4. Lupback IP address.
If you still thought about this before, then do not rush to give a definite answer :)
To answer the question from the title of the publication, I put together such a lab in GNS3:
Some explanations for the topology:
1. Tracing will be done from PC1 to PC2.
2. Each router has a loopback type XXXX
3. OSPF Area 0 is running on all routers and all interfaces.
4. OSPF Interface Cost is distributed in such a way that traffic from any router to 60.0.0.0/24 (PC2 network) goes “vertically”, i.e. through the chain of remaining routers. Conversely, traffic up to 10.0.0.0/24 (PC1 network) from any router other than Cisco1 will go through SW1 (which corresponds to the network 123.0.0.0/24). Thus, we achieve a situation in which the incoming interface of the original packet and the outgoing interface of the ICMP message do not match.
Someone will say: why do we need such a far from reality topology, in my company all traffic goes in both directions strictly symmetrically.
Answer: For OSPF, this is really not the most typical situation, it was used solely to simplify the configuration. In reality, BGP is mainly responsible for the asymmetry of your traffic paths.
Run tracing
As you can see, Cisco and Juniper responded from the IP of the incoming interface, whereas Debian Linux and Mikrotik (having the same Linux in the roots of their operating system) responded from the IP interface that was outgoing for the ICMP packet (123.0.0.X).
Record Route for comparison:
Conclusion
The behavior of Linux and Mikrotik is explained in the RFC 1812 clause. This clause indicates that the source address of the ICMP message must be the address of the interface through which the ICMP packet is to be sent.
At the same time, industry giants such as Cisco and Juniper allow themselves to ignore the RFC directive, apparently relying on their not a lot of experience. Indeed, to observe in the trace the IP addresses of the interfaces through which the original packet must pass, in my opinion, seems to be a better solution than to detect in the same IP trace from subnets that, strictly speaking, have no direct relationship to the actual packet path.
Source: https://habr.com/ru/post/329244/
All Articles