IS-IS Neighbor Discovery

Like other routing and signaling protocols IS-IS has built-in automatic neighbor discovery mechanism which is known by IIHs (IS-IS Hello PDUs), because IS-IS is not IP based protocol the IIH PDUs and all other IS-IS PDUs are directly encapsulated on the data-link layer.

IS-IS has two hierarchical levels (L1 and L2) and two network types (Point-to-Point and Broadcast) so it’s essential to have different types of hello messages or PDUs for serve these networks since the data-link layer for broadcast and P2P links have different style of addressing so they need different treatment, due to this differences  there are three IIH PDUs and they are  identified in the IS-IS PDU Type field in the IS-IS 8-bit common header that is attached to all the IS-IS messages as the following:

Level-1 LAN hello (PDU type 15)
Level-2 LAN hello (PDU type 16)
P2P hello (PDU type 17)

Each of which acting slightly different, Level1 and Level-2 LAN hellos or PDUs are used in broadcast network, whereas P2P hello is used in P2P links (P2P hellos can be used on Ethernet links in some circumstance).

once the IS-IS demon get enabled each router builds its IIH for the supported levels and send them out all the IS-IS capable interfaces (ISO enabled Interfaces in JunOS and CLNS enabled interfaces in IOS), these hellos or PDUs are carrying the desired information to negotiate the protocol parameters, these parameters include:

PDU Type field
Maximum area address field
Circuit type field
Holding time field
Source ID field
Priority field
DIS LAN-ID field

Other information are also carried in the IIH PDU but they are irrelevant to our discussion here.

1-PDU Type field is 1-byte length field that identifies the type of PDU that the IS-IS message is carrying.

2-Maximum area address field carries the configured areas (maximum 3 areas)

3-Circuit type field carries the circuit type configured on the interface, 1 for L1 2 for L2 or 3 for L1/L2, this field is also important for the P2P circuits because there is only one P2P IIH type, so the circuit type is used to identify which Level holding time to reset.

4-Source ID field carries the System-ID of the origin router.

5-Hold time field, this field used by the origin router to instructs the receiving router after how many seconds  the receiver can declare that the adjacency with the origin router is down, this timer is also used to calculate the interval of the hello PDUs (usually holding time/3=hello interval)

6-Priority field,  value 0-127 used in DIS election (default on IOS and JunOS to 64)

7-DIS LAN-ID, initially this field carries the origin system-id but once the adjacency is established this field will carry the DIS elected on the LAN.

IIH on Broadcast network.
When you enable IS-IS on a LAN interface the router builds the appropriate  hello PDU (according to the Levels enabled on that interface L1, L2 or L1/2) and send it in regular interval, most implementations have L1/L2 enabled by default, however Level-1 LAN hellos send to  multicast destination MAC address  01:80:c2:00:00:14, whereas Level-2 LAN hellos are send to multicast destination MAC address 01:80:c2:00:00:15, all routers running IS-IS on that segment including the local router are listing to this address, all IS-IS messages are send to these two multicast addresses, unicast communication will never happen between IS-IS routers, so once the router sends out the IIH all routers on the segment will receive the message, the tree-way hand-shake procedures will then followed to verify the communication between each two devices is working properly.

The IIH PDUs also used to verify MTU of the link by adding another TLV called Padding TLV, more details about the padding TLV and it’s function can be found in the IS-IS MTU Mismatch Post.

