Displayed Routes in "sh ipr" different than expected based on LSDB

[Timothy_Corcora]

Issue:

Why does sh IPR treat destination networks differently even though at first glance they should be treated the same?



Referring to this diagram: Mah-670-1 and Mah-670-2 are routers serving as the gateway between a building and the larger campus network. Dug-agg-1 and Dug-agg-2 are the aggregation routers that connect them to the OSPF area (0.0.3.2) that they all belong to.

Mah-670-1 has an OSPF P2P link with Dug-agg-1 and with Mah-670-2.

Mah 670-2 has an OSPF P2P link with Dug-agg-2 and with Mah-670-1.

Dug-agg1 and Dug-agg-2 have an OSPF P2P link to each other as well as P2P links to the larger campus network. All P2P and passive VLANs are in the same VR.

The sh ipr for mah-670-1 shows :

#or 10.112.1.0/24 10.3.11.157 12 UG-D---um--f- CA-P2P-Dagg1 4d:22h:16m:17s

#or 10.112.1.0/24 10.3.11.214 12 UG-D---um--f- ca-p2p-Mah-int 4d:22h:16m:17s

#or 10.113.1.0/24 10.3.11.157 10 UG-D---um--c- CA-P2P-Dagg1 4d:22h:16m:17s

#or 10.114.1.0/24 10.3.11.157 10 UG-D---um--c- CA-P2P-Dagg1 4d:22h:16m:17s



All of these routes are #or

Why then, does the 10.112.1.0/24 show two routes in the routing table (one through the Agg, one through the bld partner)

While the 10.113 and 10.114 show only one route (through the agg)?



Please note that both routes appear in the lsdb summary for each network.



Sh ospf lsdb

10.112.1.0 10.56.1.4 0x800009ed 117 0xcccd

10.112.1.0 10.56.2.4 0x800009ef 1091 0xadeb

10.113.1.0 10.56.1.4 0x800030d0 1437 0x7120

10.113.1.0 10.56.2.4 0x80004add 1571 0x 267

10.114.1.0 10.56.1.4 0x800025ed 1437 0x4c32

10.114.1.0 10.56.2.4 0x800025f4 1571 0x373f



The LSDB tells the router about both paths to each network.

The IPR table chooses to show both paths for 112.1, But only one path for 113.1 and 114.1

Why?

[Timothy_Corcora]

Tomasz,
ECMP is enabled

(vr VR-Campus) Mah-670-1.4 # sh config | include iproute
enable iproute sharing vr VR-BldgServices
enable iproute sharing vr VR-Campus
enable iproute sharing vr VR-HSTDSVCS
enable iproute sharing vr VR-PCI
enable iproute sharing vr VR-vdi
enable iproute sharing vr VR-VoIP
configure iproute sharing max-gateways 16

In this particular case the VR in question is VR-Campus

The diagram shows the two aggregtion routers at the top. These are the path back to the backbone. The two MAH routers at the bottom are the building routers for the Mahoney building. The Mahoney routers are the gateway (VRRP) routers for all of the VLANs active in the Mahoney building. The aggregation routers are the path out to all of the other buildings in area 0.0.3.2 and also to the backbone.

The aggregation routers are the ABRs for the area. Several other buildings live in the same area. Each building has a router pair connected back to the aggregation routers in the same fashion as Mahoney. In our IP scheme the second octet is unique to a building. In the case of Mahoney 10.33.x.x are the VLANs in that building.

[Erik_Auerswald]

Hi Tomasz,

EXOS shows all equal cost routes in the show iproute output, but if ECMP is not enabled, only one route is programmed into the FIB, as shown by the f flag.

Since two routes to 10.112.1.0/24 are shown as installed into the FIB, ECMP is enabled.

But it is a good observation that the routes towards 10.113.1.0/24 and 10.114.1.0/24 show a metric of 10, but the routes towards 10.112.1.0/24 show a metric of 12.

@Timothy: Please provide additional information about the network topology.

Thanks,
Erik

[Tomasz]

Hi Timothy,

Quick guess - is ECMP enabled? Looks like different link metrics and for some reason both paths to 10.112.1.0 have ultimate metrics of 12.
It would be easier to read and troubleshoot if you pointed some breader picture (where are the networks connected) and relevant config parts.

Regards,
Tomasz

[Timothy_Corcora]

Erik,
Thanks for your time and energy on this.
I appreciate the assist!

Tim