IS-IS for IPv6: Multi-Topology and the Single-Topology Trap

IS-IS is the quietest way to break IPv6 in your network. It will happily form an adjacency, show every neighbor as up, and route IPv4 perfectly, while dropping your IPv6 traffic into a black hole on any link where IPv6 is not fully enabled. The reason is a default almost nobody thinks about: by default IS-IS runs a single topology, and IPv6 is forced to follow the IPv4 shortest-path tree whether or not IPv6 is actually usable along that path. This article shows the fix, multi-topology IS-IS, on real Cisco IOS XE 17.18, with the actual adjacency and the IPv6-only prefix it learns. It is part of the PingLabz IPv6 routing and services guide.

How IS-IS carries IPv6 in the first place

IS-IS was designed to be protocol-agnostic. It runs directly over the data link (not inside IP), and it advertises reachability using TLVs (Type-Length-Value structures) inside its link-state PDUs. Adding a new network-layer protocol means defining new TLVs, not redesigning the protocol. IPv6 support arrived exactly this way: two new TLVs, one for IPv6 reachability and one for the IPv6 interface address, plus a Network Layer Protocol ID (NLPID) that advertises "I speak IPv6" to neighbors.

Because IS-IS carries IPv4 and IPv6 in the same link-state database by default, the naive expectation is that turning on IPv6 "just works." And in a lab where every link is dual-stacked, it appears to. The problem only surfaces when your topology is not uniform, which in the real world it almost always is.

The single-topology default: the trap

Here is the mechanism that catches people. In its default mode, IS-IS computes one shortest-path-first (SPF) tree, based on the IPv4 metrics, and then uses that same tree to forward both IPv4 and IPv6. There is one topology, one SPF result, and IPv6 is a passenger.

Now picture a network where one link in the path is IPv4-only (perhaps an older segment nobody has migrated, or a link where IPv6 was simply never configured). IS-IS still considers that link part of the single topology because it carries IPv4. The single SPF calculation may well choose a path that crosses that IPv4-only link because it is the shortest for IPv4. IPv6 packets are then handed to a next hop that cannot forward them, because IPv6 is not enabled on that link. The result is a black hole: the routing table looks healthy, the adjacencies are up, and IPv6 traffic silently dies. Nothing in show isis neighbors hints at the problem, because the adjacency itself is perfectly fine. This is the single-topology trap, and it is exactly the kind of failure that eats an afternoon before someone thinks to question the topology mode.

Multi-topology: giving IPv6 its own SPF

The fix is multi-topology IS-IS (often abbreviated MT). With multi-topology enabled, IS-IS maintains and computes a separate topology and a separate SPF for IPv6. Each link can advertise its own IPv6 metric, and the IPv6 SPF only considers links that are actually IPv6-capable. An IPv4-only link simply does not appear in the IPv6 topology, so the IPv6 SPF routes around it. IPv4 and IPv6 now make independent forwarding decisions, which is what you want the instant your two address families do not overlay perfectly.

This is the same idea OSPF solves by running two completely separate processes (OSPFv2 for IPv4, OSPFv3 for IPv6). IS-IS keeps everything in one protocol instance and one adjacency, and simply computes two SPFs. That efficiency is a big part of why large service providers favour IS-IS: one protocol, one set of adjacencies, correct independent routing for both address families.

The configuration

Here is the working multi-topology configuration from CORE1 facing BR1 on the lab, IOS XE 17.18:

router isis PLZ
 net 49.0001.0000.0000.0002.00
 metric-style wide
 address-family ipv6
  multi-topology
interface Ethernet0/2
 ipv6 router isis PLZ
 isis network point-to-point

Walk through it line by line. The net (Network Entity Title) is the router's IS-IS identity: area 49.0001, system ID 0000.0000.0002, and the NSAP selector 00. metric-style wide switches IS-IS to wide metrics (more on why that is mandatory below). Under address-family ipv6, the multi-topology command is the whole point of the exercise: it tells IS-IS to compute a dedicated IPv6 SPF. On the interface, ipv6 router isis PLZ enables IPv6 IS-IS on that link, and isis network point-to-point tells IS-IS to treat the link as a point-to-point circuit, which skips the DIS (Designated Intermediate System) election you do not need on a link with only two routers.

The adjacency: one neighbor, both levels

With both ends configured, the adjacency forms. Note the level:

CORE1#show isis neighbors
Tag PLZ:
System Id       Type Interface     State Holdtime Circuit Id
BR1             L1L2 Et0/2          UP    27       02

The neighbor BR1 is up as type L1L2, meaning the router participates in both Level 1 (intra-area) and Level 2 (inter-area) routing, which is the IOS default until you constrain it. The state is UP and the holdtime counts down normally. This is the deceptive part: this output looks identical whether or not multi-topology is enabled and whether or not IPv6 is actually forwarding. The adjacency is a link-layer relationship; it tells you nothing about whether IPv6 SPF is correct. That is precisely why the single-topology trap is so easy to miss, the neighbor table lies by omission.

The IPv6-only prefix, learned correctly

The proof that IPv6 is genuinely routing lives in the IPv6 routing table. On the lab, BR1 hosts an IPv6-only branch LAN, and CORE1 learns it through IS-IS:

