In many ways, IS-IS is a simpler, and perhaps more elegant, routing protocol than OSPF. However, it often gets misunderstood. Perhaps due to its roots in OSI or perhaps because it’s not as widely deployed as OSPF. Some of the confusion come from how it behaves on multi-access networks. What is a Designated Intermediate System (DIS)? Why do we need a pseudonode? How do we flood Link State PDUs (LSPs)? In this post, I’ll cover all of that and more. This is going to be a deep dive so save this blog for when you have some time to focus.
IS-IS is a link state protocol, which means that we need to build a link state database that describes how all the intermediate systems (routers) are interconnected, and what prefixes they are associated with. Simply put, we need to build a graph. Let’s do a quick recap of graph theory.
A graph consists of vertices (nodes) and edges (links). When referring to a single node, it’s called a vertex. This is shown below:
There are different types of graphs. They can be undirected and unweighted:
With this type of graph, there is no weight assigned and there is no way of having asymmetric costs as there is a single edge between the two vertices.
The next type of graph is a directed graph:
With the directed graph, you can only travel in one direction. Think of a one-way street. Normally we would represent a single connection between two vertices with two edges because we want to be able to go in each direction.
All that missing now is to add weights to the edges. This is a weighted, directed graph:
When building a link state database (LSDB), the graph would look something like the image above. Why is this important?
Imagine that we have a network of six routers on the same multi-access network:
How would we represent this in the graph? Every vertex would need an edge to every other vertex. This means that we would need N*N(-1) edges, for a total of 30 edges. It would look something like this:
You can see that already with six routers the graph starts to get complicated. Now imagine if you had a 100 routers on the same multi-access network, for example using a L2 service from a service provider where you have a router at each location. Using the formula from before, that would be 100*99 = 9900 edges.
You may have been surprised at how this graph looks because most people think that the graph would look something like this:
However, while this graph shows a full mesh, it misses that we need two vertices between every vertex to be able to assign costs individually.
With an understanding of graphs, we can now start looking into how to create a simplified graph that makes it easier and faster to run shortest path first (SPF). In OSPF this would be achieved by using the Type 2 LSA where an Designated Router (DR) and Backup Designated Router (BDR) are elected. In IS-IS, we have the DIS. The DIS serves two purposes in IS-IS:
- Simplify the graph on multi-access networks by advertising a pseudonode
- Helping routers on the multi-access network to have a consistent view (synchronize)
What is a pseudonode? The pseudonode is the representation of the multi-access network as a node. Instead of every vertex having an edge to every other vertex, each vertex has an edge to the pseudonode and the pseudonode has an edge to every vertex. This is shown below:
Even by just the diagram you can see that it looks a lot simpler. We have gone from N(N-1) to N*2 links. Instead of 30 edges, we now have 12. Going back to the example with 100 routers, it would be 200 vertices instead of 9900!
The DIS gets elected based on priority on the multi-access segment. If there is a tie, the router with highest SNPA (Subnetwork Point of Attachment) wins (normally MAC address).
Now let’s look at how the pseudonode is advertised. In IS-IS, all information about a routers links, neighbors, and prefixes, are advertised in the LSPs. An LSP is identified by System ID, Pseudonode ID, and Fragment Number. A router with only a few interfaces will typically generate a single LSP, but the pseudonode is its own LSP. To demonstrate this, I’m using the following lab in CML with four routers in the same multi-access network and an additional router:
S1 is currently the DIS as we can see in the LSDB:
S1#show isis data IS-IS Level-2 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL S1.00-00 * 0x00000006 0x3AE1 967/* 0/0/0 S1.01-00 * 0x00000003 0x1B8B 1042/* 0/0/0 S2.00-00 0x00000005 0x8F89 966/1199 0/0/0 S3.00-00 0x00000005 0xE232 1002/1199 0/0/0 DC1.00-00 0x00000007 0x8FF6 1146/1199 0/0/0 DC2.00-00 0x00000007 0x8A44 1150/1198 0/0/0
All LSPs except one end in 00-00. The LSP, generated by S1, that ends with 01-00 is the LSP for the pseudonode.
Now lets look at the details of the LSDB, focusing on the LSPs that S1 and S2 generate:
S1#show isis data det IS-IS Level-2 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL S1.00-00 * 0x00000006 0x3AE1 955/* 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: S1 Metric: 10 IS-Extended S1.01 IP Address: 10.0.0.1 Metric: 10 IP 10.0.0.1/32 Metric: 10 IP 172.16.0.0/24 S1.01-00 * 0x00000003 0x1B8B 1029/* 0/0/0 Metric: 0 IS-Extended S1.00 Metric: 0 IS-Extended S2.00 Metric: 0 IS-Extended S3.00 Metric: 0 IS-Extended DC1.00 S2.00-00 0x00000005 0x8F89 954/1199 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: S2 Metric: 10 IS-Extended S1.01 IP Address: 10.0.0.2 Metric: 10 IP 10.0.0.2/32 Metric: 10 IP 172.16.0.0/24
Notice that in the LSP S1.00-00, S1 says that it is connected to the pseudonode (S1.01-00) with a metric of 10:
Metric: 10 IS-Extended S1.01 IP Address: 10.0.0.1
S2 has the same information:
Metric: 10 IS-Extended S1.01 IP Address: 10.0.0.2
In the pseudonode LSP, it shows that the pseudonode is connected to all the routers with a metric of 0:
S1.01-00 * 0x00000003 0x1B8B 1029/* 0/0/0 Metric: 0 IS-Extended S1.00 Metric: 0 IS-Extended S2.00 Metric: 0 IS-Extended S3.00 Metric: 0 IS-Extended DC1.00
Now that we understand the pseudonode and how it gets advertised, let’s move on to how the DIS ensures that the routers have the same view (are synchronized). We already know that we have LSPs advertising information, but there are two more packets we need to know about:
- Complete Sequence Numbers PDU (CSNP)
- Partial Sequence Numbers PDU (PSNP)
Note that sequence numbers for CSNP and PSNP refer to the range of LSP IDs values, in other words, a set of LSPs, not the sequence number of the individual LSP.
The CSNP is a list of all the LSPs that a router knows of. By advertising a list of all the LSPs you know of, other routers can compare it to the LSPs they know of. The two routers may be in full synch, or one router knows of a LSP that the other doesn’t. If missing any LSPs, the router can request them using a PSNP. One or more LSPs can be requested. The PSNP is also used to acknowledge one or more LSPs.
With an understanding of CSNP and PSNP, let’s look at what the role the DIS plays on multi-access networks. The DIS will by default generate a CSNP every 10 seconds. The DIS here is acting as a reference point for all the other routers. The CSNP lists all the LSPs it has in its LSDB and then the other routers compare the CSNP to their local LSDB as shown below:
Based on the comparison, there are three possible outcomes:
- The router has the same LSPs with the same LSP IDs and sequence numbers in the LSDB. No action needs to be performed, they are in synch.
- The CSNP has LSPs with LSP IDs that don’t exist locally, or the sequence number on the DIS is higher. The router needs a copy of those LSPs and it will request them using a PSNP. The PSNP is flooded onto the segment and the DIS receives it and floods the requested LSPs.
- The router has a LSP that the DIS doesn’t have, or with a higher sequence number locally. The router will update the DIS by flooding such LSPs onto the segment.
Now let’s take a closer look at CSNPs, PSNPs, and LSPs. First, we can see that the DIS is sending a CSNP roughly every 10 seconds:
Now let’s take a look at what the CSNP contains:
Frame 32: 100 bytes on wire (800 bits), 100 bytes captured (800 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Complete Sequence Numbers Protocol Data Unit
PDU length: 83
Source-ID: 0100.0000.0001
Source-ID-Circuit: 00
Start LSP-ID: 0000.0000.0000.00-00
End LSP-ID: ffff.ffff.ffff.ff-ff
LSP entries (t=9, l=48)
Type: 9
Length: 48
LSP Entry
LSP Sequence Number: 0x00000006
Remaining Lifetime: 1194
LSP checksum: 0x3ae1
LSP-ID: 0100.0000.0001.00-00
LSP Entry
LSP Sequence Number: 0x00000001
Remaining Lifetime: 1195
LSP checksum: 0x9730
LSP-ID: 0100.0000.0001.01-00
LSP Entry
LSP Sequence Number: 0x00000005
Remaining Lifetime: 1193
LSP checksum: 0x8f89
LSP-ID: 0100.0000.0002.00-00
At first, the CSNP has only S1 and S2 because they are currently not adjacent with S3 and DC1. Note that there is a sequence number and remaining lifetime associated with each LSP.
Now they are also adjacent with S3 so it will be included in the CSNP:
Frame 75: 116 bytes on wire (928 bits), 116 bytes captured (928 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Complete Sequence Numbers Protocol Data Unit
PDU length: 99
Source-ID: 0100.0000.0001
Source-ID-Circuit: 00
Start LSP-ID: 0000.0000.0000.00-00
End LSP-ID: ffff.ffff.ffff.ff-ff
LSP entries (t=9, l=64)
Type: 9
Length: 64
LSP Entry
LSP Sequence Number: 0x00000006
Remaining Lifetime: 1158
LSP checksum: 0x3ae1
LSP-ID: 0100.0000.0001.00-00
LSP Entry
LSP Sequence Number: 0x00000002
Remaining Lifetime: 1195
LSP checksum: 0x2e89
LSP-ID: 0100.0000.0001.01-00
LSP Entry
LSP Sequence Number: 0x00000005
Remaining Lifetime: 1157
LSP checksum: 0x8f89
LSP-ID: 0100.0000.0002.00-00
LSP Entry
LSP Sequence Number: 0x00000005
Remaining Lifetime: 1193
LSP checksum: 0xe232
LSP-ID: 0100.0000.0003.00-00
At this point S3 is missing LSPs from S1 and S2 so it requests them in a PSNP:
Frame 77: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Partial Sequence Numbers Protocol Data Unit
PDU length: 51
Source-ID: 0100.0000.0003
Source-ID-Circuit: 00
LSP entries (t=9, l=32)
Type: 9
Length: 32
LSP Entry
LSP Sequence Number: 0x00000000
Remaining Lifetime: 1199
LSP checksum: 0x0000
LSP-ID: 0100.0000.0001.00-00
LSP Entry
LSP Sequence Number: 0x00000000
Remaining Lifetime: 1199
LSP checksum: 0x0000
LSP-ID: 0100.0000.0002.00-00
S1 floods these LSPs onto the segment:
Frame 78: 103 bytes on wire (824 bits), 103 bytes captured (824 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Link State Protocol Data Unit
PDU length: 86
Remaining lifetime: 1157
LSP-ID: 0100.0000.0001.00-00
Sequence number: 0x00000006
Checksum: 0x3ae1 [correct]
[Checksum Status: Good]
Type block(0x03): Partition Repair:0, Attached bits:0, Overload bit:0, IS type:3
Area address(es) (t=1, l=4)
Protocols supported (t=129, l=1)
Hostname (t=137, l=2)
Type: 137
Length: 2
Hostname: S1
Extended IS reachability (t=22, l=11)
IP Interface address(es) (t=132, l=4)
Extended IP Reachability (t=135, l=25)
Frame 79: 103 bytes on wire (824 bits), 103 bytes captured (824 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Link State Protocol Data Unit
PDU length: 86
Remaining lifetime: 1156
LSP-ID: 0100.0000.0002.00-00
Sequence number: 0x00000005
Checksum: 0x8f89 [correct]
[Checksum Status: Good]
Type block(0x03): Partition Repair:0, Attached bits:0, Overload bit:0, IS type:3
Area address(es) (t=1, l=4)
Protocols supported (t=129, l=1)
Hostname (t=137, l=2)
Type: 137
Length: 2
Hostname: S2
Extended IS reachability (t=22, l=11)
IP Interface address(es) (t=132, l=4)
Extended IP Reachability (t=135, l=25)
Later, DC1 comes online and request LSPs S1, S2, and S3:
Frame 126: 84 bytes on wire (672 bits), 84 bytes captured (672 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Partial Sequence Numbers Protocol Data Unit
PDU length: 67
Source-ID: 0100.0000.0004
Source-ID-Circuit: 00
LSP entries (t=9, l=48)
Type: 9
Length: 48
LSP Entry
LSP Sequence Number: 0x00000000
Remaining Lifetime: 1199
LSP checksum: 0x0000
LSP-ID: 0100.0000.0001.00-00
LSP Entry
LSP Sequence Number: 0x00000000
Remaining Lifetime: 1199
LSP checksum: 0x0000
LSP-ID: 0100.0000.0002.00-00
LSP Entry
LSP Sequence Number: 0x00000000
Remaining Lifetime: 1199
LSP checksum: 0x0000
LSP-ID: 0100.0000.0003.00-00
S1 will flood those LSPs as can be seen below:
DC1 is now part of the CSNP:
Frame 139: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Complete Sequence Numbers Protocol Data Unit
PDU length: 115
Source-ID: 0100.0000.0001
Source-ID-Circuit: 00
Start LSP-ID: 0000.0000.0000.00-00
End LSP-ID: ffff.ffff.ffff.ff-ff
LSP entries (t=9, l=80)
Type: 9
Length: 80
LSP Entry
LSP Sequence Number: 0x00000006
Remaining Lifetime: 1114
LSP checksum: 0x3ae1
LSP-ID: 0100.0000.0001.00-00
LSP Entry
LSP Sequence Number: 0x00000003
Remaining Lifetime: 1189
LSP checksum: 0x1b8b
LSP-ID: 0100.0000.0001.01-00
LSP Entry
LSP Sequence Number: 0x00000005
Remaining Lifetime: 1113
LSP checksum: 0x8f89
LSP-ID: 0100.0000.0002.00-00
LSP Entry
LSP Sequence Number: 0x00000005
Remaining Lifetime: 1149
LSP checksum: 0xe232
LSP-ID: 0100.0000.0003.00-00
LSP Entry
LSP Sequence Number: 0x00000006
Remaining Lifetime: 1190
LSP checksum: 0x1092
LSP-ID: 0100.0000.0004.00-00
At this point the routers are fully synchronized and the CSNP will be sent every 10 seconds, but there will be no action to be taken unless something happens in the network that would require updating an LSP, such as:
- New adjacency
- Lost adjacency
- Prefixes added
- Prefixes removed
- New DIS
- Interface going down
- Change of metric
As we’ve seen, the DIS is only used as a reference point. It generates a CSNP that all the other routers compares to their local LSDB. Routers flood LSPs directly to the multi-access network without first sending them specifically addressed to the DIS. This is different to OSPF where DR/BDR sits in the flow of LSUs.
If a router learns of a new LSP, it floods it onto the multi-access segment. The DIS will advertised the LSP in the next CSNP. If it’s not in the CSNP, it must have been lost in transit (hah) and the router will flood it again onto the segment. If a specific router missed the flooded LSP for some reason, it can request it with a PSNP from the DIS when it learns of it in the CSNP.
Because the DIS doesn’t serve a critical role by sitting as an intermediary in the flow of LSPs, there is no reason to elect a backup DIS. No such concept exists in IS-IS. However, to detect a failure of DIS more quickly, it will set its Hello and Hold time to a third of what is configured. In the capture below, we can see that S1 (01.0000.0000.0001) sends Hellos much more frequently:
S1 (01.0000.0000.0001) is sending Hellos roughly every 3 seconds while the others are sending roughly every 10 seconds.
Now, we still want to understand what happens when the DIS fails. To test this, I enabled debugs on S3 and pinged an IP available via DC2, that is, a destination that is traversing the multi-access segment. The output below shows the debugs and the ping:
S3#show debug IP routing: IP routing debugging is on ISIS: IS-IS Update related packet debugging is on for router process null IS-IS CSNP/PSNP packets debugging is on for router process null IS-IS SPF Timing and Statistics Data debugging is on for IPv4 unicast topology base IS-IS SPF Timing and Statistics Data debugging is on for router process null on IPv4 unicast topology base IS-IS SPF events debugging is on for IPv4 unicast topology base IS-IS SPF events debugging is on for router process null on IPv4 unicast topology base IS-IS SPF triggering events debugging is on for IPv4 unicast topology base IS-IS SPF triggering events debugging is on for router process null on IPv4 unicast topology base IS-IS global RIB debugging is on for IPv4 unicast topology base IS-IS global RIB debugging is on for router process null on IPv4 unicast topology base S3#ping 10.0.0.5 re 100000 so lo0 Type escape sequence to abort. Sending 100000, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds: Packet sent with a source address of 10.0.0.3 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! <SNIP> Success rate is 99 percent (4416/4417), round-trip min/avg/max = 3/5/39 ms
No packets were lost when we lost the DIS! Let’s look at it in more detail.
S3 is now only adjacent to S2 and DC1:
S3#show isis nei System Id Type Interface IP Address State Holdtime Circuit Id S2 L2 Gi0/0 172.16.0.11 UP 29 S3.01 DC1 L2 Gi0/0 172.16.0.1 UP 20 S3.01
Let’s look at the LSDB:
S3#show isis data IS-IS Level-2 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL S1.00-00 0x00000006 0x3AE1 378/1157 0/0/0 S1.01-00 0x00000003 0x408B 0 (1163)/1199 0/0/0 S2.00-00 0x00000008 0xB55E 1157/1199 0/0/0 S3.00-00 * 0x00000007 0x0B06 1153/* 0/0/0 S3.01-00 * 0x00000001 0x5162 1153/* 0/0/0 DC1.00-00 0x00000009 0xAED3 1157/1199 0/0/0 DC2.00-00 0x00000007 0x8A44 519/1198 0/0/0
Note that the previous pseudonode, S1.01-00 now has a remaining lifetime of 0 and that there is a new pseudonode LSP named S3.01-00.
Let’s check the details of the LSDB:
S3#show isis data det IS-IS Level-2 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL S1.00-00 0x00000006 0x3AE1 324/1157 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: S1 Metric: 10 IS-Extended S1.01 IP Address: 10.0.0.1 Metric: 10 IP 10.0.0.1/32 Metric: 10 IP 172.16.0.0/24 S1.01-00 0x00000003 0x408B 0 (1109)/1199 0/0/0 Purge Originator: S3 Hostname: S3 S2.00-00 0x00000008 0xB55E 1103/1199 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: S2 Metric: 10 IS-Extended S3.01 IP Address: 10.0.0.2 Metric: 10 IP 10.0.0.2/32 Metric: 10 IP 172.16.0.0/24 S3.00-00 * 0x00000007 0x0B06 1099/* 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: S3 Metric: 10 IS-Extended S3.01 IP Address: 10.0.0.3 Metric: 10 IP 10.0.0.3/32 Metric: 10 IP 172.16.0.0/24 S3.01-00 * 0x00000001 0x5162 1099/* 0/0/0 Metric: 0 IS-Extended S3.00 Metric: 0 IS-Extended S2.00 Metric: 0 IS-Extended DC1.00 DC1.00-00 0x00000009 0xAED3 1103/1199 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: DC1 Metric: 10 IS-Extended DC2.00 Metric: 10 IS-Extended S3.01 IP Address: 10.0.0.4 Metric: 10 IP 10.0.0.4/32 Metric: 10 IP 172.16.0.0/24 Metric: 10 IP 172.16.1.0/30 DC2.00-00 0x00000008 0x8845 1156/1198 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: DC2 Metric: 10 IS-Extended DC1.00 IP Address: 10.0.0.5 Metric: 10 IP 10.0.0.5/32 Metric: 10 IP 172.16.1.0/30
We can see that S1.01-00 is being purged and that the originator was S3. The header of the LSP is still there, but the contents are gone.
Now let’s dive into the debugs. Before S1 interface is shutdown, we can see that we receive the CSNP and that it has the same contents as our LSDB:
*Apr 26 18:55:52.189: ISIS-Snp: Rec L2 CSNP from 0100.0000.0001 (GigabitEthernet0/0) *Apr 26 18:56:00.253: ISIS-Snp: Rec L2 CSNP from 0100.0000.0001 (GigabitEthernet0/0) *Apr 26 18:56:00.254: ISIS-SNP: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF *Apr 26 18:56:00.254: ISIS-SNP: Same entry 0100.0000.0001.00-00, seq 6 *Apr 26 18:56:00.255: ISIS-SNP: Same entry 0100.0000.0001.01-00, seq 3 *Apr 26 18:56:00.255: ISIS-SNP: Same entry 0100.0000.0002.00-00, seq 6 *Apr 26 18:56:00.255: ISIS-SNP: Same entry 0100.0000.0003.00-00, seq 5 *Apr 26 18:56:00.256: ISIS-SNP: Same entry 0100.0000.0004.00-00, seq 7 *Apr 26 18:56:00.256: ISIS-SNP: Same entry 0100.0000.0005.00-00, seq 7
Then the adjacency to S1 is lost (based on hello timers):
*Apr 26 18:56:51.397: %CLNS-5-ADJCHANGE: ISIS: Adjacency to S1 (GigabitEthernet0/0) Down, hold time expired
S3 builds a pseudonode LSP and floods it:
*Apr 26 18:56:51.406: ISIS-Upd: Building L2 pseudonode LSP for GigabitEthernet0/0 *Apr 26 18:56:51.409: ISIS-Upd: New LSP *Apr 26 18:56:51.409: ISIS-SPF-TRIG: L2, new LSP 0 0100.0000.0003.01-00 *Apr 26 18:56:51.410: ISIS-Upd: TID 0 full SPF required *Apr 26 18:56:51.439: ISIS-Upd: Sending L2 LSP 0100.0000.0003.01-00, seq 1, ht 1199 on GigabitEthernet0/0 via high priority queue *Apr 26 18:56:51.449: ISIS-Upd: TLV contents different, code 22
Note that a full SPF is required.
Because there is a new pseudonode, S3 must also update its own LSP (0100.0000.0003.01-00) and run a full SPF:
*Apr 26 18:56:51.450: ISIS-SPF-TRIG: L2, 0100.0000.0003.00-00 TLV contents changed, code 22 *Apr 26 18:56:51.451: ISIS-Upd: TID 0 full SPF required *Apr 26 18:56:51.451: ISIS-SPF-TRIG: L2 SPF needed, adjacency deleted, from 0x25802E4 *Apr 26 18:56:51.451: ISIS-SPF-TRIG: L2 SPF triggered after LSPGEN *Apr 26 18:56:51.511: ISIS-Upd: Sending L2 LSP 0100.0000.0003.00-00, seq 7, ht 1199 on GigabitEthernet0/0 via high priority queue
It then starts sending the CSNP onto the multi-access segment:
*Apr 26 18:56:51.923: ISIS-SNP: Sending L2 standard CSNP on GigabitEthernet0/0
The other routers also need to update their LSPs so they will flood it onto the multi-access segment and S3 will receive them:
*Apr 26 18:56:55.914: ISIS-Upd: Rec L2 LSP 0100.0000.0002.00-00, seq 8, ht 1199, *Apr 26 18:56:55.915: ISIS-Upd: from SNPA 5254.00d7.ddcc (GigabitEthernet0/0) *Apr 26 18:56:55.916: ISIS-Upd: LSP newer than database copy *Apr 26 18:56:55.917: ISIS-Upd: TLV code mismatch (132, 22) *Apr 26 18:56:55.918: ISIS-SPF-TRIG: L2, 0100.0000.0002.00-00 TLV code mismatch (132, 22) *Apr 26 18:56:55.918: ISIS-Upd: TID 0 full SPF required *Apr 26 18:56:55.955: ISIS-Upd: Rec L2 LSP 0100.0000.0004.00-00, seq 9, ht 1199, *Apr 26 18:56:55.955: ISIS-Upd: from SNPA 5254.00b7.638b (GigabitEthernet0/0) *Apr 26 18:56:55.956: ISIS-Upd: LSP newer than database copy *Apr 26 18:56:55.957: ISIS-Upd: TLV contents different, code 22 *Apr 26 18:56:55.958: ISIS-SPF-TRIG: L2, 0100.0000.0004.00-00 TLV contents changed, code 22 *Apr 26 18:56:55.959: ISIS-Upd: TID 0 full SPF required
S3 now purges the previous pseudonode LSP:
*Apr 26 18:57:01.413: ISIS-Upd: Purging L2 LSP 0100.0000.0001.01-00, seq 3 *Apr 26 18:57:01.432: ISIS-Upd: Sending L2 LSP 0100.0000.0001.01-00, seq 3, ht 0 on GigabitEthernet0/0 via high priority queue
This is what the purge looks like in a packet capture:
Frame 10666: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
IEEE 802.3 Ethernet
Logical-Link Control
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
ISO 10589 ISIS Link State Protocol Data Unit
PDU length: 40
Remaining lifetime: 0
LSP-ID: 0100.0000.0001.01-00
Sequence number: 0x00000003
[Checksum: [missing]]
[Checksum Status: Not present]
Type block(0x03): Partition Repair:0, Attached bits:0, Overload bit:0, IS type:3
Purge Originator ID (t=13, l=7)
Type: 13
Length: 7
Number of System IDs: 1
System ID: 0100.0000.0003
Hostname (t=137, l=2)
Type: 137
Length: 2
Hostname: S3
Looking at the SPF and RIB compute time, the impact was minimal:
*Apr 26 18:56:56.621: ISIS-Stats: SPF only compute time 0.024 *Apr 26 18:56:56.621: ISIS-Stats: IPv4 RIB only compute time 0.007 *Apr 26 18:56:56.622: ISIS-Stats: Complete L2 SPT, *Apr 26 18:56:56.622: ISIS-Stats: Compute time 0.031/0.031, 4/1 nodes, 1/3 links, 0 suspends
It took 24 ms to run SPF, and then 7 ms to update the RIB. This means that the impact is not noticeable for the event of electing a new DIS, flooding LSPs, purging, running SPF, and updating the RIB, but as always, your mileage may vary.
Summary
The way that IS-IS handles multi-access segments and especially the flooding is quite elegant. It represents the multi-access segment with a pseudonode, going from N*(N-1) edges to N*2. As opposed to OSPF, the DIS does not act as an intermediary, routers flood their LSPs onto the segment and the DIS simply acts as a reference point. It periodically (every 10 seconds by default) generates and sends a CSNP that consists of a list of the LSPs it has in its LSDB. Other routers will compare their own LSDB to the CSNP and see if they need to request a LSP by sending a PSNP. If the CSNP is missing LSPs, the routers will flood the LSP directly onto the segment, and not via the DIS.
Great article!
Thanks, Ken!