Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

MPLS trace issue

Hello,

I have a problem for which I can't give any explanation to myself. Here's what I have:

10.0.0.0 || CE_WEST -- PE_WEST -- P-SP -- PE_EAST -- CE_EAST || 20.0.0.0

I deployed an MPLS VPN between the two sites.

I read in the MPLS and VPN Architectures vol II the following:

----

When TTL propagation is disabled in an MPLS VPN backbone, a user who executes a

trace on a CE router will usually not see the egress PE router because that router

performs only a label lookup and is not affected with the IP TTL

----

I disabled TTL propagation and did a trace from 10.0.0.1 to 20.0.0.1 (CE router interfaces) and I saw PE_WEST, PE_EAST and CE_EAST in the trace, which is not what I expected to see. In the LFIB of PE_EAST, a packet to 20.0.0.0 should not trigger a L3 lookup since this network is not directly connected and is not an aggregate and thus this router should not examine the TTL field of the packet at all. I executed a few debugs on the routers and noticed that PE_EAST does not do any L3 lookup. However, I see it in the trace and can't find an explanation for this.

Maybe I did not understand something or it's just something that has changed over time in recent IOS version(let's not forget the book is from 2003).

Any ideas why this happens will be very much appreciated.

Thank you

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: MPLS trace issue

Pavel,

The behavior described in your original post used to be true but has since been changed as of 12.3(13), 12.0(31)S, 12.2(18)SXE and 12.3(14)T.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
25 REPLIES

Re: MPLS trace issue

Hi,

Your understanding is correct, using "no mpls ip propagate-ttl" causes a traceroute command to ignore all hops traversed by the MPLS packet in the network, are you sure that you've added this command on both PEs (to work in both ways).

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008020a42a.shtml#no_mpls

Are you trying to do the trace from the PE itself, if yes, then for this command to take effect you need to use the local keyword.

http://www.cisco.com/en/US/products/ps6350/products_command_reference_chapter09186a0080430c47.html#wp1049262

HTH,

Mohammed Mahmoud.

New Member

Re: MPLS trace issue

Hi,

I have enabled this command on all PE routers and even the P routers (although this does not concern me in this case). I am trying to trace from a CE to a CE (their loopback interfaces).

I examined the LFIB and the CEF table, tried some debugs and saw that L3 lookup is not done on the Egress PE router (and that's how it is supposed to be), but somehow this PE router appears in the path.

New Member

Re: MPLS trace issue

Here's the LFIB of the PE-East router:

PE-East#sh mpls for

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 23.0.0.0/8 0 Fa0/0 34.0.0.3

17 18 22.22.22.22/32 0 Fa0/0 34.0.0.3

18 Untagged 20.0.0.0/8[V] 126 Fa0/1 45.0.0.5

19 Aggregate 45.0.0.0/8[V] 0

20 Untagged 80.0.0.0/8[V] 0 Fa0/1 45.0.0.5

21 Aggregate 2001:0:0:45::/64 0

22 Aggregate 2001:0:0:20::/64 0

and here's the trace from the 10.0.0.0 network to the 20.0.0.0 network executed on CE-West:

CE-West#trace 20.0.0.1

Type escape sequence to abort.

Tracing the route to 20.0.0.1

1 12.0.0.2 308 msec 236 msec 308 msec

2 45.0.0.4 [AS 1] [MPLS: Label 18 Exp 0] 720 msec 432 msec 668 msec

3 45.0.0.5 [AS 1] 692 msec 540 msec 948 msec

CE-West#

Cisco Employee

Re: MPLS trace issue

Pavel,

It is actually normal behavior to see the egress PE in the traceroute output as the egress PE pops the label, checks the IP TTL and forwards the packet to the CE or sends an ICMP TTL expired message back to the source, depending on the result of the TTL check.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Hi Harold,

AFAIK, that the ingress router should appear in the trace as the first trace packet is sent from the CE with TTL of 1 and thus the first ingress router decrements the TTL, drops the packet, and sends an ICMP TTL-exceeded message to the source, and then the second packet on until the packet reaches the final egress router, the issue here is that the packet reached the egress PE with a large TTL value (since the ingress PE converted the TTL to 255, as we have disabled TTL propagation), and thus the egress PE shouldn't appear in the TTL as it won't send a TTL expired message, Harold please share us your opinion.

BR,

Mohammed Mahmoud.

New Member

Re: MPLS trace issue

Hi Harold,

Thank you for clearing this up! However, I still have a couple of questions for this case? Is the passage that I posted in my first post outdated? Is this something that has changed over time in newer IOS releases? Is the IP TTL field the only field from the IP packet that is examined (considering the packet is not for a directly connected network)?

I would be very thankful if you help me out with these questions.

Mohammed,

I think what Harold said was that not only the label TTL field is checked, but also the IP TTL. This is just how I image it would work, but I may be wrong.

Greetings,

Pavel

Re: MPLS trace issue

hi Pavel,

You are totally correct about the IP TTL field, after looking out to the big picture, i think that both PEs should appear, the ingress should appear as per my last post, and the egress should appear as per Harold's last post, and thus your output is consistent.

Harold,

If you may please confirm these results.

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

That is correct.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Cisco Employee

Re: MPLS trace issue

Pavel,

The behavior described in your original post used to be true but has since been changed as of 12.3(13), 12.0(31)S, 12.2(18)SXE and 12.3(14)T.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: MPLS trace issue

Harold,

Thank you so much for explaining everything that was unclear to me!

This shows me why I should avoid reading older books :)

