340 12. IP Reachability Information Area 49.0001 Level 2-only Area 49.0300 Area 49.0400 Pennsauken Frankfurt London Washington New York Paris Tag 200 Tag 200 Barcelona Milan Rome Madrid Montreal Chicago Boston Quebec 192.168.1.13/32 192.168.1.13/32 ؉Tag 200 192.168.1.13/32 ؉Tag 200 FIGURE 12.19. Admin tags are a convenient way of implementing an AS-wide policy for leaking /32s IOS command output London#show isis database London.00-00 level-1 verbose IS-IS Level-1 LSP London.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL London.00-00 * 0x00000010 0x574C 819 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: London IP Address: 192.168.0.166 Metric: 0 IP 192.168.0.166/32 Route Admin Tag: 200 Domain-wide Prefix Distribution 341 Metric: 10 IP 172.26.26.0/24 Metric: 10 IS-Extended London.00 [… ] The second IOS policy now needs to match against all previously tagged prefixes. See the example below, which uses a route-map for achieving that purpose. IOS configuration To match against the previously tagged prefixes you need to unconfigure the redistribute isis ip level-2 into level-1 distribute-list 166 command and use the redis- tribute isis ip level-2 into level-1 route-map command instead. This com- mands points to a route-map, which has far more fine-grained control than an access list would offer. London# show running-config router isis redistribute isis ip level-2 into level-1 route-map leak-tagged-L2-to-L1 passive-interface Loopback0 net 49.0001.1921.6816.8007.00 metric-style wide ! route-map leak-tagged-L2-to-L1 permit 10 match tag 200 ! [… ] The route-map leak-tagged-L2-to-L1 is fairly simple. It permits all prefixes, which carry the tag 200 and report it back to the IS-IS redistribution process for inclu- sion in the Level-1 database. You can verify the results of your policy by using the show isis database <lsp-id> verbose command. The verbose modifier also displays the Admin tags, which the detail modifier does not. IOS command output London#show isis database London.00-00 level-1 verbose IS-IS Level-1 LSP London.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL London.00-00 * 0x0000000D 0x8140 797 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: London IP Address: 192.168.0.166 342 12. IP Reachability Information Metric: 0 IP 192.168.0.166/32 Metric: 10 IP 172.26.26.0/24 Metric: 10 IS-Extended Frankfurt.00 Metric: 20 IP-Interarea 192.168.168.5/32 Route Admin Tag: 200 [… ] In JUNOS we need to perform the same two steps. First all the routers in the network need to tag all their loopback networks using the tag #200. This is achieved by applying the policy tag-lo0. JUNOS configuration In JUNOS the tagging is done once again via a policy. The policy tag-lo0 reads as: take all IP addresses from your logical interface lo0.0 and apply an IS-IS tag #200 to it. [edit] hannes@Frankfurt# show [… ] protocols { isis { export tag-lo0; } } policy-options { policy-statement tag-lo0 { from { interface lo0.0; } then { accept; tag 200; } } } [… ] You can verify if the tag has been correctly applied using the show isis database extensive output and spot the TLVs section of that output. hannes@Frankfurt> show isis database Frankfurt extensive IS-IS level 1 link-state database: Frankfurt.00-00 Sequence: 0x5, Checksum: 0x47da, Lifetime: 1171 secs [… ] TLVs: Area address: 49.0001 (3) Speaks: IP Domain-wide Prefix Distribution 343 Speaks: IPv6 IP router id: 192.168.168.5 IP address: 192.168.168.5 Hostname: Frankfurt [… ] IP extended prefix: 192.168.168.5/32 metric 0 up 6 bytes of subtlvs Administrative tag 1: 200 IP extended prefix: 172.16.33.5/30 metric 0 up No queued transmissions If your policy is working correctly you should see the tag #200 applied to your loop- back IP prefix. The tag is encoded using a sub-TLV to the Extended IP Reach TLV #135. Now if everything is tagged correctly we change our leak-L2-to-L1 policy to match against the presence of Admin tags rather than specifying a list of cumbersome and error- prone route-filters. JUNOS configuration The old leak-L2-to-L1 policy is renamed to leak-tagged-L2-to-L1 – additionally the from route-filter statements are removed and the tag statement is inserted as pri- mary identifier for routes that need to get leaked. [edit] hannes@Frankfurt# show [… ] protocols { isis { export leak-tagged-L2-to-L1; } } policy-options { policy-statement leak-tagged-L2-to-L1 { from { tag 200; protocol isis; level 2; } to { protocol isis; level 1; } then accept; } } [… ] Using Admin tags for route leaking is a powerful tool that you will not like to miss in medium-to large-sized networks. Also interoperability between IOS and JUNOS is 344 12. IP Reachability Information mature now and there are no reasons not to deploy it. As with the introduction of com- munities for iBGP routing it takes some time to set up all the tagging policies but once done you will enjoy not needing to administer access lists any more. 12.7 Conclusion The IP Reachability TLVs have been facing constant evolution and change. First intro- duced in RFC 1195, later redefined in RFC 2966 and today obsoleted by the traffic engin- eering drafts, a variety of TLVs conveying IP reachability information is found in today’s IS-IS networks. There is no indication that this evolution will stop and when looking at all these changes one thing remains certain: the process of change itself. The open nature of the Extended IP Reachability TLVs make sure that the protocols can and will be fur- ther extended. The Admin tag and multitopology drafts continue to further evolve the IP Reachability TLVs. Comparing IS-IS based on the root specification ISO 10589 to how IS-IS is deployed today shows that almost none of the original TLVs are in use anymore. What still is almost unchanged are the original frame formats and PDU headers, another proof that IS-IS is an easily extended routing protocol. In recent years many extensions for a variety of diverse applications have been speci- fied and then deployed. Those enhancements are sometimes of a very different nature, ranging from name resolution functions, which are aimed to ease operations and man- agement, to supporting new network address families like IPv6. There are even exten- sions that put “band-aids” on general protocol weaknesses like missing checksums in certain PDU types. Some go as far as to question the suitability of a single SPF calcula- tion operation for a joint IPv4 and IPv6 topology. This chapter covers the major IS-IS protocol extensions that have not yet been cov- ered. It highlights recent enhancements, for example for IPv6, additional checksum pro- tection, stronger authentication, multitopology SPF and graceful restart capability. 13.1 Dynamic Hostnames The entity to uniquely describe an IS-IS router in a given topology is the System-ID. The System-ID is a 48-bit (6 byte) field that really does not fit in anywhere in the IP universe. This reveals two operational problems regarding the System-ID once deployed: • It is hard to memorize • It is hard to translate (resolve) to a name Consider the CLI output below. If a NOC engineer needs to verify if a certain adja- cency is up, they need to check lists and manually map the System-IDs to a router name. Luckily in our example the routers’ loopback addresses are mapped to the System-ID using a binary coded decimal (BCD) scheme. JUNOS command output hannes@Frankfurt> show isis adjacency Interface System L State Hold (secs) SNPA so-0/0/0.0 1921.6800.1017 2 Up 25 so-0/2/0.0 1921.6800.1012 2 Up 26 345 13 IS-IS Extensions so-1/0/0.0 1921.6800.1019 2 Up 22 so-1/1/0.0 1921.6800.1018 1 Up 20 so-1/2/0.0 1921.6800.1021 2 Up 22 so-2/0/0.0 1921.6800.1022 2 Up 24 so-2/1/0.0 1921.6800.1023 1 Up 26 [… ] It is often possible to make the router translate Network Layer addresses to names using the Domain Name System (DNS). While utilizing the DNS for IPv4 and IPv6 addresses may be a viable solution, it is not for System-IDs. No DNS software today, nor any client resolver at the router, supports translation for these 48-bit entities. To get a name translation service up and running, network service providers started to maintain mapping tables for name resolution. In IOS you can manually configure those mapping tables using the clns host con- figuration command. IOS configuration The clns host configuration option translates names to a NSAP prefix. If you want to use it just for System-ID translation then enter the minimal NSAP (8-bytes) and set the Area-ID (first byte) and Selector Byte (last byte) to zero. London#show running-config [… ] clns host Pennsauken 00.1921.6800.1021.00 clns host New-York 00.1921.6800.1021.00 clns host Washington 00.1921.6800.1021.00 clns host Frankfurt 00.1921.6800.1021.00 clns host Paris 00.1921.6800.1021.00 [… ] In JUNOS you can manually configure static name to System-ID mappings using the static-host-mapping keyword under the system {} stanza: JUNOS configuration hannes@Frankfurt> show configuration system { [… ] static-host-mapping { Pennsauken sysid 1921.6800.1017; London sysid 1921.6800.1012; New-York sysid 1921.6800.1019; Washington sysid 1921.6800.1021; Paris sysid 1921.6800.1022; } } [… ] 346 13. IS-IS Extensions Maintaining a mapping table on all of the routers is an easy thing if the network consists just of six routers like the example network does. However, over time it is very awkward to distribute mapping information each time a router is added, changed or removed. Relying on an external server like the DNS is not a viable choice either. If you troubleshoot your IS-IS network because there is a problem, then there may be a situation where connectivity to the name resolution server is disrupted and you have to fall back to manual translation. The best troubleshooting tool can be a problem if it does not work as expected when you need it most. The ISIS-WG of the IETF found that the best place for a System-ID to name transla- tion service is actually the routing protocol itself. RFC 2763 describes a TLV to advertise hostnames along with a router’s LSP to distribute name to System-ID mapping informa- tion throughout a given level. The dynamic Hostname TLV is illustrated in Figure 13.1. The TLV is nothing but a freeform string that conveys the router’s hostname. Usually the hostname is one of the very first things initially configured on a router. IOS configuration Setting of the hostname causes not only the prompt to change. Additionally the host- name is advertised using TLV #137. London#show running-config [… ] hostname London ! JUNOS configuration In JUNOS the hostname is set inside the system {} stanza using the hostname key- word. hannes@Frankfurt> show configuration system { host-name Frankfurt; [… ] } Dynamic Hostnames 347 Type Length Hostname 137 Bytes 1 1 1–255 FIGURE 13.1. The dynamic Hostname TLV #137 is an envelope for transporting a simple ASCII string As soon as you change the router’s hostname two things happen: • The router prompt changes to use the new name • A new LSP is issued, and the Hostname TLV #137 contains the new name Once a router receives an LSP and it detects the presence of a Hostname TLV #137, it starts to maintain a hostname to System-ID cache. As soon as the router synchronizes with one of its adjacent routers it learns all LSPs and, as a side benefit, all the known System-ID to name mapping information is learned. The tcpdump output shows the Washington LSP. Tcpdump output 11:36:45.587565 OSI, IS-IS, length: 405 L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) lsp-id: 1921.8900.1021.00-00, seq: 0x000002fd, lifetime: 1198s chksum: 0xe984 (correct), PDU length: 405, Flags: [ L1L2 IS ] Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) Traffic Engineering Router ID TLV #134, length: 4 Traffic Engineering Router ID: 192.168.1.21 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 192.168.1.21 Hostname TLV #137, length: 10 Hostname: Washington Extended IS Reachability TLV #22, length: 75 IS Neighbor: 2092.1113.4007.00, Metric: 5, sub-TLVs present (64) IPv4 interface address subTLV #6, length: 4, 172.16.33.6 IPv4 neighbor address subTLV #8, length: 4, 172.16.33.5 [… ] All receiving routers extract the first six bytes of the LSP-ID (System-ID) plus the content of the Hostname TLV #137 to populate the hostname cache. You can display the hostname to System-ID mapping cache using the show isis hostname command which is available both on IOS and JUNOS. JUNOS command output In JUNOS you can display the System-ID to name cache using the show isis host- name command. The output shows if the mapping has been learnt by receipt of a Hostname TLV #137 (Type ϭ Dynamic) or a static mapping defined under the system {} stanza (Type ϭ Static). The local router always has its type set to Static. 348 13. IS-IS Extensions hannes@Frankfurt> show isis hostname IS-IS hostname database: System ID Hostname Type 1921.6800.1017 Pennsauken Dynamic 1921.6800.1012 London Dynamic 1921.6800.1019 New-York Dynamic 1921.6800.1021 Washington Dynamic 1921.6800.1008 Frankfurt Static 1921.6800.1022 Paris Dynamic 1921.6800.1018 Stockholm Dynamic 1921.6800.1023 Munich Dynamic 1921.6800.1024 Vienna Dynamic [… ] IOS command output IOS lists additionally from which level it learned the hostname mappings. The asterisk indicates that the information originated locally. London# show isis hostname Level System ID Dynamic Hostname (notag) * 1921.6800.1012 London 2 1921.6800.1017 Pennsauken 2 1921.6800.1019 New-York 2 1921.6800.1021 Washington 2 1921.6800.1008 Frankfurt 2 1921.6800.1022 Paris 1 1921.6800.1018 Stockholm 1 1921.6800.1023 Munich 1 1921.6800.1024 Vienna If there is no hostname in the hostname cache, then most likely the router in question does not originate the Hostname TLV as part of its link-state PDU. Dynamic Hostnames 349 TABLE 13.1. The IS-IS Name Resolver replaces the System-ID by the cached Hostname string. Hexadecimal representation Name representation System-ID 1921.6800.1017 Pennsauken Node-ID 1921.6800.1017.00 Pennsauken.00 LSP-ID 1921.6800.1017.00-00 Pennsauken.00-00 You can verify that the dynamic Hostname TLV is present by looking into the link- state database: JUNOS command output The presence of a Hostname line in the show isis database extensive output shows that the originating system did add the Hostname TLV. . make sure that the protocols can and will be fur- ther extended. The Admin tag and multitopology drafts continue to further evolve the IP Reachability TLVs. Comparing IS-IS based on the root specification. external server like the DNS is not a viable choice either. If you troubleshoot your IS-IS network because there is a problem, then there may be a situation where connectivity to the name resolution. extract the first six bytes of the LSP-ID (System-ID) plus the content of the Hostname TLV #137 to populate the hostname cache. You can display the hostname to System-ID mapping cache using the show