New-York# show running-config [… ] ! this is the interface to the RIP router interface FastEthernet0/0 ip address 172.16.67.133 255.255.255.252 router rip network 172.16.0.0 router isis net 49.0001.1921.6800.1189.00 redistribute rip metric 8 [… ] New York’s LSP looks in the tcpdump packet trace as follows: Tcpdump output A redistributed RIP route shows up in the LSP as an IP External Reachability TLV: 14:48:32.234806 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.6800.1189.00-00, seq: 0x000002fd, lifetime: 1198s chksum: 0xe984 (correct), PDU length: 405, Flags: [ L1L2 IS ] [… ] IP External reachability TLV #130, length: 12 IPv4 prefix: 47.11/16 Default Metric: 8, Internal, Distribution: up IS Reachability TLV #2, length: 67 IsNotVirtual IS Neighbor: 0000.0000.0003.02, Default Metric: 10, Internal IS Neighbor: 0000.0000.0003.02, Default Metric: 10, Internal [… ] You can also spot the IP External TLVs by looking into the isis database using the show isis database command. IOS command output The bold marked output represents the content transported using the IP External Reachability LSP, which can be displayed using the show isis database command. Amsterdam# show isis database verbose [… ] IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL Amsterdam.00–00 0x00000762 0x6467 732 0/0/0 NLPID: 0xCC 0x8E 310 12. IP Reachability Information Area Address: 49.0001 IP Address: 192.168.1.1 Metric: 10 IS London.02 Metric: 10 IP-External 172.16.33.2 255.255.255.252 [… ] In JUNOS the external prefixes can be spotted at two places of the show isis database extensive command line output. JUNOS command output JUNOS yields information at two places of the show isis database command line out- put. First, at the LSP Overview Section next to LSP-Name, Sequence Number, Checksum and Lifetime Information and then in the detailed TLV Breakdown. hannes@olive-2> show isis database extensive [ ] IS-IS level 2 link-state database: New-York.00-00 Sequence: 0x3a, Checksum: 0x249e, Lifetime: 64986 secs IS neighbor: Wash-D.C 02 Metric: 24 IP prefix: 47.11.0.0/16 Metric: 8 External IP prefix: 172.16.1.0/24 Metric: 24 Internal IP prefix: 192.168.1.2/32 Metric: 0 Internal [… ] TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPv6 IP router id: 192.168.1.2 IP address: 192.168.1.2 Hostname: olive-2 IS neighbor: Wash-D.C., Internal, Metric: default 24 IP prefix: 192.168.1.2/32, Internal, Metric: default 0 IP prefix: 172.16.1.0/24 Metric: default 63 IP external prefix: 47.11.0.0/16, Internal, Metric: default 8 No queued transmissions Finally, look at a configuration example for JUNOS, which has the same effect as the above described IOS configuration. In JUNOS all exchange of routes between routing protocols have to go through policies which are defined under the policy-options configuration branch. Each policy consists of one or more from and then parts. The from clause means more like “if”, which is a bit counterintuitive, as one would understand from as something like “origin” at first. However the from statement always takes the inet.0 Routing Table as input and computes a subset of these routes. The then portion tells what to do with the prefixes that match the from part. In our example, the policy rip-routes-to-isis takes all Old-style IP Reach (RFC 1195) Information 311 routes in the main routing table inet.0 that match the from part. The from part matches all routes, all of which have been learned through RIP, and computes a list of prefixes plus rele- vant attributes like Metrics. Once the policy is called under the protocols isis section the previously computed list of routes will get inserted into an IS External Reachability TLV #130. JUNOS configuration In JUNOS a policy needs to scan the main routing table inet.0 for all routes that are learned via RIP. They get set to a metric of 8 and, through use of the export statement under the protocols isis section, are exported into IS-IS using the IP External Reachability TLV #130. New-York# show configuration [… ] protocols { isis { export rip-routes-to-isis interface so-7/0/0.0; interface lo0.0; } rip { group washington-POP { neighbor fe-0/1/0.0; } } } policy-options { policy-statement rip-routes-to-isis { from protocol rip; then { metric 8; accept; } } } [… ] Figure 12.5 shows that the External IP Reachability TLV #130 shares exactly the same format as the IP Internal Reachability TLV #128. The only difference is that certain combinations of the TLV Type and the Internal/External Bit of the Metric Bytes are not valid. More about the valid and invalid combinations of the both TLVs, which finally led to the demise of the old-style IP-Reach TLVs, is covered in the section that discussed the extended IP Reachability TLV 135. 312 12. IP Reachability Information 12.2.4 Inter-Domain Information Type TLV #131 The Inter-Domain Type TLV is related to the belief that Inter-Domain routes should be transported in the External IP Reachability TLV #130. It ought to give further evidence about the routing domain from where these routes have been obtained. This TLV has become obsolete, as Inter-Domain routes are not dumped into IS-IS anymore. Figure 12.6 shows the basic structure of that TLV. The first byte contains information about the format of the Inter-Domain Information Value that follows. Three types are defined: Type 0 and 1 indicate reserved or local usage and Type 2 indicates that a two-byte AS number follows. Typically this Information TLV is inserted before an IP External Reachability TLV #130 and helps the receiving router to store AS-related information (where the route came from) with the external routes. Neither IOS nor JUNOS make use of this TLV, due to the harm to scaling that redistribution of Inter-Domain routes into IS-IS causes. Old-style IP Reach (RFC 1195) Information 313 TLV Type TLV Length IP Address 130 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.5. Structure of the External IP Reachability TLV #130 12.2.5 Interface Address TLV #132 The Interface Address TLV #132 is valid in IIH and LSP PDUs. It should tell a remote router about the IP addresses that are configured at the neighbouring router. If a router sees one of its own IP addresses in a remote router’s Hello PSU, then the adjacency will not come up. The format of the IP Interface Address TLV is shown in Figure 12.7. The TLV length is always a multiple of 4 bytes, each entry conveying an IP address. Typically there is just one IP address contained in this TLV, however if one or more secondary address (es) are configured, the secondary IP address (es) also show up here. 314 12. IP Reachability Information TLV Type TLV Length Inter-Domain Information Type 131 Bytes 1 1 1 1–254 2 Inter-Domain Information Value FIGURE 12.6. The obsolete TLV #131 conveys additional information about external routes TLV Type TLV Length IP Address 132 Bytes 1 1 4 4 N*4 IP Address FIGURE 12.7. The IP Interface Address TLV #132 gets advertised in IIHs and LSPs Watch the results of the following configuration. IOS configuration If you want to configure in IOS more than one IP address per interface, you have to use the keyword secondary after the IP address. A msterdam# show running-config [… ] interface GigabitEthernet 3/0 ip router isis ip address 172.16.33.1 255.255.255.0 ip address 172.16.34.1 255.255.255.0 secondary router isis net 49.0001.1921.6801.1001.00 is-type level-1 [… ] Once we start tcpdump on a workstation, which is on the LAN, we will get a similar output. Note that the number in brackets behind the TLV is the length of that TLV. Tcpdump output All the configured IP addresses are listed in the IP Interface Address TLV. 16:19:27.486634 OSI, IS-IS, length: 84 L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 0000.0000.0003, holding time: 40s, Flags: [Level 1, Level 2] lan-id: 0000.0000.0003.02, Priority: 70, PDU length: 84 IS Neighbor(s) TLV #6, length: 6 IS Neighbor: 0002.b32b.0e52 Protocols supported TLV #129, length: 1 NLPID(s): IPv4 IP Interface address(es) TLV #132, length: 8 IPv4 interface address: 172.16.33.1 IPv4 interface address: 172.16.34.1 Area address(es) TLV #1, length: 4 Area address (3): 49.0001 You can also display the contents of the IP Interface Address TLV through use of a CLI command. In JUNOS the show isis adjacency detail command reveals information about the IP address that the neighbour holds. JUNOS command output In JUNOS you can explore the IP address of a neighbour using the show isis adja- cency command. hannes@New-York> show isis adjacency detail NY-Access4 Interface: ge-4/0/1.0, Level: 2, State: Up, Expires in 8 secs Priority: 70, Up/Down transitions: 1, Last transition: 2d 21:54:18 ago Circuit type: 2, Speaks: IP, IPv6, MAC address: 00:90:69:2b:0e:52 Restart capable: Yes LAN id: NY-Access4.02, IP addresses: 172.16.33.1 IPv6 addresses: fe80::7777:69ff:fea0:8001 [… ] In Cisco IOS you can display the IP addresses of your neighbour by issuing the show clns neighbor detail command. Old-style IP Reach (RFC 1195) Information 315 IOS command output In IOS you can display the contents of TLV #132, which are the IP address (es) of a neigh- bour, using the show clns neighbor detail command. Amsterdam#show clns neighbors detail System Id Interface SNPA State Holdtime Type Protocol New-York POS4/0 *HDLC* Up 2 L2 IS-IS Area Address(es): 49.0001 IP Address(es): 172.16.34.1* Uptime: 04:04:52 [… ] The IS-IS router will refuse to build an adjacency if the Hello message from any of the neighbouring routers contains an IP addresses that is local to the local router, assuming that there is something broken. IOS logs that event once you start turning on debug out- put for isis adj-packets. IOS debug output IOS logs if it receives a Hello PDU from a neighbour holding bogus IP addresses. Amsterdam# debug isis adj-packets IS-IS Adjacency related packets debugging is on Amsterdam # 1d08h: ISIS-Adj: Rec L1 IIH from 0090.6994.a43e (GigabitEthernet3/0), cir type L1L2, cir id 1921.6800.1133.02, length 1492 1d08h: ISIS-Adj: No usable IP interface addresses in LAN IIH from GigabitEthernet3/0 1d08h: ISIS-Adj: Sending L2 LAN IIH on GigabitEthernet3/0, length 1497 [… ] In JUNOS you can log a sub-net mismatch by setting the error flag under the protocols isis traceoptions branch. JUNOS debug output JUNOS shows you in the isis-log messagefile that it could not find a matching IP sub- net. protocols { [… ] isis { traceoptions { file isis-log size 1m microsecond-stamp; 316 12. IP Reachability Information flag error; flag packets detail; } [… ] } } Jun 16 10:24:18.154351 Received PTP IIH, source id Amsterdam on so-7/0/0.0 Jun 16 10:24:18.154430 intf index 2 Jun 16 10:24:18.154455 max area 0, circuit type l1l2, packet length 56 Jun 16 10:24:18.154476 hold time 27, circuit id 1 Jun 16 10:24:18.154500 ptp adjacency tlv length 5 Jun 16 10:24:18.154521 neighbor state down Jun 16 10:24:18.154542 neighbor extended local circuit id 1 Jun 16 10:24:18.154563 speaks IP Jun 16 10:24:18.154587 speaks IPV6 Jun 16 10:24:18.154615 IP address 10.0.0.6 Jun 16 10:24:18.154705 area address 49.0001 (3) Jun 16 10:24:18.154730 restart RR reset RA reset holdtime 0 Jun 16 10:24:18.154772 ERROR: IIH from Amsterdam without matching addresses, interface so-7/0/0.0 From an IS-IS perspective, a multiprotocol IGP like IS-IS should not police adjacen- cies based on Layer 3 information such as IP sub-nets. Many developers argue that, par- ticularly on broadcast interfaces, the forwarding next-hop resolver relies on a protocol to supply MAC addresses for correctly framing a routed packet. In the IP world this is typ- ically the ARP protocol. The router OS kernel relies on ARP solely to resolve L3 next- hop to MAC address mapping, because such IP addresses belonging to the same sub-net need to be present in order for the next-hop resolution sub-system to work correctly. While this violates the multiprotocol nature of IS-IS a bit, it is common consensus among implementers of routing protocols to do it that way. 12.2.6 IP Authentication TLV #133 The IP Authentication TLV was meant to be a dedicated authentication method only applied for IP Reachability Information. The IOS and JUNOS implementers however never implemented that dedicated Authentication TLV. Instead they implemented the far more general Authentication TLV #10 that authenticates all TLVs in a given PDU. Because no vendor ever supported the IP Authentication TLV #133, it finally got depre- cated. Now in the official TLV Code Point Allocation scheme (RFC 3359) it is marked as illegal. Deployment experience in the mid 1990s has revealed the deficiencies of the RFC 1195 and ISO 10589 defined TLVs. Beside the obviously too small 6-bit Metrics, the mess surrounding Internal/External Routes and the limited functionality to add link- related information into the LSP caused the IS-IS community to define some new- and Old-style IP Reach (RFC 1195) Information 317 redefine some old TLVs. This set of TLVs is mostly referred to as New-Style Metrics, con- trasting to the historical Old-Style Metrics. 12.3 New-style Topology (IS-Reach) Information The IS Reachability TLV that was proposed in ISO 10589 actually has two major limita- tions. Besides the obvious limitation of the 6-bit metric space there is another limitation, which does not allow adding any link-related information to an adjacency. The old-style (ISO 10589 and RFC 1195) TLVs are quite strictly formatted: each neighbour adjacency consumes 11 bytes and so does not have any place where additional information could be attached to a particular adjacency. Given that, it was clear that a revision of both the IS-Reachability and IP-Reachability TLVs needed to have a bigger metric space and more importantly, it needed to be ready for further extensions. The IETF revised the existing IS Reachability TLV #2 and IP Reachability TLVs #128 and #130 to correct these deficiencies and provide further extensibility mechanisms. RFC 3784 mentions two new TLVs: • Extended IS Reachability TLV #22 • Extended IP Reachability TLV #135 These metrics are also known as wide-metrics. Figure 12.8 show the basic structure of the extended IS Reachability TLV. The first seven bytes hold the System-ID plus pseudonode number. Next there is room for a 24-bit metric. Why 24-bits and not 32-bits? The basic idea behind that scheme was to be able to do all the calculations during an SPF run using 32-bit unsigned integers without exhaust- ing the integer space. Therefore, the extended IS Reach TLV #22 theoretically supports up to 255 hops (1 byte), each at a maximum metric of 16.7 million, without wrapping the 32-bit integer space. Twenty-four bits are also enough for expressing a bandwidth range of 64 KBit/s to 1 Terabit/s in the inverse bandwidth metric scheme. The calculation for this is straightforward: just assume the lowest bandwidth (64 KBit/s) and assign it to the highest metric (2^24). 64 Kbit/s * 2^24 ϭ 1073741824 Kbit/s/1024 ϭ 1048576 Mbit/s ϭ 1024 GBit/s ϭ 1Tbit/s The next byte is probably the most powerful of this TLV. If this is non-zero then there is additional information included about this link/adjacency. In fact, the Extended IS Reach TLV #22 is the first TLV to have a variable length, including so-called sub-TLVs that carry additional information about the link. Please note that generally in IS-IS there is no notion of a link. All that IS-IS can express is adjacencies. In WAN environments the mapping of adjacencies to links is typically a one-to-one mapping. In LAN environments this can be a one-to-one relationship but does not have to be. Practically speaking, 95 per cent of all the circuits in a service provider core topology are pure point-to-point links, so in most envir- onments the term link and adjacency can be used interchangeably. There is more detailed information about TLVs and sub-TLVs in Chapter 11, “TLVs and Sub-TLVs”. 318 12. IP Reachability Information 12.3.1 Automatic Metric Calculation The Metric field is typically a dimensionless scalar, which expresses the preference of using that link. Typically it is calculated according to the inverse bandwidth of that link. Each implementation allows to set an internal Reference Bandwidth parameter. The Reference Bandwidth is the base value which will be divided by the bandwidth of the interface to yield the metric. So, for instance, if the Reference Bandwidth is 1 Gbit/s, then a 10 Mbit/s circuit will be assigned a metric of 100. Similarly a Fast Ethernet circuit will be assigned a metric of 100. The problem with Reference Bandwidth is that they are constantly changing, depending how fast the circuits in the network are being upgraded. Assume there are OC-192/STM- 64 circuits deployed in the network, which are capable of transporting roughly 10 Gbit/s. As soon as the network turns on its first OC-768/STM-256 the metric scheme has to be revised. For instance, for a long time OSPF used to have the Reference-Bandwidth of 100 Mbps, because at the time when OSPF was specified the architects of the protocol thought that 100 Mbps would be sufficient forever. One could argue that what could be New-style Topology (IS-Reach) Information 319 TLV Type TLV Length Neighbour ID optional subTLV Value 22 Bytes 1 1 ID Length (6) ϩ 1 3 1 1 1 1–242 Metric subTLVs Length optional subTLV Type optional subTLV Length Neighbour ID optional subTLV Value ID Length (6) ϩ 1 3 1 1 1 1Ϫ* Metric subTLVs Length optional subTLV Type optional subTLV Length FIGURE 12.8. The most significant change of the Extended IS Reachability TLV #22 is the support for sub-TLVs and 24-bit metrics . also spot the IP External TLVs by looking into the isis database using the show isis database command. IOS command output The bold marked output represents the content transported using the IP. always takes the inet.0 Routing Table as input and computes a subset of these routes. The then portion tells what to do with the prefixes that match the from part. In our example, the policy rip-routes-to-isis. certain combinations of the TLV Type and the Internal/External Bit of the Metric Bytes are not valid. More about the valid and invalid combinations of the both TLVs, which finally led to the demise of the old-style