DIS Preemption Churn on a Metro Broadcast LAN
A metro Ethernet segment connects six routers in one IS-IS Level 2 broadcast domain: four access routers and two core routers. All interfaces use the default DIS priority and default hello timers. The DIS has always been one of the access routers because it has the highest MAC address. That access router has a single 1G uplink to the core, while the two core routers have 100G uplinks. During a software upgrade, the access router acting as DIS reloads. A core router becomes DIS and originates a new pseudonode LSP. When the upgraded access router returns, it preempts the DIS role, a third pseudonode LSP appears, and the LAN experiences about 20 seconds of intermittent packet loss and route churn. The customer wants the core router with the lowest router ID to be DIS under all normal conditions and wants next month's repeat upgrade to have minimal impact. No new hardware is allowed.
1. How is the DIS elected, and why was the access router DIS despite the core routers' 100G links?
Read the worked answer
IS-IS DIS election uses the interface priority first (higher wins; default 64), then the highest SNPA/MAC address as the tiebreaker. Interface bandwidth and router ID play no role. Because all six routers used the default priority, the access router with the highest MAC became DIS. The DIS has two jobs that matter here: it originates the pseudonode LSP representing the broadcast LAN, and it generates CSNPs. That is why the access router's reload and return are visible as LSP and CSNP churn. Setting a higher priority on a core router would have made the result deterministic; the 100G uplinks are irrelevant to the election unless the design encodes them in priority.
2. Why did the returning access router cause a second transition and about 20 seconds of loss?
Read the worked answer
DIS election is preemptive. When the access router returned, it had the same default priority but the highest MAC, so it immediately reclaimed DIS. That created a new pseudonode LSP and invalidated the one originated by the core router, forcing all routers on the LAN to update their databases, run SPF, and rebuild adjacency-related state. The 20 seconds is consistent with adjacency re-establishment plus LSP flooding and SPF, not with a link failure. The first transition, when the access router reloaded, was unavoidable; the second was avoidable. If the core router had been given a higher priority, the returning access router could not preempt, and only the access router's adjacency state would change. For the repeat upgrade, the same preemption would occur unless priorities are changed first or the access router's DIS role is removed before the reload.
3. What configuration achieves the customer's intent, and how do you verify it before the repeat upgrade?
Read the worked answer
Set the IS-IS Level 2 interface priority on the intended core router higher than on every other router, for example 110, set the other core router to 100 and all access routers to 64. Do not rely on router ID: the tiebreaker is MAC/SNPA, and the customer's lowest-router-ID requirement cannot be guaranteed by equal priorities. If the two core routers tie, the one with the higher MAC wins, which may not be the lowest router ID. Verify with show router isis interface that the priorities are correct and with show router isis adjacency and show router isis database that the expected router originates the pseudonode LSP. During the upgrade, expect one transition when the access router goes down and none when it returns; monitor CSNP/PSNP counts and route churn. Optionally lower the access router's priority to 1 before the reload so it cannot outrank the cores.