OSPF Area 11 OSPF Area 47 OSPF Area 0 Backbone Pennsauken Frankfurt London Washington New York Paris Amsterdam Stockholm Vienna Munich Atlanta Miami San Jose San Fran 1 2 3 4 1 2 4 3 F IGURE 12.13. OSPF leaks all prefixes into all areas, which is one of OSPFs scaling harms 330 Domain-wide Prefix Distribution 331 Typically, leakage of all routes into the non-zero areas is not necessary. All that the non- zero area needs to know is the area internal routes and a default route that points to the Area Border Routers. IS-IS has much better scaling properties in that respect. Consider Figure 12.14. Very much like OSPF, IS-IS passes on Level 1 information to Level 2. However, the other direction is by default blocked: Level 1 routers have to rely on a default route generated by the L1L2 routers. Flooding just a default route is clearly a very scalable approach; however, the use of the default route as the only routing information pointing towards the ATTached Level 2 router is very unspecific information. Sometimes it is necessary to trade protocol scal- ability for optimality of traffic flow. The side effect of unspecific information can be sub- optimal routing, as shown in Figure 12.15. Traffic towards 192.168.1.13/32 gets attracted to the closest L1L2 router, which is Router Barcelona, due to a lower metric of the default-route 0/0 of 2000, although from a total routing metric perspective, sending the traf- fic straight to the L1L2 Router Milan would be more optimal. The sub-optimal path-cost Madrid-Barcelona-Paris-Frankfurt is 22000. The more optimal path would be Madrid- Milan-Frankfurt with a composite path-cost of 11500. The use of unspecific routing- information makes IS-IS have a kind of “blind spot” and results in sub-optimal routing. RFC 2966 lifts that strict requirement to pass just the default 0/0 route down to Level 1 and allows leaking of prefixes from Level 1 to Level 2. Additionally, RFC 2966 allows external routes to exist in Level 1, which was strictly forbidden according to RFC 1195. But allowing the routes to flow from Level 2 to Level 1 is still not enough, as shown in Figure 12.16. Suppose some router, located beyond Paris in Level 2 originates (among others) its loopback IP address, either in the internal IP Reachability TLV #128 or the Extended IP Reachability TLV #135. Barcelona re-distributes the 192.168.1.1/32 prefix into Level 1. The Level-1 LSP travels through Level 1 finally arriving at Milan. Milan does what every L1L2 router has to do, and accepts unconditionally all Level-1 IP prefixes and injects them into Level 2. This creates a wonderful routing loop as from this point on nobody really knows where the route really did originate. Therefore a Marker Bit is needed to mark routes that have been marked as Leaked from Level 2 to Level 1. Additionally, all L1L2 routers need to suppress prefixes where the Marker Bit is set and not propagate them fur- ther. The Marker Bit is called, in RFC 2966 terminology, the Up/Down Bit. The Extended IP Reachability TLV #135 has had support for the Up/Down Bit from the beginning. The old (RFC 1195) style TLVs do not have support for the Up/Down Bit in the ori- ginal specification, because none of the original authors was aware that too much scal- ability could lead to a problem. RFC 2966 also redefines the MSB of the default-metric for the two old-style IP Reachability TLVs #128 and #130. Per RFC 1195, the MSB of the default-metric was specified as Reserved and should therefore be set to zero. See Figure 12.17 and Figure 12.18 for the revised version of the old-style TLVs. 12.6.1 Leaking Level-2 Prefixes into Level 1 In both IOS and JUNOS the default behaviour of IS-IS is RFC 1195 compliant and does not leak L2 prefixes from Level 2 to Level 1. When you want certain prefixes to leak through you have to explicitly configure that. Area 49.0001 Level 2-only Area 49.0200 Area 49.0100 Pennsauken Frankfurt London Washington New York Paris Amsterdam Stockholm Vienna Munich Atlanta Miami San Jose San Fran 1 3 1 3 0/0 0/0 0/0 0/0 F IGURE 12.14. IS-IS suppresses per default Level 2 routing information to Le vel 1 332 Domain-wide Prefix Distribution 333 Area 49.0001 Level 2-only Area 49.0300 192.168.1.13/32 Barcelona Milan RomeMadrid Frankfurt Paris 0/0 0/0 10000 1000010000 1500 20002000 1500 1500 FIGURE 12.15. Injection of default routes often causes sub-optimal routings Area 49.0001 Level 2-only Area 49.0300 192.168.1.1/32 Barcelona Milan RomeMadrid FrankfurtParis 1 3 4 5 2 F IGURE 12.16. Leaked-down prefixes need to get marked, otherwise routing loops will form 334 12. IP Reachability Information TLV Type TLV Length IP Address 128 Bytes 1 1 1 1 1 1 4 4 N*12 Default Metric 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 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 U/D U/D FIGURE 12.17. RFC 2966 redefines the MSB of the default-metric of TLV #128 to support the Up/Down Bit In IOS there are two possible ways to leak prefixes from Level 2 to Level 1. The first one controls the leaking via an extended access list. The second one controls route leak- ing via a route-map. In the following examples, depending on the application, both methods are used. For smaller networks, where the loopback IP addresses of all the routers in a network fall under a common network prefix, the access-list options is typically good enough. The following IOS configuration leaks prefixes, which match the extended access list 166 from Level 2 to Level 1. IOS configuration Using the redistribute isis ip level-2 into level-1 distribute-list command the network administrator can specify an extended IP access list which matches prefixes based on a simple prefix/wildcard bit scheme for leaking from the Level 2 database into the Level 1 database. Amsterdam# show running-config [… ] Domain-wide Prefix Distribution 335 TLV Type TLV Length IP Address 130 Bytes 1 1 1 1 1 1 4 4 N*12 Default Metric 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 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 U/D U/D F IGURE 12.18. RFC 2966 redefines the MSB of the default-metric of TLV #130 to support the Up/Down Bit router isis redistribute isis ip level-2 into level-1 distribute-list 166 passive-interface Loopback0 net 49.0001.1921.6816.8007.00 metric-style wide ! access-list 166 permit ip 192.168.0.0 0.0.0.255 any access-list 166 permit ip 192.168.168.0 0.0.0.255 any [… ] IOS command output Using the show isis database command you can spot the leaked prefixes. Amsterdam# show isis database Amsterdam.00-00 detail IS-IS Level-1 LSP Amsterdam.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL Amsterdam.00-00 * 0x00000003 0x94B7 1193 0/0/0 336 12. IP Reachability Information Area Address: 49.0001 NLPID: 0xCC Hostname: Amsterdam IP Address: 192.168.0.166 Metric: 0 IP 192.168.0.166/32 Metric: 10 IP 172.26.26.0/24 Metric: 10 IS-Extended London.00 Metric: 40 IP-Interarea 192.168.168.3/32 Metric: 30 IP-Interarea 192.168.168.4/32 Metric: 20 IP-Interarea 192.168.168.5/32 Metric: 20 IP-Interarea 192.168.168.6/32 Leaked IP prefixes are prepended via the keyword IP-Interarea that is printed if the Down Bit is found in one of the IP Reach TLVs. In JUNOS policy processing there is always a default policy for each routing protocol. The default policy for IS-IS is to reject Level 2 routers from inclusion in the Level 1 data- base. If you want to change that behaviour then you need to write a policy and call it using the export statement. This causes your Level 2 prefixes being evaluated before the default policy has chance to reject it. JUNOS configuration In JUNOS the most important task is writing the policy. The policy-statement leak-L2- to-L1 is a single term policy and it consists of three parts. The from portion reads like “if” and the keywords route-filter, protocol, level are ANDed together. That is, if the prefix is originated within protocol isis AND it is Level 2 AND it falls under the route-filter 192.168.0/24 OR 192.168.168/24 THEN put it into the IS-IS Level 1 database. [edit] hannes@Frankfurt# show [… ] protocols { isis { export leak-L2-to-L1; } } policy-options { policy-statement leak-L2-to-L1 { from { route-filter 192.168.0.0/24 orlonger; route-filter 192.168.168.0/24 orlonger; protocol isis; level 2; } to { protocol isis; level 1; Domain-wide Prefix Distribution 337 } then accept; } } [… ] Using the show isis database detail command you can verify if your prefixes have been leaked correctly. JUNOS command output In JUNOS the leaked prefixes are marked with the Down Bit. hannes@Frankfurt> show isis database detail IS-IS level 1 link-state database: Frankfurt.00-00 Sequence: 0x7, Checksum: 0x8cbb, Lifetime: 1187 secs IS neighbor: London.00 Metric: 10 IP prefix: 172.26.26.0/24 Metric : 10 Internal Up IP prefix: 192.168.0.167/32 Metric : 0 Internal Up IP prefix: 192.168.168.3/32 Metric : 40 Internal Down IP prefix: 192.168.168.4/32 Metric : 30 Internal Down IP prefix: 192.168.168.5/32 Metric : 20 Internal Down IP prefix: 192.168.168.6/32 Metric : 20 Internal Down [… ] In the output you can identify leaked prefixes based on the down keyword, which is printed if the Down Bit is found in one of the IP Reachability TLVs. 12.6.2 Leaking Level-1 External Prefixes into Level 2 RFC 1195 explicitly forbids the use of External IP Reachability TLVs in Level 1. RFC 2966 loosens that restriction as well and allows injecting external information, such as from another routing protocol (RIP, OSPF, BGP, statics), into IS-IS as well. This is par- ticular useful when networked-technology does not speak IS-IS or not even a routing protocol, and the network has to use static routes to inject reachability information. At this point, the authors do not want to encourage injection of reachability information (such as customer prefixes or dial-pools) into IS-IS. In modern network designs, all reachability information is typically carried into BGP, as BGP scales much better with respect to transporting massive amounts of routes. More consideration of these points will be covered in Chapter 16, which deals with IS-IS related network design issues and best current practices. If wide metrics are used in the network then that section can be skipped: the Extended IP Reachability TLV #135 has no notion of internal versus exter- nal prefixes and therefore all Level-1 prefixes get leaked to the Level-2 by default. In IOS you can inject external information from Level 1 to Level 2 via a simple redis- tribute isis ip level-2 into level-1 command. IOS transfers all routes that match the access list 155 from Level 1 to Level 2 irrespective of whether it is an external or an internal route. 338 12. IP Reachability Information IOS configuration Like the Level 2 to Level 1 redistribution in IOS you can specify a Level 1 to Level 2 redis- tribution list which points either to a route-map or to an extented access list. Amsterdam# show running-config [… ] router isis redistribute isis ip level-2 into level-1 distribute-list 155 passive-interface Loopback0 net 49.0001.1921.6816.8007.00 metric-style wide ! access-list 155 permit ip 10.0.0.0 0.0.255.255 any [… ] JUNOS makes distinction between internal or external prefixes. If you want to inject external prefixes into the Level 2 of your network you need to match against the exter- nal keyword in your routing-policy. JUNOS configuration The default policy for leaking external prefixes from Level 1 to Level 2 is reject. If you want to pre-empt the default policy you have to chain-in a policy called leak-ext-L1-to- L2 which catches all external Level 1 routes which match the 10.0/16 prefix. [edit] hannes@Frankfurt# show [… ] protocols { isis { export leak-ext-L1-to-L2; } } policy-options { policy-statement leak-ext-L1-to-L2{ from { route-filter 10.0.0.0/16 orlonger; protocol isis; external; level 1; } to { protocol isis; level 2; } then accept; } } [… ] Domain-wide Prefix Distribution 339 Notice the access lists and route filters that control the leakage between the two levels. It turned out that managing these access lists is a particular pain for large networks. Every time you deploy new routers whose loopback IP addresses need to be leaked then you need to touch all L1L2 routers in your network adjusting the access lists. Most ISPs mit- igated the problem by assigning blocks of loopback addresses to different POPs. The access lists on the L1L2 routers therefore only need to be touched if a block in the POP is fully allocated. Another common practice is to filter based on a prefix length such as /32. Therefore only the loopback IP addresses get leaked – while this may seem as a modest approach for medium-sized networks it clearly does not scale for large networks. The largest networks in the world consist of about 7000–8000 IS-IS speaking routers. Leaking all 8000 prefixes at every L1L2 router may overwhelm the smaller routers in the POP. So what is needed is a more selective way of picking off the /32s from Level 2. 12.6.3 Use of Admin Tags for Leaking Prefixes Most routing protocols support a tagging mechanism to enforce a route-redistribution policy. IS-IS has a similar extension formulated in draft-martin-neal-policy-isis-admin- tags.txt. The draft mentions two optional sub-TLVs to the Extended IP Reachability TLV #135 carrying 32-bit and 64-bit tags. Figure 12.19 shows how these administrative tags are being used in large-scale deployments. First, each interesting /32 prefix (in the figure it is Quebec’s prefix 192.168.1.13/32) is tagged on the default leakage from Level 1 to Level 2. Interesting typically means all those routers that rely on a proper IGP metric like public Internet routing. In our example, the Tag #200 is used for all Internet routers that carry Internet routes. The L1L2 routers Boston and Chicago attach the Tag #200 along with the route. Next, those tagged prefixes travel through the Level-2. On the egress L1L2 routers (Frankfurt and Paris) the leaking policy now gets very simple as all we have to look for is Tag #200 to find out whether to leak the prefix or not. The policy needs to be configured only once and then all you have to do is properly tag the prefixes and your network will act accordingly. In the following two configurations you will see two configurations for IOS and two configurations for JUNOS. The first of the two respective configurations does the tagging and the second one does the leakage based on the existence of a tag. Applying admin tags is fairly simple in IOS. An admin tag is typically an interface prop- erty and can be set using the keyword isis tag <tag>. IOS configuration In IOS you set the Admin tag typically on the Loopback Interface. Using the show isis database London.00-00 level-1 verbose you can verify if the Admin tag has been successfully attached to your Loopback route. London# show running-config [… ] interface Loopback0 ip address 192.168.0.166 255.255.255.255 isis tag 200 ! . where the Marker Bit is set and not propagate them fur- ther. The Marker Bit is called, in RFC 2966 terminology, the Up/Down Bit. The Extended IP Reachability TLV #135 has had support for the Up/Down. also redefines the MSB of the default-metric for the two old-style IP Reachability TLVs #128 and #130. Per RFC 1195, the MSB of the default-metric was specified as Reserved and should therefore be. 2966 redefines the MSB of the default-metric of TLV #128 to support the Up/Down Bit In IOS there are two possible ways to leak prefixes from Level 2 to Level 1. The first one controls the leaking