Duplicate System ID Across Areas During an OSPF-to-IS-IS Migration
An enterprise is migrating from OSPF to IS-IS and has defined three areas: 49.0001 (core), 49.0002 (data center), and 49.0003 (campus). The NET template is 49.000X.0100.0000.000Y.00, where Y is the router number. During cutover, an engineer copies an old template and assigns 49.0002.0100.0000.0001.00 to the data-center border router, while the core border router already uses 49.0001.0100.0000.0001.00. Both routers are level-2 and participate in the same backbone. Within 10 minutes, the core border router's loopback prefix disappears from remote route tables, then reappears, and logs show 'IS-IS LSP sequence number mismatch' and duplicate LSP IDs. The data-center router is stable. No authentication or MTU issues exist. The design requires level-2 connectivity between all areas.
1. Explain why the duplicate system ID causes this instability even though the two routers are configured with different area addresses.
Read the worked answer
The area address is not the identity that distinguishes LSPs. An LSP ID is formed from the 6-byte system ID, a 1-byte pseudonode ID, and a 1-byte fragment number. Both routers have system ID 0100.0000.0001, so both originate LSP ID 0100.0000.0001.00-00. Because both routers are level-2, they share the same level-2 link-state database even though their area addresses differ. Each router believes it is the sole originator of that LSP ID. When one router refreshes its LSP with a higher sequence number, the other router sees its own LSP ID with an unexpected sequence number, re-originates with a still higher sequence, and the two overwrite each other. The core router's loopback disappears when the data-center router's LSP version wins, because that version does not contain the core loopback prefix. It reappears when the core router wins again. The data-center router looks stable only because its own prefixes remain present or because it is winning the sequence race at that moment. The area boundary does not protect level-2, so this is a domain-wide duplicate identity.
2. Propose a corrected NET plan and a safe migration procedure for the data-center border router.
Read the worked answer
Keep the area addresses but make every system ID unique. For example, assign the data-center border router 49.0002.0100.0000.0011.00 and reserve 0100.0000.0001 for the core router. Derive system IDs from a documented loopback or router-ID plan so that duplicates are detectable before cutover. Before changing anything, audit all NETs with show router isis and show router isis database detail across the domain and compare the six-byte system IDs, not the full NET. For migration, use a maintenance window even if the release supports multiple NETs. If multiple NETs are supported, add the new NET, wait for new adjacencies and for the new LSP to be flooded, then remove the old NET. If only one NET is supported, shut down IS-IS on the data-center router, change the NET, restart IS-IS, and clear the old adjacency. The old LSP ID may persist until its lifetime expires, so verify that it is purged or ignored. After the change, confirm that the old LSP ID no longer appears as an active LSP and that both routers' prefixes are present on remote routers.
3. Which SR OS show commands would you use to prove the conflict before making the change, and what exactly would you compare?
Read the worked answer
Use show router isis database detail on the core router and on at least one remote level-2 router. For the suspicious LSP ID, compare the sequence number, remaining lifetime, and the advertising router's identity as reported by the database. Also run show router isis database lsp-id 0100.0000.0001.00-00 detail on both routers and inspect the sequence number and checksum. On the core router, show router isis database should show its own LSP with a sequence number that is being reset or contested. On remote routers, the same LSP ID may alternate between two different sets of prefixes, which proves two originators. Check show router isis statistics for LSP regenerations and sequence-number jumps, and examine logs for duplicate LSP or sequence mismatch messages. Do not compare only the NET strings: two different NETs can still share the same system ID. The proof is one LSP ID with conflicting content or rapidly increasing sequence numbers from two physically different routers.