Mostly ISIS is used in SP and OSPF is used in enterprise networks
Wherever i read there is a statement made that ISIS is more scalable than OSPF
Can u explain how is ISIS more scalable than ospf with a real scenario
Thanks
Hello Anoop
Take a look at this post:
I hope this has been helpful!
Laz
Hey Laz,
Can i have some inputs regarding UP/DOWN bit in ISIS in comparison with ATT bit.
Hello Richard
For information about the up/down bit, take a look at the following lesson:
For information bout the attached bit (ATT) take a look at this lesson:
In summary:
- Once a level 1-2 router is connected to another area, it will set the ATT bit in its level 1 LSP. When a level 1 router sees this, it will generate a default route that is pointed to the level 1-2 router.
- The up/down bit is used to indicate to an L1-L2 router not to redistribute a network that has already been redistributed. This is a loop prevention mechanism.
I hope this has been helpful!
Laz
Hello, everyone.
Everything is perfectly clear apart from the old CLNS-related things and addressing to me. CBT Nuggets state that IS-IS uses CLNS as its transport and that is where I hit a wall. This is how an IS-IS packet looks like in Wireshark:
Is ISO 10589 the CLNS header or something here? If so, what exactly does it do for us here? I probably compare it too much to UDP since I am used to seeing port numbers and such⊠why not omit it or move this information to the IS-IS header itself?
Also, does IS-IS operate on L2 or L3? It runs on top of an Ethernet Frame but is separated by ISO 10589 together with LLC that defines it as ISO Network Layer..
Also what is routeing? Iâve read the documentation and it also calls it routeing, is this some kind of inside joke or a typo that I am not understanding here? 
Thank you
David
Hello David
Well, not quite. ISO/IEC10589 is the international standard that defines the IS-IS protocol itself. This is the original definition of the protocol, defined way back in the 1990s. It was originally designed based on the OSI model, and for this reason, it was originally developed by ISO. IS-IS was later incorporated into RFCs by the IETF for use with IPv4, IPv6, and other TCP/IP-related uses, but its initial definition is rooted in the ISO organization.
For historical reasons, wherever you see ISO10589 in Wireshark, it simply means an IS-IS header and payload. Now this may introduce another confusion concerning the IS-IS HELLO âlayerâ that appears in Wireshark, but Iâll address that shortly.
This is a loaded question 
and thereâs a lot of detail that has to be shared for full comprehension. Much of it depends on who you ask, your perspective, and how itâs defined. Often, you will hear people say that ISIS exchanges messages using Layer 2, and this is what you will see most often, even in official documentation. I believe this is due to the fact that it doesnât rely on a Layer 3 protocol (IPv4 or IPv6), as OSPF or BGP do, to exchange routing protocol messages. It does depend on the use of the appropriate multicast IS-IS MAC addresses in Layer 2.
- 01:80:C2:00:00:14 â All Level-1 IS-IS routers
- 01:80:C2:00:00:15 â All Level-2 IS-IS routers
However, strictly speaking, the ISIS PDU in the capture is a Layer 3 PDU, since it is encapsulated within the Layer 2 Data Link sublayers of LLC and MAC (802.3 Ethernet).
Thatâs something else thatâs interesting. When IS-IS messages are exchanged, youâll see that the Ethernet frame being used is 802.3 and not Ethernet II (see your Wireshark capture). This means that the structure of the Data Link Layer in this particular case uses both the MAC and LLC sublayers. (Ethernet II, which is not IEEE-based, doesnât use the LLC sublayer).
Now, another question that comes up is, why does there seem to be another encapsulated packet called ISIS HELLO? Is this another Layer? Well, no, it isnât. Itâs still part of the IS-IS Layer 3 PDU, but Wireshark chooses to display it as a separate entity. Strictly speaking, it is still part of the L3 PDU. This is just a display issue.
This phrase is somewhat misleading. Hereâs what they really mean.
IS-IS belongs to the OSI/CLNS protocol family, not the TCP/IP suite. So when people say âCLNS transport,â they really mean IS-IS uses OSI-style encapsulation and addressing, not that thereâs a CLNS/CLNP header wrapping the IS-IS packet. So you wonât see a CLNS portion within Wireshark.
No typo or inside joke! âRouteingâ is the traditional British/Commonwealth English spelling used in many older ISO and ITU-T standards. It means exactly the same as âroutingâ. Many international standards bodies have used this spelling in the past, but this is rare to see today.
I hope this has been helpful!
Laz
Hello Laz.
This has been very helpful, thank you.
Do we know why IS-IS still runs above the 802.3 header and not Ethernet 2? I understand that IS-IS goes way back but they never decided to make a change and instead include IS-IS in the EtherType field in Ethernet 2? Because with how IS-IS is implemented, the EtherType field is not there and its job is instead handled by LLC.
Also, to finalize this, I need some clarification regarding CLNS, CLNP, NSAP and NET.
The old OSI addressing scheme that was used back then is called NSAP, correct? This is the weird address that we have to configure with IS-IS that defines the area the router is in and its system ID (the others are often ignored).
The last byte in the NSAP is called the NSEL. This portion identifies the network service on the box and is always 0. If this portion is set to 0, the overall NSAP address is called the Network Entity Title (NET) which identifies the box as a whole? Since it doesnât indicate any specific service.
ISO OSI Addressing
- An OSI L3 address is called Network Service Access Point (NSAP)
- 49.0001.0102.5525.5003.00
- 49.4ad0.6d87.f2c1.cafe.600d.f00d.00
Components:
- Authority and Format ID: 1B, determines how to interpret the rest
- Area ID: variable length, describes the area
- System ID: 6B, acts as the ID of the device (think of router ID)
- NSEL: 1B, identifies the network service on the box
- If NSEL=0, the address is called the Network Entity Title (NET)
Moving these two aside. I cannot wrap my head around how CLNS differs from CLNP and what uses what. CLNS performed a function similar to UDP and IP, itâs not exactly a protocol but itâs similar to an API as it lies somewhere between L3 and L4.
CLNP is the actual L3 protocol that uses NSAP addresses? Where exactly do CLNS and CLNP come into contact here?
We donât have to go deep as I assume this is old stuff, just a basic definition is fine!
Thank you
David
Hello David
The answer is a combination of various trends and approaches involved in creating and maintaining protocol standards. The first reason is what you have already stated: it was initially designed that way, using the IEEE 802.3 Ethernet standard, which leverages both the MAC address and the LLC sublayers.
When Ethernet II prevailed over IEEE802.3 in the mid-1990s as the primary Ethernet standard (when TCP/IP overtook Novellâs IPX standard), standards organizations ensured that compatibility between IEEE 802.3 and Ethernet II was maintained. And this was done in a very simple way. The difference between the two standards is in the Ethernet Header, and specifically in the 2-byte field that comes after the Source Address.
For Ethernet II this is called the EtherType field, while for IEEE 802.3 it is called the Length field. Network devices that support Ethernet are capable of recognizing both. How? Specifically:
- When the value of the field is †1500, the frame is considered an IEEE 802.3 frame, and the value is interpreted as the Length of the payload in octets or bytes.
- When the value of the field is â„ 1536, then the frame is considered an Ethernet II frame, and the field is interpreted as EtherType, that is, a field that indicates the protocol encapsulated within the payload of the frame (i.e. IPv4, IPv6 etc)
Now, because this framework works VERY well, and supports other technologies that use IEEE 802.3 (i.e. STP and LLDP), there was never any need to change it. Indeed, there is no technical, financial, or compatibility-based reason to change it. This, along with what is often called âstandardization inertia,â which is the resistance to change, has not required this change.
First of all, your explanation of your understanding is completely correct. It is true that when the NSEL is 00, the address identifies the network entity itself (the router) rather than a specific service on it. For IS-IS, you always configure a NET, not an NSAP with a non-zero NSEL. The NSEL is always fixed at 0 and never used for routing decisions.
This terminology is confusing because OSI strictly separates the concept of a service from the protocol that implements it. Even though TCP/IP does the same, it tends to blur these boundaries more than the stricter OSI approach. Letâs take a closer look at each of these to understand their differences and their roles:
CLNS (Connectionless Network Service): This is a service definition or API, not a protocol or packet format. It describes the service offered by the Network Layer to the upper layers, specifying things like connectionless, best-effort datagram delivery etc.
CLNP (Connectionless Network Protocol): This is the actual Layer 3 protocol defined in ISO 8473. Itâs the real packet format, headers, and forwarding rules implemented on the wire. CLNP is the protocol that implements and provides the CLNS service, and it uses NSAP addresses for routing and forwarding. CLNP is the OSI equivalent of IPv4/IPv6, itâs the actual Network Layer protocol.
In summary:
- Upper layers (Transport/Application) use the CLNS service interface
- The network actually forwards packets using the CLNP protocol
- CLNP implements CLNS
I think that the main confusion about these concepts is that in Cisco documentation and elsewhere, youâll often see âCLNSâ and âCLNPâ incorrectly used interchangeably. When people say âCLNS routingâ or âCLNS packets,â theyâre typically referring to CLNP. The formal distinction matters for understanding the architecture, but network engineers and documentation often blur the terms.
Youâre right, unless you are working closely with OSI-based protocols and applications beyond IS-IS, a definition at this point should be enough. However if youâd like to explore further, let me knowâŠ
I hope this has been helpful!
Laz
PS. I replaced your image with some text that says the same thing, just for copyright reasons⊠
Hello Laz.
My bad, I didnât know the Live presentations could be considered as copyrighted.
Iâve received a ton of great help from you here, thank you so much. I have one final question.
The hello packet is purposely filled with padding bytes to make it as large as its configured MTU. This is because IS-IS has no mechanism to determine what the neighborâs MTU is. I have no clue why they did not just add an extra field to it that would say what the routerâs MTU is but this is how it works.
My question is, shouldnât the hello have a size of 1514 here instead of 1513? Where does that one byte go?
It has a size of 1514 on LAN segments (interfaces not configured as P2P).
The P2P Hello is weird. It is displayed in Wireshark as P2P HELLO instead of L1/L2 HELLO. Apparently from what Iâve learned, on P2P links, there are no separate hello packets per level like there are on broadcast links.
It gets even more unusual when we realize why it is this way. Apparently, the P2P Hello includes a three-way handshake mechanism. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it.
From what I understand, without this mechanism, a router would consider a neighbor alive and well even if there is only unidirectional connectivity upon receiving a hello. I canât read it in Wireshark because Wireshark decided not to implement it
My question is, isnât there also the risk of having the exact same problem on LAN IS-IS networks? So why was this implemented only for P2P?
Thank you.
David
Hello David
This is an interesting one. I havenât found any definitive explanations for this behavior. I have examined some additional Wireshark captures of IS-IS hellos, and it seems that the size on the wire is always 1513 and not the expected 1514. This is not an issue of Ethernet II vs 802.3 with the LLC etc, because the MTU definition remains the same regardless of the structure of the headers. The official documentation of IS-IS states, as you suggested, that the padding should be such that it causes the frame to reach the maximum that the exit interface can safely transmit without fragmentation. Thatâs 1500 (1514 with headers) not 1499 (1513 with headers).
I believe it comes down to how vendors decide to implement the standard. Because the standard defines the purpose of the padding without being explicit, vendors are freer to implement the purpose as they see fit rather than strictly. For whatever reason, some implementations may decide to leave one extra byte available as a safety margin based on field tests and production network experience.
It is interesting that this Cisco documentation talks about IS-IS Padding behavior, and shows that the values are what you would expect âminus 1â but it doesnât explain why!
Although unidirectional failures can occur on both P2P and LAN segments, IS-IS implements a three-way handshake only on P2P links. This is a design choice by engineers to develop the protocol, and I donât know definitively why this is the case. My feeling, however, is that this is the case due to the nature of P2P links.
P2P links are much more susceptible to unidirectional failures, and the failure impact there is much more severe and harder to detect. On a P2P link, each router has exactly one neighbor, so a unidirectional failure can lead to a silent, false adjacency and blackholing of traffic. The three-way handshake ensures that both sides explicitly confirm bidirectional reachability before the adjacency is considered fully up.
On LANs, however, IS-IS relies on a different operational model involving a DIS, periodic CSNPs for syncing and verification, and redundant flooding behavior, which all together, tend to expose failures more visibly and correct them through database synchronization mechanisms. As a result, LAN failures are more likely to be detected indirectly and quickly, whereas P2P failures can remain silent. Make sense?
Well, we tend to err on the side of caution just to be sure that everything conforms to the laws. No worries!
I hope this has been helpful!
Laz