As example imagine that we have 3 routers JR1, JR2 and JR3 and they are running IS-IS on a GE interface which is connected to the same Ethernet segment, JR1 will build two IS-IS hellos (Level1 and Level2) and send them out each to the appropriate multicast destination MAC address and mark the interface with adjacency state NEW, R2 and R3 received JR1′s hellos and they will copy JR1′s MAC address from the layer 2 header of the received message and add it thier own hello message in a TLV called IS-Neighbor TLV (TLV#2) then they will send their own hellos out the GE interfaces, JR1 will receive this mesagge and will see his MAC address in the IS-Neighbor TLV (SeenSelf) so he will move the adjacency state from New to Initializing and generating a new IIH which will carry JR2 and JR3 MAC address in the IS-Neighbor TLV and change the adjacency state again to UP, JR1 and JR2 on the other hand will doing the same (SeenSelf then generates new IIH) and get the adjacency up.

JUNOS Level-1 and Level-2 LAN IIHs

mounir@JR1.core1> show log isis
Apr  7 09:32:18 trace_on: Tracing to "/var/log/isis" started
Apr  7 09:32:18.748497 Sending L1 LAN IIH on ge-0/0/0.0
Apr  7 09:32:18.748949     max area 0, circuit type l1l2
Apr  7 09:32:18.748974     hold time 27, priority 64, circuit id JR3.core3.02
Apr  7 09:32:18.748993     neighbor b0:c6:9a:23:7c:0
Apr  7 09:32:18.749009     neighbor b0:c6:9a:23:80:0
Apr  7 09:32:18.749025     speaks IP
Apr  7 09:32:18.749039     speaks IPv6
Apr  7 09:32:18.749070     IP address 150.0.0.1
Apr  7 09:32:18.749096     area address 49.0001 (3)
Apr  7 09:32:18.749115     restart RR reset RA reset holdtime 0
Apr  7 09:32:18.749135     packet length 62
Apr  7 09:32:18.749178 Sending L2 LAN IIH on ge-0/0/0.0
Apr  7 09:32:18.749196     max area 0, circuit type l1l2
Apr  7 09:32:18.749213     hold time 27, priority 64, circuit id JR3.core3.02
Apr  7 09:32:18.749229     neighbor b0:c6:9a:23:7c:0
Apr  7 09:32:18.749244     neighbor b0:c6:9a:23:80:0
Apr  7 09:32:18.749258     speaks IP
Apr  7 09:32:18.749272     speaks IPv6
Apr  7 09:32:18.749293     IP address 150.0.0.1
Apr  7 09:32:18.749315     area address 49.0001 (3)
Apr  7 09:32:18.749332     restart RR reset RA reset holdtime 0
Apr  7 09:32:18.749349     packet length 62
Apr  7 09:32:21.029220 Received L1 LAN IIH, source id JR3.core3 on ge-0/0/0.0
Apr  7 09:32:21.029338     intf index 68, snpa b0:c6:9a:23:80:0
Apr  7 09:32:21.029357     max area 0, circuit type l1l2, packet length 62
Apr  7 09:32:21.029375     hold time 9, priority 64, circuit id JR3.core3.02
Apr  7 09:32:21.029397     neighbor b0:c6:9a:23:78:0 (ourselves)
Apr  7 09:32:21.029413     neighbor b0:c6:9a:23:7c:0
Apr  7 09:32:21.029428     speaks IP
Apr  7 09:32:21.029446     speaks IPV6
Apr  7 09:32:21.029472     IP address 150.0.0.3
Apr  7 09:32:21.029496     area address 49.0001 (3 bytes)
Apr  7 09:32:21.029513     restart flags []
Apr  7 09:32:21.029566     updating neighbor JR3.core3
Apr  7 09:32:21.937635 ISIS L2 hello from JR3.core3 interface ge-0/0/0.0 absorbed
Apr  7 09:32:22.696952 Received L2 LAN IIH, source id JR2.core2 on ge-0/0/0.0
Apr  7 09:32:22.697199     intf index 68, snpa b0:c6:9a:23:7c:0
Apr  7 09:32:22.697221     max area 0, circuit type l1l2, packet length 62
Apr  7 09:32:22.697240     hold time 27, priority 64, circuit id JR3.core3.02
Apr  7 09:32:22.697261     neighbor b0:c6:9a:23:78:0 (ourselves)
Apr  7 09:32:22.697278     neighbor b0:c6:9a:23:80:0
Apr  7 09:32:22.697293     speaks IP
Apr  7 09:32:22.697311     speaks IPV6
Apr  7 09:32:22.697337     IP address 150.0.0.2
Apr  7 09:32:22.697361     area address 49.0001 (3 bytes)
Apr  7 09:32:22.697378     restart flags []
Apr  7 09:32:22.697432     updating neighbor JR2.core2

IOS Level-1 and Level-2 LAN IIHs

Apr 10 05:25:04.551: ISIS-Adj: Sending L1 LAN IIH on GigabitEthernet0/1, length 1497
Apr 10 05:25:07.851: ISIS-Adj: Sending L2 LAN IIH on GigabitEthernet0/1, length 1497
Apr 10 05:25:07.851: ISIS-Adj: Sending L1 LAN IIH on GigabitEthernet0/1, length 1497
Apr 10 05:25:09.083: ISIS-Adj: Rec L2 IIH from 0002.fc3b.f400 (GigabitEthernet0/1), cir type L1L2, cir id 0000.0000.0005.01, length 1497
Apr 10 05:25:09.739: ISIS-Adj: Rec L1 IIH from 0005.3206.63c2 (GigabitEthernet0/1), cir type L1, cir id 0000.0000.0004.01, length 1497
Apr 10 05:25:11.031: ISIS-Adj: Sending L1 LAN IIH on GigabitEthernet0/1, length 1497
Apr 10 05:25:13.655: ISIS-Adj: Rec L1 IIH from 0002.fc3b.f400 (GigabitEthernet0/1), cir type L1L2, cir id 0000.0000.0005.01, length 1497

Once the three-way hand-shake process is done, the DIS election process will take place which will be discussed in the next post IS-IS DIS in Practice.


No related posts.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

3 Responses to “IS-IS Neighbor Discovery”

  1. [...] the previous post IS-IS Neighbor Discovery we have discussed how IS-IS automatically discovers neighbors, in this post we will discuss the DIS [...]

  2. [...] Once the three-way hand-shake process is done, the DIS election process will take place which will be discussed in the next post IS-IS DIS in Practice. [...]

  3. The Is-Neighbor TLV used in IIH is TLV #6 and not #2 as mentioned.

Leave a Reply