Concerning scenario 1, when you generate a ping on R11 using the ping 10.1.1.2 command, if you don’t specify the source of the ping, the router will use the interface “closest to the destination” as the source. How does it determine that? It looks at the routing table. The interface “closest to the destination” is actually the exit interface that would be used to reach the destination according to the routing table.
If you specify the source of the ping, using an interface or an IP address, then it doesn’t need to look at the routing table. Because a router has many interfaces (unlike a PC for example) it must somehow determine out of which interface to send the packet, even if the packet is generated by the router itself. If the actual command doesn’t specify the source interface of the communication, then the routing table must be used to choose that source interface.
Concerning Scenario 2, in such a case, a routing table lookup would definitely take place. The destination IP is on a different subnet than the interface, thus, the routing table would be consulted to see where the packet should be sent. It would see that the destination is an interface on the router itself, but it would still use the routing table lookup to determine that.
Concerning Scenario 3, I am not familiar with the intricacies of the Windows OS, but I would agree with you that the Windows routing table is consulted. You described the process very well, and I belive that the description using the routing table simply gives more information about the mechanisms that are working in the background that make it all happen. I believe you have a good grasp of this process.
Its been awhile since I asked this question, but I wanted to re-open discussion around this topic, particularly of how a router or multi layer switch would not have to look at its routing table to forward a packet if we were to include the source IP/interface of a ping in the scenario I described above.
from the point of view of R11, if we were to ping R2’s interface 10.1.1.2 (or the loopback of R12) without specifying a source IP/interface, you mentioned a routing table look up would be necessary in order to determine the egress interface the router needs to use to reach that destination IP. That is perfectly clear. What I dont understand is how specifying the source IP/interface on the ping command would avoid a routing table lookup.
For example, from R11, if we ran the command ping 2.2.2.2 source g0/1 (or ping 2.2.2.2 source 10.1.1.1) the ping would fail unless we had an entry on our routing table that knows how to reach the 2.2.2.2/32 network. I understand we specified the egress interface here, but I dont see how that would be enough to forward that packet without having an entry in the RIB that matches the destination IP we want to reach, in which case we would still need to perform a routing table lookup even when specifying the source IP/interface.
So finally, my question would be how specifying the source IP/interface would negate having to look at our routing table when a router generates a packet? since doing this without an entry on our RIB that can match the destination IP of our packet always fails
Thanks for your detailed question. In my post I was specifically talking about the scenario where you ping the 10.1.1.2 destination while specifying either the source IP address of 10.1.1.1 or the exit interface of Gi0/1. Looking at the routing table is used to determine the exit interface. If you specify the exit interface in your ping and the destination is on the same subnet as the source interface, then theoretically speaking, you don’t need any additional information from the routing table. It is for this reason that I said that a routing lookup is unnecessary.
My point was that such an action has enough information to perform the ping without looking up any information in the routing table. Now what actually happens depends upon the way that a particular routing device is designed to operate. Whether or not the routing table is actually referenced may depend upon the internal programming of the device itself.
It may actually use the routing table just out of its fundamental operation. However, theoretically speaking, it doesn’t really have to.
Now in the example you state where the destination is 2.2.2.2 which is outside of the subnet of the Gi0/1 interface, of course, the routing table must be referenced, and the destination address must be in the routing table, otherwise the ping will indeed fail.
I’m just trying to understand how CEF per-destination load sharing works when both next-hops are on the same network and via the same exit ethernet interface.
I would expect per-destination to result in traffic to 9.9.9.9 to only use one of those next hops, however, trace routes show that both next hops are used.
R5#traceroute 9.9.9.9 source 5.5.5.5
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.0.3 7 msec
155.1.0.1 5 msec
155.1.0.3 6 msec
2 155.1.146.6 8 msec
155.1.37.7 7 msec
155.1.146.6 8 msec
3 155.1.79.9 14 msec
155.1.67.7 15 msec *
Does that mean CEF is purely used for load balancing across physical links?
First of all, let me clarify that CEF load-balancing balances traffic across available routes and not (necessarily) between interfaces. If multiple routes use the same exit interface or different exit interfaces is irrelevant as far as CEF load balancing goes.
Now when CEF determines the next hop for a packet, it uses a hash of the source and destination IP addresses (by default). This ensures that packets for the same flow (same source and destination IP) consistently use the same path. Based on this, you should indeed see the same next hop IP for all of your traceroute probes. Indeed, Cisco’s documentation states that:
You can use per-destination load balancing to ensure that packets for a given host pair arrive in order. All packets intended for a certain host pair are routed over the same link (or links).
Since seeing different paths in your traceroute output, CEF is not functioning like this. The only thing I can think of is that you may be using a platform that uses a slightly different hashing algorithm that may include other elements such as Layer 4 ports, which may be different for each individual probe. Alternatively, it could simply be an issue of a misconfiguration (i.e. you’ve enabled per-packet load balancing), but I’m quite sure you checked that
The other thing I am thinking is that traceroute, as a utility, is used to test connectivity. Could it be that traceroute on the router itself overrides the CEF operation in order to test multiple next hop IP addresses in the multiple probes it sends? I know I’m reaching for straws here, but it’s just a thought. I haven’t read any documentation that states this, but I’m just thinking out loud.
I regret not being able to provide more information for this to resolve the reason for this behavior. If you do gain any more insight into this, please share it with us so that we can continue the conversation.
After an update from Rene, there is a more clear explanation for the differences you see! CEF can be configured to use the original or unversal algorithm. When the universal algorithm is used, multiple parameters are used as input. For more info, take a look at this NetworkLessons note and its links.
