This topic is to discuss the following lesson:
Is the maximum composite 1023 and 63 or 1024 and 64? ENSLD 2.0 says 1024 and 64
Hello Chase
In the context of the IS-IS protocol, the maximum values for composite metrics can be a source of confusion due to the specifications and implementations. Here are some aspects of this topic that will help to clarify:
What are the maximum composite metrics in IS-IS:
-
Default IS-IS Metrics:
- IS-IS uses a default metric of 10 for links, and the maximum default metric value for a single link is 63.
-
Wide Metrics:
- With the introduction of “wide metrics” to accommodate larger networks and provide more granular control over path selection, the maximum metric for a single link is extended to 16,777,215 (2^24-1).
- However, composite metrics for calculating the path can differ. The composite metric is essentially the sum of individual link metrics along the path.
Now the Cisco ENSLD 2.0 mentions the maximum composite values as 1024 and 64. However, this might be based on Cisco’s specific implementation or configuration context.
According to most sources, the values of 1023 and 63 are traditionally seen in older or default configurations without wide metric extensions. The 1024 and 64 values are likely referencing specific configurations or extensions, possibly considering a limit imposed by specific hardware or software versions.
Looking at the official RFC 1195 on page 17 it seems to alude to a maximum of 63. You have to remember that some vendors may not adhere strictly to the rules in the RFC and may adjust them as needed.
So there’s no official answer, I guess it really depends upon the implementation that you are using. If you’re using Cisco devices, I would trust the Cisco documentation.
I hope this has been helpful!
Laz
Hello, everyone.
I found something weird when labbing and I would like to confirm this. If I configure this NSAP address on one of my XE routers - net 0002.3333.3333.3333.00. It will advertise its Area Address like this:
I believe the IOS moves the first two zeroes that I have configured into the AFI part (since NET addresses start with XX.XXXX …).
If I configure this NSAP address on one of my neighboring XR routers - net 0002.4444.4444.4444.00. It will advertise its Area Address like this:
It like completely ignores the first two zeroes and moves the 02 instead into the AFI part.
My routers would not establish an L1 adjacency because of this. Is this normal behaviour? Like does XR just refuse to use 00.xxxx unless I manually tell it to?
My other question is, is it possible to fix this without completely changing the area address? It’s impossible with XR to configure the area address as 00.02. If I do that, it just converts the 02 into 0002.
Thank you
David
Hello David
This is expected behavior, and it is related to the use of 00 (in hexadecimal) for the AFI. This addressing scheme was designed for a much broader use, rather than just for ISIS. In this sense, the AFI plays an important role, informing routers about who owns the address space and how the rest of the NSAP should be interpreted.
00 is a reserved/undefined AFI within the ISO standard. It does not point to any public or private authority, nor is it considered a valid numbering plan. So, for the purposes of ISIS, it is a bad practice to use it because it can be interpreted in unpredictable ways by various vendors and platforms.
IOS-XR is generally stricter in its interpretation of protocols, due to its primary use within provider networks. When it sees the reserved/undefined values of 00 for the AFI, it strips those bytes completely, considering them unusable, and uses an area address of 02. IOS-XE on the other hand is not so strict, so it accepts the use of the 00 as the AFI, thus interpreting the command differently, and ultimately getting a different area ID. Since the Area IDs are different, the adjacency cannot form.
As far as I know there is no way to make IOS-XR recognize 00 as a legitimate AFI.
Now, having said all of this, 00 should never be used as the NET for use with IS-IS, exactly for the reasons shown by your experimentation. The use of 49 is almost universally adopted to ensure compatibility and predictable behavior across platforms and vendors.
I hope this has been helpful!
Laz
1 Like
Hello, everyone.
When running wide metrics, the TLVs that were used before to advertise prefixes, such as IP Internal Reachability and IP External Reachability are changed.
They now use the IP Extended Reachability and Extended IS Reachability
Here is my Wireshark capture, the first one is for narrow metrics and the remaining ones are wide
From what I understand, these TLVs were intended for MPLS TE but they have a 32-bit metric field which was used to provide support for wider metrics.
My question is, when Multitopology is configured, my books state that there should be the following TLVs:
Multi Topology Reachable IPv6 Prefixes
Multi Topology Reachable IPv4 Prefixes
I did find the IPv6 in Wireshark but any IPv4 prefixes are advertised as Extended IP Reachability. Do we know whether the second TLV is being used or not?
Thank you
David