Troubleshooting Asymmetrical Routing

Asymmetrical Routing (ASR) is a fancy way of saying that the packets are using different paths according to the direction of the traffic.If everything works as expected, you might not even realize that it’s happening (e.g the Internet). Imagine you had a ticket on the lab involving ASR, the first step to fixing the issue would be to understand how the traffic flows from host A to host B but how would you do it?. You are probably thinking of traceroute, but a regular traceroute only gives you the path used to reach the end host, not the path used by the return flow (let’s assume the ticket is on a Backbone device, so you couldn’t do a return trace).
The alternative is to use the record route option in IP.
From the RFC:

The record route option provides a means to record the route of an internet datagram.
When an internet module routes a datagram it checks to see if the record route option is present. If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route beginning at the byte indicated by the pointer, and increments the pointer by four.
If the route data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the address into the recorded route. If there is some room but not enough room for a full address to be inserted, the original datagram is considered to be in error and is discarded. In either case an ICMP parameter problem message may be sent to the source host.

Let’s lab it up. This is the topology we are going to be using:

We want to see the path that traffic from R1 lo0 takes to reach R4 lo0 and viceversa, let’s test the trace:

R1#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 10.1.3.3 256 msec 40 msec 56 msec
  2 10.3.4.4 132 msec *  8 msec

Ok, so it would seem that R1 goes to R3 and then R4. No info on the return path, let’s test the ping with the record route option:

R1#ping
Protocol [ip]:
Target IP address: 4.4.4.4
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 1.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (204 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (10.1.3.1)
   (10.3.4.3)
   (4.4.4.4)
   (10.2.4.4)
   (10.1.2.2)
   (1.1.1.1) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 1 (164 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (10.1.3.1)
   (10.3.4.3)
   (4.4.4.4)
   (10.2.4.4)
   (10.1.2.2)
   (1.1.1.1) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Success rate is 100 percent (2/2), round-trip min/avg/max = 164/184/204 ms

We can see that we have ASR because the traffic goes from R1 (10.1.3.1) to R3 (10.3.4.3) to R4 (4.4.4.4) and R4 (10.2.4.4) sends the reply via R2 (10.1.2.2) back to R1 (1.1.1.1).  It’s easier to see in the topology diagram (blue arrows)

With this information, we can take the appropriate measures to fix the ASR. In our case, simply change the default route on R4 (or R1).

R4(config)#no ip route 0.0.0.0 0.0.0.0
R4(config)#ip route 0.0.0.0 0.0.0.0 10.3.4.3

R1#ping
Protocol [ip]:
Target IP address: 4.4.4.4
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 1.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (36 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (10.1.3.1)
   (10.3.4.3)
   (4.4.4.4)
   (10.3.4.4)
   (10.1.3.3)
   (1.1.1.1) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 1 (44 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (10.1.3.1)
   (10.3.4.3)
   (4.4.4.4)
   (10.3.4.4)
   (10.1.3.3)
   (1.1.1.1) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Success rate is 100 percent (2/2), round-trip min/avg/max = 36/40/44 ms

The ASR is gone since the traffic goes from R1 (10.1.3.1) to R3 (10.3.4.3) to R4 (4.4.4.4) and R4 (10.3.4.4) sends the reply via R3 (10.1.3.3) back to R1 (1.1.1.1).

In case you are wondering about why the number is hops is a maximum of 9, this is because the limitation on the size of IP options (maximum 40 bytes).  From Understanding Linux Network Internals:

Because of limited space in the header, only nine addresses at most can be stored (and even fewer, if the header contains other options). Therefore, the packet arrives with the first nine [*] addresses stored in the option; the receiver has no way of knowing what routers were used after that. Since this option makes the header (and therefore the IP packet) grow along the way, and since other options may be present in the header, the sender is supposed to reserve the space that will be used to store the addresses. If the reserved space becomes full before the packet gets to its destination, the additional addresses are not added to the list even if the maximum size of an IP header would permit it. No errors (ICMP messages) are generated when there is no room to store a new address. For obvious reasons, the sender is supposed to reserve an amount of space that is a multiple of 4 bytes (the size of an IP address).

This is easily seen with Wireshark, for example:

In conclusion, a nice tool to have, specially for the lab since on most cases, firewalls/routers with strict security configurations will drop packets that have IP options enabled.

reference:https://blog.initialdraft.com/archives/2732/