Conclusion 299 299 11.4 Conclusion Based upon this chapter’s examination of the Hellos and the NLRI carrying packets, in both OSPF and IS-IS, OSPFv2 is not quite as extensible as IS-IS. On the Hello side, OSPFv2 in general lacks extensibility. For the NLRI carrying packets, OSPF now contains a set of so-called “Opaque LSAs” that could be used to carry exten- sible information for additional address families. But to address the non-extensibility in OSPF in conjunction with the ongoing deployment of IPV6, the OSPF protocol design- ers had to develop a whole new version of OSPF. And unfortunately, OSPFv3 does not have much in common with OSPFv2, since the code was mostly a rewrite from scratch, so it doesn’t use all the stable code of the OSPFv2 version. All routing software has to undergo a maturity process to become stable enough for productive use in the Internet backbones of the world and OSPFv3 maturity may take a little longer as it tries to be all things to all packets. Compared to OSPF, IS-IS is almost like a case study on how to do it right the first time. From day one, IS-IS has been designed to stay neutral no matter which Network Layer protocol information it had to transport. IS-IS has always been effectively multi-protocol ready: in the 1980s it was used for routing CNLP traffic; in the 1990s IPv4 traffic was added; and, since 2001, IPv6 has been efficiently carried. It helps when the message elem- ents and packet types of the base IS-IS routing protocol use the proper TLV encoding. In addition, special precautions have been made not to exhaust the small 8-bit code space through use of sub-TLVs, even in the newer TLVs. TLVs and sub-TLVs turn out to be a powerful vehicle to further extend the protocol. Due to the extra complexity of sub-TLV encoding and tight sanity checks based on known TLV structure, before loading TLV contents into the link-state database are recommended. Finally, the code changes from the IPv4 to an IS-IS supporting IPv6 required only 400–600 lines of code, not an entire rewrite of the protocol. It is unlikely that active rout- ing of IPv6 prefixes will do any harm to the base stability of the IS-IS code. Adapting in a constantly changing environment is what Darwin’s Law is all about. When it comes to routing protocols, extensibility is a prerequisite for routing protocol evolution. It is the authors opinion that IS-IS adapts better than OSPF, which is why it will continue to prevail in the largest routed networks in the world. 12 IP Reachability Information IS-IS was ready from day one for extensibility. Originally intended to route CLNP pre- fixes, today IS-IS carries routing information about a variety of networking protocols including IPv4 and IPv6. In this chapter you will learn about the various places where IP prefixes or IP reachability information, which is the IS-IS term, is encoded. Support for IP prefixes came in three waves. The chapter covers both the old-style (first generation) and the new-style (second generation) TLVs. Additionally, the limitations of the first- generation IPv4-related TLVs defined in the Integrated IS-IS Routing specification (RFC 1195) will be highlighted. Finally, some of the reasoning surrounding the particular prob- lems that the more recent traffic-engineering TLVs solve will be explained. IS-IS has multiple places to convey IP reachability information. To understand why the IP-related TLVs have been re-engineered continually, it is necessary to take advantage of hindsight and consider the times when a specific protocol decision was made. Therefore, before exploring the style of the IP TLVs, a look at one of the original ISO 10589 TLVs is needed. Of course ISO 10589 is totally unrelated to IP; however, to acquire an understand- ing of how ISO 10589 encodes information, it is a good idea to also get a better under- standing of why the first generation of IP TLVs are the way they are. 12.1 Old-style Topology (IS-Reach) Information Figure 12.1 shows how IS-IS encodes neighbour reachability information in the IS Reachability TLV #2. The TLV conveys pure router-to-router connectivity information and is unrelated to IP. The first byte is the Virtual Flag, which is either set to zero or one. Typically this is set to zero. It is only set to 1 in Level 2 LSPs and indicates that this link is used to repair an area partition. However, partition repair isn’t something that a proto- col should address. Typically partitioning of Level 1 areas is avoided by putting enough links in the area. IOS supports area partitioning for CLNP. However, JUNOS lacks sup- port for healing broken, partitioned areas. Therefore the least common denominator is the simplistic design rule: “Never let an area get partitioned”, and try to avoid partitioning of an area by throwing enough links at the problem. After the virtual flag there is a basic structure of 11 bytes that may be repeated through- out the TLV. That 11-byte structure holds 4 bytes of metric-related information and 6 bytes of System-ID appended with the one-byte Pseudonode-ID. Interestingly, the basic ISO 10589 specification supports multidimensional metrics. There are distinct metrics 301 for Delay, Error, Expense and a mandatory default metric. The basic idea behind this scheme is that each router computes four distinct “topologies” by running a dedicated SPF oper- ation for each. However, at the time IS-IS was first deployed (end of the 1980s) people were cautious about using CPU cycles and therefore only computed the mandatory SPF topology, which is the default topology. If IS-IS would have been first deployed at the end of the 1990s, computing distinct SPF trees probably would have not been much of an issue due to the massive processing power available even in embedded router systems. For routing IP, the IS-IS implementation of IOS and JUNOS does not support computa- tion of anything but the default topology. Both only propagate the default metric and ignore any other metrics during receipt and during the SPF run. IOS, however, does sup- port multidimensional metrics for routing CLNP, as already mentioned. Each of the four possible metrics is represented by a dedicated byte. The most signifi- cant bit (MSB) of the respective metric byte indicates what additional metrics an individ- ual router supports. Typically the MSB is set in the Delay, Expense and Error metrics, which indicate that the metric is not supported. Next to the MSB there is the Internal/External bit, which expresses whether the Metric is comparable or not. Internal means it is compar- able, while External means it is not. (Internal metrics are always based on the same rout- ing protocol, while externals metrics are independent of IS-IS.) Typically the I/E bit is set to 302 12. IP Reachability Information TLV Type TLV Length Virtual Flag Neighbour ID 2 Bytes 1 1 1 1 1 1 1 ID Length (6) ϩ1 N*11 ؉ 1 0 Default Metric R 0 I/E 0 Delay Metric S 1 I/E 0 Expense Metric S 1 I/E 0 Error Metric S 1 I/E 0 Neighbour ID 1 1 1 1 ID Length (6) ϩ1 Default Metric R 0 I/E 0 Delay Metric S 1 I/E 0 Expense Metric S 1 I/E 0 Error Metric S 1 I/E 0 F IGURE 12.1. The IS-Reachability TLV is the blueprint for all the old-style Reachability TLVs encompassing 6-bit metrics zero, indicating that the metric is comparable. Confused? Don’t worry! Simply assume the I/E bit is always set to zero – in this TLV the I/E bit has no real practical meaning. Next, there are 6 bits that hold the metric information. Six bits can only express routing metrics ranging from 0 to 63, which is quite limited these days. Once again, the design choice of using 6 bits goes back to the anxiousness about the SPF calculation consuming too many CPU cycles. In every step of the SPF calculation a sorting function needs to be executed. One can optimize that sorting function through the use of linear arrays. Consider Figure 12.2 where a router’s preliminary metric during the SPF calculation is 456. Now the process needs to find out if there are any other routers offering a better path to a given destination (the System-ID) by applying a sorting function. Using index arrays, one can skip that sorting function. All that need be done is store a pointer to the System-ID at the 456th entry in the array. If the array gets traversed from zero to the end, the first non-null pointer must be the highest value. This implementation has the disadvantage that it consumes mem- ory. By limiting the Link Metric to 63 and the Aggregated Metric to 1023, IS-IS makes sure that the indexing function does not consume too much memory. This is another place where CPU/memory constraints have made their way into the IS-IS protocol. In hindsight, almost always where protocol designers tried to address a particular CPU/memory/ environment shortage issue of the time by protocol properties, those protocol properties finally got deprecated over time. It turned out that protocols live much longer than micro- processors or memory chip restrictions do. Old-style Topology (IS-Reach) Information 303 0 SysID 1921.6800.1008.00 Metric 456 1 2 3 4 5 455 1023 456 FIGURE 12.2. Index arrays helped to speed up search operations For lower bandwidth links the limitation to just 63 distinct metric values was not much of an issue, because there was not much disparity between the smallest and the largest bandwidth links in a network. Consider (for instance) a DS0 (64 Kbps) circuit and a T1 (1.544 Mbps) circuit. The T1 has 24 times the bandwidth of the DS0. Inverse bandwidth metric schemes are commonly used (since the lower the metric, the more attractive the route), so setting the T1 line to a metric of 1 and the DSO to a metric of 24 provides good differentiation between the two bandwidths in the metric space. Now, consider that the highest bandwidth in the network becomes an OC-3/STM-1 circuit capable of carrying 155 Mbps. Assign the lowest-cost metric to the high-speed circuit, as before. About 100 times the capacity of a single T1 circuit fits into an OC-3/STM-1 circuit, so assign a met- ric of 100 to the T1. Stop! Assigning a metric of 100 doesn’t work because there are only 6 bits available. The metric must be “clipped” to 63. Continuing with the 155 Mbps example, re-doing the calculation for the DS0 again exposes the limitations of a 6-bit met- ric space. About 2400 DS0s fit into an OC-3/STM-1 circuit. However, since there is no bigger metric, once again clip the metric to 63. The end result is that, from an IS-IS per- spective, the DS0 link becomes now indistinguishable to the T1 line, as both metrics are now 63. That increasing disparity of IGP metrics became the motivation to introduce new TLVs that have a broader metric field than just 6 bits (called wide-metrics in IS-IS). 12.2 Old-style IP Reach (RFC 1195) Information It is best to demonstrate the way of thinking embodied in the ISO 10589-defined TLVs first. Then it is easier to catch the spirit of the IP reachability information, which is very similar to the IS-Reach TLV #2. RFC 1195 specifies six new IP-related TLVs that are used to convey IP reachability information. Two of the 6 TLVs became deprecated and are not used anymore. The remaining 4 TLVs are used for a variety of functions, like transporting IP routes, inform- ing neighbours of new capabilities and troubleshooting ease. 12.2.1 Internal IP Reachability TLV #128 The Internal IP Reachability TLV #128 is probably the most important of the RFC 1195- defined TLVs. It conveys internal routing information, which is to say, directly con- nected routes. Figure 12.3 shows the basic structure of TLV #128. Please refer to Figure 12.1 for comparison. Correct – they look very similar. The structure basically starts, as in ISO 10589, with the same 4 bytes of metric information. The Metric fields are still 6 bits. Although broader metrics would not have an impact on CPU cycles (this is just leaf- information), the protocol designers decided to stay consistent with the spirit of ISO 10589. The IP Network Number and the Netmask follow after the 4 Metric bytes. These fields have these names because it was common at the beginning of the 1990s to specify IP reachability information not as prefixes and prefix lengths but rather as networks and network masks. The internal IP Reachability TLV gets automatically advertised when IS-IS is run on an interface with a configured IP address, or through use of the passive option. Whenever IS-IS is run on an interface, once an adjacency forms, all IPv4 addresses on that interface are encoded using TLV #128 in the router’s LSP. Alternatively, if the router needs to be configured to advertise a sub-net but not form an adjacency (there are valid reasons to do this, as discussed in Chapter 16), use the passive option. The passive 304 12. IP Reachability Information option is a way to include an IP sub-net in the link-state announcement, however, there is no attempt to establish an adjacency over that link. This is achieved by suppressing all Intermediate Systems to Intermediate Systems Hellos (IIHs). The passive option is available on both IOS and JUNOS. Consider the following two configuration examples. JUNOS configuration In JUNOS the passive option is a per-level or alternatively a per-interface property. [edit] hannes@Frankfurt# show [… ] protocols { isis { interface fe-4/2/0.0 { level 2 passive; } Old-style IP Reach (RFC 1195) Information 305 TLV Type TLV Length IP Address 128 Bytes 1 1 1 1 1 1 4 4 N*12 Default Metric R 0 I/E 0 Delay Metric S 1 I/E 0 Expense Metric S 1 I/E 0 Error Metric S 1 I/E 0 1 1 1 1 Default Metric R 0 I/E 0 Delay Metric S 1 I/E 0 Expense Metric S 1 I/E 0 Error Metric S 1 I/E 0 SUbnet Mask IP Address 4 4 SUbnet Mask FIGURE 12.3. Structure of the IP Reachability TLV #128 interface fe-1/3/1.0 { passive; } interface lo0.0; } } [… ] JUNOS command output You can display the actual interface list and check whether an interface is passive or not using the show isis interface command and spot passive flags. hannes@Frankfurt> show isis interface IS-IS interface database: Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric fe-1/3/1.0 3 0x2 Munich.02 Passive 10/10 fe-4/2/0.0 3 0x1 Passive Passive 10/10 so-0/0/0.0 1 0x1 Disabled Point to Point 10/70 lo0.0 0 0x1 Passive Passive 0/0 IOS configuration In IOS the passive-interface configuration option is available across the entire rout- ing-protocols including IS-IS. The passive-interface removes the interface from the list where CLNS PDU (ϭ IS-IS in this case) are being sent. New-York# show running-config [… ] router isis passive-interface GigabitEthernet0/0 net 49.0001.1921.6816.8007.00 is-type level-2-only [… ] IOS command output The show clns interface command shows CLNS processing disabled for all passive interfaces. New-York# show clns interface GigabitEthernet0/0 is up, line protocol is up CLNS protocol processing disabled Good network designs are not supposed to use the passive interface a lot. With the help of BGP, IS-IS is responsible for quick network discovery and re-routing and BGP is responsible for transporting the bulk amount of the discovered routing information. 306 12. IP Reachability Information In newer versions of IOS there is even a knob called passive-only which reduces the announcements of IP reachability information in IS-IS to a bare minimum, which is to announce the loopback interface only. In JUNOS similar behaviour can be created using routing policies. More about routing policy design philosophy and use of the passive- only knob appears in Chapter16. 12.2.2 Protocols Supported TLV #129 The Protocols Supported TLV makes IS-IS a true multiprotocol IGP. Using this TLV an IS-IS router can tell other routers what protocols it speaks. It is basically an envelope for Protocol Capability Codes. The Protocols Supported TLV is transmitted in Hellos and also in LSPs. It contains 1-byte Network Layer Protocol IDs (NLPIDs, one for each proto- col that a router speaks on a per-interface (IIH), or on a per router basis (LSP)). The two most important NLPIDs are 0xCC, indicating IPv4 forwarding capability, and 0x8e indicating IPv6 forwarding capability. Table 12.1 shows a list of common NLPIDs. For example, if an IS-IS v4-only router does not find this TLV or the NLPID contain- ing IPv4 (0xCC) in the Hello from one of its neighbours, it keeps the adjacency down. Similarly, if a router speaks IPv4 on any interface, it will tell others that it globally speaks IPv4 and announce that capability in its LSP. If the NLPID is missing in the Protocol Supported TLV, then the router will be disregarded entirely during a SPF run. Chapter 13, “IS-IS Extensions”, takes a closer look into this TLV and discusses the lim- itation specifically with regard to transport of new Network Layer Protocols like IPv6. It will be shown that, especially given the “router-global” nature of that TLV in LSPs, there is a problem when computing non-congruent Network Layer topologies. Furthermore, in Chapter 10 the exact steps and the role of TLV#129 during the SPF run was explored in great detail. Old-style IP Reach (RFC 1195) Information 307 TABLE 12.1. In the OSI world every protocol has a one-byte Network Protocol ID, even for non-OSI protocols. Code point Code point name 0x00 NULL 0x01 T.70 0x02 X.29 0x03 X.633 0x08 Q.931, Q.932, Q.933, X.36, ISO 11572, ISO 11582 0x09 Q.2931 0x0c Q.2119 0x81 CLNP 0x82 ES-IS 0x83 IS-IS 0x85 IDRP 0x8a X25 ES-IS 0x8e IPv6 0xcc IPv4 0xcf PPP IOS and JUNOS work very differently with regard to when this TLV is sent in a Hello message and when it will be suppressed. IOS makes a general differentiation if an interface is used for pure CLNP routing or also for integrated IP routing. As soon as the ip router isis and a valid ip address <address> <mask> are configured on an IOS platform this TLV appears in the Hello PDUs. If one of the two statements is missing, generation of that TLV is suppressed. Tcpdump output As soon as the ip router isis configuration statement plus a valid ip address <address> <mask> is configured on an IOS platform you will see the Protocols Supported TLV in IIHs indicating that this router understands IPv4 on this circuit. 11:35:23.248504 OSI, IS-IS, length: 63 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.0012, holding time: 30s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 63 Point-to-point Adjacency State TLV #240, length: 1 Adjacency State: Up (0) Protocols supported TLV #129, length: 1 NLPID(s): IPv4 (0xcc) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.12.14 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 JUNOS had the advantage of being introduced to the market at a time when there was no need to support CLNP routing any longer. Therefore the pure-CLNP-routing case could easily be ignored. IS-IS in JUNOS is meant to transport IPv4 and IPv6 prefixes only. IS-IS is by definition multiprotocol, so JUNOS always generates the Protocols Supported TLV #129 irrespective of whether an IPv4 or IPv6 address is configured on that interface. The explanation why the NLPIDs are set unconditionally is deferred to Chapter 13, “IS-IS Extensions”, which gives a better overview by example of the IPv6 transition. Tcpdump output Since Version 5.1 JUNOS unconditionally generates a Protocols Supported TLV with the NLPIDs of IPv4 (0xCC) and IPv6 (0x8e) in both Hello and LSP PDUs. 01:32:47.162118 OSI, IS-IS, length: 63 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.0008, holding time: 27s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 63 Point-to-point Adjacency State TLV #240, length: 15 Adjacency State: Up (0) 308 12. IP Reachability Information Extended Local circuit-ID: 0x0000001a Neighbor System-ID: 1921.6800.0012 Neighbor Extended Local circuit-ID: 0x00000000 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.12.13 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 RFC 1195 specifies two IP reachability-related TLVs. The first TLV has already been covered in this chapter. The next section shows why splitting IP reachability information over two TLVs makes sense, according to RFC 1195, and how the External IP reachability TLV is used today. 12.2.3 External IP Reachability TLV #130 At the end of the 1980s, there was the belief that there would be a single routing protocol for routing both intra-domain routes and inter-domain routes. So the routing protocols were prepared to mark routes Intra-Domain for internal routes from Inter-Domain for external routes. For that reason, everything had to be packaged in a dedicated TLV. Today, common sense is that IGPs like IS-IS, OSPF or Cisco Systems proprietary E-IGRP, do not transport large numbers of external routes very well, and so IGPs are not used according to the original purpose of conveying Inter-Domain routes. So if today no Inter-Domain routes are dumped into IS-IS, why does an External IP Reachability TLV still have a justification? Remember there are always routes in a service provider’s network which are sourced by another routing protocol, for example RIP or OSPF. If those routes are injected into the IS-IS “cloud” they are packaged in the External reachability TLV. Consider the setup shown in Figure 12.4. New York learns the RIP route 47.11/16 from the RIP router in the POP. New York exports the RIP routes via the following IOS configuration into the IS-IS cloud of the sample network. Old-style IP Reach (RFC 1195) Information 309 RIP Router 1 RIP Router 2 47.11/16 (1) … 52.33/16 (1) … Washington New York LSP External 47.12/16 New-York, Seq 0x2fc Lifetime 1181s LSP External 47.11/16 New-York, Seq 0x2fc Lifetime 1181s LSP External 47.12/16 Wash D.C., Seq 0x129 Lifetime 1192s LSP External 52.33/16 Wash D.C., Seq 0x129 Lifetime 1192s FIGURE 12.4. Two RIP routers injecting routes into IS-IS IOS configuration All the RIP routes, which are learned over FastEthernet0/0, get exported into IS-IS using the IP External Reachability TLV #130 with a metric of 8. . Reachability TLV #130 At the end of the 1980s, there was the belief that there would be a single routing protocol for routing both intra-domain routes and inter-domain routes. So the routing protocols were. Mbps) circuit. The T1 has 24 times the bandwidth of the DS0. Inverse bandwidth metric schemes are commonly used (since the lower the metric, the more attractive the route), so setting the T1 line. 49.0001 JUNOS had the advantage of being introduced to the market at a time when there was no need to support CLNP routing any longer. Therefore the pure-CLNP -routing case could easily be ignored. IS-IS