ISIS Adj not coming up

Unanswered Question
Oct 13th, 2007

I changed the MTU of my gige link from 1500 to 1600, and configured mpls MTU 1538. doing that ISIS does not form adj.

I see CLNS is showing neigbor but as ES-IS? why is that.

Router A:

interface GigabitEthernet0/0/9

description link to RouterB

mtu 1600

ip address x.x.x.x y.y.y.y

no ip directed-broadcast

ip router isis

no negotiation auto

tag-switching mtu 1538

tag-switching ip

isis network point-to-point

isis authentication mode md5

isis authentication key-chain KEY-ISIS

end

Router A neigbor:

RouterA#sh clns neighbors

System Id Interface SNPA State HT Type Protocol

RouterB(P-TGi0/0/9 001a.e3a2.8808 Up 292 IS ES-IS

Other end:

Router B:

interface GigabitEthernet0/0/8

description Connected to Router A

Gig0/0/9

mtu 1600

ip address x.x.x.x y.y.y.y

no ip directed-broadcast

ip router isis

no negotiation auto

tag-switching mtu 1538

tag-switching ip

isis network point-to-point

isis authentication mode md5

isis authentication key-chain KEY-ISIS

end

RouterA(P-EGi0/0/8 001b.2b04.ec09 Up 250 IS ES-IS

I cannot see ISIS neigbor here.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Harold Ritter Sat, 10/13/2007 - 08:35

Atif,

The IS-IS hellos are probably not getting across the link. The reason you are seeing the adjacency as ES-IS is that the ES-IS hellos are not padded, while the IS-IS hellos are.

Do you have a switch between the two routers? If so, make sure that the switch allows 1600 bytes packets through.

Hope this helps,

atif-siddiqui Sat, 10/13/2007 - 10:35

ok I see. I will try to find out. as it is WAN link provided by other provider.

thanks.

antasson Sun, 10/14/2007 - 12:13

Another doubt I have is if after applying the mtu changes you shut/no shut both interfaces or just one.

Regards,

Antonio

atif-siddiqui Sun, 10/14/2007 - 20:01

We did that, but did not work.

I will find out tomorrow what do we have in the middle...

If it is DWDM, will it affect us? is there MTU setting on it? I am not sure

swaroop.potdar Sun, 10/14/2007 - 20:46

On both sides issue a "show ip interface check the IP MTU value on each side.

Set the ISIS MTU on each respective interface to the IP MTU you observe and the adjacency will come up.

HTH-Cheers,

Swaroop

libanm Mon, 10/15/2007 - 18:48

I agree with swaroop, this is due to the default hello padding, try disabling hello packet, if you are sure the both end point's MTU, this will reduce the CPU/BW. go into each interface and type

no isis hello padding

atif-siddiqui Tue, 10/16/2007 - 05:56

i did disable the padding, still does not come up.

only comes up when we reduce MTU to 1500. in the middle there is DWDM, which has enough limit for MTU

Harold Ritter Tue, 10/16/2007 - 16:36

Atif,

It would definitely be worth pinging from one router to the other using packet sizes over 1500 bytes just to confirm your providers setting.

Regards,

atif-siddiqui Tue, 10/16/2007 - 05:54

GigabitEthernet0/0/9 is up, line protocol is up

Internet address is x.x.x.x/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 1600 bytes

Helper address is not set

Directed broadcast forwarding is disabled

Multicast reserved groups joined: 224.0.0.2

Outgoing access list is not set

Inbound access list is not set

Proxy ARP is enabled

Security level is default

Split horizon is enabled

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is disabled

IP fast switching on the same interface is disabled

IP Flow switching is disabled

IP CEF switching is enabled

IP Null turbo vector

IP multicast fast switching is enabled

IP multicast distributed fast switching is disabled

IP route-cache flags are Fast, Distributed, CEF

Router Discovery is disabled

IP output packet accounting is disabled

IP access violation accounting is disabled

TCP/IP header compression is disabled

RTP/IP header compression is disabled

Probe proxy name replies are disabled

Policy routing is disabled

Network address translation is disabled

WCCP Redirect outbound is disabled

WCCP Redirect inbound is disabled

WCCP Redirect exclude is disabled

BGP Policy Mapping is disabled

Interface config:

mtu 1600

ip address x.x.x.x 255.255.255.252

no ip directed-broadcast

ip router isis NRP

no negotiation auto

tag-switching mtu 1538

tag-switching ip

isis network point-to-point

isis authentication mode md5

isis authentication key-chain KEY-ISIS

no isis hello padding

end

this is the same config on the other side.

etienne.basset Tue, 10/16/2007 - 04:18

hello

alternatively, you can decrease 'clns mtu' on your interface. But as you will apparently run MPLS on the link, it's worth checking the link 'real mtu'

regards

Etienne

swaroop.potdar Tue, 10/16/2007 - 08:22

Your config looks fine, can you run debug isis adj-pac and attach the o/p. this shouldprovide a clue whats going wrong.

HTH-Cheers,

Swaroop

swaroop.potdar Tue, 10/16/2007 - 08:28

To add more, my initial reply was based on similar experience, but between 76k and GSR-IOS XR. But did a quick test with 76k and dont see any problem neither am able to introduce such problem with similar config.

HTH-Cheers,

Swaroop

atif-siddiqui Tue, 10/16/2007 - 11:07

Also interestingly I can ping (DF Set)across with Higher MTU:

GSR-A#ping

Protocol [ip]:

Target IP address: x.x.x.69 --> GSR B connected interface IP

Repeat count [5]:

Datagram size [100]: 1550

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: y

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 1550-byte ICMP Echos to x.x.x.69, timeout is 2 seconds:

!!!!!

***

GSR-B#ping

Protocol [ip]:

Target IP address: x.x.x.70

Repeat count [5]:

Datagram size [100]: 1550

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: y

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 1550-byte ICMP Echos to x.x.x.70, timeout is 2 seconds:

!!!!!

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

atif-siddiqui Tue, 10/16/2007 - 10:41

Hi,

This gige is connected via DWDM, and MTu is set 9600.

What else we can check for.

Thanks

swaroop.potdar Tue, 10/16/2007 - 12:56

The debug from the other side would give a clue, as this guy seems to be on the lower end of the mtu, as you can see only outbound "sends" no receives.

It seems this side interface falls marked to the remote side mtu.

HTH-Cheers,

Swaroop

atif-siddiqui Fri, 10/26/2007 - 07:54

Here is the log from other side:

G0/0/8 on this side also does not recieve anything. In the middle there is DWDM and MTU is set to 9600, not sure what other reasons can be, setting MTU back to 1500 brings ISIS UP.

Oct 13 02:55:21.723 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS2/1/0), cir type L2, cir id 03, length 4469

Oct 13 02:55:21.723 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:21.723 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:23.099 EST: ISIS-Adj: Rec serial IIH from 0018.741e.5080 (GigabitEthernet0/0/0), cir type L2, cir id 00, length 1596

Oct 13 02:55:23.099 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:23.099 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:23.927 EST: ISIS-Adj: Sending serial IIH on POS2/1/0, length 4469

Oct 13 02:55:23.947 EST: ISIS-Adj: Sending serial IIH on POS3/1/0, length 4469

Oct 13 02:55:24.051 EST: ISIS-Adj: Rec serial IIH from 001b.2b8b.e41b (GigabitEthernet0/0/9), cir type L2, cir id 00, length 1496

Oct 13 02:55:24.051 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:24.051 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:24.223 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS3/0/0), cir type L2, cir id 02, length 4469

