The document provides an overview of Intermediate System-to-Intermediate System (IS-IS) route leaking.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
The IS-IS routing protocol allows for a two-level hierarchy of routing information. There can be multiple Level 1 areas interconnected by a contiguous Level 2 backbone. A router can belong to Level 1, Level 2, or both. The Level 1 link-state database contains information about that area only. The Level 2 link-state database contains information about that level as well as each of the Level 1 areas. An L1/L2 router contains both Level 1 and Level 2 databases. It advertises information about the L1 area to which it belongs into L2. Each L1 area is essentially a stub area. Packets destined for an address that is outside of the L1 area are routed to the closest L1/L2 router to be forwarded on to the destination area. Routing to the closest L1/L2 router can lead to sub-optimal routing when the shortest path to the destination is through a different L1/L2 router. Route leaking helps reduce sub-optimal routing by providing a mechanism for leaking, or redistributing, L2 information into L1 areas. By having more detail about interarea routes, an L1 router is able to make a better choice with regard to which L1/L2 router to forward the packet.
Route leaking is defined in RFC 2966 for use with the narrow metric Type, Length and Value (TLV) types 128 and 130. IS-IS extensions for Traffic Engineering defines route leaking for use with the wide metric TLV type 135. Both drafts define an up/down bit to indicate whether or not the route defined in the TLV has been leaked. If the up/down bit is set to 0 the route was originated within that L1 area. If the up/down bit is not set (it is 0), the route has been redistributed into the area from L2. The up/down bit is used to prevent routing information and forwarding loops. An L1/L2 router does not re-advertise into L2 any L1 routes that have the up/down bit set.
Typically an L1 router forwards packets destined for an address outside of the local area to the closest L1/L2 router, which can lead to sub-optimal routing decisions. In the network diagram below, Router C forwards all traffic destined for area 2 and 3 via routers X and Y. If we assume that all links have a cost of 1, all links, this means a cost of 2 to reach Router X and a cost of 5 to reach Router Y. Likewise Router D routes traffic for both Routers X and Y through Router B.
When you use route leaking, information about Area 2 and 3 can be redistributed into Area 1 by Routers A and B. This allows Router C and Router D to choose optimal paths to get to Area 2 and Area 3. Router C now sends traffic to Area 3 via Router A; which reduces the cost to 3, while still forwarding to Area 2 through Router A. Likewise Router D forwards to Area 2 through Router C, while still routing to Area 3 via Router B.
By enabling route leaking on Router A and Router B, Routers C and D were able to determine their true costs for reaching Area 2 and Area 3. Route leaking gave IS-IS the ability to do "shortest-path exiting" for packets going to other Areas.
In an MPLS-VPN environment reachability information is needed for each of the Provider Edge (PE) router's loopback addresses. Leaking routes for the PE loopbacks allows a multi-area hierarchy to be used in this type of implementation.
Route leaking can also be used to implement a crude form of traffic engineering. By leaking routes for individual machines or services from specific L1/L2 routers you can control the exit point from the L1 area used to reach these addresses.
Route leaking is implemented and supported in Cisco IOS® Software Releases 12.0S, 12.0T, and 12.1. The 12.0T and 12.1 releases use the same configuration command. The command syntax differs for the 12.0S release, however both commands are entered within the router IS-IS configuration. You must create an IP extended access list to define which routes will be leaked from Level 2 into Level 1. IOS 12.0S only supports route leaking using type 135 TLVs. If route leaking is configured without configuring wide style metrics, route leaking will not occur. IOS 12.0T and 12.1 support route leaking using either narrow or wide style metrics, but we recommend using wide style metrics.
The configuration commands for each IOS release are shown in the table below:
IOS Software Release | Command |
---|---|
12.0S | advertise ip l2-into-l1 <100-199> metric-style wide Note: The second statement is required. |
12.0T and 12.1 | redistribute isis ip level-2 into level-1 distribute-list <100-199> metric-style wide Note: The second statement is optional, but recommended. |
Leaked routes are referred to as interarea routes in the routing table and IS-IS database. When viewing the routing table leaked routes are marked with an ia designation.
RtrB# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 55.55.55.1 to network 0.0.0.0 i ia 1.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0 i ia 2.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0 i ia 3.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0 i ia 4.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0 55.0.0.0/24 is subnetted, 1 subnets C 55.55.55.0 is directly connected, Serial1/0 i ia 5.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0 7.0.0.0/24 is subnetted, 1 subnets C 7.7.7.0 is directly connected, FastEthernet0/0 44.0.0.0/24 is subnetted, 1 subnets i L1 44.44.44.0 [115/20] via 55.55.55.1, Serial1/0 i*L1 0.0.0.0/0 [115/10] via 55.55.55.1, Serial1/0
In the IS-IS database leaked routes are marked with an IP-Interarea designation.
RtrB# show isis database detail IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL rpd-7206g.00-00 0x00000008 0x0855 898 1/0/0 Area Address: 49.0002 NLPID: 0xCC Hostname: rpd-7206g IP Address: 44.44.44.2 Metric: 10 IP 55.55.55.0/24 Metric: 10 IP 44.44.44.0/24 Metric: 10 IS-Extended rpd-7206a.00 Metric: 20 IP-Interarea 1.0.0.0/8 Metric: 20 IP-Interarea 2.0.0.0/8 Metric: 20 IP-Interarea 3.0.0.0/8 Metric: 20 IP-Interarea 4.0.0.0/8 Metric: 20 IP-Interarea 5.0.0.0/8
Before the introduction of route leaking the up/down bit for type 128 and 130 TLVs, bit eight of the default metric was reserved for the following uses: it should be set to zero on transmission and ignored upon receipt. Bit seven, the I/E bit, was used to distinguish between internal and external metric types for redistributed routes in TLV 130. In IOS release 12.0S and earlier, bit eight was used as the I/E bit, instead of bit seven. This introduces several inter-operability discrepancies between the 12.0S and 12.0T/12.1 releases when using narrow-style metrics.
A router running IOS 12.0T or 12.1 recognizes the up/down bit and treats the route accordingly whether or not route leaking is configured on that router. If an L1 or L1/L2 router not running IOS 12.0T or 12.1 code redistributes routes using metric-type external, it sets bit eight of the default metric to 1. An L1/L2 router running 12.0T or 12.12.1 sees bit eight (the up/down bit) and interprets it as a route that has been leaked. As a result the route is not re-advertised in that router's L2 LSP. This can cause the undesired effect of routing information not being propagated throughout the network.
Conversely, if a route has been leaked into L1 by a router running IOS 12.0T or 12.1, it sets bit eight to 1. Routers in the L1 area running IOS release 12.0S or earlier see that bit eight is set and treats the route as having metric-type external. An L1/L2 router running IOS release 12.0S or earlier re-advertises the route in its L2 LSP because it does not recognize bit eight as the up/down bit. This can lead to the formation of routing loops.
These irregularities are demonstrated in the following example. RtrA is running IOS release 12.1 and is leaking several routes using narrow-style metrics. RtrB is running IOS 12.0S and is redistributing several routes with metric-type external.
On RtrA the redistributed routes from RtrB are incorrectly seen as interarea routes:
RtrA# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set i L2 1.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0 i L2 2.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0 i L2 3.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0 i L2 4.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0 55.0.0.0/24 is subnetted, 1 subnets C 55.55.55.0 is directly connected, Serial1/0 i L2 5.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0 7.0.0.0/24 is subnetted, 1 subnets C 7.7.7.0 is directly connected, FastEthernet0/0 i ia 110.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0 44.0.0.0/24 is subnetted, 1 subnets C 44.44.44.0 is directly connected, ATM3/0 i ia 120.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0 i ia 140.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0 i ia 130.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0 i ia 150.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
On RtrB the routes leaked by RtrA are incorrectly seen as external:
RtrB# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR Gateway of last resort is 55.55.55.1 to network 0.0.0.0 i L1 1.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0 i L1 2.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0 i L1 3.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0 i L1 4.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0 55.0.0.0/24 is subnetted, 1 subnets C 55.55.55.0 is directly connected, Serial1/0 i L1 5.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0 7.0.0.0/24 is subnetted, 1 subnets C 7.7.7.0 is directly connected, FastEthernet0/0 S 110.0.0.0/8 is directly connected, Null0 44.0.0.0/24 is subnetted, 1 subnets i L1 44.44.44.0 [115/20] via 55.55.55.1, Serial1/0 S 120.0.0.0/8 is directly connected, Null0 i*L1 0.0.0.0/0 [115/10] via 55.55.55.1, Serial1/0 S 140.0.0.0/8 is directly connected, Null0 S 130.0.0.0/8 is directly connected, Null0 S 150.0.0.0/8 is directly connected, Null0
If you do not use redistribution with metric-type external, bit eight is not set. This workaround prevents the problem of an L1/L2 router running IOS 12.1 not re-advertising the redistributed routes in its L2 LSP. If you are using wide-style metrics, routers running IOS 12.0S are able to recognize the up/down bit. This workaround prevents the introduction of routing loops by 12.0S routers that do not recognize the up/down bit in type 128 and 130 TLVs.
Additionally, narrow-style metrics are only 6 bits versus the 32 bits used by wide-style metrics. When using narrow-style metrics, many of the interarea routes may be leaked with the maximum internal metric of 63 regardless of the true metric. For these reasons we recommend avoiding redistribution with metric-type external and using wide-style metrics instead.