[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]

JUNOSe 9.1.x BGP and MPLS Configuration Guide > Configuring MPLS > Verifying and Troubleshooting MPLS Connectivity

Verifying and Troubleshooting MPLS Connectivity

In IP networks, the ping and traceroute commands enable you to verify network connectivity and find broken links or loops. In MPLS-enabled networks, you can use the ping command to determine whether IP connectivity exists to a destination even when the ping packets must traverse multiple LSPs. You can use the traceroute command to determine the labels that data packets use when traversing LSPs to the destination.

In an MPLS-enabled network, however, you cannot use these IP commands to determine MPLS connectivity to a destination. Instead, you can use the MPLS ping and trace features to detect data plane failures in LSPs. Specific mpls ping and trace mpls commands enable you to target different types of MPLS applications and network topologies. The various ping mpls and trace mpls commands send UDP packets, known as MPLS echo requests, to the egress LSR of MPLS packets in a given FEC. Each echo request is forwarded along the same data path as the MPLS packets in that FEC.

The echo request packets use a destination address in the 127.0.0.0/8 range and port 3503. The default address is 127.0.0.1. This address range prevents IP from forwarding the packet, so that the echo request must follow the MPLS data path. This behavior is different from that of the IP ping and traceroute commands, which send ICMP packets to the actual destination.

Each MPLS echo request packet contains information about the FEC stack that is being validated. LSRs that receive an MPLS echo request respond with MPLS echo reply packets.

The ping mpls commands perform a basic connectivity check. When the echo request exits the tunnel at the egress LSR, the LSR sends the packet to the control plane. The egress router validates the FEC stack to determine whether that LSR is the actual egress for the FEC. The egress router sends an echo reply packet back to the source address of the echo request packet. The egress router can send the packet back by means of either the IP path or the MPLS path.

The trace mpls commands isolate faults in the LSP. For these commands, successive echo request packets are sent along the path. The first packet has a TTL of one; the TTL value is incremented by one for each successive packet. The first packet therefore reaches only the next hop on the path; the second packet reaches the next router after that. Echo request packets are sent until either an echo reply is received from the egress router for the FEC or a TTL of 32 is reached.

When a TTL expires on an LSR, that LSR sends an echo reply packet back to the source. For transit routers, the echo reply indicates that downstream mapping exists for the FEC, meaning that the packet would have been forwarded if the TTL had not expired. The egress router sends an echo reply packet verifying that it is the egress.

Although you cannot send IPv6 UDP packets for MPLS ping, you can use the ping mpls l3vpn command with an IPv6 prefix to investigate IPv6 VPNs.

MPLS Echo Reply Generation

Echo reply packets are sent by E-series routers that receive an echo request packet, even when MPLS is not enabled on that router. This situation is a transient condition when the router is receiving labeled packets. A return code in the echo replies indicates to the sending router that no label mapping exists on the receiving router.

MPLS Connectivity and ECMP

When an MPLS ECMP is part of the tunnel being explored by an MPLS echo request, the request packet takes one of the available ECMP paths. Probing FECs with different label stacks can yield different ECMP paths. However, you cannot guarantee complete coverage of all the ECMP paths.

You can use MPLS trace to determine which paths are present on an MPLS LSR. When the TTL expires on an MPLS LSR, the echo reply that is returned includes a downstream mapping TLV. This TLV contains all the downstream mappings of the LSR on which the TTL expired, if that feature is supported by the LSR. You can use the detail version of the trace mpls commands to display these downstream mappings.

Supported TLVs

Table 27 lists the TLVs supported by the MPLS LSP ping feature. Table 28 lists the sub-TLVs supported for the Target FEC Stack TLV.

Table 27: TLVs Supported by MPLS LSP ping 
Type Number
Value
Comments

1

Target FEC Stack

Multiple FEC stack sub-TLVs are not supported. A single LSP ping message cannot have more than one target FEC stack TLV.

