|
|
Operating and Troubleshooting the NetworkFor the most part, EuropCom plans to keep managing its network as before, using IPv4 tools, processes, Management Information Bases (MIBs), and transport. It sees IPv6 as a new service deployment rather than a replacement for IPv4. Therefore, it will be managed as a service (service monitoring, IPv6 traffic management, and so on), although the network itself will still be managed with the current IPv4 tools. Configuration management and topology management, for instance, will continue to be performed using HP OpenView. This strategy relies on the fact that most devices will be either IPv4 only or dual stack, and none will be IPv6 only.
Service and Traffic MonitoringAll the IPv6 services management will be performed over MPLS 6PE (all the IPv6 enabled devices have 6PE connectivity). Service availability will be monitored using Nagios (IPv6 ping) and IPv6 traffic management using Cisco Network Analysis Module (NAM). See Chapter 10, "IPv6 Network Management," for details. AddressingEuropCom is a well-established ISP, with more than 200 IPv6 customers. Therefore, it could justify and obtain a /32 prefix from the RIPE/NCC (see Chapter 12, "Generic Deployment Planning Guidelines," for details on deployment planning), as illustrated in Table 13-9. The prefix allocated to EuropCom is 2001:6FC::/32.
The EuropCom addressing plan is in full compliance with RFC2373. EuropCom will keep 2001:6FC::/48 to use for its own infrastructure. It will assign up to/48 to large enterprise customers, and up to /56 to small business customers, out of its 2001:6FC::/32 block. Residential customers will each get a /64 prefix. Note that there is no fundamental difference whether the customers are VPN customers or IA customers. Allocated addresses will always be within the public range (2001:6FC::/32). For large enterprise customers, the assigned prefix will be in the form 2001:6FC:1abc::/48, where abc identifies the customer. Small enterprise customers will get 2001:6FC:2abc:defg::/56, where abc:defg identifies the customer (defg > 0). EuropCom does not intend to "enforce" a routing policy that would require a customer to follow the preceding rule, other than making sure VPNv6 customers will not advertise more than a certain number of prefixes per PE. Link-Local AddressesOn PE-CE interfaces, EuropCom will use link-local addresses for peering with the CE, in the form FE80::83D7:ID, where 83D7 is EuropCom ASN (33751) in hexadecimal format and the ID is a 16-bit numeric value, starting at 1, reusable from link to link, and from PE to PE. Note that because most PE-CE links are point to point, most peering address on the PE-CE interface will be FE80::83D7:1. On the CE side, the corresponding CE-PE address will be in the same format, with the customer ASN. For instance, EuropCom customer Cisco, with ASN 21214, will use FE80::52DE:1. Addresses for ManagementBecause using link-local addresses on the PE-CE interface might be an issue for troubleshooting and management (could not ping the interface from remote devices, for instance), and for any router application required to locally generate packets (including ICMPv6, Telnet, and so on), each side should assign a global address on the PE-CE interface, from its own prefix. Typically, EuropCom customers will choose a small block (for instance /64) out of the prefix they got from EuropCom, and configure a loopback address out of it (one per CE). Note that assigning global addresses may open some security breach and such addresses should be properly protected against DoS attacks (see the "Security" section). EuropCom itself will use 2001:6FC::/64 for that purpose, and assign 2001:6FC::PE#/128 at each 6PE and 6VPE (in each vrf). These global addresses will be advertised to all EuropCom 6PEs, but will never cross the autonomous system boundaries. Using Unique-Local AddressesEuropCom is not really concerned about unique-local addresses, which could be used for intra-site or inter-site communication. Because unique-local addresses are not publicly routable, a customer using unique-local addresses will be allocated a public range anyway so that it can access the IPv6 Internet. EuropCom will simply filter unique-local prefix (FC00::/8) on the boundary to the public Internet, while treating them as regular global addresses when exchanged between sites of a VPN. In practice, 6PE routers will have the configuration shown in Example 13-25. Example 13-25. Filtering Unique Local Addresses
The preceding prefix list will prevent unique-local or anything else outside the EuropCom prefix range to be advertised to the IGW. The leaking of addresses from a VPN site to the Internet is closely controlled by EuropCom, so no prefix list is required on 6VPE routers. Inter-Provider CommunicationsFor connecting IX and POPs together, EuropCom is using IPv4, and therefore does not have to create a specific IPv6 addressing plan and can just use the existing IPv4 one, based on a private 172/16 block. For interconnecting with other providers at IXs, EuropCom plans to use inter-AS 6PE, which again will not use any IPv6 addresses, thus saving the need to agree on IPv6 addressing rules on these interfaces. MultihomingEuropCom CE routers can be multihomed in several ways:
In the case of IPv6 VPN service, a customer will be allocated 2001:6FC:1abc::/48, and will distribute smaller chunks to each site, (2001:6FC:1abcd:WXYZ::/s), like in the multihomed case. MTU DiscoveryInitially, no backbone routers will be upgraded to software images that can send ICMPv6 messages. So P-routers cannot send "packet-too-big" ICMPv6 messages back to the source. Unlike IPv4, transit routers cannot fragment IPv6 packets with a size that does not fit the outgoing link MTU. If MTU design is not tuned up front, large IPv6 packets could be black-holed by the MPLS core. To prevent core routers fragmenting VPNv4 traffic, EuropCom has been using mpls mtu on the ingress PE to core interfaces, consistent with the core MTU. That way, packets can be fragmented at the edge of the network if it is larger than the configured maximum labeled MTU size. The same configuration applies to IPv6 labeled packets, because they use the same LSP (and label stack) as VPNv4. The difference is that instead of fragmenting IPv6 packets, the edge routers (6PE and 6VPE) will send a "packet-too-big" ICMPv6 message back to the source. Note that the "consistent MTU" approach applies to the core only. The MTU on the PE-CE link can be smaller than the one configured in the core. In this case, the PE will send back an ICMPv6 too-big message over the MPLS core. SecurityAn important aspect of the IPv6 deployment planning and design is that of assessing the security risks it would introduce in EuropCom network. The analysis was performed based on the guidelines mentioned in Chapter 9, "Securing IPv6 Networks," and it was decided that as a general rule, all IPv4 security policies will be matched for IPv6. At the same time, EuropCom had to consider several IPv6- and 6PE-specific security policies. Securing the EdgeIn the process of securing the edge, EuropCom took the following measures:
EuropCom interfaces directly with only a subset of its customers. In these cases, it considers implementing protective measures for its routers against floods of control message such as Router Solicitations, Neighbor Solicitation, and MLD traffic. Example 13-26 shows how an interface is configured to police all Neighbor Solicitation and "All Routers" messages. Example 13-26. Configuring Control-Plane Protection
When implementing the policies shown in Example 13-26, consideration should be given to their impact on the router operation. They should be implemented on a large scale only on interfaces that support the functionality in hardware. Securing the 6PE InfrastructureThe MPLS backbone and the PE routers are critical elements to support the IPv6 service as well as existent, revenue-generating IPv4 services. The IPv6 deployment should not open any security holes that can expose it to attacks. A few security measures have to be enforced to protect the MPLS because of the 6PE/VPNv6 overlay:
Another useful feature that should be leveraged on the PE routers but, depending on the platform it can be used for EuropCom CE routers as well, is the control-plane protection. If the policy prevent-attack in Example 13-26 is modified to include all ICMP traffic, it could be used to protect the router resources used for control purposes. control-plane service-policy input prevent-attack Most network elements that support EuropCom IPv6 service are dual stack. The IPv4 side of these routers is already secured based on the best practices recommendations. TroubleshootingBeing able to easily troubleshoot network anomalies with regard to the new deployed service is a key element of the EuropCom deployment process. EuropCom operation engineers are familiar with BGP, MPLS, IPv4, and VPN. When troubleshooting IPv6, anything that looks similar to VPNv4 will dramatically minimize their learning curve. In fact, very few of the tools and commands used to troubleshoot 6PE and 6VPE are specific to IPv6. In the vast majority of the cases, the troubleshooting methodology is the same for IPv4 and IPv6, and the commands and tools vary by one keyword. RoutingThe deployed solution (6PE/6PE) involves principally BGP, which EuropCom has been already operating for IPv4 services. The same set of commands EuropCom is already familiar with can be used (with different set of arguments) for IPv6, and similar outputs are obtained. For instance, you can display a summary of BGP IPv6 activity as shown in Example 13-27. Example 13-27. BGP IPv6 Activity Summary
Each table (BGP IPv6, BGP VPNv6) can be looked at individually, as shown in Example 13-28. Example 13-28. Dumping BGP IPv6 Table
IPv6 routing tables can be displayed, to identify each routing protocol contributor to routable entries, as shown in Example 13-29. Example 13-29. Dumping IPv6 Routing Table
Note that, from an IPv6 routing perspective, entries reachable over the MPLS backbone are listed as "indirectly connected" because MPLS is providing a layer 2 tunnel mechanism. ForwardingForwarding anomalies should be detected, understood, and troubleshot. Tools such as ping ipv6 and traceroute ipv6 are used to validate data-plane connectivity and detect traffic black-holing. Commands such as traceroute mpls and show mpls forwarding can pinpoint the damaged node, interface, and FEC. At the edge, troubleshooting forwarding failures for a particular IPv6 destination commonly leads to breaking down the recursive resolution into elementary pieces. This requires combining analysis of IPv6 routing (iBGP/eBGP), IP routing (IS-IS/OSPF), label distribution (BGP/LDP/RSVP), and adjacency resolution to narrow down a resolution breakage. PE-CE ConnectivityThe IPv6 ping and traceroute are useful to check connectivity from a PE to a CE, whether locally attached, or remote over the MPLS backbone. When locally attached, EuropCom uses IPv6 ping with the CE link-local address (used for eBGP peering), as illustrated here (pinging Nice-CE): Nice-PE-IA#ping FE80::4F6B:44%Serial1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::4F6B:44, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/48 msThe same command can be used to test remote PE or CE reachability, but only IPv6 global addresses can be used (link-locals are not advertised beyond the link): London-PE-IA# ping 2001:6FC:1120:1::44
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:6FC:1120:1:44::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/48 msNote that the ping (and traceroute) over MPLS requires PEs and CEs to announce one IPv6 global prefix. Each 6PE router announces 2001:6FC::PE#/128, filtered at the autonomous system edge. Each IPv6 CE configures 2001:6FC:prefix:CE#/128 and announces it as part as their less-specific prefix (2001:6FC:prefix::/n). Reachability of remote PEs and CEs can be tested by using traceroute. EuropCom has configured all its PEs with no mpls ip propagate-ttl forwarded, so when traceroute is executed from a CE, it will only show the IPv6 nodes: Nice-CE#traceroute 2001:6FC::1
Type escape sequence to abort.
Tracing the route to 2001:6FC::1
1 2001:6FC::26 [AS 33751] 32 msec 32 msec 20 msec
2 2001:6FC::1 [AS 33751] [MPLS: Label 73 Exp 0] 20 msec 20 msec 20 msec
3 2001:6FC::1 [AS 33751] 28 msec 20 msec 20 msecAfter the P-routers have been upgraded with images that support ICMPv6, the same command executed on the PE router (TTL is then propagated) will also show P-routers responses, as illustrated here: Nice-PE-IA#traceroute 2001:6FC::1
Type escape sequence to abort.
Tracing the route to 2001:6FC::1
1 ::FFFF:172.20.25.1 [MPLS: Labels 38/73 Exp 0] 40 msec 32 msec 32 msec
2 ::FFFF:172.20.10.1 [MPLS: Labels 30/73 Exp 0] 60 msec 32 msec 32 msec
3 2001:6FC::1 [MPLS: Label 73 Exp 0] 32 msec 32 msec 16 msecWhen run from a 6VPE router, both ping and traceroute commands accept a vrf argument, exactly as in the case of VPNv4. Note that the traceroute command is useful for evaluating the path across the MPLS backbone, but not for troubleshooting data-plane failures. The P-routers are IPv6 unaware (like they are VPNv4 unaware), so the ICMPv6 messages that they generate in response to the traceroute command are forwarded to the egress PE using the received label stack. It is the egress PE that can route the ICMPv6 message to the source of the traceroute. When the MPLS path is broken, it is also broken from the ICMP message, which cannot reach the egress PE. For troubleshooting data-plane failures, LSP ping should be used. PE Imposition PathOn Cisco routers, when it comes to troubleshooting the imposition path, the most useful command to start from is the Cisco Express Forwarding (CEF) show ipv6 cef command. You can either display the forwarding table with label stacks used for each destination prefix, as shown in Example 13-30, or display details for a specific entry, to analyze how the destination was resolved and the label stack computed, as shown in Example 13-31. Example 13-30. Dumping IPv6 Forwarding Table
Example 13-31. Details on an IPv6 Entry in the Forwarding Table
From the preceding detailed output, each label composing the label stack has a different origin that can be tracked down individually. BGP table has the bottom label, as shown in Example 13-32. Example 13-32. Details on a BGP Entry in the BGP Table
PE Disposition PathThe disposition path can be looked at and troubleshot by displaying the MPLS forwarding table. Example 13-33 illustrates the output at Milan-IGW. Example 13-33. Dumping the MPLS Forwarding Table
The label used for switching has been announced by iBGP (6PE in this example), and can be checked. Example 13-34 illustrates this switching. Example 13-34. BGP Label Analysis
Label Switch PathBecause the 6PE and 6VPE LSP endpoints are IPv4 addresses, the IPv4 tools EuropCom has been using to troubleshoot LSPs are more than ever useful to detect data-plane failures that would lead to IPv6 traffic black-holing. In Example 13-35, at Nice-PE-IA, the show ipv6 route command provides the LSP IPv4 tail end. Example 13-35. Analyzing the Label Switch Path
And the traceroute-LSP, executed from Nice-PE-IA, is shown in Example 13-36. Example 13-36. Traceroute-LSP Example
Troubleshooting Routing and ForwardingWhen it comes to fine troubleshooting of routing and forwarding anomalies, enabling debugging commands can prove useful, although the number of messages (factor of the activity on the wire) can annihilate the usability of such tool (debug ipv6 cef, debug mpls packet, debug ipv6 packet for the forwarding path; debug bgp ipv6 and debug bgp vpnv6 for the control plane). External tools, such as ethereal, are also used in critical cases to capture and analyze relevant traffic. |
|
|