Section 7.4. IS-IS Areas


7.4. IS-IS Areas

In the introduction to Section 7.3, I stated that OSPF areas are easier to design, configure, and administer than IS-IS areas because the tools for creating different kinds of network behaviors are inherent in the protocol, whereas similar behaviors in IS-IS must be created using routing policies. While this is true, here is a factor in favor of IS-IS: Those same routing policies, although more difficult to configure and administer, might make IS-IS easier to troubleshoot. Whether you are dealing with automobiles, home appliances, or routing protocols, ease of use on the surface often means complexity "under the hood," and you have to get into those greasy parts under the hood to do troubleshooting. In the case of OSPF, the easy configuration of different area types is made possible by optional flags and LSAs being exchanged in the background. When things go wrong, particularly when the problem is not your own configuration but a bug in the OSPF code, you might have to dive into the various RFCs to gain a deeper understanding of how to find the source of the problem. But the routing policies creating various IS-IS area behaviors are right in the configuration, readily available for you to read and debug.

7.4.1. Backbone and Non-Backbone Areas

You have already gotten some hints that area concepts are somewhat different in IS-IS than they are with OSPF. For one thing, the AID, found as a part of the IS-IS Network Entity Title, applies to the entire router rather than to an interface as it does in OSPF. Then there are the adjacencies, which are either L1 for adjacencies between routers with the same AID, or L2, which can be between routers with the same or different AIDs.

But it gets more complicated. The default behavior of most IS-IS implementations is to accept both L1 and L2 Hellos on an interface. You learned in Chapter 4 that if the AIDs match between neighbors and the neighbors are not set to either L1-only or L2-only, both an L1 and an L2 adjacency will be established between the neighbors. Table 7.1 repeats the table of adjacency rules that you first saw in that chapter.

Table 7.1. Summary of Different L1/L2 and Area ID Combinations, and the Resulting Adjacencies

R1 Type

R2 Type

AIDs

Adjacency

L1-only

L1-only

Same

L1

L1-only

L1-only

Different

None

L2-only

L2-only

Same

L2

L2-only

L2-only

Different

L2

L1-only

L2-only

Same

None

L1-only

L2-only

Different

None

L1-only

Both

Same

L1

L1-only

Both

Different

None

L2-only

Both

Same

L2

L2-only

Both

Different

L2

Both

Both

Same

L1 and L2

Both

Both

Different

L2


Figure 7.32 shows what effect the IS-IS adjacency rules can have. The adjacencies between RTR2 and RTR3, and between RTR4 and RTR5, are L2 adjacencies because the AID portions of their NETs are different. But wherever the AIDs are the same, both L1 and L2 adjacencies are created by default. How, then, do you differentiate the backbone and nonbackbone areas in this topology?

Figure 7.32. By default, both and L1 and L2 adjacency is formed between routers with the same AIDs. If the AIDs differ, only an L2 adjacency is formed.


Figure 7.32 illustrates that it is not always easy to draw nice neat circles, with ABRs interconnecting them, to illustrate IS-IS areas. It is therefore best to think of IS-IS areas not topologically, as with OSPF areas, but to think of them as a set of contiguous adjacencies. So, an IS-IS backbone area is a contiguous[8] set of L2 adjacencies. An IS-IS nonbackbone area is a contiguous set of L1 adjacencies. As with OSPF, all inter-area traffic must pass through the backbone, and therefore the backbone interconnects all nonbackbone areas. ISO 10589, in fact, does not speak of a backbone area at all; instead, it calls the backbone area an L2 subdomain, a descriptive and useful term. You can and usually should make the area topologies more distinct that that shown in Figure 7.32 by manipulating the adjacency type a router will accept. If a router is in an L1 area and does not have connections to any other area, it should be configured as an L1-only router. If a router is in the L2 subdomain, it should be configured as an L2-only router. If the router is in an L1 area but has a connection to an L2 router (which has a different AID), the router is configured to accept both L1 and L2 adjacencies. Depending on the specific implementation, you can accomplish this either by setting the entire router to accept both adjacency types, knowing that its neighbors in its area will send only L1 Hellos and the routers in the L2 subdomain will send only L2 Hellos, or by configuring per interface the adjacency types that are accepted.

[8] That is, not partitioned.

Figure 7.33 shows the effect of setting the accepted adjacency types. The area topology is more distinct, and circles can be drawn to indicate a bit more clearly where the areas appear. Note that the circles still do not indicate clear boundaries like they do in OSPF; they only serve to show what groups of routers belong to the same area.

Figure 7.33. Setting the type of adjacency each router will accept is necessary to create clearly distinct L1 and L2 areas.


An L2 subdomain does not need to contain any L2-only routers. Take the network in Figure 7.34. Here, the L1 areas are completely and reliably interconnected among their L1/L2 routers. The connections within the areas are L1, and the connections between the L1/L2 routers are L2. This network again illustrates why it is best to think of the L2 subdomain as a contiguous set of L2 adjacencies rather than as a distinct topological area.

