IS-IS L1 Exit Selection and OSPF Redistribution Feedback
A service provider runs IS-IS with a single L1 access region and an L2 core. Twelve aggregation routers sit in L1; R1 and R2 are the only L1/L2 ABRs, and both set the attached bit. The core contains six P routers and two PE routers; the L2 metric from R1 to the far PE is 40 and from R2 is 15. Access routers consistently send all PE-bound traffic through R1 because their L1 metric to R1 is 10 and to R2 is 30. A legacy OSPF domain is connected at R5 and R6, and connected and OSPF external routes are mutually redistributed into IS-IS on both routers. Recently, OSPF external prefixes began oscillating and some traffic from the OSPF domain loops between R5 and R6 during convergence. One access uplink also flaps every few minutes, causing repeated SPF runs across the L1 region.
1. Why do the L1 access routers always choose R1 for PE-bound traffic, and what design change would make the access region follow the true L2 cost without losing default-route reachability? Recommend a specific approach and state its risks.
Read the worked answer
L1 routers do not have L2 topology. Both ABRs set the attached bit, so each L1 router installs a default route whose next hop is the nearest ABR by L1 metric; R1 at 10 beats R2 at 30. The L2 metric 40 vs 15 never enters the L1 SPF. The default route is not a summary of the L2 cost, so traffic follows the closest exit, not the best end-to-end path.
Options: (a) change L1 link metrics so R2 is closer, which distorts all traffic and is fragile; (b) move the aggregation routers into L2, which scales poorly; (c) leak selected L2 prefixes, especially PE loopbacks and core summaries, into L1 with metrics that reflect L2 distance. Option (c) is the usual SP design: keep the default route for unknown destinations, but advertise the PE loopbacks as more-specific L1 routes. Set the leaked metric on R1 to 100 and on R2 to 50 so R2 is preferred for PE destinations, while R1 still provides a default. Do not leak the full L2 table into L1, because that increases L1 SPF and database size.
Risks: leaking creates more-specific routes that can override the default and require careful metric management; a leaked route can attract traffic to an ABR that later loses its L2 path. Verify with show isis database detail, show route table inet.0 protocol isis level-1, and a traceroute from an access router to a far PE.
2. R5 and R6 mutually redistribute OSPF and IS-IS. Explain the loop mechanism you observe and give a concrete policy design that prevents it while still allowing the OSPF prefixes to be reachable from the core. Include the tag handling in both directions.
Read the worked answer
The loop is caused by two redistribution points and no route identity. R5 learns an OSPF external and injects it into IS-IS; R6 learns the same prefix from IS-IS and redistributes it back into OSPF as an external; R5 then sees a new OSPF external and the cycle repeats. Preference differences make it worse: IS-IS L2 routes have preference 18, OSPF external 150, so an IS-IS copy can override the original OSPF route.
Use tags plus a one-way policy. On both R5 and R6:
- OSPF-to-IS-IS: match
protocol ospf, set tag 100, accept; reject any route already tagged 200. - IS-IS-to-OSPF: reject tag 100; set tag 200 on
protocol isisroutes, accept.
Sketch:
policy-statement OSPF-TO-ISIS {
term from-isis { from tag 200; then reject; }
term ospf { from protocol ospf; then { tag 100; accept; } }
term else { then reject; }
}
policy-statement ISIS-TO-OSPF {
term from-ospf { from tag 100; then reject; }
term isis { from protocol isis; then { tag 200; accept; } }
term else { then reject; }
}
Apply OSPF-TO-ISIS as the IS-IS export policy and ISIS-TO-OSPF as the OSPF export policy. Also restrict redistribution to internal OSPF routes where possible, or use a single redistribution point. Verify show route <prefix> extensive for the tag and show ospf database external for the originating router.
3. The flapping access uplink causes repeated SPF runs. Propose an IS-IS timer and interface treatment that reduces churn without hiding a real failure for more than a few seconds. What would you verify before applying it?
Read the worked answer
Use IS-IS SPF backoff, not a long static delay. A starting point:
protocols isis {
spf-interval { delay 200; holddown 5000; }
interface ge-0/0/0.0 { hold-time up 2000 down 0; }
}
The 200 ms delay absorbs transient events; the 5 s holddown caps repeated SPF runs. Do not set the delay to many seconds, because a real core failure would then be hidden. Add BFD on the uplink so a real failure is detected in milliseconds and the SPF is triggered once, rather than by interface up/down events. If the uplink is flapping at the physical layer, fix the optics or add hold-time up to prevent an unstable link from being advertised immediately. Before applying, check show log messages | match isis, show isis adjacency detail, and interface error counters; if the flap is caused by CRC errors, timer tuning only masks it. Verify after the change with show isis spf statistics and a controlled interface shutdown.