Routing

Hi,

I’m trying to repeat the “Interprovider VPN example - Multihop MP-EBGP with P Routers”, using Olive, described at the following link http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-11993771.html#id-11976247, where instead of using RSVP-TE to setup LSPs, I want to use LDP. Besides, I cut the links between routers B and C and D and E.

Unfortunately my experiment fails in one point and I do not understand the reason. Control plane seems to work well, VRF are correctly populated, label exchanges are OK. The problem is on data plane.

I followed step by step a packet from CE F to CE A. The problem shows up when the packet reaches router C. Before reaching router C the packet has (correctly) two labels:

- the top one advertised by router PE C to router PE D through BGP (“family inet labeled-unicast” has been used) and associated to the BGP Next-hop, which is the lo0.0 interface of router B,

- the bottom one is the label advertised by router B through the MP-eBGP session between the two PEs B and F.

Now, router C has also the LDP label associated to the lo0.0 interface of router B (the BGP Next-Hop) since the lo0.0 interface of router B is advertised by OSPF and there is an OSPF path toward this interface. Also, LDP is configured on all backbone routers (PE and P).

Now, my intuition says that router C should swap the top label above to the LDP label. Should it happen, the packet would go straight to PE B, and arrive at router B with only the VPN label. Unfortunately router C instead of label swapping does a label popping, thus sending packet to router G with only the VPN label. And of course router G drops the packet. In other words, continuity of LSP from PE E to BGP Next-Hop (lo.0 of PE B), breaks at router C

Any idea of the reason why does this happen ? It seems as there is no connection between LDP label associated to BGP Next-Hop, advertised by G to router C through LDP and the label advertised by router C to router D through BGP.

Topology is on Juniper document, configurations in the attached file (I only changed IP addresses).

Thanks a lot in advance to anyone can help me.

Attachment(s)

Interprovider-vpn.txt   3 KB 1 version

One more information. I have done the same test lab using Cisco routers and everything works fine. The problem I mentioned in my first post does not show up.

Am I missing some tricky command ?

Hi,

Can you set below knob on routers C and D and see if it resolves the probelm?

set protocols mpls traffic-engineering bgp-igp-both-ribs

Regards

Surya Prakash

Hi,

Below is the capture from my notes explaining why we need this traffic-engineering knob. The reason why it works on other vendor routers, is that it uses by Labeled Path wherever it is available.

Hi Surya,

thanks a lot for your suggestion. It works !!! As a matter of fact. the key point is the functioning of the "family inet labeled-unicast" statement. 

In the Juniper document, after a careful reading I found the solution to the mistery:

When you set family inet labeled-unicast, the local router announces internal routes from inet.0in the following manner:

• If a label exists for the route, the local router creates a label, performs a swap, and announces the route from inet.0 with the label.
• If a label does not exist for the route, the local router creates a label, performs a pop, and announces the route from inet.0 with the label.

Routes learned from the labeled-unicast session are placed into the inet.0 routing table.

Therefore, in order to tie labels sent by BGP between routers C and D, with labels received internally through LDP, you need in inet.0 a route with a label. And this is the point where the command you suggested plays a key role. As a matter of fact it is enough the command

[edit protocols mpls]
traffic-engineering bgp-igp;

that lets you to shift labeled paths from inet.3 to inet.0 (the command you suggested lets you to copy from inet.3 to inet.0, the final result is the same).

Thanks a lot again and wish you a wonderful 2012.

Tiziano

Hi,

Yes, "set protocols mpls traffic-engineering bgp-igp" would suffice the requirement in this scenario. But since this command will move entries from inet.3 to inet.0 table, VPN services like L3VPN, L2VPN... could be affected. These services would require BGP NH addresses to be present in inet.3 table for route resolution. Hence I would recommend "set protocols mpls traffic-engineering bgp-igp-both-ribs".

Wish you too a very happy and prosperous new year.

Regards

Surya Prakash