Troubleshooting ISIS Adjacencies

Compared to OSPF, forming an adjacency in ISIS quite a bit easier. Only a few items need to match:

• Authentication

• Circuit type (L1, L2, or L1L2)

  • With the exception that L1L2 can form an adjacency with L1-only and L2-only

• Area ID (only for an L1 adjacency)

  • Area ID does not need to match for an L2 adjacency

• MTU

  • This is ensured by padding Hellos to the MTU value of the interface

For an L2 adjacency, you may have a hard time not forming an adjacency! The circuit type just needs to be L1L2 or L2, and the area ID does not need to match.

Notably, in ISIS hello/dead timers do not need to match, as they do in OSPF. Also the network mask does not need to match. (It does need to match in OSPF except when using the p2p network type).

	OSPF	ISIS
Subnet mask must match?	Yes, unless p2p	No
Neighbor’s interface address must be reachable out the local interface?	Yes	Yes
Hello/Dead interval must match?	Yes	No
Stub type must match?	Yes	N/A
RID/System ID must be unique?	Yes	Yes
Area ID must be the same?	Yes	Yes for L1 adjacencies. No for L2 adjacencies
Network type must match?	"Yes” but a mismatch can work in certain cases	Yes, network types much strictly be both p2p or both broadcast

What happens if one router uses p2p network type, and the other uses the default broadcast?

In OSPF we saw that two neighbors can reach a FULL adjacency with one side p2p and one side broadcast. The router that has p2p configured generates a warning, which states that its neighbor has elected a DR which makes no sense on a p2p network.

In ISIS, these two routers never become neighbors. This is because a p2p adjacency uses a separate Hello PDU type compared to a broadcast adjacency.

• Hellos from 0000.0000.0001 are P2P Hellos, and Hellos from 0000.0000.0002 are L1 Hellos. Both routers are L1-only.

In total there are three ISIS Hello types:

• P2P

  • This single type is used for both L1 and L2 p2p adjacencies

• L1 LAN (broadcast)

• L2 LAN (broadcast)

What happens if MTU mismatches?

In OSPF we saw that when the MTU mismatches, neighbors are stuck in Exstart/Exchange. This is because there is a field in the DBD packet header for the MTU of the link.

In ISIS there is no such field. However, by default, hello packets are padded to the MTU of the link.

• The hello is padded with “useless” data to make the Hello frame the size of the MTU of the link. This ensures that both neighbors support the same MTU on the link.

The problem that can occur is similar to the one-way communication issue seen in OSPF. The router with the higher MTU will receive Hellos from the neighbor, but they will never list the local router as being “seen.” The neighbor will be shown as being stuck in INIT.

R1(config)#int gi1
R1(config-if)#mtu 9000

R1#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
0000.0000.0002  L1   Gi1           10.1.2.2        INIT  28       01

On the router with the lower MTU, the Hellos will be discarded, because they are bigger than the MTU of the interface. The neighbor will never be seen.

R2(config-if)#int gi1
R2(config-if)#mtu 1500

R2#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R2#

You can turn off hello padding with the following command:

R1(config-if)#no isis hello padding always 

*Dec  7 14:49:27.838: %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0002 (GigabitEthernet1) Up, new adjacency

• The adjacency comes up once the Hello packets are small enough to be accepted by R2

• Without the always keyword, the first two Hellos will be padded (to preform an MTU check) and then subsequent Hellos will not be padded, to save on bandwidth. Without the no isis hello padding command, every single Hello is padded. (This indefinite padding of the Hello is the default behavior).

What happens if timers don’t match?

ISIS adjacencies work just fine when the timers don’t match. Each router advertises its own holding timer, which tells the other neighbor how long to set the holding timer for this adjacency.

This concept should make more sense with an example.

R1 uses the default hello-interval of 10 and hello-multipler of 3, so it sets the holding timer to 30 in its Hellos:

R2 uses a hello-interval of 60 with the default multipler of 3. It signals its holding timer as 180 seconds.

On R1, the holding timer for R2 is the value as learned from R2’s Hello, not any locally configured value on R1.

R1#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R2              L1   Gi1           10.1.2.2        UP    163      01

• R1 is counting down from 180 seconds for R2’s holding timer

R2 uses R1’s holding timer, which is learned from R1’s Hello:

R2#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R1              L1   Gi1           10.1.2.1        UP    28       01

Put simply, the configured holding-interval is signaled to a neighbor, and tells the neighbor what to set the holding timer to for the adjacency.

What happens if the subnet mask doesn’t match?

If both routers can reach each other, but the mask is incorrect on one (for example a /25 instead of a /24), the adjacency still works just fine. The subnet mask is not signaled in the Hello.

What happens if both routers have interfaces in a completely different subnet?

