MPLS trace issue
Hi guys,
I kind of 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:
Well, 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 to this.
Maybe I did not understand something or it's just something that changed recently (let's not forget the book is from 2003).
Any ideas?
I kind of 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
Well, 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 to this.
Maybe I did not understand something or it's just something that changed recently (let's not forget the book is from 2003).
Any ideas?
Comments
-
rossonieri#1 Member Posts: 799 ■■■□□□□□□□hi,
lets do double check..
which PE interface IP showed in your trace? i guess that will not be an egress interface. --> was ingress.
"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."
why the LFIB of PE_EAST and the other - will do an L3 lookup - because its not directly connected.
if it is directly connected - why bother do an L3 lookup? just forward the traffic.
cheers.the More I know, that is more and More I dont know. -
PStefanov Member Posts: 79 ■■□□□□□□□□Here's a the trace from the 10.0.0.0 network to the 20.0.0.0 network executed from CE-West:
Type escape sequence to abort.
Tracing the route to 20.0.0.1
1 12.0.0.2 308 msec 236 msec 308 msec // interface of PE-West to CE-West
2 45.0.0.4 [AS 1] [MPLS: Label 18 Exp 0] 720 msec 432 msec 668 msec //interface of PE-East to CE-East
3 45.0.0.5 [AS 1] 692 msec 540 msec 948 msec // interface of CE-East to PE-Eastif it is directly connected - why bother do an L3 lookup? just forward the traffic.
Because labels are assigned to prefixes and if the router does just a label lookup and does not know for which specific host the packet is for, it does not know how to change the link-local information in the packet (MAC addresses for instance). -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□littlegrave wrote:Here's a the trace from the 10.0.0.0 network to the 20.0.0.0 network executed from CE-West:
Type escape sequence to abort.
Tracing the route to 20.0.0.1
part 1
1 12.0.0.2 308 msec 236 msec 308 msec // interface of PE-West to CE-West
2 45.0.0.4 [AS 1] [MPLS: Label 18 Exp 0] 720 msec 432 msec 668 msec //interface of PE-East to CE-East
3 45.0.0.5 [AS 1] 692 msec 540 msec 948 msec // interface of CE-East to PE-East
part 2
Because labels are assigned to prefixes and if the router does just a label lookup and does not know for which specific host the packet is for, it does not know how to change the link-local information in the packet (MAC addresses for instance).
hmmmm...
1. is this a production net using ISP? did you use a loopback address?
2. correct - but MPLS doesnt use link local information because it doesnt need to know it as long as the LSP has established --> MPLS already have its own link local infomation.
i like this discussion
cheersthe More I know, that is more and More I dont know. -
PStefanov Member Posts: 79 ■■□□□□□□□□Nope, this is just a lab I am doing during my MPLS preparation for the written exam and yes, I used loopback interfaces between the PE routers. I
By link-local information I meant that as long as the router has to forward the packet on a connected interface, it has to know the MAC address of the connected device (in this case the egress PE router) because I am not using MPLS in the customer network. Not only will the router do a label lookup, but also a lookup in the CEF FIB ->packet overwrite. At least, this is how I image it works. but maybe I am wrong? -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□littlegrave wrote:By link-local information I meant that as long as the router has to forward the packet on a connected interface, it has to know the MAC address of the connected device (in this case the egress PE router) because I am not using MPLS in the customer network. Not only will the router do a label lookup, but also a lookup in the CEF FIB ->packet overwrite. At least, this is how I image it works. but maybe I am wrong?
nope - like i said, it doesnt need it as long the LSP has been established - it will begin forward the traffic. --> thats why they build MPLS network in the first place - reducing the extraload
cheersthe More I know, that is more and More I dont know. -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□littlegrave wrote:For those who are interested and want to know the solution and explanation for this issue can go here. That was a nice discussion with Mohammed and the Technical Leader of Cisco - Harold Ritter
hi littlegrave,
so whats the score for me?
cheers...the More I know, that is more and More I dont know.