2

Downstream Mapping

Only the IPv4 (numbered or unnumbered) downstream address type is supported.

Flag I for the Interface and Label Stack object is supported. Flag N, to treat the packet as a non-IP packet, is not supported.

An MPLS LSP trace echo request includes this TLV. This TLV contains the downstream address all-routers-multicast; that is the well-known IP address 224.0.0.2. Validation of the downstream address is not performed.

Verification of the downstream address is not performed on receipt of an MPLS echo request that contains this TLV.

In an MPLS echo reply, multipath information is not supported in this TLV; the multipath type is always set to 0 in the reply. However, the reply includes one downstream mapping TLV for each downstream path.

3

Pad

This TLV is included in the MPLS echo request packet. The TLV can specify either "Do not reply" or "Reply via an IPv4/IPv6 UDP packet."

7

Interface and Label Stack

This TLV is generated if requested by the received downstream mapping TLV.

9

Errored TLVs

This TLV is generated if an error is encountered while parsing one of the received TLVs.

10

Reply TOS Byte

–



Table 28: Sub-TLVs Supported for the Target FEC Stack TLV 
Subtype Number
Value
Comments

1

LDP IPv4 prefix

–

2

LDP IPv6 prefix

–

3

RSVP IPv4 LSP

–

6

VPN IPv4 prefix

–

7

VPN IPv6 prefix

–

8

L2 VPN endpoint

For VPLS and L2VPN

10

FEC 128 pseudowire

For Martini encapsulation

ping mpls ip

ping mpls l2transport

ping mpls l3vpn

ping mpls rsvp tunnel

ping mpls vpls

trace mpls ip

trace mpls l2transport

trace mpls l3vpn

trace mpls rsvp tunnel

trace mpls vpls

Sample Network Topology

Figure 61 shows a sample IPv4/IPv6 L3VPN topology with LDP or RSVP-TE base tunnels. Two base tunnels (one in each direction) are present between 10.1.1.1 and 10.2.2.2. The packet flow examples that follow refer to this sample topology.


Figure 61: Sample MPLS L3VPN Topology

MPLS LSPs to an IP prefix

Use the ping mpls ip and trace mpls ip commands for MPLS LSPs that are configured to use LDP; labeled BGP; or a combination of LDP, BGP, and RSVP-TE (as for inter-AS and carrier-of-carriers topologies). When you specify a VRF name, the LSP to the specified prefix must originate from the VRF because the ping is generated from the specified VRF.

Packet Flow Example for the ping mpls Command

The following example illustrates the packet flow that results when you issue the ping mpls ip command from router PE 1 (10.1.1.1) to router PE 2 (10.2.2.2) over an LDP base tunnel.

host1:pe1#ping mpls ip 10.2.2.2/32
  1. PE 1 sends an MPLS echo request UDP packet that contains an LDP IPv4 sub-TLV. The packet is sent as a labeled packet over the target LSP. The packet has the following attributes:

    Source address

    10.1.1.1

    Destination address

    127.0.0.0/8

    UDP port

    3503

    TTL

    255

    IPv4 prefix in the TLV

    10.2.2.2/32

    Sender's handle

    Randomly generated 32-bit number used to match the reply

    Sequence number

    Integer that is incremented for each echo request packet

  2. Router P 1 label-switches the packet to P 2.
  3. Router P 2 label-switches the packet to PE 2 (assuming PHP is not configured).
  4. Router PE 2 pops the label and determines that the destination address is in the 127.0.0.0/8 subnet. PE 2 sends the packet up to the control plane. The MPLS ping application on the control plane then creates an MPLS echo reply to the received echo request. The echo reply packet has a return code of 3, which means that the replying router is an egress for the FEC at stack depth. The echo reply packet includes the Interface and Label Stack TLV to indicate both the interface on which the request packet was received and the incoming label stack. The MPLS echo reply packet is sent back as a (labeled) UDP packet with the following attributes:

    Source address

    10.2.2.2

    Destination address

    10.1.1.1

    UDP port

    3503

  5. When the MPLS echo reply reaches router PE 1, the router matches the sender's handle and the sequence number to the echo request packet that PE 1 sent out. If the values match, the CLI displays an exclamation point (!).