Let’s say R1 and R2 cannot reach each other over IP, because their interfaces are in different subnets. You may think that they should still form an ISIS adjacency, because ISIS operates at L2.

What happens is the routers do a check on the interface address seen in the Hello, and conclude that the address is not reachable out the local interface. The adjacency never comes up. The neighbors are never seen in show isis neighbor output.

#R1
int Gi1
 ip add 10.12.12.1 255.255.255.0

#R2
int Gi1
 ip add 10.1.2.2 255.255.255.0

R2#
*Dec  8 01:24:34.445: ISIS-Adj: cir type L2, cir id 01, length 1496
*Dec  8 01:24:34.446: ISIS-Adj: No usable IP interface addresses in serial IIH from GigabitEthernet1

• The interface IP address is signaled in the Hello, but the network mask is not signaled. It is up to the router to determine whether the neighbor is reachable directly off its local interface.

What happens if there is a layer 3 ACL blocking unicast traffic?

A layer 3 ACL does not affect ISIS, because it operates at layer 2.

What happens if there is a layer 2 ACL?

Depending on what layer 2 MAC address is blocked, it will potentially result in the neighborship stuck in INIT.

There are three destination MAC addresses used by ISIS:

1. 0900.2b00.0005 - IS Hello

   • Only used for P2P Hellos

2. 0180.c200.0014 - All L1 IS’s

   • Used for broadcast L1 Hellos

   • Used for LSPs and SNPs (Sequence Number Packets, CSNP and PSNP) on an L1 adjacency

3. 0180.c200.0015 - All L2 IS’s

   • Used for broadcast L2 Hellos

   • Used for LSPs and SNPs on an L2 adjacency

Consider the following setup:

#R1
interface GigabitEthernet2
 service instance 100 ethernet
  encapsulation dot1q 100
!
interface BDI100
 ip address 10.100.12.1 255.255.255.0
 ip router isis 
 encapsulation dot1Q 100
 isis network point-to-point 
!
bridge-domain 100 
 member GigabitEthernet2 service-instance 100
!
router isis
 net 49.0001.0000.0000.0001.00
 is-type level-2-only

#R2
interface GigabitEthernet2
 service instance 100 ethernet
  encapsulation dot1q 100
  mac access-group BLOCK_IS_HELLO in
!
interface BDI100
 ip address 10.100.12.2 255.255.255.0
 ip router isis 
 encapsulation dot1Q 100
 isis network point-to-point 
!
bridge-domain 100 
 member GigabitEthernet2 service-instance 100
!
mac access-list extended BLOCK_IS_HELLO
 deny   any host 0900.2b00.0005
 permit any any
!
router isis
 net 49.0001.0000.0000.0002.00
 is-type level-2-only

R2 is blocking any frames with a destination MAC of the IS Hello. R1 will see R2 has stuck in INIT, and R2 will not see R1. This is the same one-way communication issue seen with MTU mismatch.

R1#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R2              L2   BD100         10.100.12.2     INIT  23       08


R2#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R2#

Let’s now allow the IS Hellos but discard the frames destined for all L2 IS’s (0180.c200.0015).

#R2
mac access-list extended BLOCK_L2_IS
 deny any host 0180.c200.0015
 permit any any
!
int Gi2
 service instance 100 ethernet 
  no mac access-group BLOCK_IS_HELLO in
  mac access-group BLOCK_L2_IS in

Both neighbors see each other as UP. This is because they both list eachother in their Hello. This is all that is required for the adjacency to come up.

R1#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R2              L2   BD100         10.100.12.2     UP    27       08

R2#show isis nei

System Id       Type Interface     IP Address      State Holdtime Circuit Id
R1              L2   BD100         10.100.12.1     UP    29       08

However, R2 is discarding the LSPs and SNPs from R1- (which are destined for all L2 IS’s MAC), so R2 never sees the R1.00-00 LSP. Because of this, R2 has no reachability to prefixes beyond R1.

R1#show isis data

IS-IS Level-2 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd      ATT/P/OL
R1.00-00            * 0x00000003   0x11BD                1075/*         0/0/0
R2.00-00              0x00000007   0xC2CE                1035/1199      0/0/0


R2#show isis dat

IS-IS Level-2 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd      ATT/P/OL
R2.00-00            * 0x00000007   0xC2CE                1027/*         0/0/0

On a broadcast network, blocking the L1 or L2 all IS’s destination MAC will result in the same condition as when blocking the IS Hello destination MAC on p2p: the adjacency will be stuck in INIT on one side.

Further Reading

https://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/200293-IS-IS-Adjacency-and-Area-Types.html

https://www.ciscopress.com/articles/article.asp?p=730191&seqNum=7

Hannes Gredler and Walter Goralski, The Complete IS-IS Routing Protocol, Chapter 5