Leaking IS-IS Level 2 Routes into Level 1

Problem

Your IS-IS network has several areas, some which have multiple exit points to your core area, and you want to increase the routing efficiency of your Level 1 routers.

Solution

On the Level 1Level 2 router, create a policy to leak a specific Level 2 route into the Level 1 link-state database:

	[edit policy-options policy-statement level2- 
leaking  term 1 ]
	aviva@RouterJ# set from protocol isis 
	aviva@RouterJ# set from level 2 
	aviva@RouterJ# set from route-filter 10.0.21.0/24 prefix-length-range /32-/32 

	aviva@RouterJ# set to protocol isis 
	aviva@RouterJ# set to 
level 1 
	aviva@RouterJ# set then accept 
	aviva@RouterJ# show 
	term 1 {
	 from {
	 protocol isis;
	 
level 2;
	 route-filter 10.0.21.0/24 prefix-length-range /32-/32;
	 }
	 to {
	 protocol isis;
	 level 1;
	 }
	 then accept;
	}

Then apply the policy to IS-IS:

	[edit protocols isis]
	aviva@RouterJ# set export level2- 
leaking

 

Discussion

Unlike OSPF, which combines all routes from all areas into a single link-state database, IS-IS keeps separate databases for its Level 2 and Level 1 routes. Because a Level 1 router knows only about the routers in its area, it routes traffic that is destined for another area to the nearest Level 1Level 2 router, and that router then forwards the traffic to the external area. Under most circumstances, this is what you want to happen because it minimizes the number of routes on which the SPF calculation needs to be performed. In some situations, however, this behavior results in traffic going through more links than necessary as it travels from a Level 1 router to its destination. Figure 11-2 shows such a case. To reduce the number of links, you can inject, or leak, an external route from the Level 2 link-state database into an area's Level 1 database.

In this network, traffic sent from the Level 1 RouterH to RouterE, which is in an external network, goes through RouterF because it is the closest Level 1Level 2 router. You can see this in the RouterH routing table:

	aviva@RouterH> show route 10.0.21.2
	inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[IS-IS/15] 00:31:53, metric 10
	 > to 10.0.8.1 via fe-0/0/1.0

RouterF then routes the traffic through all three routers in Area 1, taking a total of seven hops for the packet to travel from RouterH to RouterE. If you could route the traffic from RouterH to RouterG, which is the other Level 1Level 2 router in Area 2, the path would be only four hops.

Figure 11-2. IS-IS topology for leaking routes from Level 2 to Level 1

You do this is by creating a routing policy on RouterG that leaks the route to the external network 10.0.21.0/24 into the Level 1 routers in Area 2. The policy in this recipe contains a route filter that matches all /32 addresses in this external network and redistributes all IS-IS Level 2 routes from the network into IS-IS Level 1. Matching the /32 addresses captures all the addresses you are interested in, which are the loopback addresses. After you apply the policy on the Level 1Level 2 router, you see on RouterH, the Level 1 router, that the route to 10.0.21.0/24 has leaked into its routing table:

	aviva@RouterH> show route 10.0.21.2
	inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.21.0/24 *[IS-IS/18] 00:00:09, metric 40
	 > to 10.0.8.1 via fe-0/0/1.0

Instead of having a cost of 15, which is the default cost of an intra-area IS-IS route, the route has a cost of 18, which is the default for an interarea IS-IS route.