Oct 13 02:55:24.227 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:24.227 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:24.531 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS2/0/0), cir type L2, cir id 03, length 4469

Oct 13 02:55:24.531 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:24.531 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:25.568 EST: ISIS-Adj: Sending L2 IIH on GigabitEthernet0/0/8, length 1597

Oct 13 02:55:25.784 EST: ISIS-Adj: Sending serial IIH on POS2/0/0, length 4469

Oct 13 02:55:26.108 EST: ISIS-Adj: Sending serial IIH on GigabitEthernet0/0/9, length 1496

Oct 13 02:55:26.488 EST: ISIS-Adj: Sending serial IIH on GigabitEthernet1/0/0, length 1596

Oct 13 02:55:27.488 EST: ISIS-Adj: Sending serial IIH on POS3/0/0, length 4469

Oct 13 02:55:27.792 EST: ISIS-Adj: Rec serial IIH from 0018.741e.5080 (GigabitEthernet1/0/0), cir type L2, cir id 01, length 1596

Oct 13 02:55:27.792 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:27.792 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:28.292 EST: ISIS-Adj: Sending serial IIH on GigabitEthernet0/0/0, length 1596

Oct 13 02:55:29.080 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS3/1/0), cir type L2, cir id 01, length 4469

Oct 13 02:55:29.080 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:29.080 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:30.552 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS2/1/0), cir type L2, cir id 03, length 4469

