MPLS trace issue

[littlegrave]

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

[Harold Ritter]

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,

[mohammedmahmoud]

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.

[Harold Ritter]

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,

[mohammedmahmoud]

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.

[Harold Ritter]

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,

[mohammedmahmoud]

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.

[Harold Ritter]

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,

[mohammedmahmoud]

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.

[Harold Ritter]

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,

[mohammedmahmoud]

Harold,

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

Have a nice day :)

BR,

Mohammed Mahmoud.

[Harold Ritter]

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,