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