The Complete IS-IS Routing Protocol- P14 pdf

380 13. IS-IS Extensions New York London Pennsauken Frankfurt London Washington NewYork Paris IPv6 IPv4 FIGURE 13.14. For each network topology a dedicated IS Reach is mesh processed Multi Topology Extension 381 Tcpdump output The Multi Topology Supported TLV reports that this link can be a member of both the IPv4 Unicast (0) and the IPv6 Unicast (2) Topology. 02:00:08.223369 Out OSI, IS-IS, length: 82 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1027, holding time: 27s, circuit-id: 0x01, Flags: [ L1L2 IS ] circuit-id: 0x01, PDU length: 82 Point-to-point Adjacency State TLV #240, length: 15 Adjacency State: Up Extended Local circuit ID: 0x00000001 Neighbor SystemID: 1921.6800.1008 Neighbor Extended Local circuit ID: 0x00000100 Protocols supported TLV #129, length: 2 NLPID(s): IPv4, IPv6 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.33.213 IPv6 Interface address(es) TLV #232, length: 16 IPv6 interface address: fe80::2a0:a5ff:fe12:3398 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Restart Signaling TLV #211, length: 3 Restart Request bit clear, Restart Acknowledgement bit clear Remaining holding time: 0s Multi Topology TLV #229, length: 4 IPv4 unicast Topology (0x000), Flags: [none] IPv6 unicast Topology (0x002), Flags: [none] The IIH reports that it can run IPv4 and IPv6. It lists valid IPv4 and IPv6 addresses and therefore the router can create valid next-hop entries. So the protocols are listed in the MT Topology TLV #229. Type Length 229 Bytes 1 1 Topology-ID O 2 A R R Topology-ID O 2 A R R F IGURE 13.15. The Topologies Supported TLV #229 lists the topologies that the link carries Each router advertises an adjacency for a common topology adjacency using the Multi Topology IS-Reachability TLV #222 (see Figure 13.16). Tcpdump output 02:10:39.192433 OSI, IS-IS, length: 151 L1 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) lsp-id: 1921.6800.1027.00-00, seq: 0x00000050, lifetime: 1199s chksum: 0x1477 (correct), PDU length: 151, Flags: [ L1L2 IS ] [ ] Multi Topology TLV #229, length: 4 IPv4 unicast Topology (0x000), Flags: [none] IPv6 unicast Topology (0x002), Flags: [none] Protocols supported TLV #129, length: 2 382 13. IS-IS Extensions TLV Type TLV Length Neighbor ID optional subTLV Value 222 Bytes 1 1 ID Length (6) ϩ 1 3 1 1 1 1–240 Metric subTLVs Length optional subTLV Type optional subTLV Length Neighbor ID optional subTLV Value ID Length (6) ϩ 1 3 1 1 1 1Ϫ* Metric subTLVs Length optional subTLV Type optional subTLV Length Topology-ID 2 Reserved FIGURE 13.16. The Multi Topology IS Reachability TLV #222 is similar to the Extended IS Reachabil- ity TLV #22 Multi Topology Extension 383 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) [ ] Multi-Topology IP6 Reachability TLV #237, length: 16 IPv6 unicast Topology (0x002), Flags: [none] IPv6 prefix: 2001:708:0:ff19::/64, Distribution: up, Metric: 250000, Internal Multi Topology IS Reachability TLV #222, length: 13 IPv6 unicast Topology (0x002), Flags: [none] IS Neighbor: 1921.6800.1008.00, Metric: 250000, no sub-TLVs present The tcpdump output also shows that the link IPv6 prefix is not encapsulated in the IP6 Reachability TLV #236, but rather in the Multi Topology IP6 Reachability TLV #237. The structure of that TLV is illustrated in Figure 13.17. TLV #237 almost looks identical and also shares the semantics of the IP6 Reach TLV. The only difference is that it gets prepended with the 12-bit Topology ID. A similar clone for the Extended IPv4 Reachability #135 exists, which is the MT IPv4 Reachability TLV #235, as illustrated in Figure 13.18. For the default Topology #0 there is already an IPv4 Reachability TLV, which is #135 hence the usage of the TLV #235 is highly questionable in Topology #0. However, in other IPv4 related topologies such as the IPv4 multicast topology, usage of the MT IPv4 Reach TLV #235 does make sense. 13.5.1 JUNOS Configuration Per JUNOS 6.2 the multi topology extensions are available. The configuration is a “one- liner” which turns on multi topology support on all interfaces that have family iso and family inet6 configured and are listed in the protocols isis inter- face {} stanza. If you do not want to run multi topology support for a given Topology /Adress Family on a given interface, then you can disable multi topology generation by configuring no-ipv6-unicast or no-ipv6-unicast under the protocols isis interface {} stanza. JUNOS configuration The topologies ipv6-unicast configuration string turns on MT generation on all inter- faces. The no-ipv6-unicast command under the protocols isis interface stanza disables MT generation for the IPv6 topology. hannes@Frankfurt> show configuration [ ] protocols { isis { topologies ipv6-unicast; [ ] interface fe-0/3/3.0 { no-ipv6-unicast; } interface lo.0; } } 384 13. IS-IS Extensions Next you need to verify if your neighbour also supports multi topology. This gets revealed in the show isis adjacency command output. TLV Type TLV Length metric Reserved Prefix optional all-subTLVs Length optional subTLV Type U/D optional subTLV Length optional subTLV Value 237 Bytes 1 1 4 1 0–16 1 1 1–244 E S Prefix Length 1 1 metric Reserved Prefix optional all-subTLVs Length optional subTLV Type U/D optional subTLV Length optional subTLV Value 4 1 0–16 1 1 1Ϫ* E S Prefix Length 1 1 Topology-ID 2 Reserved F IGURE 13.17. The Multi Topology IPv6 Reachability TLV #237 shares the semantics of the IP6 Reachability TLV #236 JUNOS command output The neighbour also supports multi topology for the IPv6 Unicast topology. hannes@Frankfurt> show isis adjacency detail [… ] London Interface: so-1/2/0.0, Level: 2, State: Up, Expires in 23 secs Priority: 0, Up/Down transitions: 11, Last transition: 00:24:12 ago Circuit type: 3, Speaks: IP, IPv6 Topologies: Unicast, IPV6-Unicast Restart capable: Yes IP addresses: 172.16.33.29 IPv6 addresses: fe80::203:fdff:fec8:3c00 [… ] Multi Topology Extension 385 TLV Type TLV Length metric Prefix Length Prefix optional all-subTLVs Length optional subTLV Type optional subTLV Length optional subTLV Value metric Prefix Length Prefix optional all-subTLVs Length optional subTLV Type optional subTLV Length optional subTLV Value 135 U/D sub Bytes 1 1 4 1 0–4 1 1 1–245 4 1 0–4 1 1 1Ϫ* U/D sub 1 1 Topology-ID 2 Reserved F IGURE 13.18. The Multi Topology IPv4 Reachability TLV #235 shares the semantics of the Extended IP Reachability TLV #135 386 13. IS-IS Extensions The router has now received LSPs from neighbouring routers and processed them in a per-protocol SPF calculation. The output of all the show isis spf <*> commands has changed. It now displays the statistics and results on a per-topology breakdown. JUNOS command output The output of the show isis spf log command encompasses results for each topology. hannes@Frankfurt> show isis spf log IS-IS level 2 SPF log: Start time Elapsed (secs) Count Reason Fri Nov 7 01:58:29 0.000120 1 Updated LSP Paris.00-00 Fri Nov 7 01:58:33 0.000141 1 Updated LSP Frankfurt. 00-00 Fri Nov 7 01:58:38 0.000118 1 Updated LSP London.00-00 Fri Nov 7 01:59:54 0.000114 1 Updated LSP London.00-00 Fri Nov 7 01:59:59 0.000219 2 Lost adjacency London on so-1/2/0.0 Fri Nov 7 02:45:22 0.000084 1 Reconfig IPV6 Unicast IS-IS level 2 SPF log: Start time Elapsed (secs) Count Reason Fri Nov 7 01:58:15 0.000066 7 Lost adjacency Pennsauken on so-7/0/0.0 Fri Nov 7 01:58:16 0.000095 2 Updated LSP Frankfurt. 00-00 Fri Nov 7 01:58:19 0.000098 1 Lost adjacency London on so-1/2/0.0 Fri Nov 7 01:59:54 0.000084 1 Updated LSP London.00-00 Fri Nov 7 02:23:46 0.000202 1 Periodic SPF Fri Nov 7 02:34:45 0.000113 1 Reconfig Fri Nov 7 02:45:22 0.000267 1 Reconfig The configuration in IOS is equally simple. 13.5.2 IOS Configuration IOS now supports per-address family configuration. By configuring the multi- topology command under the address-family ipv6 stanza, multi topology support is turned on all interfaces that have the ipv6 router isis command listed. IOS configuration London# show running-config [… ] router isis net 49.0001.1921.6800.1012.00 metric-style wide passive-interface Loopback0 ! address-family ipv6 multi-topology exit-address-family ! Multi Topology Extension 387 Next you may want to verify that the peer supports multi topologies as well. Similar to the JUNOS example, in IOS the show clns neighbors detail command your neighbour states. IOS command output London# show clns neighbors detail System Id Interface SNPA State Holdtime Type Protocol Frankfurt POS2/0 PPP Up 25 L2 M-ISIS Area Address(es): 49.0001 IP Address(es): 172.16.33.213* IPv6 Address(es): FE80::2A0:A5FF:FE12:3398 Uptime: 00:13:42 NSF capable Topology: IPv4, IPv6 Finally, you want to check how the processing of the IPv6 topology went. You can see the log for the IPv6 MT Topology using the show isis ipv6 spf-log command. IOS command output The show isis ipv6 spf-log command shows the SPF duration and reason for the last calculations based on the IPv6 Unicast Topology. London#show isis ipv6 spf-log IPv6 level 2 SPF log When Duration Nodes Count First trigger LSP Triggers 01:03:10 8 6 3 Frankfurt.00-00 NEWADJ DELADJ LVCONTENT 00:53:03 4 6 1 PERIODIC 00:52:49 5 1 2 London.00-00 DELADJ TLVCODE 00:52:34 4 6 2 London.00-00 NEWADJ TLVCODE 00:38:01 4 6 1 PERIODIC 00:28:24 4 6 1 Frankfurt.00-00 TLVCODE 00:22:57 4 6 1 PERIODIC 00:17:46 4 2 2 London.00-00 DELADJ TLVCODE 00:07:54 4 1 1 PERIODIC 13.5.3 Summary and Conclusion Because of the stringent requirements of RFC 1195, which requires that all routers support all Network Layer protocols, it is hard to deploy IPv6 (for example) increment- ally. Convex migration schemes help to avoid routing loops during a network rollout. However, if there is mis-configuration then it is relatively easy to break a multi protocol environment in IS-IS. For that purpose, the IS-IS WG defined four additional TLVs that make each router build distinct topologies and perform a per Network Layer protocol SPF calculation. Multi topologies are a viable solution for deploying IPv6 incrementally 388 13. IS-IS Extensions in the network, however, there is serious concern in the Service Provider community as to whether this complexity is necessary at all. Most service providers have MPLS as the uniform transport vehicle, and MPLS is already deployed in their networks. The idea is that the inner core topology runs on IPv4 only and IPv6 Reachability Information is exchanged via BGP. BGP uses IPv4 to resolve the next-hops and then traffic is relayed between a pair of BGP speakers using the MPLS magic carpet. It is the authors’ opinion that if there is a possibility to re-use that MPLS magic carpet, then there should be serious consideration whether an IPv6 control plane is required, necessary and worth the hassle. 13.6 Graceful Restart The Internet is about to become the new public infrastructure. When the Internet will replace today’s communication infrastructure is not as easy to predict. Common sense says that you can pull the plug when the new infrastructure is better, faster and more resilient than the old infrastructure. However, especially in terms of availability and soft- ware stability, IP switching platforms in the past lacked the resiliency and redundancy of the old infrastructure, like TDM multiplex networks and voice switches. Typically it is the software that makes systems fail (assuming that the hardware designers have done their job well). When it comes to software, TDM multiplexers do not expose any weak- nesses due to their almost static configuration and so naturally avoiding any complex signalling software. On the other hand, voice switches have to rely on signalling proto- cols like SS7. Unfortunately, stability and “feature velocity” negatively impact each other. It is relatively easy to freeze code and do some bug fixing in order to get to stable signalling code and release the stable code in the hope that it does not break in the live network. In a fast progressing world like the IP world, that approach is not feasible because there will be always further enhancements/bug fixes to the base protocol. Modern software release models apply careful testing to the code base before it is released to the public. However, it turned out that there is a no more brutal reality-check to verify if the code works than exposing it to the live Internet. Furthermore, the support teams of the vendors had to be very responsive to fix any kind of problem really fast. Due to the 24 ϫ 7 nature of the Internet (non-business hours traffic is just 70 per cent of the peak traffic during business hours) almost no maintenance window can be established. The necessary software upgrades are really painful for the users and operators, as a soft- ware upgrade always means about 60–180 seconds outage until the entire router complex (control plane and forwarding plane) is rebooted. A reboot of a routing node results in a changed topology. This topology change will have a negative impact on other routers, entailing AS-global SPF runs, BGP route flaps and subsequent route damping by external BGP peering partners. Modern routers are based upon a clear separation between the control plane and forwarding planes. The two entities can work independently from each other for a short period of time. For example, the forwarding plane can easily keep forwarding state while the control plane (in Cisco, it is the Route-Processor; Juniper Networks calls it the Routing Engine) is rebooting. Keeping forwarding state means that the forwarding plane Graceful Restart 389 forwards packets based on the last good routing information, effectively freezing the for- warding table. The control plane can next reboot, while the forwarding engine is still passing traffic. The trouble starts when the control processor is coming up again. Because it just rebooted, it does not have any state knowledge of its adjacencies nor does it have any topological insight (that is, the link-state database is empty). If a router is in that state and it generates an IIH and does not demonstrate that it has achieved 3-way state by listing its neighbour’s adjacency state or SNPA (for more on adjacency management see Chapter 5, “Neighbour Discovery and Handshaking”), then the adjacency will be imme- diately disrupted and global SPF recalculation will occur. Graceful restart attempts to fix the problem of missing state during reboot. It does not make a difference why the control plane processor has been rebooted. It could be because of a software crash or due to a controlled operation like a software upgrade. Figure 13.19 illustrates the timing after a reboot. Router B requests Router A to stay quiet for 180 seconds. In that 180 seconds it needs to re-instate all adjacencies, bring up the BGP mesh and recalculate its routes. Finally it needs to compare the previously frozen forwarding plane information with the new cal- culated prefix list and apply, if necessary the required changes. Amsterdam Stockholm t t IIH Restart Request, New holdtime180 s IIH Restart Acknowlegement, Newholdtime180 s FIGURE 13.19. Router Stockholm requests a grace period of 180 seconds [...]... Based on the VPI/VCI or DLCI field, the Layer-2 switch looks up the outgoing port and just as importantly, an outgoing VPI/VCI or DLCI Based on this information, the VPI/VCI or DLCI is rewritten before the cell or the packet leaves the router The VPI/VCI or DLCI field has purely local meaning and is only valid on the interface downstream to the receiver The concept of label swapping comes from the original... with the protocol 2 Forwarding State Model RSVP uses two basic messages for requesting and granting forwarding state: the PATH and the RESV messages The Path message describes what the sender wants to transmit to the receiver, and the RESV message describes what the receiver is willing to accept The PATH message travels hop-by-hop downstream to the receiver and the RESV message travels upstream from the. .. Tweaking In the IP world, routing protocols try to compute the shortest path between a pair of sub-nets A common sense example from the real world says that the shortest path may not be the best path, as everybody getting stuck in the Monday morning and Friday evening traffic jams on the highways knows The shortest path from a distance perspective means nothing if the load on that path is too high and therefore... routers in the network, and the traffic jumps onto the Washington–London path In the end, nothing is gained, as there is still an imbalance, however, this time on a different link in the core network In this example the change resulted in an even worse overall utilization because now two network segments are congested The main problem here is the granularity in controlling the traffic Often the only granularity... receiver to the sender along the path established The receiver can set up forwarding state in a stepby-step fashion and, as soon the RESV message arrives at the requester, everything is ready and then the forwarding path can immediately be used That property is a wide deviation from the usual “signalling” and routing paradigm found in IP networks Routing typically does not get any feedback – at best a routing. .. will be written into the VPI/VCI fields and the forwarding paradigm stays the same The label look up determines the outgoing port and outgoing label, with which the cell will be rewritten upon transmission 403 VCI CLP HEC VPI FIGURE 14.8 In the cell-based MPLS world, IP protocols do the label setup PT GFC Q.2931 Signalling Cell Header PNNI Routing PT GFC CLP Label HEC RSVP/LDP OSPF /IS-IS 404 14 Traffic... router modifies is the shim header The MPLS shim header consists of a 20-bit label value plus EXP, S and TTL bits The label information inside the MPLS shim header is constantly rewritten along the switching path as in ATM or Frame Relay switch networks The TTL field carries the same semantics as the IP TTL field The main purpose is to prevent harm resulting from persistent forwarding loops The Experimental... Pennsauken is the penultimate router on the forwarding path and therefore it has to tell the egress router to unwrap the packet It does so by swapping the label to zero and forwarding it to Washington The Egress or tail end router in Washington knows now to POP the top label off the stack and do a regular IP lookup on the packet inside 14.4 MPLS Signalling Protocols Now the next big question is: how are... the receiver confirms that it is willing to accept traffic according to the flow request, then admission is granted Then all routers across the path are required to set up per-flow schedulers to guarantee that the individual application can transmit the traffic with the requirements granted by the network The per-flow model failed due to the inherent scaling problems of implementing it in hardware This was... that they could perform both traffic engineering and routing on a single platform if for no other reason than cost The lack of router knowledge of the underlying topology also causes sometimes weird re -routing behaviour Consider Figure 14.5, where the direct VC between Paris and Frankfurt fails In the IGP topology every VC has a cost of 1 Because there is no direct alternate path (cost 1) available, the . how the processing of the IPv6 topology went. You can see the log for the IPv6 MT Topology using the show isis ipv6 spf-log command. IOS command output The show isis ipv6 spf-log command shows the. side of the bus to the other and almost tipping the bus over. Consider Figure 14.2, where the traffic engineer tries to offload some traffic on the Frankfurt to London link by changing the link-metric. numbers the fragments and detects the start and end of an IP packet is needed to reassemble the packet at the end of the cell-switching domain. In the ATM world those functions are performed by the