EIGRP not doing unequal cost load balancing

Lucas Rene · ‎05-12-2019

Hi everyone! New here, and i hope to be an active user. I encounter myself doing some EIGRP LABS.

The thing is i want to do some unequal load balancing, and i have two routes to reach 172.16.2.0/24 network. I type the variance 2 command (or 100, it doesnt matter) in order to do some unequal load balancing but its not showing up in my routing table... what could be the problem? Thanks in advance.

Z#show ip eigr topo 172.16.2.0/24

IP-EIGRP (AS 100): Topology entry for 172.16.2.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 156260

Routing Descriptor Blocks:

192.168.23.1 (FastEthernet1/0), from 192.168.23.1, Send flag is 0x0

Composite metric is (156260/128257), Route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 5100 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

192.168.13.1 (FastEthernet0/0), from 192.168.13.1, Send flag is 0x0

Composite metric is (158820/156260), Route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 5200 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

As you can see, if i do a show ip route, there is only one route to 172.16.2.0

Gateway of last resort is not set

D 192.168.12.0/24 [90/30820] via 192.168.23.1, 00:02:33, FastEthernet1/0

[90/30820] via 192.168.13.1, 00:02:33, FastEthernet0/0

C 192.168.13.0/24 is directly connected, FastEthernet0/0

172.16.0.0/24 is subnetted, 3 subnets

D 172.16.1.0 [90/156260] via 192.168.13.1, 00:02:33, FastEthernet0/0

D 172.16.2.0 [90/156260] via 192.168.23.1, 00:02:33, FastEthernet1/0

C 172.16.3.0 is directly connected, Loopback1

C 192.168.23.0/24 is directly connected, FastEthernet1/0

CCENT

Giuseppe Larosa · ‎05-12-2019

Hello Lucas,

EIGRP can perform unequal cost load balancing but only with paths that satisfy the Feasibility Condition

You can check using

show ip eigrp topology all

The reported distance has to be stricly lower then the feasible distance (the composite metric as advertised by the neighbor)

The computed distance over the backup path has to be less then V * feasible_distance.

Likely for the prefix of interest you have a successor and no feasible successors, you can check this with show ip eigrp topology all

The reason the FC has to be satisfied is that in any case EIGRP wants to avoid possible routing loops even temporary.

Hope to help

Giuseppe