Adjacency Up but LSPs Lost on a 1500-Byte Path
Two Nokia 7750 SR routers are connected by a new 100G wavelength service. The provider's service demarcation is a third-party switch that supports only 1500-byte frames; the routers' access ports were left at the default 1500 while their core-facing ports are 9212. The IS-IS Level 2 point-to-point adjacency between the routers comes up and stays up, but about 60 prefixes that should be learned over the new link never appear. The routers' LSP retransmit counters climb, and each router's IS-IS database shows only its own LSP plus fragments learned from other links. Hello PDUs are small and are exchanged normally. The operations team has checked IP addressing, area IDs, authentication, and level capability, all of which match. The link is carrying live traffic for a few directly connected prefixes, so the team is reluctant to shut it down. The design requires jumbo frames end to end once the demarcation is replaced.
1. How can the adjacency be up while the LSPs are not exchanged, and what evidence would you collect?
Read the worked answer
IIHs are small (tens to a few hundred bytes), so they pass a 1500-byte path even when the IS-IS LSP MTU is larger. A router may be configured with an LSP MTU of 1492 or a larger value derived from the interface MTU; an LSP above the path MTU is dropped, and IS-IS does not fragment LSPs. The adjacency stays up because hellos keep flowing, but the database never synchronizes. If the mismatch is one-directional, one router receives the other's LSPs while its own are lost, producing asymmetric databases. Collect show router isis adjacency detail for state and last transition, show router isis database and detail for missing remote LSP IDs, LSP retransmit and PSNP counters, interface and port MTU on both routers and the demarcation, the configured lsp-mtu, and a packet capture showing large LSPs or CSNP requests for LSPs that never arrive. Hello padding, if disabled, has hidden the issue.
2. What are the remediation options, and what are the trade-offs?
Read the worked answer
Immediate: lower both router interfaces, or at least the IS-IS LSP MTU, to fit 1500, then clear the adjacency and confirm full database exchange. Lowering the interface MTU affects all traffic and may break jumbo-dependent services, so scope it to the link and schedule a short window. Alternatively set a lower LSP MTU on both routers, which avoids touching user MTU but increases fragment count and must be supported consistently on both vendors. Do not simply disable hello padding or ignore it: it is a detection tool, not the cause. Medium-term: replace or reconfigure the demarcation to pass 9212 so the design intent is met. In either case, verify with LSP counts and retransmit counters before carrying traffic. Reducing LSP size by filtering prefixes is only a workaround when the prefix count is stable; it does not fix the MTU.
3. What turn-up and change-process checks would prevent this class of failure?
Read the worked answer
Record the MTU of every device in the path, not just the two routers, and compare it with the IS-IS LSP MTU. Keep hello padding enabled during turn-up and until the link is proven: padding makes IIHs the size of the interface MTU, so a mismatch prevents adjacency instead of producing a half-working adjacency. Add pre- and post-change checks that compare expected and received LSP counts, show router isis database detail, and LSP retransmit counters; alert on rising retransmits. Include a large-prefix test or inspect the largest LSP before declaring the link ready. In change templates, require a documented MTU for the service demarcation and a post-change verification of the remote LSDB, not just adjacency state. Finally, monitor show router isis statistics for CSNP and PSNP anomalies after any MTU-related change.