An interesting argument often happens between our network engineers and other IT professionals (security, VoIP, server, etc.) about traffic flows. Most enterprise networks are built with dual paths via dual network devices for redundancy (Cisco just loves it when you buy double the network gear). At a Layer-3 level, since there are two (or more, but usually just two) paths, the routing protocols load balance traffic over equal paths (ECMP). At a packet level, Cisco devices running CEF are going to choose a single path for each source-destination pair. So, even though your routing protocol will show two paths to a destination:
CR01#sh ip rou 10.30.100.121
Routing entry for 10.30.100.121/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 10.30.100.36 on GigabitEthernet3/2, 1d01h ago
Routing Descriptor Blocks:
* 10.30.100.36, from 10.28.254.238, 1d01h ago, via GigabitEthernet3/2
Route metric is 11, traffic share count is 1
10.30.100.4, from 10.28.254.238, 1d01h ago, via GigabitEthernet3/1
Route metric is 11, traffic share count is 1
all the traffic from a specific source (10.58.1.2) is going to the same next hop:
CR01#sh ip cef exact-route 10.58.1.2 10.30.100.121
10.58.1.2 -> 10.30.100.121 : GigabitEthernet3/2 (next hop 10.30.100.36)
This is normal per-destination routing; a single path through the network for the same stream of traffic. This is a good thing as it keeps packets from arriving at the destination out-of-order.
However, this is only one part of the TCP session – in this case traffic from 10.58.1.2 to 10.30.100.121. It comes in one port on CR01 and goes out GigabitEthernet3/2. The trick is the return traffic – 10.30.100.121 to 10.58.1.2 – does not necessarily take the same path. It looks like this:
(the red line is 10.58.1.2 to 10.30.100.121)
(the green line is 10.30.100.121 to 10.58.1.2)
So, the traffic in this TCP session is taking different paths in the network. Other IT Engineers get all mad about this and say it’s asynchronous routing and that causes problems (especially the security guys with their IDSs and FWs). I’ve always considered this to be real asynchronous routing:
But they insist all traffic from a single TCP session has to go in and out of the exact same interfaces on all devices, not just the WAN.
What really gets ’em hot is when equal cost routing and CEF do this:
Oh, the horror! I keep arguing with that that this is normal part of networking and if their devices can’t handle it, then their devices are broke, the network is working fine. In fact, I would propose it would cause more problems to try to manipulate IGP costs to enact a single path, in both directions, for all traffic. Good luck getting the configurations right to do that on all devices.
What are your thoughts? Is my terminology – “loadbalanced” – correct? Or do you consider this asynchronous routing?