Oct 13 02:55:30.552 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:30.552 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:30.648 EST: ISIS-Adj: Rec serial IIH from 0018.741e.5080 (GigabitEthernet0/0/0), cir type L2, cir id 00, length 1596

Oct 13 02:55:30.648 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:30.648 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:32.037 EST: ISIS-Adj: Sending serial IIH on POS2/1/0, length 4469

Oct 13 02:55:32.053 EST: ISIS-Adj: Rec serial IIH from *HDLC* (POS3/0/0), cir type L2, cir id 02, length 4469

Oct 13 02:55:32.053 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:32.053 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:32.329 EST: ISIS-Adj: Sending serial IIH on POS3/1/0, length 4469

Oct 13 02:55:33.173 EST: ISIS-Adj: Rec serial IIH from 001b.2b8b.e41b (GigabitEthernet0/0/9), cir type L2, cir id 00, length 1496

Oct 13 02:55:33.173 EST: ISIS-Adj: rcvd state UP, old state UP, new state UP

Oct 13 02:55:33.173 EST: ISIS-Adj: Action = ACCEPT

Oct 13 02:55:33.441 EST: ISIS-Adj: Sending L2 IIH on GigabitEthernet0/0/8, length 1597

Oct 13 02:55:33.529 EST: ISIS-Adj: Rec serial

Harold Ritter Fri, 10/26/2007 - 10:56

Atif,

Ultimately, you need to verify that the physical network does support 1600 bytes. The best way to do that is by using an extended ping as follow:

R1#ping ip

Target IP address: 172.16.12.2

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: yes

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1498

Sweep max size [18024]: 1600

Sweep interval [1]:

Type escape sequence to abort.

Sending 103, [1498..1600]-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:

!!!.................................................................

...................................

Success rate is 2 percent (3/103), round-trip min/avg/max = 20/36/60 ms

R1#

You see in this case that the MTU is 1500 bytes. The first 3 pings works (1498, 1499, 1500) and the rest of the ping fails.

Regards,

atif-siddiqui Fri, 10/26/2007 - 11:23

ok. there were some layer2 tests done on the circuit and it could pass from 64 bytes to 2000 bytes with nor prpblems.

Tried pings with DF bit set for 1600 bytes p2p link IP and it is also fine.

I can try this as well. and will post the results.

ilya.varlashkin Tue, 10/16/2007 - 13:23

Try 'no isis hello padding' on both sides. If adjacency comes up, then it's an MTU issue, otherwise it's something else. Debug from the other side would be indeed helpful.

Harold Ritter Tue, 10/16/2007 - 16:30

"no isis hello padding" only applies after the session has been established. Hellos sent before session establishment are padded regardless.

Regards,

atif-siddiqui Mon, 11/05/2007 - 15:41

Here is another secnario in the LAB.

