Level 1 Prefix Invisible to the Core After Summarization
An ISP runs IS-IS on Nokia SR OS with a Level 2 core (area 49.0002, four core routers) and twelve Level 1 branch areas, each dual-homed to a pair of ABRs that are Level 1-2. Branch prefixes are summarized per region, so core routers see only the summaries. Level 1 routers receive a default route via the ATT bit set by the ABRs. A new centralized voice application in the core must reach branch subnet 172.20.5.0/24 over the lowest-latency path, but core routers have no IS-IS entry for that prefix. Traffic follows the regional summary to whichever ABR is nearest, and in several cases crosses the core twice. The customer will not leak all 400 branch prefixes into Level 2 and will not change summarization. The 172.20.5.0/24 route is tagged with IS-IS route tag 500 on the branch router's Level 1 LSP. Change control requires that the solution not create a feedback path or require a maintenance window.
1. Why is 172.20.5.0/24 missing from the core LSDB and RIB, and why does the design produce tromboning instead of a black hole?
Read the worked answer
Level 1 and Level 2 have separate link-state databases. An ABR does not, by default, advertise Level 1 prefixes into Level 2; it advertises Level 2 reachability into Level 1 via the ATT bit and default route. The core therefore has only the regional summary, not the /24. A packet to 172.20.5.0/24 matches the summary and is delivered to the nearest ABR. That ABR does have the /24 in its Level 1 database, but if it is not the branch's home ABR, its shortest Level 1 path may transit the branch area to the other ABR and then re-enter the core. The result is suboptimal but not a black hole, because every ABR has some Level 1 path to the prefix. The missing piece is policy: the prefix exists only in Level 1 and is never exported into the Level 2 LSDB, so core SPF cannot choose the correct exit ABR.
2. Design the route leak on SR OS: give the policy match and action, where it is applied, and the safeguards that keep it from growing beyond the intended prefixes.
Read the worked answer
Create an SR OS route policy that matches only the intended routes: from protocol isis with tag 500, action accept, and set a distinct tag such as 600 plus a high metric. Apply it as the IS-IS level-2 export policy on both ABRs. Do not use a blanket accept. The tag 600 marker lets you deny re-leak and audit the routes later. Verify the Level 2 LSP size and fragment count after applying to one ABR, then the second; check that the leaked route's metric does not make it attract transit traffic for other destinations. Import and export policies in SR OS are evaluated at the ABR, so both ABRs need the policy for redundancy. No maintenance window is required because the policy can be added and removed per ABR, with only the affected prefixes reconverging. Also confirm the regional summary still exists and that the more specific /24 is preferred over it.
3. After the leak, a branch engineer reports that 172.20.5.0/24 now has two next-hops, one pointing into the core. Is this a loop, how do you verify it, and what would you change?
Read the worked answer
Not necessarily a loop. IS-IS prefers Level 1 over Level 2 (Nokia default preference 15 versus 18), so the branch router should still install its own Level 1 route and ignore the leaked Level 2 copy. Seeing two next-hops on a core router is expected: the leaked route and the summary both point toward the branch. Verify with show router isis routes and show router route-table that the active route is Level 1 with the expected next-hop, and inspect the Level 2 LSP for tag 600. A real problem appears if an ABR exports Level 2 routes back into Level 1: a branch could then prefer a leaked copy over its local route only if the local route is missing, which would indicate a separate failure. Prevent this by denying tag 600 in any Level 1 export policy and by not enabling Level 2-to-Level 1 leaking except for the default route. If the leaked route is preferred somewhere because the Level 1 route is missing, fix the policy or the Level 1 failure, not the metric.