Cisco Employee

Re: MPLS trace issue

Unfortunately/fortunately, everything moves so fast that on one side it is hard to keep up but on the other it keeps all of us employed ;-)

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Hi Harold,

Let me guess, does this change has anything to do with PHP.

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

This change is directly related to the way the egress PE processes the TTL. It is therefore not related to the PHP processing.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

Correct me if i am wrong, according to the PHP, tracing a LAN on a CE router from another CE router should differ from tracing the WAN ip of the same CE router from the other CE router.

HTH,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

This is actually not related to the PHP. The PHP occurs on the penultimate hop router, not on the egress router.

The old behavior used to make a difference between aggregate labels (labels for which an ip lookup was required) and regular labels. The new behavior doesn't.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

The reason that i've been trying to relate it to PHP, is that i've once traced a customer CE WAN IP from another CE router and both the ingress and the egress PE appeared in the trace which is normal, but when tracing his LAN only the ingress PE appeared in the trace while the egress PE didn't, and therefore i've related it to PHP as the WAN ips (directly connected to the PE) are not treated like the LAN IPs (directly connected to the CE router).

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

That is precisely what I was referring to. The traceroute to a subnet with an aggregate label (i.e. the CE IP address on the PE-CE link) from another CE shows both the ingress and egress PEs. This behavior applies equally to the old and new IOS code.

Again, this has nothing to do with the PHP processing, which occurs on the router upstream of the egress PE.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

Yes i got the aggregate and regular label issue from your previous post, i was just explaining to you the reason i thought about the PHP (as i thought that PHP causes the aggregate label packet to be forwarded to the egress PE router as an IP packet not a label packet (as the upstream router has performed PHP to the packet) and thus the IP TTL would be checked, while the regular label like the LAN IPs are still sent labeled to the Egress PE and thus the egress PE would still check the MPLS TTL and not the IP TTL and thats why the Egress PE won't appear in the second trace.

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

The PH router doesn't have any knowledge of the aggregate label and would therefore be unable to differenciate between an aggreagte label or regular label.

As mentioned before, the new behavior decrements and checks the IP TTL for both aggregate and regular label processing. The old behavior only did it for aggregate label processing, hence the egress PE showing in the traceroute output only for aggregate labels.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

I am really enjoying this nice discussion, thank you very very very much for taking time to answer my doubts, my understanding was that ldp advertise the aggregate label packets with an imp-null and thus the PH can do the PHP, while the regular label packets are sent with regular labels and thus ordinary label swapping is done, the following example is for a WAN IP (/30) and a LAN IP (/24) and the output is from the Egress PE, and i was under the influence that this led to the trace route differences:

Router#sh tag-switching tdp bindings x.x.1.8 30

tib entry: x.x.1.8/30, rev 55779

local binding: tag: imp-null

Router#sh tag-switching tdp bindings x.x.4.0 24

tib entry: x.x.4.0/24, rev 57042

local binding: tag: 97

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

Bear in mind that the labels we are referring to are VPN labels and are therefore not propagated to the P routers but only to PE routers via BGP VPNv4.

Always nice to have that sort of discussion indeed,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

The example i've given above is an internet customer not an MPLS VPN customer, i understand that the PE routers are the only routers that understand the VPN label and that the PH can PHP the top ldp label only, but according to this then in the case of VPN the egress PE router won't be able to check the IP TTL packet because with MPLS VPN the packet will always reach the egress PE as labeled packet, please correct me.

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

That is absolutely correct. In MPLS VPN the packet reaches with the VPN label but the egress PE implementing the new behavior will detect that the label received is the bottom of stack and decrement and check the IP TTL instead of the TTL contained in the bottom of stack label, hence the egress PE showing up in the output for both aggregate and non-aggregate labels.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: MPLS trace issue

Harold,

It was really my pleasure having this discussion with you, thanks a lot.

Have a nice day :)

BR,

Mohammed Mahmoud.

Cisco Employee

Re: MPLS trace issue

Mohammed,

The egress PE first pops the bottom label and then does the TTL check on the IP TTL, hence the egress PE showing in the traceroute output.

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
217
Views
15
Helpful
25
Replies
CreatePlease to create content