6PE Solution- Traceroute output

[amit.bhagat]

Hello Guys,

I have implemented 6PE solution on GNS3. The implementation and verification can be found here-

http://sites.google.com/site/amitsciscozone/home/important-tips/mpls-wiki/6pe-ipv6-over

However, there are couple of points I want to bring up-

1) The traceroute from CE1 to CAFE:2::1 (Loopback of CE2) shows following output-

CE1#traceroute CAFE:2::1

Type escape sequence to abort.
Tracing the route to CAFE:2::1

  1 2001:1::2 228 msec 88 msec 188 msec
  2  *  *  *
  3 ABCD::2 480 msec 656 msec 748 msec
  4 CAFE:2::1 624 msec 748 msec 564 msec

PING runs with 100% success. 6PE1 CEF output shows that two labels will be imposed for CAFE:2::/64 IPv6 prefix by itself.

6PE1# show ipv6 cef CAFE:2::/64
CAFE:2::/64
     nexthop ::FFFF:2.2.2.2
    fast tag rewrite with Fa0/0, 10.1.1.2, tags imposed: {17 23}

This is proved by the packet capture below. I wonder why traceroute does not show complete trace???

2) If you closely look at the packet capture, the TTL of MPLS header is 63 i.e. CE1 sends ICMPv6 packets with TTL=64. Ideally, all ICMP packets should be sent with TTL=255. Why is this different?

Any inputs would be appreciated.

Regards,

Amit.

[Peter Paluch]

Hello Amit,

Regarding your first issue, recall that if the TTL in an MPLS label is decremented to 0 while in transit, the router on which the TTL expired has to generate an ICMP unreachable message. This message would be sent along the original LSP through which the original packet would have been delivered, as the router might not have enough knowledge to send the ICMP unreachable message directly back to the originator of the packet.

In your case, in the second line of the traceroute, it should be an internal P router that generates the ICMP unreachable message. Note, however, that it is an IPv6 packet to which the ICMPv6 unreachable message should be generated. As your internal P routers do not run the IPv6 (that's the point of 6PE), they do not understand the IPv6 content of the labeled packet and they are not able to generate ICMPv6 unreachables. So they simply drop the packet because it is unable to do anything reasonable with it.

Have a look at this URL, it nicely explains the TTL behavior for labeled packets:

http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

As to your second question, the hop limit of all router-generated IPv6 packets is 64 by default. You can change it using the ipv6 hop-limit global configuration command. This link brings you to the command reference of the command:

http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_06.html#wp2084308

Best regards,

Peter

[amit.bhagat]

Hi Peter,

That is correct, however, isn't that the point of having two labels??

So in my case, for the second line of traceroute output, the TTL will expire at the P2 router. The P2 router should forward the packet "ICMPv6 Time Exceeded" with TTL=255 along the LSP i.e. to remote 6PE2 router.

Please correct me if I am wrong.

Regards,

Amit.

[Peter Paluch]

Hello Amit,

That is correct, however, isn't that the point of having two labels??

It is not. A point of having two labels is implementing a hierarchy of processing your packet - for example, in MPLS VPNs, the inner label identifies the particular customer network in a particular VRF on the egress PE while the outer label selects the LSP towards the egress PE. But regardless of the size of the label stack in a labeled packet, once the TTL in the outermost label gets decremented to 0, the router has to replace the original packet with an appropriate unreachable message if possible.

Note now that in your case, it is the P2 that should be replacing the IPv6 ping packet with an ICMPv6 unreachable message. More precisely, the P2 has to create a complete ICMPv6 unreachable message encapsulated in an IPv6 packet (sent by P2 and destined to CE1) and labeled in the precisely same way as the original ping packet so that it can reach CE2 and be rerouted back to CE1. But how is the P2 supposed to create such a message if it does not speak the IPv6 protocol at all? :-)

So this is the reasoning as I see it. If you have any further questions please don't hesitate to ask!

Best regards,

Peter

