Previous Page
Next Page

Operating and Troubleshooting the Network

For 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.

  • The core routers are IPv4 only.

  • The ASBRs are IPv4 only.

  • The IPv4 RRs are IPv4 only.

  • Many edge routers, especially in L3 POPs, are IPv4 only, and will remain that way until the first customer using such POP requests an IPv6 access.

  • The IPv6 RRs have no IPv6-enabled interface, and no IPv6 addresses configured.

Service and Traffic Monitoring

All 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.

Addressing

EuropCom 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.

Table 13-9. EuropCom Addressing Plan

Descriptor

Description

network:ID:

NET-EUROPCOM

network:Network-Name:

EUROPCOM

network:IP-Network:

2001:6FC::/32

network:Org-Name:

EuropCom

network:Street-Address:

1701 Nice street

network:City:

London

network:State:

UK

network:Postal-Code:

17203

network:Country-Code:

44

network:Tech-Contact:

europcom-ops@europcom.net

network:Updates:

20050505

network:Updated-By:

ela@europcom.net

network:Class-Name:network:

network


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 Addresses

On 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 Management

Because 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 Addresses

EuropCom 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

router bgp <ASN>
 neighbor a.b.c.d remote-as <ASN>
 neighbor a.b.c.d update-source Loopback0
!
 address-family ipv6
 neighbor a.b.c.d activate
 neighbor a.b.c.d send-label
 neighbor prefix-list Unique-Local out
!
..
ipv6 prefix-list Unique-Local seq 10 permit 2001:6FC::/32 le 56

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 Communications

For 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.

Multihoming

EuropCom CE routers can be multihomed in several ways:

  • Connected to several (usually two) ISPs, in which case they will get a prefix from EuropCom (2001:6FC:abcd::/48) and a prefix from another provider, and advertise both of them on both sides. This does not work differently than IPv4, and has all the same inconveniences (see the "Multihoming" section in Chapter 4 for details). However, "by default", Europcom do no plan to let prefixes more specific than /35 (other than within its own 2001:6FC::/32 range) spreading over its core routing tables. In order for such multihoming configuration to be enabled, it will take case-by-case negotiations between EuropCom, an EuropCom customer and the other provider. Whenever possible, EuropCom will rather implement a multihoming solution based on RFC2260 and RFC3178, and establish a tunnel between the Customer Edge router and the Provider Edge router facing this customer, via the secondary service provider.

  • Connected to two EuropCom PEs. In that case, EuropCom will assign 2001:6FC:1abc::/48, and the CE will advertise back chunks of it (2001:6FC:1abc:WXYZ::/s) to each CE, where WXYZ is a multihomed selector, and s ranges from 49 to 52.

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 Discovery

Initially, 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.

Security

An 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 Edge

In the process of securing the edge, EuropCom took the following measures:

  • Updated the configuration of the PIX Firewall protecting the hosted services in the L1 POPs.

  • Updated any edge router IPv4 ACLs to IPv6. In matching the IPv4 security policies, the IPv6 filters defined on the edge routers observed the requirements of ICMPv6 as mentioned in Chapter 9.

  • Enabled IPv6 uRPF on all interfaces facing the Internet-access customers. This measure prevents spoofing attacks sourced by EuropCom customers.

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

ipv6 access-list DOS-acl
 permit icmp any any nd-ns
 permit ipv6 any host FF02::2
class-map match-all DOS-class
 match access-group name DOS-acl
policy-map prevent-attack
 class DOS-class
 police 70000 1500 1500 conform-action transmit exceed-action drop
!
interface GigabitEthernet1/1
 service-policy input prevent-attack

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 Infrastructure

The 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:

  • The global addresses of the loopback interfaces should not be advertised outside the EuropCom network because they can allow attackers to target a PE router over IPv6 and in the process impact the IPv4 services supported by that PE. Traffic destined for these management prefixes can be easily blocked because, based on EuropCom addressing plan, they all belong to the prefix range 2001:6FC::/64. The same policy should be implemented for any global address used on internal links.

  • If the P-routers in the MPLS backbone are capable of sending ICMP replies, traceroute ICMP traffic has to be particularly blocked at EuropCom border. As it was seen in the traceroute example of a previous section, in this case the path would reveal the IPv4 addresses of the P-routers. This information can be used to attack the network core over IPv4.

  • ACLs can be implemented on PE routers to protect bandwidth, buffer, and processing resources in case of an IPv6 attack, as mentioned in the previous section.

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.

Troubleshooting

Being 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.

Routing

The 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

Nice-PE-IA#show bgp ipv6 summary
For address family: IPv6 Unicast
BGP router identifier 100.26.26.1, local AS number 33751
BGP table version is 15, main routing table version 15
12 network entries using 1692 bytes of memory
22 path entries using 1672 bytes of memory
5/4 BGP path/bestpath attribute entries using 580 bytes of memory
14 BGP rrinfo entries using 336 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4328 total bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
BGP activity 13/1 prefixes, 23/1 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.46.46.1     4 33751     991     983       15    0    0 16:26:21       10
100.47.47.1     4 33751     991     983       15    0    0 16:26:22       10
FE80::4F6B:44%Serial1/0
                4 20331     982     987       15    0    0 14:55:52        1

Each table (BGP IPv6, BGP VPNv6) can be looked at individually, as shown in Example 13-28.

