IS-IS Level 2 to Level 1 Route Leaking Configuration

2026年9月19日 LOG admin

In a two-level IS-IS design, Level 1 routers only know about their own area. When they need to reach another area they take the default route towards the nearest L1/L2 router — whether or not that router is on the optimal path. Route leaking fixes this by redistributing selected Level 2 prefixes down into Level 1, giving internal routers enough detail to pick the better exit. This guide covers the mechanism, the configuration on IOS and IOS XE, and the up/down bit rule that prevents the obvious mistake from becoming a loop.

Why the default route is not enough

Level 1 areas behave like stub areas: an L1 router sees a default route advertised by the attached L1/L2 routers and uses the nearest one. In a topology with two L1/L2 edge routers of unequal cost to the destination, the "nearest" router is frequently the wrong choice, and traffic takes a detour that no amount of tuning inside the area can fix.

Route leaking provides interarea detail. Leaked routes appear in the routing table marked ia (interarea) and in the IS-IS database as Level 1 entries carrying the L2 prefix.

Configuration

! Classic IOS 12.0S style
router isis
 metric-style wide
 advertise ip l2-into-l1 100        ! 100 = extended ACL permitting the prefixes

! IOS 12.0T / 12.1 and later, IOS XE
router isis
 net 49.0001.0000.0000.0001.00
 metric-style wide
 redistribute isis ip level-2 into level-1 distribute-list 100

access-list 100 permit ip 172.16.1.0 0.0.0.255 any
access-list 100 permit ip 172.16.2.0 0.0.0.255 any
access-list 100 permit ip 172.16.3.0 0.0.0.255 any

Two details that decide whether this works:

Wide metrics are required. Route leaking is defined for narrow metric TLVs 128/130, but IS-IS traffic-engineering extensions define it for the wide metric TLV 135, and in practice you want metric-style wide configured consistently across the domain.
The distribute-list is your filter, and you should have one. Leaking "everything" from L2 into L1 can be legitimate in a small domain and a scaling problem in a large one. Permit only what internal routers need to make a better decision.

The up/down bit: the rule that prevents loops

An L1/L2 router does not re-advertise back into Level 2 any L1 route whose up/down bit is set (pattern 0x1 in the distribution field). The bit records where a prefix came from:

up/down bit = 0 — the route originated within the L1 area. It can be advertised upward into L2 normally.
up/down bit = 1 — the route was leaked down from L2 into L1. An L1/L2 router must not send it back up, which is what stops routing information loops between levels.

Practically: you cannot accidentally create a leak-loop by leaking on two edges of the same area. The protocol refuses to push leaked routes back up, and this is also why the leaked route shows as ia rather than as a native L1 prefix.

Filtering and tagging leaked routes

! Tag on the way in, filter on the way out
route-map SET-TAG permit 10
 set tag 60

router isis
 redistribute static ip route-map SET-TAG

! On the leaking router: only leak routes with specific tags
ip access-list extended LEAK-ONLY
 permit ip 10.10.0.0 0.0.255.255 any

router isis
 redistribute isis ip level-2 into level-1 distribute-list LEAK-ONLY

! Verify
show ip route isis | include ia
show isis database detail | section TLV 135
show isis database level-1 detail | include "172.16"

Tags are worth using when leaked prefixes also feed an external protocol: a route map matching the tag applies policy consistently on the boundary instead of relying on prefix lists duplicated in three places.

Design guidance

Leak deliberately, not globally. Leak the specific destination prefixes that internal routers need to choose between edge routers — typically the prefixes of other areas and the default-bearing edge links.
Never leak the default route itself unless you intend to override the L1 default; doing it accidentally removes the fallback for everything you did not leak.
Keep metrics consistent. Mixed narrow/wide metric configuration across levels guarantees confusing route selection after a leak.
Watch scale. Every leaked prefix lives in the L1 database of every router in the area; a large leak doubles the LSP size on constrained platforms.
Verify from the leaf. The configuration is on the L1/L2 router, but the proof is that an L1 router now shows ia routes with an interface next-hop pointing at the better edge router.

Done carefully, route leaking is the cleanest way to remove suboptimal interarea paths without abandoning the two-level design that makes IS-IS scale.