%CLNS-5-ADJCHANGE: New / Hold time expred

[MAKhan]

Hi,

Router is getting the following errors on access router; I dont know really weather its because of the corrupt ISIS packet or could be something else (instability)? Any idea ?

Best regards

Khan

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTaaaaa (Tunnelaaaaa) Down, hold time expired

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTaaaaa (Tunnelaaaaa) Up, new adjacency

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTbbbbb (Tunnelbbbbb) Down, hold time expired

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTbbbbb (Tunnelbbbbb) Up, new adjacency

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTccccc (Tunnelccccc) Down, hold time expired

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTccccc (Tunnelccccc) Up, new adjacency

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTaaaaa (Tunnelaaaaa) Down, hold time expired

%CLNS-5-ADJCHANGE: ISIS: Adjacency to RTaaaaa (Tunnelaaaaa) Up, new adjacency

[Harold Ritter]

I have seen this behavior before in scenarios where the tunnel destination was learnt via ISIS. Make sure that you learn the tunnel destination via either static or a routing protocol with a lower AD.

Hope this helps,

[slicker]

If the first issue ( learning about the tunnel endpoint through the tunnel) is not it then just check for integrity of the tunnel by pinging about 1000 pings with the maximum mtu of the tunnel.

[MAKhan]

I think you are right, may be we have to increase the hello-interval for the tunnels.

Any more idea?

Best Regards

Khan

[Harold Ritter]

I doubt that this will have any positive affect. How are you learning about the tunnel destination?

Thanks,

[MAKhan]

We are using the OSPF protocol to learn the destination addresses. Here is the sample configuration for the tunnels:

Interface Loopback0

ip address 11.10.10.29 255.255.255.252

Interface Tunnel123

description Tunnel towards ABC Office

ip unnumbered loopback0

clns router isis abc123

isis adjacency-filter abc123

tunnel source loopback0

tunnel destination 10.10.10.2

tunnel checksum

[olorunloba]

I'm not sure it is right to use the loopback 0 both as the tunnel source and the tunnel ip address. Furthermore, if the loopback 0 is part of the OSPF network, you might be having recursive routing at the other end, which you will see as the tunnel going up and down at your end. Try and use different ip addresses for the tunnel source and ip address, and try to ensure that the tunnel source is not part of the ospf to ensure that you do not relearn it through the tunnel. Note, redistribution could also be a problem.

[olorunloba]

I think you need to check the routes that are being advertised by the ISIS to. The tunnel source and ip should also not be together there.

[Harold Ritter]

According to the configuration, ISIS only carries CLNS routes. This doesn't seem to be the problem.

[olorunloba]

I'm not to familiar with ISIS or CLNS, but I feel the error is due to recursive routing on the tunnel interface. I feel using the same ip address for the tunnel source and its ip address would result in recursive routing. If for example, the OSPF route learnt by the remote router is less specific than a /30 (the mask of the loopback), the remote would install the ISIS route, which would then be recursive.

Would appreciate your input.

[Harold Ritter]

If only ISIS is used only for clns and not ip that should not happen since no ip route will be learnt via ISIS.

I think the next step to try to troubleshoot this issue should be to run a "deb isis adj" on either side to see if the hellos are sent and received.

You could also use extended ping to test the integrity of the tunnel.

[MAKhan]

Yes your are right we have only configured the ISIS routing on the tunnel interfaces.

I will check the output of "debug isis adjencies" to check if the hello packets are dropped somehow.

I feel that its something to do with hello packets or interval settings because of the inactivity between two ends or within the OSPF clouds.

Best Regards

Khan