OSPF Load Banacing
yuriz43
Member Posts: 121
in CCNA & CCENT
Obviously this is not a topic covered by the CCNA, however, after doing some practice labs, I've noticed some weirdness when it comes to redundant paths to a network using OSPF.
If you have to equal cost routes to a network, is OSPF supposed to distribute the packets between the two paths? I was doing a traceroute and got some really funky results. It seems like the icmp messages get sent between the two links.
Check out these traceroutes: I never seem to reach my destination. On the other hand, if I do a ping to 10.1.30.101 it works fine... Very weird!
Tracing the route to 10.1.30.101
1 10.1.10.101 32 msec
10.1.20.102 44 msec
10.1.10.101 56 msec
Tracing the route to 10.1.30.101
1 10.1.20.102 36 msec
10.1.10.101 32 msec
10.1.20.102 32 msec
Router#show ip route 10.1.30.101
Routing entry for 10.1.30.0/24
Known via "ospf 1", distance 110, metric 128, type intra area
Last update from 10.1.10.101 on Serial0/1, 00:21:02 ago
Routing Descriptor Blocks:
* 10.1.20.102, from 10.1.30.102, 00:21:02 ago, via Serial0/0
Route metric is 128, traffic share count is 1
10.1.10.101, from 10.1.30.101, 00:21:02 ago, via Serial0/1
Route metric is 128, traffic share count is 1
If you have to equal cost routes to a network, is OSPF supposed to distribute the packets between the two paths? I was doing a traceroute and got some really funky results. It seems like the icmp messages get sent between the two links.
Check out these traceroutes: I never seem to reach my destination. On the other hand, if I do a ping to 10.1.30.101 it works fine... Very weird!
Tracing the route to 10.1.30.101
1 10.1.10.101 32 msec
10.1.20.102 44 msec
10.1.10.101 56 msec
Tracing the route to 10.1.30.101
1 10.1.20.102 36 msec
10.1.10.101 32 msec
10.1.20.102 32 msec
Router#show ip route 10.1.30.101
Routing entry for 10.1.30.0/24
Known via "ospf 1", distance 110, metric 128, type intra area
Last update from 10.1.10.101 on Serial0/1, 00:21:02 ago
Routing Descriptor Blocks:
* 10.1.20.102, from 10.1.30.102, 00:21:02 ago, via Serial0/0
Route metric is 128, traffic share count is 1
10.1.10.101, from 10.1.30.101, 00:21:02 ago, via Serial0/1
Route metric is 128, traffic share count is 1
Comments
-
kryolla Member Posts: 785depends on your switching method process, fast switching, or cef. For CEF there is per destination or per packetStudying for CCIE and drinking Home Brew
-
kryolla Member Posts: 785try to traceroute through the router and not from the router and see if you get different resultsStudying for CCIE and drinking Home Brew
-
yuriz43 Member Posts: 121Ah weird! When I do a traceroute through the router the results are consistent!
Whats going on here? Why does it behave differently when I initiate the traceroute from the router itself? -
kryolla Member Posts: 785when you do a traceroute from the router it is process switched per packet meaning every packet is load balancing between the 2 paths. When you are going through the router it is CEF switched per destination-source pair by default meaning it is only using 1 path.Studying for CCIE and drinking Home Brew
-
yuriz43 Member Posts: 121Interesting, using the show cef interface and show ip interface commands, I can see that CEF is indeed enabled on my interfaces, and per packet switching is disabled..
IP CEF switching is enabled
IP route-cache flags are Fast, CEF
Per packet load-sharing is disabled
These are the settings on all of my ethernet interfaces. So why is switched per packet balancing being used when I initiate the traceroute from my router? These policies must only apply to packets coming into my interfaces, to be forwarded somewhere else, right?? This could definitely make trouble shooting from routers themselves difficult...
Thanks for answering my questions btw. This is a very cool topic. -
kryolla Member Posts: 785Packets generated by the router are process switched and not CEF. Only packets that transit the router are CEF switched to a certain extent.Studying for CCIE and drinking Home Brew
-
wat08 Member Posts: 128
-
yuriz43 Member Posts: 121Well this clears things up! Great link btw. Above the scope of the CCNA but great to know in my future studies.
Thanks guys!