This topic is to discuss the following lesson:
Hi Rene,
Is there any way to make it P2P like OSPF ? Thanks
br//zaman
Hello Zaman,
There is yes, you can use this command:
R1(config-if)#isis network ?
point-to-point Specify ISIS point-to-point networkYou can use this on broadcast networks (like Ethernet) when you only have two routers. This disables the creation/election of a DIS so it’s more efficient.
Rene
Hello Rene
i have Problem with understanding that DIS / PSN
please explain it to me more simple
Which is far less than the six neighbor adjacencies we would have without the pseudonode where each router would report three neighbor adjacencies.
As per this sentence there are only 3 neighbor adjacencies. But when we configured ISIS each routers have full mesh Neighbourship with each other .I am still confuse how does DIS help to reduce the neighbor adjacencies ?
Thanks in advance
Hello BGP
With the pseudonode, there are a total of four adjacencies in the whole topology. If there were no pseudonode, each router would have to create an adjacency with every other router. That means:
- R1 - R2
- R1 - R3
- R1 - R4
- R2 - R3
- R2 - R4
- R3 - R4
So by using the pseudonode you reduce the number of adjacencies, you reduce the complexity of the topology, and you reduce the number of updates that have to be exchanged between particular routers.
Actually, as per the sentence, each router reports three adjacencies. The total number of adjacencies or unique pairs of routers in the list above is six.
The idea is similar to the use of the DR and BDR in OSPF. In order to appreciate this even more, let’s take an example of 10 routers. WIth 10 routers using a pseduonode, you have 10 adjacencies. Without a pseudonode, if you do the calculations you’ll find you will have 45 adjacencies!
I hope this has been helpful!
Laz
Another issue is that the link-state database can grow exponentially. Can you explain a bit more about it? How LSD may grow without Pseudonode. As Each router will send the LSP and others are going except it. Eventually, all routers receive the LSP from each router in LAN. In that case how come link-state database got reduced with pseudonode
I don’t quite understand.
In OSPF will not create adjacencies between BDR. Thus, it can reduce the number of neighbors.
But in ISIS, it still creates adjacencies for each one, what is the point？
Hello Kevin
When implementing OSPF, if there are many routers connected to the same broadcast domain, a DR and BDR election takes place. All routers in the broadcast domain create two neighbor adjacences: One to the DR and one to the BDR. There is also an adjacency between the DR and BDR.
When implementing IS-IS, there is a similar mechanism. The Designated IS (DIS) is elected and it creates a virtual router called a pseudonode. This pseudonode plays the corresponding role of the DR in OSPF. However, in this case, each router will create a single neighbor adjacency with this virtual device. Even the physical DIS creates an adjacency (internally) to the pseudonode.
So each IS-IS router doesn’t create an adjacency with every other router in the broadcast domain, but only a single adjacency to the pseudonode. Does that make sense?
I hope this has been helpful!
Laz
Thank you in advance. I’m still a little confused
You said
“So each IS-IS router doesn’t create an adjacency with every other router in the broadcast domain, but only a single adjacency to the pseudonode”
But I saw each router create an adjacency with every other route in this picture
How does this make sense?
Hello Kevin
Ah yes, that’s a great observation! Let me clarify. The purpose of the DIS and pseudonode is to reduce the number of adjacencies in the flooding of LSDB updates, not the actual discovery of neighbors or forming of relationships.
The output of the show isis database does indeed show a full mesh of adjacencies, but these adjacencies weren’t discovered using individual exchanges of updates between those neighbors. They were established with the exchange of updates between each individual IS-IS router and the pseudonode alone. This reduces the number of exchanged packets.
So even though routers discover each other, full adjacencies (for the purpose of database synchronization) on broadcast networks are only formed with the pseudonode (DIS). This is where the efficiency comes in – rather than each router having a full adjacency with every other router, they all just have one with the pseudonode. This minimizes the LSDB update flooding.
Unlike OSPF, IS-IS makes the distinction between:
- adjacencies for the purpose of database synchronization
- and IS-IS neighbor adjacencies
I hope this has been helpful!
Laz
Hello, everyone.
So if I understand this right, everyone builds an adjacency with everyone else, the LSPs aren’t centralized (sent to the DIS first and then to everyone else) and anyone (with the right priority) can just take over this role.
So basically anything that OSPF had is almost completely different here. In this case, the DIS is used to help routers on the broadcast segment to synchronize and to represent the broadcast segment in the LSPDB (which OSPF shares too via Type 2 LSAs).
The flooding of LSAs and the number of adjacencies was the primary reason why the DR in OSPF was invented, right? If I understand this right, IS-IS fixes it this way:
- Everyone is fully meshed with everyone but from the perspective of the LSPDB, no one is aware of this as they see the pseudonode in the middle.
- LSPs are only flooded under the following circumstances:
- The DIS sends CSNPs periodically
- If a router has an LSP but its sequence number is lower (or the LSP isn’t in the LSPDB), it can request the LSP via a PSNP from the DIS.
- If a router has an LSP but its sequence number is higher, it will send the LSP to everyone.
In OSPF, without the DR, everyone would flood everything to its neighbors. For ex: R1 would learn something from R2 and then flood that exact same thing to all its neighbors on the segment ,even though they already received the LSA from R2.
In IS-IS, flooding only happens if the DIS advertises a CSNP that lacks something.
Basically, everyone just relies on the DIS. They don’t acknowledge the routing updates they receive from the neighbors.
For example, if I advertise something to the DIS, the DIS does not acknowledge it. What it does instead is advertise a CSNP where the LSP that I just advertised should be included - that’s my acknowledgement. If it isn’t there, I retransmit it.
If the DIS (or anyone else) advertises something to other routers, the routers do not acknowledge it at all. They literally just rely on the fact that the DIS will generate CSNPs and if they see something lacking, they will just request or flood it. If they don’t request or flood anything, it means their database is stable.
This leads to another funny thing which is that the PSNP packets are only used for requests and not acknowledgements which is the opposite of how a P2P segment works.
Thank you!
David
Hello David
It looks like you have a solid understanding of the operation of IS-IS:
- Everyone builds adjacencies with everyone else
- LSPs are not centralized
- Anyone can take over the DIS role
- The DIS is there to sync via CSNPs
Your flooding description is also spot on. The only thing that I could clarify further on is this statement:
LSP flooding is actually immediate and proactive, not triggered by CSNPs.
Otherwise, I believe you’re solid! 
I hope this has been helpful!
Laz
Hello Laz
LSP flooding is actually immediate and proactive, not triggered by CSNPs.
I mean’t it in the sense that if a router discovers that it lacks something, it will request it via a PSNP and it will be flooded. Any new/updated LSAs are immediate.
I have one more question. IS-IS also separates links from subnets, right? If we consider this topology (the only broadcast segment is the SW1 segment, all others are P2P)
For example, if we examine what R6 has to say about itself:
We can deduce the following:
R6 has a neighbor called R3 and it has a cost of 10 to reach it.
Unlike OSPFv2, IS-IS doesn’t specifically say what network resides there on that specific link. All we know is that it exists somewhere on R6, which is similar to OSPFv3 - the links are separated in T1/T2 LSAs while the subnets are in their own Type 8/9 LSAs.
In other words, the links and subnets are separated. The routers do not say “here on this link, this network resides”.
If I understand this right, this would mean in IS-IS that a full SPF is performed only if something related to the neighbor entry changes, not the IP entry.
If the IP entry changes but the neighbor entry is still the same, the physical path hasn’t changed and it would be pointless to run a full SPF
On the other hand, if the neighbor entry (IS entry or link entry if I may call it that) changes, that means that a physical path has probably changed and that a full SPF recomputation is necessary.
Thank you
David
Hello David
Yes, your understanding is correct. You’ve essentially discovered one of the key architectural strengths of IS-IS, which is the separation or the “decoupling” of topology information (links/adjacencies) from reachability information (IP prefixes). And indeed it does function like OSPFv3 in this aspect.
This is indeed correct. Since the SPF tree is built from IS-neighbor relationships, when only a prefix changes, IS-IS can simply use the already-computed SPF tree, attach the new prefix to the appropriate node, and update the routing table incrementally. This is much more CPU-efficient than running full SPF, especially in large networks where prefix changes are far more frequent than topology changes. And this is one of the many reasons that IS-IS is a routing protocol that is preferred as the underlay IGP for large networks.
It’s amazing to see that a protocol like IS-IS has had this decoupling in its design for so many years, and OSPF has only now introduced this decoupling in v3. It just goes to show you how well these protocols were designed way back when…
I hope this has been helpful!
Laz
Hello Laz.
Thank you very much for confirming 
I have one more thing to confirm. The SysID has to be unique in IS-IS and two routers will not become adjacent if they share the same SysID.
If the neighbors are not directly connected, you can still have a problem. The router will refuse the LSA if it sees that it comes from someone with the same System ID as it.
What about the other areas? Can two routers in separate areas have the same SysID?
The routers don’t really see eachother but I am not sure how a L2 router would respond to this if it saw the same SysID either in both L1 and L2 LSDB or only in the L2 LSDB.
Or to put this better, a router in Area 1 can share the same SysID as a router in Area 2. These routers will never see eachother. Even the L2 routers in Area 1 and Area 2 will not be aware of this (considering that they only have the L2 LSDB for foreign areas and this LSDB only contains the routers and links in the backbone. Foreign neighbors/links aren’t advertised into the backbone).
The only exception that I can think of is that if you configure the same SysIDs on L2 routers that are connected to the backbone, that will definitely cause problems.
Thank you
David
Hello David
This is another one of those “what if” scenarios that helps us understand not only the operation of the protocol, but also the architectural intent.
Under certain circumstances, a duplicate SysID in two different L1 routers in two different IS-IS areas will not cause problems, as you described very well. Although it may not cause immediate unpredictable behavior, it is still a bad practice for the following reasons:
- It creates confusion in network management and troubleshooting
- It prevents or at least complicates future network changes (upgrading routers to L1/L2, area mergers)
- It may break if you use MPLS Traffic Engineering or certain route-leaking features
- It makes monitoring by NMSes impossible due to a lack of uniqueness identifying IS-IS routers (since the SysID is typically used)
This is why the ISO 10589 standard explicitly states that a global uniqueness is required. So, although it can work, it does complicate things in the mentioned areas, and for this reason should be avoided.
I hope this has been helpful!
Laz