The following sample output represents what you might see when you issue the ping mpls ip and ping mpls ip detail commands for the topology shown in Figure 61.

host1:pe1#ping mpls ip 10.2.2.2/32

Sending 5 UDP echo requests for LDP IPv4 prefix, timeout = 2 sec

!!!!!     

Success rate = 100% (5/5), round-trip min/avg/max = 4294967295/4/0 ms



host1:pe1#ping mpls ip 10.2.2.2/32 detail

Sending 5 UDP echo requests for LDP IPv4 prefix, timeout = 2 sec

  MplsNextHopIndex 32 handle 8073311

    '!' - success, 'Q' - request not transmitted,

    '.' - timeout, 'U' - unreachable,

    'R' - downstream router but not destination

    'M' - malformed request, 'N' - downstream router has no mapping



Sending MPLS ping echo request, handle 8073311 seq 21241

! 10.2.2.2 Replying router is an egress for the FEC at stack depth/0 seq 
21241

Sending MPLS ping echo request, handle 8073311 seq 21242

! 10.2.2.2 Replying router is an egress for the FEC at stack depth/0 seq 
21242

Sending MPLS ping echo request, handle 8073311 seq 21243

! 10.2.2.2 Replying router is an egress for the FEC at stack depth/0 seq 
21243

Sending MPLS ping echo request, handle 8073311 seq 21244

! 10.2.2.2 Replying router is an egress for the FEC at stack depth/0 seq 
21244

Sending MPLS ping echo request, handle 8073311 seq 21245

! 10.2.2.2 Replying router is an egress for the FEC at stack depth/0 seq 
21245



Success rate = 100% (5/5), round-trip min/avg/max = 4/4/0 ms

Packet Flow Example for the trace mpls Command

The following example illustrates the packet flow that results when you issue the trace mpls ip command from router PE 1 (10.1.1.1) to router PE 2 (10.2.2.2) over an LDP base tunnel.

host1:pe1#trace mpls ip 10.2.2.2/32
  1. PE 1 sends an MPLS echo request UDP packet that contains an LDP IPv4 sub-TLV and a Downstream Mapping TLV. The packet has the following attributes:

    Source address

    10.1.1.1

    Destination address

    127.0.0.0/8

    UDP port

    3503

    TTL

    1

    IPv4 prefix in the TLV

    10.2.2.2/32

    Sender's handle

    Randomly generated 32-bit number used to match the reply

    Sequence number

    Integer that is incremented for each echo request packet

  2. The TTL expires on router P 1. P 1 exceptions the packet up to the control plane. Router P 1 then creates an MPLS echo reply packet in reply to the received MPLS echo request. The MPLS echo reply packet has a return code of 8, which means that the packet would have been label-switched at the outermost label (label-stack depth 1). The Downstream Mapping TLV is set to indicate the path that the packet would have taken from the router. The Interface and Label Stack TLV is included in the echo reply packet. The MPLS echo reply packet is sent back as a labeled UDP packet with the following attributes:

    Source address

    10.3.3.3

    Destination address

    10.1.1.1

    UDP port

    3503

  3. When the MPLS echo reply reaches router PE 1, the router matches the sender's handle and the sequence number to the echo request packet that PE 1 sent. The CLI displays the router ID of the router that sent the echo reply. The detail version of the command displays the downstream mapping TLV contained in the MPLS echo reply.
  4. Steps 1–3 are repeated with a TTL of 2 and the destination address set to router P 2's router ID, 10.4.4.4.
  5. Router PE 1 next sends an MPLS echo request with a TTL of 3. This packet's TTL expires on router PE 2. PE 2 exceptions the packet up to the control plane. The MPLS trace application on the control plane then creates an MPLS echo reply to the received echo request. The echo reply packet has a return code of 3, which means that the replying router is an egress for the FEC at stack depth. The echo reply packet includes the Interface and Label Stack TLV to indicate both the interface on which the request packet was received and the incoming label stack. The Downstream Mapping TLV is not included in the echo reply packet.
  6. When PE 2's echo reply packet reaches router PE 1, the router matches PE 2's handle and the sequence number to the echo request packet that PE 1 sent. The CLI displays the router ID for PE 2, indicating that PE 2 is the target router.