Figure 7.34. An L2 subdomain can consist entirely of the connections between L1/L2 routers, with no L2-only routers in it.


One final note should be made about L1/L2 routers. Because the L1 area address is assigned to the entire router rather than to an interface, an IS-IS router with one AID can only connect a single L1 area to the L2 subdomain. This differs from OSPF ABRs, which can connect multiple nonbackbone areas to area 0. However, as Section 7.4.8 discusses, an IS-IS router can have more than one AID. In addition to AID migrations, multiple AIDs can be used to attach multiple L1 areas to an L1/L2 router.

7.4.2. Factors for Scaling IS-IS Areas

One reason you might want to consider setting the adjacency types on an L1/L2 router by interface rather than on the entire router is that if the entire router is set to accept both, it will originate both L1 and L2 Hellos on all interfaces. Its L1-only neighbors will reject the L2 Hellos, and its L2-only neighbors will reject the L1 Hellos, ensuring that the right adjacency types are established. But the L1/L2 router is originating twice as many Hellos on its links than it needs to, unnecessarily using up some portion of the link bandwidth. And as stated in Section 7.3.2, network control traffic should normally consume less than 1 percent of a link's bandwidth and should never exceed 5 percent.

As you learned from Chapter 4, IS-IS messages have a standard 8-byte header. To that, LAN Hellos add 19 bytes of header and Point-to-Point Hellos add 12 bytes of header. The remainder of the Hellos is TLVs, which can be one or more of the following types:[9]

[9] Hellos can actually carry more TLV types than the ones listed here; they are discussed in later chapters in the context of the extensions the TLVs support.

  • Area Addresses TLV (type 1)

  • Intermediate System Neighbors TLV (type 6)

  • Protocols Supported TLV (type 129)

  • IP Interface Address TLV (type 132)

  • Authentication Information TLV (type 10)

  • Padding TLV (type 8)

For simplicity, assume a Hello on a point-to-point link in which the originating router has only one AID, one interface IP address, supports only IPv4, and does not use authentication. The size of the Hello message adds up to:

  • IS-IS header = 8 bytes

  • Point-to-Point Hello header = 12 bytes

  • 1 Area Addresses TLV = 6 bytes

  • 1 Protocols Supported TLV = 3 bytes

  • 1 IP Interface Address TLV = 6 bytes

The total size of the Hello, then, is 35 bytes. That compares favorably with an OSPF Hello, which under similar conditions would be 48 bytes. Whereas the OSPF Hello is sent every 10 seconds, the IS-IS Hello varies according to implementation, but is typically 9 or 10 seconds. Still a favorable comparison. And you saw in Section 7.3.2 that the OSPF Hello does not use a significant amount of bandwidth even on lower-speed links such as 56kbps, so you know that IS-IS Hellos on point-to-point links also will not add significant load.

An IS-IS LAN Hello would compare less favorably to an OSPF Hello on a LAN link. Not only are there another 7 bytes of Hello header, there is an IS Neighbors TLV that adds 2 bytes plus 6 bytes for each neighbor on the link. And in some implementations such as that of Juniper Networks, the DIS sends this LAN Hello every 3 seconds. However, these days a LAN link almost always means Ethernet, and 10M Ethernet is quickly being replaced with 100M and 1000M Ethernet. So again, Hellos are an insignificant part of the link load.

As is the case with OSPF and its LSAs, IS-IS LSPs are the entities that most impact flooding, processing, and memory loads. Again, there is the 8-byte IS-IS header. This is followed by 19 bytes of LSP header information, and the rest of the LSP is a set of TLVs:

  • Area Addresses TLV (type 1) Add 3 bytes plus the total number of bytes of all area addresses configured on the router.

  • IS Neighbors TLV (type 2) Add 3 bytes plus 11 bytes for each neighbor.

  • Protocols Supported TLV (type 129) Add 2 bytes plus 1 byte for each protocol supported.

  • IP Interface Address TLV (type 132) Add 2 bytes plus 4 bytes for every IP address configured on an interface from which the LSP is transmitted.

  • Authentication Information TLV (type 10) Add 3 bytes plus the number of bytes of the authentication value. This is normally the number of bytes of the ASCII representation of the password configured on the router.

  • IP Internal Reachability Information TLV (type 128) Add 2 bytes plus 12 bytes for each IP address directly connected to the originating router that the router is advertising to IS-IS as reachable. Also include, if the router is L1/L2, 12 bytes for every summary prefix the router advertises.

  • IP External Reachability Information TLV (type 130) Add 2 bytes plus 12 bytes for every external prefix the router is advertising into the IS-IS domain.

  • Extended IS Reachability TLV (type 22) If wide metrics are configured, add 2 bytes plus, for each neighbor, 11 bytes plus the total length of all sub-TLVs. The use of this TVL and its sub-TLVs is detailed in Chapter 11.

  • Extended IP Reachability TLV (type 135) If wide metrics are used, add 6 bytes plus, for each internal prefix (directly connected or summary) or external prefix the router is advertising into IS-IS, 6 bytes plus the total length of all sub-TLVs. The use of this TLV and its sub-TLVs is detailed in Chapter 11.

