We don’t currently have any lessons on ISIS for IPv6, however, you can visit the following Member Ideas page to make any suggestions for future lesson topics. You may find that others have made similar suggestions to yours and you can add your voice to theirs.
In the meantime, you can visit the following Cisco documentation to get more insight into IS-IS for IPv6.
IS-IS’s support for multi-topology essentially allows the protocol to operate using both IPv4 and IPv6 simultaneously. It removes some restrictions that did not allow this using conventional IS-IS. This Cisco documentation describes it clearly in this way:
IS-IS multitopology support for IPv6 allows IS-IS to maintain a set of independent topologies within a single area or domain. This mode removes the restriction that all interfaces on which IS-IS is configured must support the identical set of network address families. It also removes the restriction that all routers in the IS-IS area (for Level 1 routing) or domain (for Level 2 routing) must support the identical set of network layer address families. Because multiple SPFs are performed, one for each configured topology, it is sufficient that connectivity exists among a subset of the routers in the area or domain for a given network address family to be routable.
For more information, take a look at the link to the documentation, and if you have any further questions, please feel free to ask!
What’s generally the best way to have a router take a specific path?
L2 routers always set the attached bit. What if one doesn’t really point to the rest of the network but to some stub location where the network ends? Our routers could happily install the default route towards it.
I know you can disable the attached bit but not sure how common that actually is. I guess it makes sense if the L2 router doesn’t connect to the rest of the network but in that case, you would need it to also leak routes from the area it’s connected to if you disable the attached bit.
Then there is also route leaking, like in this lessons’ scenario, for example. How common is this? If I have one prefix that I really want my routers to take the most optimal path for then sure, that’s fine. But if there are hundreds of them, route leaking would seem a bit off and I could just enable L2 on that router at that point.
One more thing, when it comes to these flags:
The RFC says this about N:
N-flag: Node Flag (Bit 2)
Set when the prefix identifies the advertising router, i.e., the
prefix is a host prefix advertising a globally reachable address
typically associated with a loopback address.
So all this flag means is that this is an address that identifies the advertising router, or is simply a loopback interface on the router?
You’re thinking about some important IS-IS design considerations. I’ll do my best to address them.
You’re right to be concerned about the ATT (attached) bit behavior. By default, any L1/L2 router that has L2 connectivity sets the ATT bit in its L1 LSPs. When L1-only routers see this bit, they automatically install a default route (0.0.0.0/0) pointing to the nearest L1/L2 router based on L1 metric. However, if an L1/L2 router connects to a “stub location” that doesn’t actually provide backbone connectivity, L1 routers will still happily install default routes toward it - potentially blackholing traffic. This is a real operational concern!
There are several ways to deal with this.
You can disable the ATT bit on that specific L1/L2 router using commands like set-attached-bit suppress or attach-bit send never (with varying syntax across platforms, make sure to check it out before applying.) Alternatively, you can keep that router as L1-only if it’s not a true area boundary router, or you can use route leaking to provide specific reachability if you suppress ATT.
Disabling the ATT bit is actually quite common in multi-exit designs or when certain L1/L2 routers shouldn’t attract default traffic. However, if you disable it, you must ensure L1 routers still have reachability via other methods.
One way to do that is indeed via route leaking. Your instinct about route leaking “hundreds of routes” is accurate, because it would defeat the purpose of the IS-IS hierarchy.
Route leaking is best used for either a small set of critical prefixes (typically 10-20 or fewer) that need optimal path selection, or for specific services like data center subnets, DNS servers, or BGP next-hop loopbacks in MPLS networks. It can also be useful for traffic engineering to specific destinations when the default “closest exit” behavior is suboptimal
If you find yourself needing to leak many routes, that’s usually a signal to reconsider your area design, either adjust boundaries, promote strategic routers to L1/L2, or flatten the hierarchy.
Concerning the N flag, essentially yes, practically speaking, it means “this prefix identifies the advertising router,” and that is typically a loopback address, but the key concept is router identification, not the interface type itself.
What the RFC is saying, as I understand it, is:
The N-flag means the prefix identifies the advertising router as a node
It is typically (but not obligatorily) a loopback address. This is just extra info given by the RFC dealing with best practice, but it’s not a hard and fast rule. Indeed, IS-IS does not care about interface type, only intent.
As best practice, you should always use loopbacks for N-flag prefixes.
The result is that other routers treat N-flag prefixes as stable router endpoints.