[amit.bhagat]

Hi Peter,

I think I see your point now. This is what I understood, please correct me if I am wrong.

Starting traceroute from CE1 to CE2 i.e source address= 2001:1::1 and destination address= CAFE:2::1

1) CE1 sends first UDP packet with TTL=1 which is received by 6PE1, decrements the TTL to 0 and sends an ICMPv6 Time Exceeded message.

2) CE1 sends second UDP packet with TTL=2 which is received by 6PE1, decrements the TTL to 1 and forwards packet after imposing the labels (IGPv4 and VPN-label with TTL=1) to P2 router. P2 router receives this packet and decrements the TTL to 0. Now the problem arises when it wishes to create an ICMPv6 packet because (a) it is not enabled for IPv6 and (b) the source address will be an IPv4 address while destination address will be an IPv6 address for the ICMP packet. THIS WILL CAUSE TRACEROUTE TO FAIL.

My understanding is that traceroute will fail for all P routers in the MPLS IPv4 core for the same reason. Do you think disabling TTL propagation could result in hiding MPLS core-however, P2 will still drop IPv6 packets with TTL=0?

Regards,

Amit.

[Peter Paluch · Accepted solution]

Hi Amit,

1. Absolutely correct. The communication between CE1 and PE1 is pure IPv6 because both routers are IPv6-enabled.
2. Correct. Regarding the (b) option, don't even think of using IPv4 addresses in an IPv6 world. Just like you cannot consider the IPX, NSAP or AppleTalk addresses for using in IPv4, you cannot (in general) consider any IPv4 addresses for using in IPv6 world. The P2 simply does not have any IPv6 address assigned and it cannot substitute any other configured address from a different protocol. Yes, there were some provisions made for converting IPv4 addresses into IPv6 (IPv4-mapped and IPv4-compatible IPv6 addresses) but forget them for now as they just confuse things. The issue at P2 is very simple - it does not understand IPv6 packets at all and even if it understood them, it does not have any global unicast IPv6 address assigned so it cannot source any IPv6 packets on its own. Do not try to look for any more complicated explanation
   

You are right, the traceroute will fail for all P routers for the same reason. Disabling the TTL propagation will effectively hide the MPLS infrastructure. The imposed MPLS labels will then carry the initial TTL of 255. As for the P2 in this case, recall that P2 makes its decisions based on the label and not on the IPv6 payload. If the label's TTL is 0 then it will drop the packet just like before but once again, the P2 is not able to look at the Hop Limit value in the IPv6 because it simply does not understand IPv6.

I am not sure if I was clear enough - please ask further.

Best regards,

Peter

[amit.bhagat]

Hi Peter,

This makes sense all the way. Great insight. Thank you so much.

I would just like to take this discussion to another point now

1) Why does the router send IPv6 packets with TTL=64?

2) Is there a way to change the TTL of IPv4 packets originated by the router?

Regards,

Amit.

[Peter Paluch]

Hello Amit,

Thank you. It is a pleasure.

1. Regarding the default TTL (let's call it the Hop Limit as that is the official name for the IPv6 "TTL" field), it is simply the IOS internal default value. I honestly do not know why the IOS developers decided to use the value of 64 as the default. In one of my previous posts I have mentioned that this default can be changed using the global configuration mode command ipv6 hop-limit
2. I do not know of any similar way to change the default TTL value of IPv4 packets originated by a router.

Best regards,

Peter

[amit.bhagat]

Hi Peter,

Coming back to our discussion on Traceroute in 6PE solution, I just read in the book "MPLS Fundamentals" (great book, BTW) that if I just enable "ipv6 unicast-routing" on P routers, the P routers will understand IPv6 packets with TTL=0. So, they will be able to send ICMPv6 Time Exceeded packets back to the originator; only this time the source of the ICMPv6 packets will be IPv4-mapped IPv6 address. Now the traceroute output will show presence of P routers in the core and the labels imposed. Brilliant !!!

Regards,

Amit.