Using the same parameters as the OSPF example in Section 7.3.2, we will assume an ISIS area with:

  • 50 routers

  • 20 connected prefixes per router

  • 2000 prefixes internal to the IS-IS domain but outside of the area

  • 5000 external prefixes advertised into the IS-IS domain

For simplicity, we will assume only one AID per router, one IP address per interface, only IPv4 support, all routers connected by point-to-point links, and no wide metrics.

The total header space is:

50(8 + 19) = 1350 bytes

The 8-byte IS-IS PDU header is, of course, not stored in the database and only influences flooding calculations, but the overall number is small enough that you can keep it in your calculations for both flooding and database size.

Assuming a 3-byte AID, the total size of the Area Addresses TLVs is:

50(3 + 3) = 300 bytes

The total size of the IS Neighbors TLVs is harder to estimate accurately without summing the number of neighbors each router has. For simplicity, we will use an average of 3 neighbors per router:

50[3 + 3(11)] = 1800 bytes

Protocols Supported TLVs are:

50(2 + 1) = 150 bytes

IP Interface Address TLVs are:

50(2 + 4) = 300 bytes

If a six-character password is used throughout the area, the Authentication Information TLVs are:

50(3 + 6) = 450 bytes

The IP Internal Reachability Information TLVs carrying the prefixes internal to the area are:

50[20(2 + 12)] = 14,000 bytes

If the area is an L1 area, you can disregard the 2000 prefixes internal to the domain but external to the area. The reason for this is explained in the next section. If the area is an L2 area, the IP Internal Reachability Information TLVs are:

2000(2 + 12) = 28,000 bytes

If the area is an L2 area, the 5000 external prefixes must be accounted for. If the area is L1, these prefixes might or might not need to be accounted for, depending on the inter-area policies you implement as described in Chapters 8 and 9. We will assume that the 5000 prefixes are advertised in the area, so the IP External Reachability Information TLVs are:

5000(2 + 12) = 70,000 bytes

A fair estimate of the size of the IS-IS LS database for this area, and the load that must be carried during flooding, is then:

1350 + 300 + 1800 + 150 + 300 + 450 + 14,000 + 28, 000 + 70,000 = 116,350 bytes

This compares quite favorably with an OSPF area of the same size, where the OSPF LS database was estimated in Section 7.3.2 to be 220,000 bytes. Even with this smaller database size, however, notice that the great majority of the 116,350 bytes is to account for the prefixes external to the area. The following section shows that these external prefixes might not be advertised into an L1 area at all.

7.4.3. Default IS-IS L1 Area Behavior

You have seen in previous sections how you can use special configurations to block all prefixes external to an OSPF domain from an OSPF area (stub areas) or to block all prefixes external to the area, both external to and internal to the OSPF domain (totally stubby areas). By default, however, all prefixes external to an OSPF area are advertised into the area.

IS-IS works from the opposite direction. By default, an IS-IS L1 area is "totally stubby"that is, no prefixes are advertised from an L2 area into an L1 area. Take the network in Figure 7.35. Looking at the route tables of the three routers with L2 adjacencies in Figure 7.36Juniper3, Juniper2, and Cisco2you can see that they have full knowledge of all prefixes in all areas.

Figure 7.35. The L1/L2 routers (Juniper2 and Cisco2) do not advertise prefixes learned from their L2 neighbor to their L1 neighbor.


Figure 7.36. The route tables of all routers with L2 adjacencies have entries for all of the prefixes in the network of Figure 7.35.

[View full width]

