ECMP on VOSS in GNS3: CPU 100%

[Fijs]

Hi all,

I’m doing some ECMP test in GNS3 using VSP’s (v8.1.0.0 image).

Setup:

The Cisco is advertising 192.168.1.1/32 via OSPF to VSP1 and VSP2.

VSP1 and VSP2 redistribute OSPF into ISIS using a route-map wich sets the metric to 5000, so I can intercept and deny these redistributed routes on the other VSP using ISIS accept policies. That way, both VSP1 and VSP2 learn 192.168.1.1 via OSPF and both are redistributing it to VSP3.

ECMP is enabled on VSP3, and it correctly learns 192.168.1.1 from VSP1 and VSP2:

VSP3:1(config)#sho ip route
************************************************************************************
Command Execution Time: Fri Mar 27 13:25:19 2020 UTC
************************************************************************************
=====================================================================================================
 IP Route - GlobalRouter
=====================================================================================================
 NH INTER 
DST MASK NEXT VRF/ISID COST FACE PROT AGE TYPE PRF
-----------------------------------------------------------------------------------------------------
...
192.168.1.1 255.255.255.255 VSP1 GlobalRouter 10 4051 ISIS 0 IBSE 7 
192.168.1.1 255.255.255.255 VSP2 GlobalRouter 10 4051 ISIS 0 IBSE 7 
192.168.1.1 255.255.255.255 VSP1 GlobalRouter 10 4052 ISIS 0 IBSE 7 
192.168.1.1 255.255.255.255 VSP2 GlobalRouter 10 4052 ISIS 0 IBSE 7 

13 out of 13 Total Num of Route Entries, 6 Total Num of Dest Networks displayed.
 --------------------------------------------------------------------------------------------------
TYPE Legend:
I=Indirect Route, D=Direct Route, A=Alternative Route, B=Best Route, E=Ecmp Route, 
U=Unresolved Route, N=Not in HW, F=Replaced by FTN, V=IPVPN Route, S=SPBM Route
PROTOCOL Legend:
v=Inter-VRF route redistributed
VSP3:1(config)#

BUT: once it learns the ECMP routes, the CPU quickly goes to 100% and stays at 100% untill the VSP reboots:

VSP3:1(config)#sho k p c
************************************************************************************
Command Execution Time: Fri Mar 27 13:25:53 2020 UTC
************************************************************************************
 Slot:1 
 Current utilization: 100 
 5-minute average utilization: 17 
 5-minute high water mark: 17 (03/27/20 13:25:49)
VSP3:1(config)#

If I disable one of the ISIS links on VSP3 and reboot, there is no issue at all. Note that I have to reboot, because once the CPU is at 100%, it only goes to normal level (2-3%) by rebooting it. Disabling one or both ISIS links while the CPU is at 100% does not help.

I can reproduce this every time. Can someone confirm (and maybe explain why?) this is a “bug” related to the GNS3 VOSS VM image?

Unfortunately I don’t have any HW VSP’s available now since I’m homeworking just like the rest of the world 🙂

Config is quite basic, but I can share the configs if needed.

Thanks!

[Miguel-Angel_RO]

Thijs,

Thanks for sharing the solution.

We are all waiting since so looong the new VSP image with data forwarding…

Mig

[Fijs]

Hi Mig,

Sorry for the huge delay…

It’s not a L3 loop. I use the method you describe most of the time, but in this case, I needed another method which as described in the initial post (using a specific metric to match the routes that should not be redistributed).

Anyway, I can answer my own question now: Yes, this is relate to GNS3 or the VOSS GNS3 image.

I tested the above scenario using real VSP’s, and it works perfectly.

Rgds

Thijs

[Miguel-Angel_RO]

Fijs,

You could be doing a L3 loop where the OSPF routes on VSP1 are injected in ISIS and ISIS routes on VSP2 are injected in OSPF.

a show ip route on all VSP before and after activating ecmp could help to debug.

In such scenario we usually work with OSPF marked as “external routes” at VSP1 and VSP2 and we configure them to not redistribute the “external” routes into ISIS or giving them a higher preference value (=lower priority).

Use on VSP1 and VSP2 “no ip alternative-route” before activating ecmp.

Another alternative is to just inject a default route (if OSPF is the default path).

All this is coming form the advanced fabric training at the Avaya times (ACE-Fx 2) where the advanced routing is covered with examples and labs.

Regards

Mig

[Fijs]

Hi Mig,

Yes it is related. If I disable ECMP on VSP3 before the OSPF neigbourship on VSP1 and VSP2 come up, everything is fine. As soon as I enable ECMP again, cpu goes to 100%. Even if I disable ECMP again, CPU remains 100%.

Rgds

Fijs