The following sample output represents what you might see when you issue the trace mpls ip command for the topology shown in Figure 61.

host1:pe2#trace mpls ip 10.1.1.1/32

Tracing LDP IPv4 prefix, timeout = 2 sec, Max TTL 32

  MplsNextHopIndex 60, handle 8073312



1 2ms 10.44.44.44 Label switched at stack-depth/1

2 1ms 10.33.33.33 Label switched at stack-depth/1

3 2ms 10.1.1.1 Replying router is an egress for the FEC at stack depth/0

Packet Flows for ping and trace to L3VPN IPv4 Prefixes

This example describes packet flow for an MPLS ping is sent from VRF PE 11 on router PE 1 to the IPv4 prefix 10.99.99.21/32. For validation at the remote end, the source address of the echo request packet must be the same as the update-source address of BGP peer.

host1:pe1#ping mpls l3vpn vrf pe11 10.99.99.21/32
  1. An MPLS echo request packet containing a single VPN IPv4 sub-TLV is sent from PE 1 with the following attributes:

    Source address

    10.1.1.1

    Destination address

    127.0.0.0/8

    UDP port

    3503

    TTL

    255

    Sender's handle

    Randomly generated 32-bit number used to match the reply

    Sequence number

    Integer that is incremented for each echo request packet

The VPN IPv4 sub-TLV has the route distinguisher set to that of the VRF and the IPv4 prefix set to 10.99.99.21/32. The packet exits PE 1 with two labels.

  1. Router P 1 switches labels based on the outer label of the packet and forwards the packet to P 2.
  2. Router P 2 switches labels based on the outer label of the packet and forwards the packet to PE 2.
  3. Router PE 2 pops both labels and determines that the destination address is in the 127.0.0.0/8 subnet. PE 2 sends the packet up to the control plane. The MPLS ping application on the control plane then creates an MPLS echo reply to the received echo request. The echo reply packet has a return code of 3, which means that the replying router is an egress for the FEC at stack depth. The echo reply packet includes the Interface and Label Stack TLV to indicate both the interface on which the request packet was received and the incoming label stack. The MPLS echo reply packet is sent back as a (labeled) UDP packet with the following attributes:

    Source address

    10.2.2.2

    Destination address

    10.1.1.1

    UDP port

    3503

  4. When the MPLS echo reply reaches router PE 1, the router matches the sender's handle and the sequence number to the echo request packet that PE 1 sent. The CLI displays an exclamation point (!).

Packet flow for an MPLS trace to an L3VPN IPv4 prefix is the same as for an IPv4 prefix except that the echo request packets and echo reply packets contain the VPN IPv4 sub-TLV instead of the LDP IPv4 sub-TLV. The following sample output represents what you might see when you issue the trace mpls l3vpn and trace mpls l3vpn vrf commands for the topology shown in Figure 61.

host1:pe1:pe11#ip8:pe1#trace mpls l3vpn 10.99.99.21/32 detail

Tracing VPN IPv4 prefix, timeout = 2 sec, Max TTL 32

  MplsNextHopIndex 73 handle 8073322



