IS-IS Strange Issue with a /32 route showing

[JonathanC1]

Hello All,

I've been troubleshooting a really odd issue majority of the weekend with a colleague which i am sure is an IS-IS problem and wanted to get a 2nd opinion if anyone had a second to review ISIS inner workings with us. In the underlay of our SDA we use IS-IS - we have installed 2 new switches but one has an issue with one link. The ISIS config is the same across board:

router isis
net 49.0000.1324.1325.1326.00
domain-password ******
metric-style wide
log-adjacency-changes
nsf ietf
bfd all-interfaces

All routed devices are level 1-2 ( the CORE devices have same config but they just have a default route originate and a redistribute of BGP prefixes for underlay.) The interfaces are all routed ports along the lines of this only:

interface TenGigabitEthernetX/X/X
description Fabric Physical Link
no switchport
dampening
ip address X.X.X.X 255.255.255.254
no ip redirects
ip router isis
load-interval 30
bfd interval 100 min_rx 100 multiplier 3
clns mtu 1400
isis network point-to-point
end

We have 1 uplink routed port on 9k switches to each core. The link from ACCESS switch <-> CORE-2 is fine but the ACCESS switch routed link to the CORE-1 is not working. LLDP/CDP traffic is working (port is UP/UP packets incrementing so have ruled out physical) and we can see IP traffic from CORE-1 through captures. IP communication is failing pings/BFD etc. Further investigation issue is probably stem from there is a /32 L2 IS-IS route on ACCESS for the CORE-1 IP! We learn this IP through CORE-2. So what is happening is any IP communication including ICMP/BFD is failing trying to route out of the CORE-2 when it should be using directly connected (It is a /31 interface so it is using longest prefix match from my understanding.)

When I look at the IS-IS database level-2 detail I can see this /32 route is an entry on CORE-2! CORE-1 it only has the /31. CORE-2 doesn't have a /32 route installed in RIB/FIB if we do a show IP route it presents the /31 and route to that.

It has baffled me as to why it is doing that for this switch only when the config is all the same for about 10 access switches on this site - other P2P uplink interfaces don't have a /32 . Could this be some kind of order of operations/bug on CORE-2 generating the /32?  In terms of redistribution I've checked BGP and LISP there is no /32 route being pushed into IS-IS on CORE-2. Is there anyway I can trace/debug further how this /32 has got to the CORE-2 when the IP lives on CORE-1. Any tips would help at this stage - IS-IS is not something I've had to dive into in detail due it all just being pretty flat for basic underlay communication.

Kind Regards

JC 

[Georg Pauwen]

Hello,

do you have a drawing of your topology, showing how your devices are connected ?

[JonathanC1]

 

The RED dot on CORE-01 is the IP /31 interface we are seeing a /32 route on ACCESS-SWITCH if that makes sense for that IP so all communication is going via CORE-02 and failing.

Many Thanks

JC

[Georg Pauwen]

Hello,

post the full running configs of all three switches in that drawing so we can lab this.

[Harold Ritter]

Hi @JonathanC1 ,

You first need to find out who originated this /32 route.

Run "show ip route <prefix> 255.255.255.255" on the access router. Look at the "from" field from the output. Go on the device specified in the "from" field and then run "show ip route <prefix> 255.255.255.255" to get more information about where it comes from.

Regards,

[JonathanC1]

The link between CORE-001 and ACCESS is 172.40.255.112/31 - The CORE-001 IP is 172.40.255.112 and ACCESS is 172.40.255.113

The ACCESS has learnt this route from CORE-002 and not directly connected (172.40.255.119 is CORE-002):-

BAR-CORE-001#sh ip route 172.40.255.112 255.255.255.255
Routing entry for 172.40.255.112/32
Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis
Last update from 172.40.255.119 on TenGigabitEthernet1/1/3, 5d ago
Routing Descriptor Blocks:
* 172.40.255.119, from 172.40.255.1, 5d ago, via TenGigabitEthernet1/1/3
Route metric is 30, traffic share count is 1

On the CORE-002:

It learns the /31 route from the access switch & the core-001 ECMP.

On the CORE-001:

It is the directly connected interface IP.

The FROM IP address is the anycast multicast RP address 172.40.255.1 - looking at ISIS it is the IP address in database detail on both CORE-01 and CORE-02. Only the CORE-02 database detail has a 172.40.255.112/32 entry.  For some reason the access switches learnt the /32 as level-2 also which I don't get (all switches are level 1-2 default)

Kind Regards

JC

[Harold Ritter]

Hi @JonathanC1 ,

BAR-CORE-001#sh ip route 172.40.255.112 255.255.255.255
Routing entry for 172.40.255.112/32
Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis
Last update from 172.40.255.119 on TenGigabitEthernet1/1/3, 5d ago
Routing Descriptor Blocks:
* 172.40.255.119, from 172.40.255.1, 5d ago, via TenGigabitEthernet1/1/3 <+++ Core1 learns the /32 from 172.40.255.1
Route metric is 30, traffic share count is 1

Can you provide the output for "sh ip route 172.40.255.112 255.255.255.255" from 172.40.255.1?

Regards,

Regards,