2

When a traceroute is initiated and receives an ICMP reply from the nodes, which interface

  1. should the be replying be from according to RFC 1812.
  2. they are actually replying from ingress (where they receive the packet) or egress (where the packet would have been sent out to - i.e. to the next node if ttl was higher)

Personal comments and research:

  1. According to a NANOG published slides, the RFC 1812 states that it should be the egress interface. I've read the ICMP section of RFC 1812 and could not find where it states that (I suspect my understanding of the terminology is off).
  2. I've read various routers (Junos, Cisco) reply from different interfaces, yet most reply form ingress (as stated by the NANOG slide 10).

I don't have a virtual Cisco lab nor do I think I have enough RAM to set up several VM routers in VirtualBox.

Community
  • 1
leviu
  • 23
  • 1
  • 5

1 Answers1

1

Hi I'm late but in the event you're still curious...

The quote from R Steenbergen's NANOG slide is correct. The behaviour is defined in Section 4.3.2.4 of RFC1812, which states:

the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted

Depending on one's Traceroute implementation, the response to a trace may be an ICMP Destination Unreachable (i.e. Unix-implemented traceroute) or an ICMP Time Exceeded (Windows-initiated traceroute). I believe this is covered in Steenbergen's presentation. Since neither of these sections make any provision for specifying source address of the ICMP response, we assume that Section 4.3.2.4 holds for these specific response types.

Picture this scenario and assume the following:

  1. Assume all links between circles (routers) are equal-cost layer-3 links (in particular, that the link between R1 and R2 is not a LAG/EtherChannel/etc)
  2. Routing within example network is such that packets go from Sender S to Receiver R over the lower path, and return via the higher path, in the directions indicated

The Traceroute under modern day implementations would look like this:

traceroute to R 
 1  A 0.329 ms  A 0.425 ms A 0.471 ms
 2  C 0.349 ms  C 0.435 ms C 0.473 ms
 3  F 0.359 ms  G 0.445 ms F 0.481 ms
 4  R 0.369 ms  R 0.455 ms R 0.491 ms

And the trace if routers were coded to the spec would look like this:

traceroute to R 
 1  B 0.329 ms  B 0.425 ms B 0.471 ms
 2  D 0.349 ms  E 0.435 ms D 0.481 ms
 3  H 0.369 ms  H 0.445 ms H 0.491 ms
 4  R 0.389 ms  R 0.455 ms R 0.496 ms

So in a more colloquial sense, modern implementations tell us how we reached a particular host. The original specification would tell us how we left a router, but would not tell us how we got there.

Note that we might think this would cause Ping to break, but the specification covers that case explicitly:

The IP source address in an ICMP Echo Reply MUST be the same as the
specific-destination address of the corresponding ICMP Echo Request
message.

In other words, for Ping, the ICMP Echo Reply source address shouldn't be an address associated with the egress interface as specified by Section 4.3.2.4, but should instead use a source address derived from the destination address of the original ICMP Echo Request.

Community
  • 1
Ron Arsenault
  • 26
  • 3
  • 1
    Well, it does answer the question in regards that the spec doesn't specify egress or ingress, but you seemed to have assumed in you example that it would just be opposite of the current implementation. (I love the example by the way). Also, the second to last node in the 2nd traceroute should be I not H. – leviu May 26 '16 at 13:15
  • "..the physical interface over which the ICMP message is transmitted" roundaboutly specifies Egress interface i.e. "do route lookup for src of probe, respond w/source IP of that interface" This lookup *may* return a result corresponding w/interface where probe arrived, in which case we get the 1st example *regardless* of implementation -- so the example doesn't assume opposite behavior. Rather, I define for illustrative purpose pathing path back to src which "takes the long way." It's why 2nd last hop is H; at that point, R3's best path to reach to S is via interface H, not interface I. – Ron Arsenault May 27 '16 at 17:57
  • 1
    Still confused. so the "over which the ICMP message is transmitted" is interpreted as "over which the ICMP message _would have been_ transmitted"? It could also be interpreted as "_was_ transmitted" just as easily... If I understood what you said about this part correctly, back to the 2nd example, we are transmitting to R, so from R3 the shortest path to R is via I not H (I am suspecting I misunderstood the first point hence I am missing this one too). – leviu May 28 '16 at 19:04
  • 1
    A literal reading of spec cannot interpret it as "was/would have." That would be like saying "use interface IP as src addr of ICMP response AFTER we send the packet," which doesn't make sense. The spec -which no one seems to implement - should be read as "if we need to send ICMP response, perform a lookup to find physical egress interface to destination, and use a src addr of that interface for our ICMP response." When I talk about R3, I refer to how it would respond to a trace from S. At hop #3, R3 needs to send ICMP to S; it would not send this response to R, so I does not come into play. – Ron Arsenault Jun 05 '16 at 07:17