jeff@Juniper3> show route inet.0: 21 destinations, 21 routes (20 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.0/24 *[Direct/0] 1w0d 08:32:02 > via fxp4.0 10.1.1.2/32 *[Local/0] 1w0d 08:32:02 Local via fxp4.0 10.2.1.0/24 *[IS-IS/18] 23:33:41, metric 20 , tag 2 > to 10.1.1.1 via fxp4.0 10.2.2.0/24 *[IS-IS/18] 00:35:34, metric 30 , tag 2 > to 10.1.1.1 via fxp4.0 192.168.2.0/24 *[IS-IS/18] 23:26:55, metric 20 , tag 2 > to 192.168.3.2 via fxp1.0 192.168.3.0/24 *[Direct/0] 12w5d 10:58:31 > via fxp1.0 192.168.3.1/32 *[Local/0] 16w2d 13:18:43 Local via fxp1.0 192.168.6.0/24 *[IS-IS/18] 23:26:31, metric 30 , tag 2 > to 192.168.3.2 via fxp1.0 jeff@Juniper2> show route inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.0/24 *[IS-IS/18] 23:30:04, metric 20 > to 192.168.3.1 via fxp3.0 10.2.1.0/24 *[IS-IS/18] 23:30:04, metric 30 > to 192.168.3.1 via fxp3.0 10.2.2.0/24 *[IS-IS/18] 00:38:21, metric 40 > to 192.168.3.1 via fxp3.0 192.168.2.0/24 *[Direct/0] 12w5d 11:22:42 > via fxp2.0 192.168.2.2/32 *[Local/0] 16w2d 13:48:54 Local via fxp2.0 192.168.3.0/24 *[Direct/0] 12w5d 11:22:42 > via fxp3.0 192.168.3.2/32 *[Local/0] 16w2d 13:48:54 Local via fxp3.0 192.168.6.0/24 *[IS-IS/15] 23:29:32, metric 20 > to 192.168.2.1 via fxp2.0 Cisco2#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 10.0.0.0/24 is subnetted, 3 subnets C 10.2.1.0 is directly connected, Ethernet1 i L1 10.2.2.0 [115/20] via 10.2.1.2, Ethernet1 C 10.1.1.0 is directly connected, Ethernet0 i L2 192.168.6.0/24 [115/40] via 10.1.1.2, Ethernet0 i L2 192.168.2.0/24 [115/30] via 10.1.1.2, Ethernet0 i L2 192.168.3.0/24 [115/20] via 10.1.1.2, Ethernet0


But when you examine the route tables of the L1-only routers Juniper1 and Cisco1 (Figure 7.37), you find that the tables do not have entries for any prefixes outside of the routers' own areas. Instead, a default route points to the L1/L2 router in that area. The default routes provide the connectivity out of the area (Figure 7.38).

Figure 7.37. The route tables of the L1-only routers in the network of Figure 7.35 have entries for only the prefixes in their own areas, plus a default route to the local L1/L2 router.

[View full width]

jeff@Juniper1> show route inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[IS-IS/15] 00:51:52, metric 10 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.2.0/24 *[Direct/0] 12w5d 11:34:09 > via fxp1.0 192.168.2.1/32 *[Local/0] 16w2d 14:01:19 Local via fxp1.0 192.168.6.0/24 *[Direct/0] 12w5d 11:34:09 > via fxp2.0 192.168.6.2/32 *[Local/0] 16w2d 14:01:19 Local via fxp2.0 Cisco1#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 10.2.1.1 to network 0.0.0.0 10.0.0.0/24 is subnetted, 3 subnets C 10.2.1.0 is directly connected, Ethernet0 C 10.2.2.0 is directly connected, Ethernet1 i*L1 0.0.0.0/0 [115/10] via 10.2.1.1, Ethernet0


Figure 7.38. The default routes provide connectivity to destinations outside of the local area, as shown by these pings from the two L1-only routers in Figure 7.35 to prefixes attached to the other L1-only router.

[View full width]

jeff@Juniper1> ping 10.2.2.1 PING 10.2.2.1 (10.2.2.1): 56 data bytes 64 bytes from 10.2.2.1: icmp_seq=0 ttl=252 time=7 .801 ms 64 bytes from 10.2.2.1: icmp_seq=1 ttl=252 time=3 .170 ms 64 bytes from 10.2.2.1: icmp_seq=2 ttl=252 time=3 .308 ms ^C --- 10.2.2.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.170/4.760/7.801 /2.151 ms Cisco1# ping 192.168.6.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.6.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min /avg/max = 4/4/8 ms


What all of this means is that an L1/L2 router advertises the prefixes in its attached L1 areas to its L2 neighbors. However, it does not advertise prefixes in its attached L2 area, or that are learned from its L2 neighbors, into its attached L1 areas.

Interestingly, the L1/L2 routers also do not advertise the default routes you see in the route tables of Figure 7.37. Instead, an L1/L2 router sets the attached bit (ATT) in its L1 LSP to indicate that it has connectivity to the L2 subdomain.[10] When an L1 router receives an LSP with the ATT bit set, it installs a default route pointing to the LSP's originatorthe L1/L2 router. A detailed display of the LSP from Juniper2 in Juniper1's IS-IS LS database indicates this set ATT bit (Figure 7.39). Figure 7.40 shows the L1 LSP originated by Cisco2. Although the display format differs, you can again see that the ATT bit has been set.

[10] There are actually 4 ATT bits, one associated with each of the four IS-IS metric fields defined by IS-IS. But because the default metric is the only metric used in dual IS-IS implementations, the ATT bit associated with that metric is also the only one used.

Figure 7.39. The L1 LSP originated by Juniper2 indicates that the attached bit (shown in bold) is set.

[View full width]

jeff@Juniper1> show isis database Juniper2.00-00 extensive IS-IS level 1 link-state database: Juniper2.00-00 Sequence: 0x75, Checksum: 0x8d18, Lifetime: 574 secs IS neighbor: Juniper2.03 Metric: 10 IP prefix: 192.168.2.0/24 Metric : 10 Internal Header: LSP id: Juniper2.00-00, Length: 137 bytes Allocated length: 157 bytes, Router ID: 1.1.1.2 Remaining lifetime: 574 secs, Level: 1 ,Interface: 2 Estimated free bytes: 0, Actual free bytes: 20 Aging timer expires in: 574 secs Protocols: IP Packet: LSP id: Juniper2.00-00, Length: 137 bytes, Lifetime : 1198 secs Checksum: 0x8d18, Sequence: 0x75, Attributes: 0xb <L1 L2 Attached> NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, Packet version: 1, Max area: 0 TLVs: Area address: 47.0001 (3) Speaks: IP Speaks: IPv6 IP router id: 1.1.1.2 IP address: 1.1.1.2 Hostname: Juniper2 IS neighbor: Juniper2.03, Internal, Metric: default 10 IS neighbor: Juniper2.03, Metric: default 10 IP address: 192.168.2.2 IP prefix: 192.168.2.0/24, Internal, Metric: default 10 IP prefix: 192.168.2.0/24 metric 10 up No queued transmissions


Figure 7.40. The L1 LSP originated by Cisco2 indicates that the attached bit (shown in bold) is set.

[View full width]

Cisco1#show isis database detail IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL [...] Cisco2.00-00 0x00000077 0xCF46 910 1/0/0 Area Address: 47.0002 NLPID: 0x81 0xCC Hostname: Cisco2 IP Address: 192.168.254.2 Metric: 10 IP 10.1.1.0 255.255.255.0 Metric: 10 IP 10.2.1.0 255.255.255.0 Metric: 10 IS Cisco2.03 Metric: 10 IS Cisco2.02 Metric: 10 IS Cisco2.01 Metric: 0 ES Cisco2 [...]


7.4.4. Redundant L1/L2 Routers

As with OSPF ABRs, it is always good design practice to have more than one L1/L2 router in an L1 area so that if one fails, the area is not isolated. If an L1/L2 router receives an LSP with the ATT bit set, it does not install a default route to the originator. Consider the network in Figure 7.41. In this network, the link from RTR1 to its L2 neighbor has failed. This does not present a problem for the L1-only routers because they have installed default routes to both of the L1/L2 routers.

Figure 7.41. If an L1/L2 router loses its attachment to its L2 neighbor, it will install a default route to the other L1/L2 router in its area.


This situation might seem to be a problem for any packets with area-external destinations that reach RTR1. Because it is an L1/L2 router, RTR1 does not normally install a default route to any other L1/L2 router. But when its L2 adjacency fails, it ceases to be an "attached" router. Seeing a set ATT bit from RTR2, it then installs a default route pointing to RTR2. It clears the ATT bit in its LSP and refloods. The L1-only routers then remove the default route to RTR1.

When the link is restored, RTR1 again becomes an attached router, removes its default route to RTR2, and refloods its LSP with the ATT bit set.

7.4.5. Address Summarization, Again

As with OSPF, you can summarize the prefixes within an IS-IS L1 area to reduce the size of the L2 LS database. How effective the summarization is depends on your address design: The more prefixes you can summarize with a single aggregate address, the more effective the summarization.

Also as with OSPF, an L1-only router cannot summarize local prefixes because doing so would lead to inconsistent databases within the L1 area. Only an L1/L2 router can summarize to its L2 neighbors.

Finally, external prefixes can be summarized into the IS-IS domain either as aggregates of prefix sets or as a default route. The advertisement of external prefixes into IS-IS, either as they are or as aggregates, is discussed in Section 7.4.7.

Address Summarization and BGP

In addition to the possible problems of loss of route accuracy discussed in this section and in Section 7.3.7, summarization might pose two problems to networks that speak BGP to external autonomous systems.

The first problem involves the advertisement of BGP routes into the local AS. When BGP advertises a route to an external destination into the local AS, it associates a next-hop address with the route that is either (depending on how you set up your BGP policies) the interface of the external BGP peer from which the route is learned or the loopback address of the local BGP router speaking to that external peer. When a router internal to the AS receives the BGP route advertisement from the local BGP router, it looks up the IGP route to the next-hop address. If a route to the next-hop address cannot be found, the BGP route is declared invalid and is not entered into the routing table.

If, on the other hand, the internal router finds multiple IGP routes to the next-hop address, it selects what it perceives as the shortest path to the next hop and installs that as part of the BGP route. But if address summarization is used within the AS, along with its associated loss of route information, the route selected to the next-hop address might not be the actual shortest path to the AS exit point.

The other problem involves the BGP Multi-Exit Discriminator (MED) route attribute. When there are multiple peering points from your AS to a neighboring AS, MEDs are sometimes attached to routes advertised to that neighbor to indicate the best entry point into your ASeither the shortest path to a local destination or the shortest transit path across your AS to another exit point. The MED value that is advertised to a neighboring AS is normally based on the value of the IGP metric to the local destination or next-hop address of the transit route. But again, because of the loss of routing accuracy, summarization within your AS can cause inaccurate MEDs to be advertised, resulting in the neighboring AS forwarding packets to your AS through a suboptimal entry point.

If you are running BGP, you must consider these factors along with the general loss of routing information internal to the routing domain when weighing the benefits of summarization against its possible costs.


7.4.6. L2 to L1 Route Leaking

The problem of routing information loss with summary routes can also apply within an IS-IS L1 area, where only a default route exists. If there is only one L1/L2 router through which to exit the area, there is no problem. If there are multiple L1/L2 routers, however, the information available to the L1-only routers limits them to choosing the closest L1/L2 router. For a given route, this router might or might not be the best exit point from the area. The L1-only routers have no way to know.

So, to expand your area design choices, it is good to be able to "leak" more specific routes from the L2 area into an L1 area when better routing information is desired. The problem is that RFC 1195 prohibits the advertisement of prefixes from L2 to L1. Figure 7.42 illustrates the reason for this prohibition. In this network, prefix X, which resides somewhere outside of the L1 area, is advertised from some L2 peer to RTR1. RTR1 advertises the prefix into the L1 area in an L1 IP Internal Reachability Information TLV within its L1 LSP. RTR2 receives that L1 LSP and, assuming the prefix to be internal to the L1 area advertises it back into the L2 area in an IP Internal Reachability TLV within its L2 LSP, creating a potential routing loop.

Figure 7.42. RFC 1195 prohibits advertising prefixes from L2 to L1 to prevent potential routing loops such as depicted here.


OSPF does not have this problem, because routes are advertised from area 0 into backbone areas in type 3 LSAs. ABRs receiving a type 3 LSA within a nonbackbone area do not advertise the LSA's prefixes into area 0. However, the IP Internal Reachability and IP External Reachability Information TLVs, as originally specified in RFC 1195, contained no facility for distinguishing the inter-area status of their prefixes.

As IS-IS has come into general use as an IP routing protocol, designers have recognized a need to sometimes inject more detailed route information into an L1 area and that a workaround to the limitations of RFC 1195 is needed. That workaround is offered in RFC 2966.[11]

[11] Tony Li, Tony Przygienda, and Henk Smit, "Domain-Wide Prefix Distribution with Two-Level IS-IS," RFC 2966, October 2000.

Notice in the format of the IP Internal and External Reachability Information TLVs in Figures 5.31 and 5.32 that the default metric field is a 6-bit metric value and an Internal/External (I/E) type flag. The eighth bit is unused, and normally ignored. RFC 2966 redefines this bit as the Up/Down (U/D) bit (Figure 7.43). When an L1/L2 router advertises a prefix from L2 to L1, it sets the Up/Down bit associated with the prefix. An L1/L2 router receiving a prefix from an L1 area with the U/D bit set does not advertise that prefix to its L2 peer. Older IS-IS implementations that do not understand the RFC 2699 extension ignore the eighth bit of the default metric field, and so pose no compatibility problem. However, be sure when advertising prefixes L2 to L1 that all L1/L2 routers do understand the extension.

Figure 7.43. RFC 2966 defines the eighth bit of the default metric field as the UP/Down bit, and uses the bit to identify prefixes that have been advertised into an L1 area from an L2 adjacency.


L2 to L1 route leaking is accomplished by configuring a routing policy on the L1/L2 router. The term leaking is commonly used because with a routing policy you can be very specific about what prefixes you want to have advertised into the L1 areayou can allow all prefixes learned from an L2 neighbor, or you might limit the allowed prefixes by such attributes as internal or external type, or you can even allow only one specific prefix. Routing policies give you quite a bit of flexibility.

Figure 7.44 shows a simple policy configuration applied at Juniper2 in Figure 7.35. A policy named L2_Leaking has been created that identifies and accepts IS-IS L2 prefixes. The policy is then applied as an export policy to the IS-IS configuration so that L2 prefixes are advertised into L1. Comparing Juniper1's route table in Figure 7.45 with its previous table in Figure 7.37, you can see that there are now entries for the prefixes in area 47.0003.

Figure 7.44. A simple JUNOS policy for advertising all prefixes from L2 to L1.

 [edit] jeff@Juniper2# show policy-options policy-statement L2_Leaking {     term 1 {         from {             protocol isis;             level 2;         }         then accept;     } } [edit] jeff@Juniper2# show protocols isis export L2_Leaking; interface fxp2.0 {     level 2 disable; } interface fxp3.0 {     level 1 disable; } 


Figure 7.45. The route table in Juniper1 of Figure 7.35 now shows entries for all prefixes learned via L2.

[View full width]

\jeff@Juniper1> show route inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[IS-IS/15] 22:22:57, metric 10 , tag 1 > to 192.168.2.2 via fxp1.0 10.1.1.0/24 *[IS-IS/18] 05:19:16, metric 30 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.1.0/24 *[IS-IS/18] 05:19:16, metric 40 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.2.0/24 *[IS-IS/18] 05:19:16, metric 50 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.2.0/24 *[Direct/0] 12w6d 09:05:14 > via fxp1.0 192.168.2.1/32 *[Local/0] 16w3d 11:32:24 Local via fxp1.0 192.168.6.0/24 *[Direct/0] 12w6d 09:05:14 > via fxp2.0 192.168.6.2/32 *[Local/0] 16w3d 11:32:24 Local via fxp2.0


The one prefix in Figure 7.35 that is conspicuously missing in Juniper1's route table is 192.168.3.0/24. The reason is quite simple: That prefix is directly attached to Juniper2, not learned from a L2 adjacency. An additional term in the routing policy (Figure 7.46) gives the results at Juniper1 that we want (Figure 7.47).

Figure 7.46. The policy of Figure 7.44 is modified to include redistributing prefixes directly connected to Juniper2 into the L1 area.

jeff@Juniper2# show policy-options policy-statement L2_Leaking {     term 1 {         from {             protocol isis;             level 2;         }         then accept;     }     term 2 {         from protocol direct;         then accept;     } } 


Figure 7.47. Juniper1's route table now shows subnet 192.168.3.0/24.

[View full width]

jeff@Juniper1> show route inet.0: 18 destinations, 19 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[IS-IS/15] 1d 00:08:06, metric 10, tag 1 > to 192.168.2.2 via fxp1.0 10.1.1.0/24 *[IS-IS/18] 07:04:25, metric 30 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.1.0/24 *[IS-IS/18] 07:04:25, metric 40 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.2.0/24 *[IS-IS/18] 07:04:25, metric 50 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.2.0/24 *[Direct/0] 12w6d 10:50:23 > via fxp1.0 192.168.2.1/32 *[Local/0] 16w3d 13:17:33 Local via fxp1.0 192.168.3.0/24 *[IS-IS/15] 00:00:30, metric 20 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.6.0/24 *[Direct/0] 12w6d 10:50:23 > via fxp2.0 192.168.6.2/32 *[Local/0] 16w3d 13:17:33 Local via fxp2.0


IOS routing policy syntax is very different from JUNOS, but the result are the same if the configuration is done correctly. Figure 7.48 shows an example of an IOS configuration at Cisco2 that again leaks routes into an L1 area. But this time we are being a bit more specific, allowing only prefix 192.168.6.0/24 into the L1 area. The distribute-list 100 that is referred to in the redistribute statement accomplishes this by specifying the prefix we are interested in and denying all others. The route table in Cisco1, displayed in Figure 7.49, shows that the policy is working as expected.

Figure 7.48. This policy permits only the prefix 192.168.6.0/24 learned from the L2 area to be leaked into the L1 area.

[View full width]

router isis redistribute isis ip level-2 into level-1 distribute-list 100 net 47.0002.0192.0168.2558.00 ! access-list 100 permit ip 192.168.6.0 0.0.0.255 any


Figure 7.49. Prefix 192.168.6.0/24 is the only prefix external to Cisco1's area that is added to its route table.

[View full width]

Cisco1#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 10.2.1.1 to network 0.0.0.0 10.0.0.0/24 is subnetted, 3 subnets C 10.2.1.0 is directly connected, Ethernet0 i L1 10.1.1.0 [115/20] via 10.2.1.1, Ethernet0 C 10.2.2.0 is directly connected, Ethernet1 i ia 192.168.6.0/24 [115/178] via 10.2.1.1, Ethernet0 i*L1 0.0.0.0/0 [115/10] via 10.2.1.1, Ethernet0


7.4.7. Redistributing External Prefixes into IS-IS

External prefixes are carried within the IP External Reachability Information TLVs. They can have either internal or external metric types, as indicated by the I/E bit in the default metric field.[12] The usual definition of these metric types is the internal metric type points to destinations within the IS-IS domain and the external metric type points to destinations outside of the IS-IS domain. But in fact when you redistribute prefixes into IS-IS, you can set the metric type to internal. The only real difference is that IS-IS gives a higher preference to external routes with a metric type of internal than to external routes with a metric type of external. The metric type therefore gives you some flexibility in manipulating how IS-IS selects external routes, somewhat similarly to OSPF E1 and E2 metric types.

[12] Although there is an I/E bit in the default metric field of the IP Internal Reachability Information TLV, it always indicates a metric type of internal.

RFC 1195 specifies that IP External Reachability Information TLVs are carried only in L2 LSPs. This rule restricts you to locating externally connected routers only in the L2 area. Fortunately, RFC 2966 again comes to our rescue. By observing that there is no reason why IP External Reachability TLVs cannot also be carried in L1 LSPs (which IS-IS implementations have been doing for a number of years anyway), it standardizes the ability to redistribute external prefixes into an L1 area.

Figure 7.50 shows a simple redistribution policy configured on Cisco1 of the network in Figure 7.35. In this configuration, two static routes are defined and are redistributed into IS-IS with a metric of 30 and a metric type of internal. The prefixes are learned by Cisco2, which advertises them into the L2 area as it would any other prefixes learned in its L1 area. Because the route leaking policy of Figure 7.44 still exists at Juniper2, the prefixes are leaked into that router's L1 area (Figure 7.51).

Figure 7.50. A simple policy for redistributing static routes into an IS-IS L1 area.

[View full width]

router isis redistribute static ip metric 30 level-1 metric-type internal net 47.0002.0192.0168.2557.00 is-type level-1 ! ip route 192.168.120.0 255.255.255.0 Null0 ip route 192.168.220.0 255.255.255.0 Null0


Figure 7.51. The redistributed routes can be seen in Juniper1's route table.

[View full width]

eff@Juniper4> show route inet.0: 20 destinations, 21 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[IS-IS/15] 1d 01:39:57, metric 10, tag 1 > to 192.168.2.2 via fxp1.0 10.1.1.0/24 *[IS-IS/18] 08:36:16, metric 30 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.1.0/24 *[IS-IS/18] 08:36:16, metric 40 , tag 1 > to 192.168.2.2 via fxp1.0 10.2.2.0/24 *[IS-IS/18] 08:36:16, metric 50 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.2.0/24 *[Direct/0] 12w6d 12:22:14 > via fxp1.0 192.168.2.1/32 *[Local/0] 16w3d 14:49:24 Local via fxp1.0 192.168.3.0/24 *[IS-IS/15] 01:32:21, metric 20 , tag 1 > to 192.168.2.2 via fxp1.0 192.168.6.0/24 *[Direct/0] 12w6d 12:22:14 > via fxp2.0 192.168.6.2/32 *[Local/0] 16w3d 14:49:24 Local via fxp2.0 192.168.120.0/24 *[IS-IS/18] 00:07:52, metric 70, tag 1 > to 192.168.2.2 via fxp1.0 192.168.220.0/24 *[IS-IS/18] 00:07:52, metric 70, tag 1 > to 192.168.2.2 via fxp1.0


The point of this and the previous section is that you can create, using route policies, the same kinds of inter-area behaviors in IS-IS as you can for OSPF. The difference is that whereas OSPF begins by leaking everything into nonbackbone areas and enables you to optionally configure restrictions to that behavior, IS-IS begins by leaking nothing into an L1 area and enables you to configure exceptions to that behavior.

7.4.8. Multiple Area IDs

Chapter 5 mentioned briefly that the Area Addresses TLV can carry up to 255 AIDs. Although a router would likely never need anywhere near 255 AIDs, in some cases 2 can be handy.

Suppose two IS-IS neighbors are each configured with AIDs 47.0001 and 47.0002. The routers still form at most one L1 adjacency and one L2 adjacency, but they recognize that they have two AIDs in common. If one of the AIDs is changed or disabled, the adjacency remains up because of the other AID. This proves useful because you can now perform area changes while the area is in operation. For example:

  • You can change the area's AID by bringing up adjacencies on the new AID before removing the old AID.

  • You can merge two areas by adding the AID of the first area to all routers on the second area, allowing the new adjacencies to form, and then removing the IAD of the second area.

  • You can split a single area by adding a new AID to the portion of the existing area that is to become the new area, waiting for adjacencies to form on the new AID, and then removing the old AID from the routers in the new area.

The use of this capability is not common, and so support for it varies from one router vendor to another depending usually on their customer demand for it.

7.4.9. IS-IS Virtual Links

ISO 10589 specifies the use of virtual links, also called virtual adjacencies, for repairing partitioned L1 areas. Briefly, this function works by electing two L2 Partition Designated Intermediate Systems in a partitioned L1 area, one in each partition. These L2 ISs then create an L1 repair path through the L2 subdomain (Figure 7.52) between Virtual Network Entity Titles. The L2 ISs then forward packets between the two partitions by encapsulating them in ISO 8473 NPDUs and forwarding them over the virtual link with the ISs' Virtual Network Entity Titles used as the source and destination addresses.

Figure 7.52. ISO 10589 specifies a procedure for creating a virtual link to repair a partitioned L1 area.


Interestingly, the application of virtual links in OSPF is to repair a partitioned backbone by creating a virtual link through a nonbackbone area. You cannot create an OSPF virtual link through the backbone area. IS-IS, conversely, uses virtual links to repair partitioned L1 areas by creating a virtual link through the L2 subdomain. No provision is made to use virtual links to repair L2 areas.

For the purposes of this book, the discussion of IS-IS virtual links is moot. No major router vendor implementing IS-IS for IP has provided the virtual link capability. The reason for this is that IS-IS is primarily found in carrier and ISP networks where there are usually either no L1 areas or where areas are so well designed that no need for a partition repair function is seen. Because no customers ask for it, router vendors find no reason to expend engineering resources developing it.




OSPF and IS-IS(c) Choosing an IGP for Large-Scale Networks
OSPF and IS-IS: Choosing an IGP for Large-Scale Networks: Choosing an IGP for Large-Scale Networks
ISBN: 0321168798
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Jeff Doyle

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net