P1(GSR) --- P3 (GSR)

P1#sh cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID

P3 POS0/0/0 122 R 12410/PRP POS0/0/0

P1#sh clns neighbors

System Id Interface SNPA State HT Type Protocol

PE1 Gi1/1/0 0019.a98c.1440 Up 23 L2 IS-IS

PE1 Gi1/1/1 0019.a98c.1440 Up 26 L2 IS-IS

P3 PO0/0/0 *HDLC* Up 275 IS ES-IS

P1#

P1#sh run interface pos0/0/0

Building configuration...

Current configuration : 329 bytes

!

interface POS0/0/0

description Connected to P3 - POS 0/0/0

ip address 18.18.18.1 255.255.255.252

no ip directed-broadcast

ip router isis

load-interval 30

tag-switching ip

crc 32

isis authentication mode md5

isis authentication key-chain ISIS

no isis hello padding

end

P1#sh ip int pos0/0/0

POS0/0/0 is up, line protocol is up

Internet address is 18.18.18.1/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 4470 bytes

P1 sees other neigbors but not P3:

P1#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE1 L2 Gi1/1/0 18.18.19.1 UP 22 01

PE1 L2 Gi1/1/1 18.18.19.49 UP 28 02

P3#sh run interface pos0/0/0

Building configuration...

Current configuration : 382 bytes

!

interface POS0/0/0

description Connected to P1 - POS 0/0/0

ip address 18.18.18.2 255.255.255.252

no ip directed-broadcast

ip router isis

load-interval 30

mpls traffic-eng tunnels

tag-switching ip

crc 32

isis authentication mode md5

isis authentication key-chain ISIS

no isis hello padding

P3#sh clns neighbors

System Id Interface SNPA State HT Type Protocol

PE2 Gi1/1/0 0019.a98c.1400 Up 28 L2 IS-IS

PE3 Gi1/1/1 0019.a98c.1500 Up 29 L2 IS-IS

P1 PO0/0/0 *HDLC* Init 29 L2 IS-IS

P3#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE2 L2 Gi1/1/0 18.18.19.17 UP 25 01

PE3 L2 Gi1/1/1 18.18.19.38 UP 27 02

P1 L2 PO0/0/0 18.18.18.1 INIT 28 00

P3#sh ip int pos0/0/0

POS0/0/0 is up, line protocol is up

Internet address is 18.18.18.2/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 4470 bytes

Above session is stuck in INIT as MTU is 4470, it was working before but changing the redudnacy mode to SSO, cause reload and it is down.

atif-siddiqui Mon, 11/05/2007 - 15:52

Changin MTU to 1500, it is working:

P1(config)#int pos0/0/0

P1(config-if)#mtu 1500

P1(config-if)#^Z

P1#sh

*Nov 5 19:41:56.638 EST: %SYS-5-CONFIG_I: Configured from console by console

P1#sh isis ne

P1#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE1 L2 Gi1/1/0 18.18.19.1 UP 26 01

PE1 L2 Gi1/1/1 18.18.19.49 UP 22 02

P3 L2 PO0/0/0 18.18.18.2 UP 23 00

P1#

other side:

P3(config)#int pos0/0/0

P3(config-if)#mtu 1500

P3(config-if)#^Z

P3#

*Nov 5 11:44:40.103 EST: %SYS-5-CONFIG_I: Configured from console by cisco on vty0sh isis ne

P3#sh i

P3#sh isis

P3#sh isis ne

P3#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE2 L2 Gi1/1/0 18.18.19.17 UP 29 01

PE3 L2 Gi1/1/1 18.18.19.38 UP 23 02

P1 L2 PO0/0/0 18.18.18.1 UP 28 00

NOW if I change the MTU to 4470 it is ok, until i reset the interface.

not sure what is happening here.

increasing to 4470:

P3(config)#int pos0/0/0

P3(config-if)#mtu 4470

P3(config-if)#^Z

P3#sh ip int

