Use of Traceroute Across an MPLS/VPN Backbone

Although the use of traceroute between VPN sites should not be a huge issue for the service provider, it may be a major issue for the customers of the VPN service who may want to see the internal structure of the backbone network. There may also be confusion on the part of the customer when a hub-and-spoke topology is deployed because the hub router will appear twice in the traceroute. The service provider can decide, based on customer demand, whether this internal structure is shown.

Regardless of which choice is taken, it is interesting to understand the mechanisms involved and the packet flow from one site to another. To achieve this, we should consider a traceroute that is initiated from one CE-router to another CE-router in a different site, or from a host in one site to a host in a different site. An example of the CE-to-CE case can be seen in Figure 13-14.

In the scenario shown in Figure 13-14, when the traceroute is started on the FastFoods San Jose CE-router, it will create an IP/UDP packet with a source IP address set to the outgoing interface address of the CE-to-PE link and the destination address set to the address of the FastFoods Lyon CE-router (Step 1). The Time-to-Live (TTL) of the packet will be set to 1, and an ICMP time exceeded message will be received back from the first router within the packet's path?in this case, the SuperCom San Jose PE-router (Step 2). No MPLS is involved at this stage.

Figure 13-14. The Traceroute from CE to CE Across MPLS Backbone

graphics/13fig14.gif

The FastFoods San Jose CE-router will now send a new packet, but this time the TTL will be set to 2 (Step 3). The receiving SuperCom San Jose PE-router will accept the packet and treat the TTL as valid. The packet will be switched based on the content of the local VRF; at this point, the packet will enter into the SuperCom MPLS/VPN backbone (Step 4).

The MPLS architecture as described in draft-ietf-mpls-arch provides two choices on how the PE-router can treat the TTL field of the packet when it first enters the MPLS backbone. These choices dictate whether to propagate the TTL value into the TTL field of the label header. In the Cisco Systems implementation of the architecture, this choice is determined through configuration, as shown in Table 13-2. The default configuration is to propagate the TTL.

Table 13-2. Propagation of TTL into TTL Field of Label Header
Step	Command	Purpose
1	tag-switching ip propagate-ttl	Propagate the TTL into the TTL field of the label header.
2	no tag-switching ip propagate-ttl	Do not propagate the TTL into the TTL field of the label header.

Note

The propagate-ttl command has two effects: It propagates the IP TTL into the label header, and it propagates the label TTL into the IP header (where the packet exits the MPLS/VPN backbone).

Assuming that TTL propagation is enabled within the SuperCom backbone, the SuperCom San Jose PE-router will now forward the packet with a label stack imposed to reach the FastFoods Lyon CE-router. This label stack will have the TTL of the original IP packet contained within the header.

Note

If this packet were to flow through ATM switches, then the TTL would not be examined again. This is because there is no concept of TTL within an ATM environment, which is treated as one hop within the MPLS environment. Refer to the MPLS architecture draft, draft-ietf-mpls-arch for further information on TTL and loop prevention in an ATM environment. Also refer to the discussion on this subject in Chapter 5.

If the packet flows through a router-based MPLS backbone?for example, across the SuperCom backbone?then when the packet reaches the next LSR in the path (the Washington P-router, in the SuperCom network), the TTL is examined, and its value is decreased by 1. The value of the TTL is now found to have reached 0. In a normal IP environment, the router will now generate an ICMP time exceeded message with itself as the source address and the source address contained within the IP packet as the destination address. The original packet would then be dropped.

If the router generating the ICMP response is a P-router (Washington, in our case), it will not have any information about the originator of the packet (that information is stored only in the PE-routers). Thus, it cannot route the ICMP time exceeded packet back because it has no route toward the offending packet originator in its routing table. However, it does still have the original label stack that was imposed by the first PE-router in the path?San Jose, in our example?and it will use this to forward the ICMP time exceeded packet toward the destination (Step 5 in Figure 13-14). This process can be seen in Example 13-17.

Example 13-17 ICMP Time Exceeded and MPLS Packet Debug


Packet is received with TTL set to 1 by the P-router:

Washington# debug tag-switching packet

TAG: PO2/0: recvd: CoS=0, TTL=1, Tag(s)=27/81

TTL expires, and an ICMP time exceeded message is generated with the P-router as

source and the destination as the source address of the originating CE-router.

Washington# debug ip icmp

ICMP: time exceeded (Time To Live) sent to 194.22.15.1 (destination was 195.12.2.2)

The new ICMP message is forwarded using the original label stack, although the

internal label of 27 has been change to allow the packet to be label-switched across

the MPLS backbone:

Washington# debug tag-switching packet

TAG: PO4/0: xmit: CoS=6, TTL=255, Tag(s)=28/81

The packet is now label-switched to the SuperCom Paris router, which connects to the FastFoods Lyon CE-router. However, this is not the real destination of the packet?the FastFoods San Jose CE-router is.

When the packet arrives at the SuperCom Paris router, if the label is not an aggregate label, then the packet is forwarded to the destination CE-router, FastFoods Lyon. Then FastFoods Lyon will route the packet back toward the MPLS core, to be label-switched to the FastFoods San Jose CE-router. However, if the label is an aggregate label, then the Paris PE-router will perform a lookup in the VRF for the FastFoods VPN and will find that the packet should be forwarded back through the MPLS core toward the FastFoods San Jose CE-router (Step 6 in Figure 13-14).

If the internal topology of the MPLS network is to be hidden from customers, then turning off TTL propagation will achieve this objective because the IP TTL will not be copied into the label TTL (the value of 255 is instead), and the MPLS/VPN backbone will be seen as one IP hop.