CORE1#show ipv6 route isis
I1  2001:DB8:99:66::/64 [115/20]
I1  2001:DB8:99:255::3/128 [115/20]

The I1 code is IS-IS Level 1. The prefix 2001:DB8:99:66::/64 is the IPv6-only branch LAN, learned across the point-to-point link and installed with the standard IS-IS administrative distance of 115 and a metric of 20. The second entry is BR1's loopback. Both arrived through the IPv6 topology, which is exactly what multi-topology gives you. In a single-topology network with a non-uniform path, those same prefixes could be present in the table yet point at a next hop that cannot forward IPv6, which is why "the route is in the table" is not by itself proof that IPv6 works end to end.

metric-style wide is not optional

This is the requirement people skip and then spend an hour debugging. IS-IS multi-topology does not work with narrow metrics. The original IS-IS metric style uses a 6-bit interface metric (values 0 to 63) and cannot carry the extended TLVs that multi-topology depends on. Multi-topology information is transported inside the wide-metric TLVs, so metric-style wide is a hard prerequisite, not a tuning preference. If you configure multi-topology under the IPv6 address family but leave the router on narrow metrics, MT simply will not engage, and you are quietly back in the single-topology trap you were trying to escape.

Wide metrics are what you want regardless of IPv6. Narrow metrics cap a single interface at 63 and a full path at 1023, which is far too coarse for modern networks. Wide metrics give a 24-bit interface metric and a 32-bit path metric, so link costs actually reflect bandwidth differences. Enable metric-style wide on every IS-IS router in the domain, consistently, before you turn on multi-topology.

A note on point-to-point circuits

The isis network point-to-point command on the interface is a small but worthwhile optimisation. On a link with exactly two routers, the default broadcast behaviour still elects a DIS and generates pseudonode LSPs, which is pure overhead when there can never be a third router on the segment. Declaring the circuit point-to-point skips the DIS election, reduces LSP flooding, and speeds up adjacency formation. Use it on any genuine point-to-point link (including routed Ethernet between two devices), and leave the default on true multi-access segments.

Migrating an existing IS-IS domain to multi-topology

You rarely deploy multi-topology on a greenfield network; you usually retrofit it onto a running IS-IS domain that started life IPv4-only. The order of operations matters. Do not flip one router to multi-topology while its neighbors are still single-topology, because a mismatch in topology capability between neighbors can drop the IPv6 routes you are trying to protect. IOS provides a transition keyword (multi-topology transition) precisely for this: it advertises both the old single-topology and the new multi-topology TLVs at the same time, so routers that have been converted and routers that have not can coexist while you work through the domain. Once every router is running multi-topology, you remove the transition keyword and the network is fully on MT. The safe sequence is: enable metric-style wide everywhere first, then add multi-topology transition everywhere, then remove transition once the whole domain is converted.

Plan the metric-style change carefully in a live network. Because narrow and wide metrics are advertised differently, mixing them across a domain during the change can cause temporary suboptimal routing. Many operators schedule the metric-style wide rollout as its own maintenance step, confirm the IPv4 topology is stable on wide metrics, and only then begin the multi-topology work. Rushing both changes together is how a routine IPv6 enablement turns into an outage.

Verifying that multi-topology actually engaged

Because the neighbor table cannot tell you whether MT is working, lean on the IPv6-specific and topology-specific show commands. show ipv6 route isis confirms the IPv6 prefixes are present with the expected I1 or I2 codes and sane metrics, as in the capture above. show isis ipv6 topology displays the dedicated IPv6 SPF result, which is the direct evidence that IS-IS is computing a separate tree for IPv6 rather than reusing the IPv4 one. And show isis database detail lets you inspect the TLVs in the link-state PDUs, where you can confirm the multi-topology reachability TLVs are actually present. If those TLVs are missing, the usual cause is that metric-style wide was never applied, or was applied on some routers but not others. The final and least deniable test is always a real IPv6 ping or traceroute end to end, because a black hole caused by an IPv4-only link only reveals itself in the data plane, never in the adjacency table.

Single-topology vs multi-topology at a glance

Key Takeaways

• IS-IS carries IPv6 with dedicated TLVs inside its existing link-state PDUs, so one protocol instance and one adjacency handle both address families.
• By default IS-IS runs a single topology: it computes one IPv4-based SPF and forces IPv6 to follow it. An IPv4-only link in the chosen path black-holes IPv6 while every adjacency still shows up.
• multi-topology under address-family ipv6 gives IPv6 its own independent SPF, so it routes around links where IPv6 is not enabled.
• metric-style wide is a hard requirement for multi-topology. Narrow metrics cannot carry MT information, and MT silently fails to engage without it.
• The adjacency table (show isis neighbors showing L1L2 UP) tells you nothing about IPv6 correctness. Confirm IPv6 with show ipv6 route isis and by testing real end-to-end reachability.

Multi-topology fixes IPv6 where you run IS-IS everywhere. When you cannot enable IPv6 on the core at all, you tunnel over it instead, which is the next article. For the full picture of IPv6 routing and services, return to the IPv6 guide.