IS-IS not working on ASR903.

[henriksenauit]

Hey you all

I have a very strange problem regarding IS-IS routing process on an ASR903 router, that I hope someone can help me with. I am trying to get IS-IS up and running between an ASR903 router and a ME3600X switch. Between the two boxes is a service provider VPLS network. We have IS-IS running on other similar links between this ASR903 and another ME3600X switch also with a VPLS network between. We are running MPLS in our backbone and uses IS-IS as the underlay IGP. It looks like the two IS-IS routers can’t see each other. When I do a debug of isis adj-packets can I see that the ME3600X switch is sending ISIS hellos packets out but does not receive any in. The same debug on the ASR903 do not give anything. It seems like it not even sending ISIS hellos. Logging level debugging is on. The two boxes can ping each other without any problems.

I have tried a couple of things when troubleshooting this problem. I have tried setting the network type to point-to-point, setting the clns mtu, disabled hello padding but nothing worked. I have also tried running OSPF over the link, and it worked without any problems. Then I tried to make a one-hop gre tunnel between them, and then run IS-IS over the gre tunnel and that also worked. When I issue the “show clns interface” command can I see that the “Next IS-IS LAN Level-2 Hello in” is always 0 on the ASR903 router on that interface. On the others interfaces that is running IS-IS the counter is changing. The same on the interface on the ME3600X switch.The software version on the ASR903 is for the IOS-XE is 3.13.1 and the IOS is 15.4(3).S1.

Do you have any idea’s to what the problem could be? 

Thanks

Michael H.

[Vasilii Mikhailovskii]

Hello.

Could you share your ISIS and interface configuration from ASR along with show clns ... show isis ... outputs?

[henriksenauit]

Hey Vassilii

Here are the show commands :-)

sh run int gi 0/2/1

interface GigabitEthernet0/2/1

 description INX2-ABC 500Mbps

 ip address 10.79.171.142 255.255.255.252

 ip router isis

 negotiation auto

 mpls ip

 bfd interval 100 min_rx 100 multiplier 3

 isis circuit-type level-2-only

 isis network point-to-point

 isis metric 2000

 no isis hello padding

 isis bfd disable

end

!

sh run | sec router isis

router isis

 net 01.f84f.5783.1a00.00

 is-type level-2-only

 metric-style wide

 log-adjacency-changes

 bfd all-interfaces

 mpls ldp sync

!

sh clns

Global CLNS Information:

  9 Interfaces Enabled for CLNS

  Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64

  ERPDU's requested on locally generated packets

  Running IS-IS in IP-only mode (CLNS forwarding not allowed)

  NET: 01.f84f.5783.1a00.00

!

sh clns interface gi 0/2/1

GigabitEthernet0/2/1 is up, line protocol is up

  Checksums enabled, MTU 1497, Encapsulation SAP

  ERPDUs enabled, min. interval 10 msec.

  CLNS fast switching disabled

  CLNS SSE switching disabled

  DEC compatibility mode OFF for this interface

  Next ESH/ISH in 37 seconds

  Routing Protocol: IS-IS

    Circuit Type: level-2

    Interface number 0x8, local circuit ID 0x103

    Level-2 Metric: 2000, Priority: 64, Circuit ID: ASR903-AAL01.03

    Level-2 IPv6 Metric: 10

    Number of active level-2 adjacencies: 0

    Next IS-IS Hello in 0 seconds

    No hello padding

    if state DOWN

!

sh ip protocols        

*** IP Routing is NSF aware ***

Routing Protocol is "isis"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Redistributing: isis

  Address Summarization:

    None

  Maximum path: 4

  Routing for Networks:

    Loopback0

    Loopback1

    BDI602

    BDI3001

    BDI3002

    BDI3100

    BDI1356

    GigabitEthernet0/2/1

    BDI1052

  Routing Information Sources:

    Gateway         Distance      Last Update

    100.110.0.19         115      00:02:42

    100.110.0.22         115      00:02:42

    100.110.0.20         115      00:02:42

    100.110.0.21         115      00:02:42

    10.79.144.17         115      00:02:42

    10.79.144.16         115      00:02:42

    10.79.144.15         115      00:02:42

    10.79.144.10         115      00:02:42

  Distance: (default is 115)

!

ping 10.79.171.141

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.79.171.141, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

[Vasilii Mikhailovskii]

Hello.

Do you see neighbour with "show clns neigh"?

If yes, try to adjust MTU on the interfaces or set "clns mtu 1400".

[henriksenauit]

Hi 

I can see the other router in the "show cons nei" on both routers. But under the protocol instead of "is-is" it is "es-is" on both routers (see below). 

sh clns nei

System Id      Interface   SNPA                State  Holdtime  Type Protocol

ME3600-INX02   Gi0/2/1     0c68.03c6.4c59      Up     245       IS   ES-IS

I tried to change the clns mtu down to 1400 but it has no effect.

[Vasilii Mikhailovskii · Accepted solution]

Hello.

This might be caused by mpls ldp igp sync feature.

Please check "show mpls ldp igp syn" output.

As a workaround try to either remove it from the box or apply maximum [feature] delay on the interface with command "mpls ldp igp sync delay ..."

[henriksenauit]

Hi

That was the only feature that I forgot to look at. It was a problem with MPLS lDP sync. It was not enable on the interface on the ME3600X switch. After I did that and flap the interfaces the isis neighbor moved to up. Thanks a lot for you help.

[aerkwannasak1]

Hi Vasilii,

I got the same problem on this topic. Now the problem has been solved. Thank you for the action that you reply it.
But I have some question. As per your workaround, I have remove ldp-igp sync on interface for disable this feature then ISIS comes up. But why after isis come up I just enable ldp-igp sync on that interface again (for test) isis not goes down, still seen as isis neighbors.

[Vasilii Mikhailovskii]

Hello.

IGP sync was invented to prevent IGP from coming up before LDP.

As if IGP comes up first (and LDP may be delayed), you would have non-labelled path over the link for some time.

So, IGP sync delays IGP convergence IF you heard LDP hello AND you have route to neighbour's transport address (LDP router-id, typically loopback).

So, here is a case:

• you reload a box;
• you have static 0.0.0.0/0 over some (non-MPLS interface);
• LDP hellos are exchanged and IGP sync comes into play;
• as far as 0.0.0.0/0 covers LDP neigbour's router-id, IGP is blocked on the interface till LDP comes up;
• but LDP can't come up, as 0.0.0.0/0 points over non-MPLS interface (and no way to reach MPLS peer over it);
• IGP stuck due to the feature.

The workaround helps you to start IGP and, due to /32 prefix from IGP, LDP converges. But once you reload your box, the same issue would be there.

Solution: don't use static 0.0.0.0/0 (over non-MPLS interface) along with IGP sync or set max delay.