Example 13-28. Dumping BGP IPv6 Table

Nice-PE-IA#show bgp ipv6 unicast
BGP table version is 15, local router ID is 100.26.26.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
* i2001:500::/48    ::FFFF:100.1.1.1     0    100      0 10000 ?
*>i                 ::FFFF:100.1.1.1     0    100      0 10000 ?
* i2001:6FC::1/128  ::FFFF:100.1.1.1     0    100      0 i
*>i                 ::FFFF:100.1.1.1     0    100      0 i
..

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

Nice-PE-IA#show ipv6 route
IPv6 Routing Table - default - 13 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
B   2001:500::/48 [200/0]
     via 100.1.1.1%Default-IP-Routing-Table, indirectly connected
B   2001:6FC::1/128 [200/0]
     via 100.1.1.1%Default-IP-Routing-Table, c
LC  2001:6FC::26/128 [0/0]
     via Loopback0, receive
..

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.

Forwarding

Forwarding 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 Connectivity

The 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 ms

The 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 ms

Note 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 msec

After 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 msec

When 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 Path

On 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

Nice-PE-IA# show ipv6 cef
2001:500::/48
  nexthop 172.20.25.1 Serial0/0 label 38 72
2001:6FC::1/128
  nexthop 172.20.25.1 Serial0/0 label 38 73
2001:6FC::26/128
  attached to Loopback0, receive
..

Example 13-31. Details on an IPv6 Entry in the Forwarding Table

Nice-PE-IA# show ipv6 cef 2001:500::/48 internal
2001:500::/48, epoch 0, RIB[B], refcount 4
  sources: RIB
..
  recursive via 100.1.1.1[IPv4:Default] label 72, fib 0252B1F8, 1 terminal fib
    path 024F56A8, path list 024F0BA8, share 0/1, type attached nexthop
    ifnums: (none)
     path_list contains at least one resolved destination(s). HW IPv4 notified.
   nexthop 172.20.25.1 Serial0/0 label 38, adjacency IP adj out of Serial0/0 0289BEF0
  output chain: label 72 label 38 TAG adj out of Serial0/0 0289BD80

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

Nice-PE-IA#show bgp ipv6 unicast 2001:500::/48
BGP routing table entry for 2001:500::/48, version 2
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  10000
    ::FFFF:100.1.1.1 (metric 30) from 100.47.47.1 (100.47.47.1)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Originator: 100.1.1.1, Cluster list: 100.47.47.1,
      mpls labels in/out nolabel/72
  10000
    ::FFFF:100.1.1.1 (metric 30) from 100.46.46.1 (100.46.46.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Originator: 100.1.1.1, Cluster list: 100.46.46.1,
      mpls labels in/out nolabel/72
LDP (used in this example, could be replaced by RSVP) has the other labels:
Nice-PE-IA#show mpls ldp bindings 100.1.1.1 32
  lib entry: 100.1.1.1/32, rev 56
        local binding: label: 40
        remote binding: lsr: 100.19.19.1:0, label: 38
Nice-PE-IA#show mpls ldp bindings 172.20.25.0 24
  lib entry: 172.20.25.0/24, rev 2
        local binding: label: imp-null
        remote binding: lsr: 100.19.19.1:0, label: imp-null

PE Disposition Path

The 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

Milan-IGW#show mpls forwarding-table
Local  Outgoing         Prefix             Bytes Label   Outgoing   Next Hop
Label  Label or VC      or Tunnel Id       Switched      interface
16     Pop Label        100.14.14.1/32     0             Se0/0      point2point
17     26               100.46.46.1/32     0             Se0/0      point2point
..
72     No Label         2001:500::/48      63121         Se1/0      point2point
73     Aggregate        2001:6FC::1/128    24123

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

Milan-IGW#show bgp ipv6 2001:500::/48
BGP routing table entry for 2001:500::/48, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  10000
    FE80::2710:2 (FE80::2710:2) from FE80::2710:2%Serial1/0 (100.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, external, best,
      mpls labels in/out 72/nolabel

Label Switch Path

Because 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

Nice-PE-IA#show ipv6 route 2001:6FC::1/128
Routing entry for 2001:6FC::1/128
  Known via "bgp 33751", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
    100.1.1.1%Default-IP-Routing-Table indirectly connected
      MPLS Required
      Last updated 02:42:12 ago

And the traceroute-LSP, executed from Nice-PE-IA, is shown in Example 13-36.

Example 13-36. Traceroute-LSP Example

Nice-PE-IA#traceroute mpls ipv4 100.1.1.1/32 verbose
Tracing MPLS Label Switched Path to 100.1.1.1/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not transmitted,
       '.' - timeout, 'U' - unreachable,
       'R' - downstream router but not target,
       'M' - malformed request
Type escape sequence to abort.
  0 172.20.25.2 0.0.0.0 MRU 1500 [Labels: 38 Exp: 0]
R 1 172.20.25.1 0.0.0.0 MRU 1500 [Labels: 30 Exp: 0] 40 ms, ret code 6
R 2 172.20.10.1 0.0.0.0 MRU 1504 [Labels: implicit-null Exp: 0] 60 ms, ret code 6
! 3 172.20.40.1 48 ms

Troubleshooting Routing and Forwarding

When 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.


Previous Page
Next Page