Level 1 Default Routing Sends Metro Traffic the Long Way
An ISP runs IS-IS with L1 areas 49.0001 (metro A, 60 routers) and 49.0002 (metro B, 35 routers) plus an L2 backbone. CR-1 and CR-2 are L1/L2 routers, each with an L1 link into metro A and an L2 link to the backbone. A new 10G link was built between metro A's edge router ER-7 and metro B's edge router ER-9; it is configured as L2 only. Since then, traffic from metro A to a prefix in metro B leaves via ER-7 into the backbone and returns through CR-1, adding 6 ms. The network still uses narrow metrics, and the operator intends to run MPLS-TE with IS-IS as the IGP. A recent fiber cut took 40 seconds to converge across the L2 core.
1. Explain why metro A's routers do not use the new ER-7/ER-9 path toward metro B, and give two design options with the trade-offs.
Read the worked answer
Why. L1 routers only know their own area plus a default route. They set the ATT bit-derived default toward the nearest L1/L2 router, which for metro A is CR-1 or CR-2, not ER-7. The new ER-7/ER-9 link is L2, so ER-7 is carrying L2 traffic, but metro A's L1 routers have no L1 route to metro B prefixes and will never select ER-7 for those destinations. The result is that traffic reaches the backbone at CR-1/CR-2, crosses to ER-9, and comes back to ER-7's L2 side.
Option 1 - selective route leaking. On the L1/L2 router that owns the optimal exit, leak the metro B aggregate from L2 into L1 with an export policy on the L1 circuit. L1 routers then have a more specific route than the default and prefer it.
- Pro: L1 routers keep a small LSDB; only the leaked aggregate is added.
- Con: leaking is policy-driven and easy to get wrong; a leaked prefix creates a second path that must be kept in sync with IGP changes, and too much leaking defeats the purpose of areas.
Option 2 - put the relevant routers in L2. Move CR-1/CR-2 and ER-7/ER-9 into L2 (or extend the L2 domain to the metro A core).
- Pro: routing is optimal by construction and there is one path computation.
- Con: larger L2 flooding domain and more LSPs to flood, which directly worsens the 40-second convergence problem already reported.
Given the stated convergence problem, leak the aggregate rather than flattening the design.
2. The operator wants MPLS-TE with IS-IS. What must change about metrics before TE is enabled, and in what order should the changes be applied?
Read the worked answer
Problem. Narrow metrics are 6-bit: usable values 1-63, and no unreserved-bandwidth or TE sub-TLVs. With two or three link speeds in the network, 1-63 cannot express 10G vs 100G distinctly, and TE cannot see available bandwidth at all.
Target. metric-style wide everywhere, which uses the extended reachability TLV and carries TE extensions.
Order of work (this matters):
- Enable wide metrics on every router while narrow is still present. Routers advertise both TLVs during the transition, and receivers prefer wide where both are present, so adjacency stays up and no path is withdrawn.
- Confirm every IS-IS adjacency is up and every prefix is reachable with the wide TLV only (check
show isis database extensivefor both narrow and wide TLVs on each LSP). - Re-tune interface metrics for the wide range - this is the point where you finally get 10G and 100G links to have different costs. Expect paths to change; schedule it.
- Enable TE (traffic engineering extensions plus RSVP) only after metrics are correct, because TE path computation inherits the IGP metric.
- Optionally restrict L2 to wide-only once all routers agree, to stop narrow TLVs from being advertised.
The common failure is enabling wide on the L2 core first and leaving L1 narrow: L1 traffic then follows a different topology than L2 traffic and you get asymmetric paths that look like a routing bug.
3. A fiber cut in the L2 core took 40 seconds to converge. What are the most likely contributors in this design, and what would you change?
Read the worked answer
In IS-IS, detection and flooding are separate; 40 seconds is far too long for either, so look at both.
Detection. Default hello/hold is 10 s x 3 = 30 s to declare a neighbour down, which alone explains most of the 40 seconds. Add BFD with a 300 ms interval and 3x multiplier on L2 core links. Do not shrink IS-IS hello/hold to sub-second across the core; BFD is the right tool and leaves the protocol timers stable.
Flooding. A fully meshed L2 core floods every new LSP to every neighbour. On point-to-point interfaces, use mesh groups so an LSP is not re-flooded back into the mesh it came from:
set protocols isis interface xe-0/0/0 mesh-group core-mesh
Keep the mesh group limited to the full-mesh p2p core; adding a non-mesh link to it silently breaks flooding.
Also check.
- LSP and SPF throttle settings: if the default throttle is left in place during a burst of LSPs, SPF runs are delayed and the 40 s reappears even with fast detection.
- Whether the 40 s was actually a stale LSP lifetime - a partitioned router keeps its LSP alive until it ages out (default 1200 s), so a partition can look like a slow convergence problem.
- The overload bit for planned maintenance: set
overload timeoutso a router coming back does not blackhole traffic while its LSPs are rebuilt.