7.4. IS-IS AreasIn 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 AreasYou 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.
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.
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 AreasOne 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]
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:
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:
Using the same parameters as the OSPF example in Section 7.3.2, we will assume an ISIS area with:
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:
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:
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:
Protocols Supported TLVs are:
IP Interface Address TLVs are:
If a six-character password is used throughout the area, the Authentication Information TLVs are:
The IP Internal Reachability Information TLVs carrying the prefixes internal to the area are:
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:
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:
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:
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 BehaviorYou 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.
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).
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.
7.4.4. Redundant L1/L2 RoutersAs 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, AgainAs 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.
7.4.6. L2 to L1 Route LeakingThe 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]
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.
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).
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.
7.4.7. Redistributing External Prefixes into IS-ISExternal 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.
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).
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 IDsChapter 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:
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 LinksISO 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. |