1 0ms 10.33.33.33 Label switched at stack-depth/2

  TLV Interface and Label stack 20 bytes

    Router 10.33.33.33 Intf 10.10.10.2

    [L34 EXP 0 TTL 1] [L68 EXP 0 S TTL 1] 

  TLV Downstream mapping 24 bytes

    Router 10.31.31.2 Intf 10.31.31.1 mtu 9180

    [L56 EXP 0 LDP] [L68 EXP 0 S Unknown] 

  TLV Downstream mapping 24 bytes

    Router 10.34.34.2 Intf 10.34.34.1 mtu 1500

    [L79 EXP 0 LDP] [L68 EXP 0 S Unknown] 

2 2ms 10.55.55.55 Label switched at stack-depth/2

  TLV Interface and Label stack 20 bytes

    Router 10.55.55.55 Intf 10.34.34.2

    [L79 EXP 0 TTL 1] [L68 EXP 0 S TTL 2] 

  TLV Downstream mapping 24 bytes

    Router 10.120.120.2 Intf 10.120.120.1 mtu 1500

    [L43 EXP 0 LDP] [L68 EXP 0 S Unknown] 

3 3ms 10.2.2.2 Replying router is an egress for the FEC at stack depth

  TLV Pad 20 bytes

  TLV Interface and Label stack 20 bytes

    Router 10.2.2.2 Intf 10.120.120.2

    [L43 EXP 0 TTL 1] [L68 EXP 0 S TTL 3]



host1:pe1#trace mpls l3vpn vrf pe11 10.99.98.21/32 reply pad-tlv exp-bits 5 
detail

Tracing VPN IPv4 prefix, timeout = 2 sec, Max TTL 32

  Handle 1921136  MplsNextHopIndex 78 [L68,L34]



1 0ms 10.33.33.33 Label switched at stack-depth/2

  TLV Pad 20 bytes

  TLV Interface and Label stack 20 bytes

    Router 10.33.33.33 Intf 10.10.10.2

    [L34 EXP 5 TTL 1] [L68 EXP 0 S TTL 1] 

  TLV Downstream mapping 24 bytes

    Router 10.31.31.2 Intf 10.31.31.1 mtu 9180

    [L56 EXP 5 LDP] [L68 EXP 0 S Unknown] 

  TLV Downstream mapping 24 bytes

    Router 10.34.34.2 Intf 10.34.34.1 mtu 1500

    [L79 EXP 5 LDP] [L68 EXP 0 S Unknown] 

2 2ms 10.55.55.55 Label switched at stack-depth/2

  TLV Pad 20 bytes

  TLV Interface and Label stack 20 bytes

    Router 10.55.55.55 Intf 10.34.34.2

    [L79 EXP 5 TTL 1] [L68 EXP 0 S TTL 2] 

  TLV Downstream mapping 24 bytes

    Router 10.120.120.2 Intf 10.120.120.1 mtu 1500

    [L43 EXP 5 LDP] [L68 EXP 0 S Unknown] 

3 3ms 10.2.2.2 Replying router is an egress for the FEC at stack depth

  TLV Pad 20 bytes

  TLV Interface and Label stack 20 bytes

    Router 10.2.2.2 Intf 10.120.120.2

    [L43 EXP 5 TTL 1] [L68 EXP 0 S TTL 3]

Inter-AS Topology

When an L3VPN ping or trace is transmitted, the TTL value on the inner (VPN) label is set to 1 by default. This value causes the TTL to expire on the egress PE of the L3VPN LSP and an echo reply can be sent back to the source. However, in an inter-AS topology, this behavior might result in premature termination of the ping or trace. You can use the bottom-label-ttl keyword to avoid this problem.

Packet Flows to L3VPN IPv6 Prefixes

Packet flow for an MPLS ping and trace to an L3VPN IPv6 prefix is the same as for an IPv4 prefix except that the echo request packets and echo reply packets contain the VPN IPv6 sub-TLV instead of the VPN IPv4 sub-TLV.

[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]