cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
601
Views
5
Helpful
5
Replies

EIGRP with VIRL does not do equal cost load balancing

Lehrling
Level 1
Level 1

Well, i might be missing something...Please help.

I have two equal cost paths to a destination. The EIGRP Topology table shows to me 2 successors for the route to the destination.Same Metric, same delay, as I said both route are sucessors. (see below)

When I test a ping to the destination, the debug shows me that it is using only one path. The ping uses only Gig0/0 for only one path. Sends no packets on the other path, with Gig0/1.

Sorry I could not paste  snippet from VIRL.

 
 
 

==========================================================

R6#sh ip eigrp topology 55.55.55.55/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.36.6) for 55.55.55.55/32
State is Passive, Query origin flag is 1, 2 Successor(s), FD is 131328
Descriptor Blocks:
192.168.16.1 (GigabitEthernet0/1), from 192.168.16.1, Send flag is 0x0
Composite metric is (131328/131072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5030 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 55.55.55.55
192.168.36.3 (GigabitEthernet0/0), from 192.168.36.3, Send flag is 0x0
Composite metric is (131328/131072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5030 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3

=================================================

 

R6#ing full packet
*Jun 20 17:55:42.927: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.927: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.932: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.932: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.936: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.937: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.941: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun
R6#20 17:55:42.942: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.945: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.945: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.949: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.950: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:42.954: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending
*Jun 20 17:55:42.954: IP: s=66.66.66.66 (local), d=55.55.55.55 (GigabitEthernet0/0), len 100, sending full packet
*Jun 20 17:55:4
3 Accepted Solutions

Accepted Solutions

show ip route 

<- do you see both path ? If yes then 
change the CEF load to be Per-packet not per-destation 

View solution in original post

Lehrling
Level 1
Level 1

Thanks a ton MHM !!! that has been great help from you.

View solution in original post

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Lehrling ,

your destination prefix is a single host /32  and the source is always the same. so a single path is picked up for a specific flow. You are using a single flow. You should have used multiple flows with at least different source addresses and/or a destination prefix that is not a /32.

 

Be aware that enabling per packet load balancing in real world is highly not recommended as it can negatively impact applications for the potential of out of order packets. CEF uses an EXOR of source IP address, destination IP address to choice a path for a given flow.

In some platforms the definition of flow can include the TCP or UDP source and destination ports allowing for more granularity.

 

 

What you see is not a limitation of VIRL, but how per flow CEF load balancing works and you would have achieved the same result with real  devices.

 

Hope to help

Giuseppe

 

View solution in original post

5 Replies 5

show ip route 

<- do you see both path ? If yes then 
change the CEF load to be Per-packet not per-destation 

Lehrling
Level 1
Level 1

Thanks a ton MHM !!! that has been great help from you.

You are so welcome 

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Lehrling ,

your destination prefix is a single host /32  and the source is always the same. so a single path is picked up for a specific flow. You are using a single flow. You should have used multiple flows with at least different source addresses and/or a destination prefix that is not a /32.

 

Be aware that enabling per packet load balancing in real world is highly not recommended as it can negatively impact applications for the potential of out of order packets. CEF uses an EXOR of source IP address, destination IP address to choice a path for a given flow.

In some platforms the definition of flow can include the TCP or UDP source and destination ports allowing for more granularity.

 

 

What you see is not a limitation of VIRL, but how per flow CEF load balancing works and you would have achieved the same result with real  devices.

 

Hope to help

Giuseppe

 

Lehrling
Level 1
Level 1

Hi Guiseppe,

 

Thanks for your feedback. I saw the equal routes int Topology table and also in the main routing table and could not find out why all the packests went over the same path. I am relatively new in networking and appreciate the speedy help of the community.

God Bless you all.

 

Review Cisco Networking for a $25 gift card