*Nov 5 11:46:30.491 EST: %SYS-5-CONFIG_I: Configured from console by cisco on vty0pos0/0/0

POS0/0/0 is up, line protocol is up

Internet address is 18.18.18.2/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 4470 bytes

P3#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE2 L2 Gi1/1/0 18.18.19.17 UP 26 01

PE3 L2 Gi1/1/1 18.18.19.38 UP 24 02

P1 L2 PO0/0/0 18.18.18.1 UP 25 00

P1 has session up too:

P1#sh ip int pos0/0/0

POS0/0/0 is up, line protocol is up

Internet address is 18.18.18.1/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 4470 bytes

P1#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE1 L2 Gi1/1/0 18.18.19.1 UP 24 01

PE1 L2 Gi1/1/1 18.18.19.49 UP 26 02

P3 L2 PO0/0/0 18.18.18.2 UP 21 00

now I shut the interface and no shut again same MTU problem. until i reduce it to 1500 and it comes up then i can make it 4470, only until the next interface reset.

P1(config)#int pos0/0/0

P1(config-if)#sh

*Nov 5 19:47:34.029 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0/0/0, changed state to down

P1(config-if)#no sh

P1(config-if)#

*Nov 5 19:48:13.596 EST: %LINK-3-UPDOWN: Interface POS0/0/0, changed state to up

P3#sh isis neighbors

System Id Type Interface IP Address State Holdtime Circuit Id

PE2 L2 Gi1/1/0 18.18.19.17 UP 22 01

PE3 L2 Gi1/1/1 18.18.19.38 UP 27 02

P1 L2 PO0/0/0 18.18.18.1 INIT 22 00

again INIT state.

Version 12.0(32)SY3

atif-siddiqui Tue, 11/06/2007 - 10:38

Summary of the problem:

- The problem occurs on ISIS Adj between GSR only.

- POS Links default MTU 4470.

- ISIS Adj Comes up initially; any resetting of neigbour router an interface or line card, line card reload, router reload, ADJ goes down.

- It only comes up when we reduce the MTU on links to 1500.

- After that increasing the MTU back to 4470 works fine until there is another neigbor router interface reset, and ISIS Adj goes down again.

- IOS version on GSR is: 12.0(32)SY3

atif-siddiqui Tue, 11/06/2007 - 14:27

Solution for POS interfaces.

Setting MTU lower than the default value fixes the problem.

We set it to 4460 on both sides and it works even after interface reset.

Gige point-to-point does not support more than 4200 when it is connected back to back.

lamarhinson Wed, 10/17/2007 - 11:11

Atif,

Also you might want to verify your ISIS mtu debug what is being sent out. You are going to have to make sure that the ISIS and Tagging mtu are the same accross both devices.

Cheers,

Lamar

atif-siddiqui Fri, 10/26/2007 - 07:56

Can you verify that the configs is ok?

Router A:

interface GigabitEthernet0/0/9

description link to RouterB

mtu 1600

ip address x.x.x.x y.y.y.y

no ip directed-broadcast

ip router isis

no negotiation auto

tag-switching mtu 1538

tag-switching ip

isis network point-to-point

isis authentication mode md5

isis authentication key-chain KEY-ISIS

end

Router A neigbor:

RouterA#sh clns neighbors

System Id Interface SNPA State HT Type Protocol

RouterB(P-TGi0/0/9 001a.e3a2.8808 Up 292 IS ES-IS

Other end:

Router B:

interface GigabitEthernet0/0/8

description Connected to Router A

Gig0/0/9

mtu 1600

ip address x.x.x.x y.y.y.y

no ip directed-broadcast

ip router isis

no negotiation auto

tag-switching mtu 1538

tag-switching ip

isis network point-to-point

isis authentication mode md5

isis authentication key-chain KEY-ISIS

end

RouterA(P-EGi0/0/8 001b.2b04.ec09 Up 250 IS ES-IS

I cannot see ISIS neigbor here.

Actions

This Discussion