The first two blog posts gave us working IGPs. In this stage, we’ll force the IGP to carry only what needs to be there, start up without creating transient black holes, and behave predictably when a P-router reboots after a maintenance window.
This post covers four optimizations applied across both providers: prefix suppression, overload bit, LSP MTU/fragmentation, and hello padding. And one platform-specific bug in IOS-XE’s IS-IS implementation that produced an unexpected result with no error message.
Topology file: topology.clab.yml · Addressing: ipam.md · Stage configs, all sixteen nodes: stage_configs/lab01-s1c-igp-opt/
The Problem with a basic IGP configuration
After previous stages with IS-IS and OSPF configuration, the routing tables on every router carry more than loopbacks. B-ASBR’s IPv6 IS-IS RIB looks overloaded:
B-ASBR#show ipv6 route isis
IPv6 Routing Table - default - 26 entries
I2 2001:DB8:2::1/128 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2::2/128 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2::3/128 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2::4/128 [115/20]
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2::5/128 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2::6/128 [115/30]
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2::7/128 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:10::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:11::/64 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2:12::/64 [115/20]
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2:13::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2:14::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:15::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:16::/64 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:17::/64 [115/30]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2:18::/64 [115/20]
via FE80::E00:E9FF:FE37:CD04, GigabitEthernet3
I2 2001:DB8:2:19::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2
I2 2001:DB8:2:1C::/64 [115/20]
via FE80::E00:17FF:FE0F:2706, GigabitEthernet2Seven loopbacks and eleven transit /64s, in a network with eight routers. B-ASBR does not need a single one of those /64s to do its job – it just needs to reach the other seven loopbacks.
The transit /64 subnets are in the RIB because every interface participating in IS-IS advertises its connected prefix into the LSDB. This is correct behavior for a basic IS-IS deployment. But in a service provider network on a large scale, a few other things need to be taken into account:
- Every transit /30 and /64 is an unnecessary FIB entry on every router in the domain
- The LSDB is larger than it needs to be, increasing SPF computation time
- Globally reachable transit links are an attack surface
- LDP, BGP, and all services need only loopback-to-loopback reachability
SP-A: OSPF Prefix Suppression
OSPF prefix suppression stops the router from advertising the prefixes attached to its transit interfaces. The adjacency stays in the Type-1 Router LSA. SPF still sees the topology; the RIB stops seeing the /30s and /64s. All transit routes disappear.
Every SP-A node runs passive-interface default with no passive-interface on the transit links, so Loopback0 is the only passive interface in the process.
IOS-XE OSPFv2:
router ospf 1
prefix-suppressionIOS-XE OSPFv3:
router ospfv3 1
address-family ipv6 unicast
prefix-suppression
exit-address-familyThe OSPFv3 command must go inside address-family ipv6 unicast. I’ll be hit by a similar problem with IS-IS IPv6.
On IOS-XR, the same configuration works at the process level. SP-A’s route reflector A-RR is an XRd-CP node, and its S1C delta is prefix-suppression directly under router ospf 1 and again under router ospfv3 1.
Applied to all 8 SP-A nodes. A-ASBR’s IPv4 table before:
A-ASBR#show ip route
10.0.0.0/8 is variably subnetted, 24 subnets, 2 masks
O 10.1.0.1/32 [110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
O 10.1.0.2/32 [110/3] via 10.1.1.41, 1d01h, GigabitEthernet2
O 10.1.0.3/32 [110/3] via 10.1.1.45, 01:33:12, GigabitEthernet3
[110/3] via 10.1.1.41, 01:37:57, GigabitEthernet2
O 10.1.0.4/32 [110/2] via 10.1.1.45, 01:33:12, GigabitEthernet3
O IA 10.1.0.5/32 [110/3] via 10.1.1.41, 01:28:54, GigabitEthernet2
O IA 10.1.0.6/32 [110/3] via 10.1.1.45, 01:24:32, GigabitEthernet3
O 10.1.0.7/32 [110/3] via 10.1.1.41, 01:20:39, GigabitEthernet2
C 10.1.0.8/32 is directly connected, Loopback0
O 10.1.1.0/30 [110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
O 10.1.1.4/30 [110/3] via 10.1.1.45, 01:33:12, GigabitEthernet3
[110/3] via 10.1.1.41, 1d01h, GigabitEthernet2
O 10.1.1.8/30 [110/2] via 10.1.1.45, 01:33:12, GigabitEthernet3
O 10.1.1.12/30 [110/2] via 10.1.1.45, 01:33:12, GigabitEthernet3
[110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
O 10.1.1.16/30 [110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
O IA 10.1.1.20/30 [110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
O IA 10.1.1.24/30 [110/3] via 10.1.1.41, 00:23:31, GigabitEthernet2
O IA 10.1.1.28/30 [110/3] via 10.1.1.45, 01:20:39, GigabitEthernet3
[110/3] via 10.1.1.41, 01:37:04, GigabitEthernet2
O IA 10.1.1.32/30 [110/2] via 10.1.1.45, 01:33:12, GigabitEthernet3
O 10.1.1.36/30 [110/2] via 10.1.1.41, 1d01h, GigabitEthernet2
C 10.1.1.40/30 is directly connected, GigabitEthernet2
L 10.1.1.42/32 is directly connected, GigabitEthernet2
C 10.1.1.44/30 is directly connected, GigabitEthernet3
L 10.1.1.46/32 is directly connected, GigabitEthernet3
C 10.255.0.0/30 is directly connected, GigabitEthernet4
L 10.255.0.1/32 is directly connected, GigabitEthernet4Ten of those twenty-four subnets are transit /30s A-ASBR learned through OSPF. Two of them – 10.1.1.20/30 and 10.1.1.24/30 – are O IA, which means an ABR built a Type-3 Summary LSA for a point-to-point link in Area 1 and flooded it into Area 0. The same table after the prefix-suppression change:
A-ASBR#show ip route
10.0.0.0/8 is variably subnetted, 14 subnets, 2 masks
O 10.1.0.1/32 [110/2] via 10.1.1.41, 2d23h, GigabitEthernet2
O 10.1.0.2/32 [110/3] via 10.1.1.41, 2d23h, GigabitEthernet2
O 10.1.0.3/32 [110/3] via 10.1.1.45, 1d23h, GigabitEthernet3
[110/3] via 10.1.1.41, 1d23h, GigabitEthernet2
O 10.1.0.4/32 [110/2] via 10.1.1.45, 1d23h, GigabitEthernet3
O IA 10.1.0.5/32 [110/3] via 10.1.1.41, 1d23h, GigabitEthernet2
O IA 10.1.0.6/32 [110/3] via 10.1.1.45, 1d23h, GigabitEthernet3
O 10.1.0.7/32 [110/3] via 10.1.1.41, 1d23h, GigabitEthernet2
C 10.1.0.8/32 is directly connected, Loopback0
C 10.1.1.40/30 is directly connected, GigabitEthernet2
L 10.1.1.42/32 is directly connected, GigabitEthernet2
C 10.1.1.44/30 is directly connected, GigabitEthernet3
L 10.1.1.46/32 is directly connected, GigabitEthernet3
C 10.255.0.0/30 is directly connected, GigabitEthernet4
L 10.255.0.1/32 is directly connected, GigabitEthernet4Twenty-four subnets down to fourteen. Every O and O IA row left is a /32 loopback: seven learned, plus A-ASBR’s own as C. Loopback-to-loopback reachability is untouched because the adjacency in the Router LSA is still in the database.
SP-B: IS-IS advertise passive-only
IS-IS prefix suppression works differently than OSPF. The IS-IS equivalent of an OSPF LSA is the Link State PDU, or LSP: one per router, carrying its adjacencies and its reachable prefixes. advertise passive-only tells IS-IS to advertise prefixes only from interfaces marked passive. Transit interfaces are active – they form adjacencies – so their connected /30 and /64 prefixes are not passive and get suppressed. Loopback0 is passive and gets advertised.
If the link prefixes are gone from the LSP, the obvious question is where the next-hop comes from. It comes from the Hello. IS-IS advertises the interface address in the Hello PDU as well as in the reachability TLVs, so a neighbour still learns which address to use to reach whatever sits behind that adjacency. Suppressing a prefix from the LSP removes it from everyone’s RIB without touching the adjacency that resolves it.
advertise passive-only only works if the loopback is explicitly flagged as passive. Without the passive flag on Loopback0, it’s treated as a non-passive interface, and its prefix is also suppressed.
IOS-XE: passive-interface Loopback0 under router isis IOS-XR: passive under router isis / interface Loopback0
IOS-XE IS-IS advertise passive-only is IPv4-Only
After I added the passive loopback config, the IPv4 IS-IS RIB was clean, but the IPv6 RIB was still holding interconnect prefixes.
All four leaking LSPs were IOS-XE – B-P2, B-P3, B-P4, B-ASBR. The clean ones were IOS-XR – B-P1, B-PE1, B-PE2, B-RR.
Unfortunately, I have no captures of that intermediate state – it was fixed when I applied the change, so I only have a small note from the captures. Here is B-ASBR’s LSP from the previous stage, before any suppression went on:
IP Address: 10.2.0.8
Metric: 10 IP 10.2.0.8/32
Metric: 10 IP 10.2.1.40/30
Metric: 10 IP 10.2.1.44/30
IPv6 Address: 2001:DB8:2::8
Metric: 10 IPv6 (MT-IPv6) 2001:DB8:2::8/128
Metric: 10 IPv6 (MT-IPv6) 2001:DB8:2:1A::/64
Metric: 10 IPv6 (MT-IPv6) 2001:DB8:2:1B::/64Metric: 10 is an interface prefix; Metric: 0 is the loopback. Working prefix suppression means every Metric: 10 prefix line disappears, and the two loopback lines drop to Metric: 0.
Root cause: On IOS-XE, advertise passive-only under the root router isis context applies only to the Standard (IPv4 Unicast) IS-IS topology. Multi-Topology IPv6 (MT-IPv6 / MTID 2) is a separate topology instance with separate advertisement control. To suppress IPv6 transit prefixes, you need advertise passive-only inside the address-family ipv6 block.
So delta configs for all four IOS-XE SP-B nodes – B-P2, B-P3, B-P4 and B-ASBR – end up as:
router isis
set-overload-bit on-startup 30
advertise passive-only
address-family ipv6
advertise passive-only
exit-address-familyThe first advertise passive-only suppresses IPv4 transit; the second, inside the IPv6 address family, suppresses MT-IPv6 transit. On IOS-XR, the problem doesn’t exist because there is no root-level form:
router isis 1
set-overload-bit on-startup 30
address-family ipv4 unicast
advertise passive-only
!
address-family ipv6 unicast
advertise passive-only
!Diagnostic approach: This bug is invisible if you only check show ip route isis. The IPv4 RIB looks completely clean. You have to inspect show ipv6 route isis and verify show isis database detail for the LSP content – specifically, check whether any MT-IPv6 IPv6 prefixes with non-zero metrics are present in the LSPs of XE nodes.
Overload Bit: Preventing the BGP Black-Hole
IS-IS converges in seconds. BGP usually converges more slowly. When a router reboots, it re-establishes IS-IS adjacencies and floods its LSP before its BGP table is populated. Other routers see it as a valid transit node and start forwarding traffic through it. Traffic destined for BGP-learned prefixes arrives at the rebooting router before it knows what to do with those prefixes. The router ends up dropping the traffic.
When a router sets the OL bit in its LSP, other routers exclude it from transit path computation – they route to it for directly attached prefixes but never through it. The OL bit gives the router time to bring up BGP before it accepts transit traffic.
On the four IOS-XE nodes – B-P2, B-P3, B-P4, B-ASBR:
router isis
set-overload-bit on-startup 30On the four IOS-XR nodes – B-P1, B-PE1, B-PE2, B-RR:
router isis 1
set-overload-bit on-startup 30The timer is 30 seconds in this lab. In production, the on-startup wait-for-bgp variant (XR) or a longer fixed timer is more appropriate.
To verify the OL bit, capture show isis database detail within the first 30 seconds of reloading a node and look for ATT/P/OL: 0/0/1. After the timer expires, it returns to 0/0/0. Our capture was taken about twenty minutes after the config went on, so the whole domain had long since cleared:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
B-P1.00-00 * 0x000000a2 0xa998 878 /* 0/0/0
B-P2.00-00 0x0000009b 0x400d 946 /1199 0/0/0
B-P3.00-00 0x0000009d 0x523d 491 /1199 0/0/0
B-P4.00-00 0x0000009a 0x6a0e 520 /1200 0/0/0
B-PE1.00-00 * 0x00000095 0xd22a 682 /* 0/0/0
B-PE2.00-00 0x00000092 0x6f90 908 /1199 0/0/0
B-RR.00-00 * 0x0000008f 0x9da8 646 /* 0/0/0
B-ASBR.00-00 * 0x000000a5 0x8d8f 883 /1199 0/0/0LSP MTU: Forcing Fragmentation for Lab Exercise
IS-IS limits each LSP PDU to the MTU of the interface (minus headers). By default on GigabitEthernet, this is ~1492 bytes. With lsp-mtu 128, we force IS-IS to fragment LSPs into 128-byte chunks.
This is a lab exercise. Nobody would run lsp-mtu 128 on a production core. I set it to watch IS-IS fragmentation behaviour. With 7 neighbors and loopback addresses to advertise, B-P1 can’t fit everything into a single 128-byte LSP.
Five fragments: B-P1.00-00 through B-P1.00-04. Fragment 0 carried the header, area address, NLPID, hostname, and the IP and IPv6 addresses. Fragment 1 took the IS-Extended adjacencies to B-P2, B-P3, and B-P4 plus the MT-IPv6 ones to B-P2 and B-P4. Fragment 2 picked up MT-IPv6 to B-P3, B-PE1, and B-ASBR alongside IS-Extended to B-PE1 and B-ASBR. Fragment 3 held IS-Extended and MT-IPv6 to B-PE2 and B-RR, and finally the IPv4 loopback prefix. The IPv6 loopback prefix did not fit at all and went into fragment 4 on its own.
I reconstructed that fragment breakdown from the stage’s verification notes. Unfortunately I lost the files with the related outputs, so I couldn’t paste them here.
The key point about fragmentation: the fragments are independently flooded, independently acknowledged, and independently aged. A router receiving all fragments of a fragmented LSP reconstructs the complete view of that node’s topology. If a fragment is missing, that router has an incomplete view and may compute suboptimal or incorrect paths. This matters at scale, where an LSP overflows because a router has that much to advertise: many SID advertisements, many TE attributes. Here I forced it with a 128-byte limit.
router isis 1
lsp-mtu 128This setting is temporary. lsp-mtu 128 must be reverted before enabling Segment Routing later on. When SR is added, each adjacency gains two adj-SID sub-TLVs (~10 bytes each), and the router’s own LSP gains a Router-CAP TLV carrying the SRGB, SRLB, Node-MSD, and SR Algorithm sub-TLVs (~35 bytes total). This pushes the LSP content past what 128 bytes can reliably accommodate during re-origination.
IS-IS keeps running, adjacencies stay up, and the LSDB looks populated, while the Router-CAP TLV and Prefix-SID sub-TLV intermittently drop out of the LSP during adj-SID re-allocation churn. Neighbors see SR-Cap: N and SID Index: None for those nodes. The issue resolves on IS-IS restart and recurs minutes later. Nothing in the IS-IS statistics indicates a problem.
Hello Padding: Physical MTU Verification
IS-IS hello PDUs can be padded to the MTU of the interface to verify that the physical link supports the full packet size. This is different from lsp-mtu – hello padding tests the data-plane MTU between two routers; lsp-mtu limits the IS-IS control-plane PDU size.
On IOS-XR, the default behavior is hello-padding sometimes: hellos are padded to the interface MTU during the initial adjacency formation (the 3-way handshake), and then padding stops once the adjacency is UP. This verifies the physical MTU without continually wasting bandwidth.
B-P1’s config explicitly declares this behavior:
router isis 1
lsp-mtu 128
interface GigabitEthernet0/0/0/0
hello-padding sometimes
!
interface GigabitEthernet0/0/0/1
hello-padding sometimes
!
interface GigabitEthernet0/0/0/2
hello-padding sometimes
!
interface GigabitEthernet0/0/0/3
hello-padding sometimes
!
interface GigabitEthernet0/0/0/4
hello-padding sometimes
!
interface GigabitEthernet0/0/0/5
hello-padding sometimes
!
interface GigabitEthernet0/0/0/6
hello-padding sometimes
!
!All seven adjacencies stayed up under both settings at once:
RP/0/RP0/CPU0:B-P1#show isis neighbors
IS-IS 1 neighbors:
System Id Interface SNPA State Holdtime Type IETF-NSF
B-P3 Gi0/0/0/1 *PtoP* Up 28 L2 Capable
B-P2 Gi0/0/0/0 *PtoP* Up 26 L2 Capable
B-PE2 Gi0/0/0/6 *PtoP* Up 29 L2 Capable
B-P4 Gi0/0/0/2 *PtoP* Up 28 L2 Capable
B-RR Gi0/0/0/4 *PtoP* Up 26 L2 Capable
B-ASBR Gi0/0/0/5 *PtoP* Up 22 L2 Capable
B-PE1 Gi0/0/0/3 *PtoP* Up 23 L2 Capable
Total neighbor count: 7The full file, all seven interfaces, is B-P1.ios in the repo. The explicit config changes nothing on the wire – sometimes is already the default. I put it in to document the intent. It’s paired with lsp-mtu 128 to show that the two are independent: hello PDUs are padded to the GigabitEthernet MTU (1500 bytes), while IS-IS LSPs are fragmented to 128 bytes. A hello PDU is not an LSP.
On IOS-XE, hello padding to MTU is the default and is not configurable at the process level in the same way. The XE nodes don’t need explicit config here.
Final Verification: The Clean State
After current configurations are fully applied on both providers, the verification outputs and summary:
SP-A (OSPF):
A-PE1#show ip route
10.0.0.0/8 is variably subnetted, 16 subnets, 2 masks
O IA 10.1.0.1/32 [110/2] via 10.1.1.21, 1d23h, GigabitEthernet2
O IA 10.1.0.2/32 [110/2] via 10.1.1.25, 1d22h, GigabitEthernet3
O IA 10.1.0.3/32 [110/3] via 10.1.1.25, 1d22h, GigabitEthernet3
[110/3] via 10.1.1.21, 1d23h, GigabitEthernet2
O IA 10.1.0.4/32 [110/3] via 10.1.1.21, 1d23h, GigabitEthernet2
C 10.1.0.5/32 is directly connected, Loopback0
O IA 10.1.0.6/32 [110/4] via 10.1.1.25, 1d22h, GigabitEthernet3
[110/4] via 10.1.1.21, 1d23h, GigabitEthernet2
O IA 10.1.0.7/32 [110/3] via 10.1.1.21, 1d23h, GigabitEthernet2
O IA 10.1.0.8/32 [110/3] via 10.1.1.21, 1d23h, GigabitEthernet2
C 10.1.1.20/30 is directly connected, GigabitEthernet2
L 10.1.1.22/32 is directly connected, GigabitEthernet2
C 10.1.1.24/30 is directly connected, GigabitEthernet3
L 10.1.1.26/32 is directly connected, GigabitEthernet3
C 10.1.10.0/30 is directly connected, GigabitEthernet4
L 10.1.10.1/32 is directly connected, GigabitEthernet4
C 10.1.11.0/30 is directly connected, GigabitEthernet5
L 10.1.11.1/32 is directly connected, GigabitEthernet5Every OSPF-learned row is a /32, and the ECMP pairs to A-P3 and A-PE2 survived. IPv6 is the same shape:
A-PE1#show ipv6 route
OI 2001:DB8:1::1/128 [110/1] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
OI 2001:DB8:1::2/128 [110/1] via FE80::E00:CCFF:FEF8:3E03, GigabitEthernet3
OI 2001:DB8:1::3/128 [110/2] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
via FE80::E00:CCFF:FEF8:3E03, GigabitEthernet3
OI 2001:DB8:1::4/128 [110/2] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
LC 2001:DB8:1::5/128 [0/0] via Loopback0, receive
OI 2001:DB8:1::6/128 [110/3] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
via FE80::E00:CCFF:FEF8:3E03, GigabitEthernet3
OI 2001:DB8:1::7/128 [110/2] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
OI 2001:DB8:1::8/128 [110/2] via FE80::E00:23FF:FE0E:9404, GigabitEthernet2
C 2001:DB8:1:15::/64 [0/0] via GigabitEthernet2, directly connected
C 2001:DB8:1:16::/64 [0/0] via GigabitEthernet3, directly connected
C 2001:DB8:1:20::/64 [0/0] via GigabitEthernet4, directly connected
C 2001:DB8:1:22::/64 [0/0] via GigabitEthernet5, directly connectedSP-B (IS-IS). These captures were taken later than the stage, so the metrics might look a little different.
B-ASBR#show ip route isis
10.0.0.0/8 is variably subnetted, 27 subnets, 2 masks
i L2 10.2.0.1/32 [115/10] via 10.2.1.41, 16:13:57, GigabitEthernet2
i L2 10.2.0.2/32 [115/20] via 10.2.1.41, 06:11:04, GigabitEthernet2
i L2 10.2.0.3/32 [115/20] via 10.2.1.45, 07:28:57, GigabitEthernet3
[115/20] via 10.2.1.41, 07:28:57, GigabitEthernet2
i L2 10.2.0.4/32 [115/10] via 10.2.1.45, 16:13:59, GigabitEthernet3
i L2 10.2.0.5/32 [115/30] via 10.2.1.41, 06:11:04, GigabitEthernet2
i L2 10.2.0.6/32 [115/20] via 10.2.1.45, 00:44:17, GigabitEthernet3
i L2 10.2.0.7/32 [115/20] via 10.2.1.41, 16:13:57, GigabitEthernet2B-ASBR#show ipv6 route isis
IPv6 Routing Table - default - 19 entries
I2 2001:DB8:2::1/128 [115/10]
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2
I2 2001:DB8:2::2/128 [115/20]
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2
I2 2001:DB8:2::3/128 [115/20]
via FE80::E00:99FF:FEAB:8404, GigabitEthernet3
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2
I2 2001:DB8:2::4/128 [115/10]
via FE80::E00:99FF:FEAB:8404, GigabitEthernet3
I2 2001:DB8:2::5/128 [115/20]
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2
I2 2001:DB8:2::6/128 [115/20]
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2
via FE80::E00:99FF:FEAB:8404, GigabitEthernet3
I2 2001:DB8:2::7/128 [115/20]
via FE80::E00:FBFF:FEC7:D406, GigabitEthernet2Twenty-seven subnets in the IPv4 table and nineteen in the IPv6 one, and every IS-IS row in both is a loopback.
The same holds in B-ASBR’s own LSP:
B-ASBR.00-00 * 0x000014A9 0x5EAE 819/* 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Topology: IPv4 (0x0)
IPv6 (0x2)
Router CAP: 10.2.0.8, D:0, S:0
Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000
Segment Routing Local Block: SRLB Base: 15000 Range: 1000
Segment Routing Algorithms: SPF, Strict-SPF
Node-MSD
MSD: 16
Hostname: B-ASBR
Metric: 10 IS (MT-IPv6) B-P4.00
Metric: 10 IS-Extended B-P4.00
Metric: 10 IS (MT-IPv6) B-P1.00
Metric: 10 IS-Extended B-P1.00
IP Address: 10.2.0.8
Metric: 0 IP 10.2.0.8/32
IPv6 Address: 2001:DB8:2::8
Metric: 0 IPv6 (MT-IPv6) 2001:DB8:2::8/128Four Metric: 10 entries, all of them adjacencies – IS-Extended for IPv4 and IS (MT-IPv6) for the IPv6 topology. Two Metric: 0 entries, both loopbacks. The Router CAP block with the SRGB and SRLB is next-stage work and did not exist when this stage closed.
Read on IOS-XR, the same LSP renders slightly differently:
RP/0/RP0/CPU0:B-P1#show isis database B-P1.00-00 detail
B-P1.00-00 * 0x00001579 0xdc0a 534 /* 0/0/0
Area Address: 49.0001
NLPID: 0xcc
NLPID: 0x8e
Router Cap: 10.2.0.1 D:0 S:0
IP Address: 10.2.0.1
IPv6 Address: 2001:db8:2::1
Hostname: B-P1
Metric: 10 IS-Extended B-P3.00
Metric: 10 IS-Extended B-P4.00
Metric: 10 IS-Extended B-RR.00
Metric: 10 IS-Extended B-P2.00
Metric: 100 IS-Extended B-PE1.00
Metric: 100 IS-Extended B-PE2.00
Metric: 10 IS-Extended B-ASBR.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-P3.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-P4.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-PE1.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-PE2.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-RR.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-ASBR.00
Metric: 10 MT (IPv6 Unicast) IS-Extended B-P2.00
Metric: 0 IP-Extended 10.2.0.1/32
Metric: 0 MT (IPv6 Unicast) IPv6 2001:db8:2::1/128
MT: Standard (IPv4 Unicast)
MT: IPv6 Unicast 0/0/0XE writes IPv6 (MT-IPv6) and IP; XR writes MT (IPv6 Unicast) and IP-Extended. Same TLVs, same wire format, two vendors’ worth of display code. B-P1 shows one prefix per address family across seven adjacencies. The two Metric: 100 links came later, in the next labs.
Both providers: dual-stack, loopbacks-only, zero transit prefix noise – and it stayed that way.
Summary of Changes
| Change | Provider | Command | Why |
|---|---|---|---|
| Passive loopback | SP-B (XE) | passive-interface Loopback0 |
Prerequisite for advertise passive-only – without it, loopback is excluded and the router disappears |
| Passive loopback | SP-B (XR) | passive under interface Loopback0 |
Same prerequisite, different syntax |
| OSPF prefix suppression | SP-A | prefix-suppression |
Remove transit /30 from OSPF RIB and LSA stubs |
| OSPFv3 prefix suppression | SP-A (XE) | prefix-suppression in address-family ipv6 unicast |
Separate AF scope – root-level command doesn’t affect IPv6 |
| OSPF/OSPFv3 prefix suppression | SP-A (XR, A-RR) | prefix-suppression under router ospf 1 and router ospfv3 1 |
XR takes it at process level for both address families |
| IS-IS advertise passive-only (IPv4) | SP-B | advertise passive-only |
Remove transit /30 from IS-IS LSDB and RIB |
| IS-IS advertise passive-only (IPv6) | SP-B (XE only) | address-family ipv6 / advertise passive-only |
Root-level command doesn’t apply to MT-IPv6 topology on XE – hidden platform behavior |
| Overload bit | SP-B | set-overload-bit on-startup 30 |
Prevent black-hole during BGP convergence after reload |
| LSP MTU | SP-B, B-P1 + B-PE1 | lsp-mtu 128 |
Lab exercise: observe IS-IS fragmentation behavior |
| Hello padding | SP-B, B-P1 | hello-padding sometimes |
Documents intent; XR default – paired with lsp-mtu to distinguish the two controls |
What’s Next
Both providers now have lean, production-realistic IGP cores: loopbacks only in the RIB, dual-stack, with startup behavior that keeps a rebooting node out of the transit path until BGP catches up. The IGP foundation is complete.
Stage 2 is MPLS transport: LDP on SP-A. The loopbacks established in the previous stages become the LDP router IDs and the foundation for label binding. Everything built in Stage 1 is about to get labels attached to it.
Yet another Blog 
Leave a comment