Re: OSPF equal cost load balancing not working?

randms2610 · ‎12-27-2018

Dear all,

I tried to setup an equal cost load balancing with OSPF (yes I know with EIGRP it can be easier but my environment uses multi vendor setup therefore EIGRP can't be used) but it doesn't seem to work.

So let's say my Cisco router (R1) connected to R2 and R4 through OSPF, and I want to reach the network behind R3, or in this case its loopback address. All network are in area 0. I'm expecting that in this setup I can have the traffic from R1 loopback (1.1.1.1) to R3 loopback (3.3.3.3) to be load balanced between R2 and R4, but what I got instead is only an asymmetric routing. See the details below:

OSPF config on R1:

R1#sh run | s router
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 10.12.12.1 0.0.0.0 area 0
 network 10.14.14.1 0.0.0.0 area 0

all the show command from R1:

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
 Known via "ospf 1", distance 110, metric 3, type intra area
 Last update from 10.12.12.2 on FastEthernet0/0, 00:39:41 ago
 Routing Descriptor Blocks:
 * 10.14.14.4, from 3.3.3.3, 00:39:41 ago, via FastEthernet0/1
 Route metric is 3, traffic share count is 1
 10.12.12.2, from 3.3.3.3, 00:39:41 ago, via FastEthernet0/0
 Route metric is 3, traffic share count is 1
R1#
R1#sh ip ospf database

OSPF Router with ID (1.1.1.1) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 415 0x80000004 0x005C0E 3
2.2.2.2 2.2.2.2 212 0x80000004 0x0089AF 3
3.3.3.3 3.3.3.3 177 0x80000004 0x00AD23 3
4.4.4.4 4.4.4.4 200 0x80000003 0x00CC1A 3

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.12.12.2 2.2.2.2 212 0x80000002 0x002CD4
10.14.14.4 4.4.4.4 200 0x80000002 0x00F1F8
10.23.23.3 3.3.3.3 177 0x80000002 0x005A83
10.34.34.4 4.4.4.4 200 0x80000002 0x008832
R1#
R1#show ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 1 FULL/DR 00:00:36 10.14.14.4 FastEthernet0/1
2.2.2.2 1 FULL/DR 00:00:33 10.12.12.2 FastEthernet0/0

Ping from loopback R1 to R3

R1#ping 3.3.3.3 sour 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/48/84 ms

Packet capture on R3 interface facing R2

Capture from R3 interface facing to R4

So it looks like the echo request goes through R1-R4-R3 then the reply goes through R3-R2-R1. From what I see it looks more like asymmetric routing instead of load-balancing.

Please advise why I am not getting the result as expected.

Thanks

Meheretab Mengistu · ‎12-27-2018

Please share the output of the following commands: sh ip route ospf, traceroute 3.3.3.3 source 1.1.1.1 probes 2, and traceroute 1.1.1.1 source 3.3.3.3 probes 2.

HTH,

Meheretab

HTH,
Meheretab

randms2610 · ‎12-27-2018

Hi Meheretab, thanks for coming by... here's the output as requested:

R1#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 10.12.12.2, 01:22:51, FastEthernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 10.14.14.4, 01:22:41, FastEthernet0/1
 [110/3] via 10.12.12.2, 01:22:41, FastEthernet0/0
 4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 10.14.14.4, 01:22:41, FastEthernet0/1
 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O 10.23.23.0/24 [110/2] via 10.12.12.2, 01:22:41, FastEthernet0/0
O 10.34.34.0/24 [110/2] via 10.14.14.4, 01:22:41, FastEthernet0/1

R1#traceroute 3.3.3.3 source 1.1.1.1 probe 2
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 10.12.12.2 24 msec
 10.14.14.4 24 msec
 2 10.23.23.3 56 msec
 10.34.34.3 16 msec

R3#traceroute 1.1.1.1 source 3.3.3.3 probe 2
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
 1 10.23.23.2 56 msec
 10.34.34.4 60 msec
 2 10.12.12.1 40 msec
 10.14.14.1 36 msec

please advise

Meheretab Mengistu · ‎12-27-2018

As you can see, there is load-balancing between the two available paths learned through OSPF. It is working as expected. If you run packet capture while you do traceroute, you should see packets traveling in both directions.

You will get more information here: https://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html

HTH,
Meheretab

HTH,
Meheretab

jalejand · ‎12-28-2018

Equal cost load balancing is working as expected. At least from R1 perspective, if it has two routes to a specific destination via OSPF then it is equally load balancing with different next hops, this also applies for R3 as unequal load balancing is not supported in OSPF.

This is natural behavior, hardware based routing is based on CEF that by default uses per-destination hashing parameters to determine which next hop address will use for an specific flow of packets. For example, destination 3.3.3.3 will always use the same link as long as the routing table doesn't change.

There are some ways to force CEF to allow packets to be distributed between links independently of its desintation like packet-sharing mode or enabling process-based switching of packets, but this can result in issues with TCP connections or firewall policies.

If you want to force a specific destination to go through a specific next hop address, you can use a PBR.

Joseph W. Doherty · ‎12-28-2018

As the other posters have commented, it appears to be working correctly. Understand, by default, OSPF load balancing uses the same next hop for all a single flow's traffic. Also, I believe, by default, OSPF (actually CEF) will use the same next hop for traffic with the same attributes it uses to determine the next hop. (This latter "feature" often results in uneven loading of your multiple paths, especially in the short term. The best feature Cisco offers for dynamic load balancing, without splitting a single flow's packets, would be PfR.)