ldp concepts

[Mark Pace Balzan]

Hi,

Im just starting to work on MPLS and I have a few questions about LDP and MPLS VPNs. Hopefully some expert out there can show me if my thinking is correct.

Q1. If I have a number of directly connected PE routers (say via ethernet) which are servicing MPLS VPNs, technically do i really need to run LDP here ? I believe the LFIB gets populated by MBGP for the VPNv4 customer prefixes, so is there any need for LDP between the directly connected PEs ?

Q2. In the case where now I have another set of PEs that are not directly connected to the set of PEs in Q1, and I have a P router to connect the two sets of PEs together. Am I correct in saying that now I must run LDP even if I am just doing MPLS VPNs, since the P router needs to know how to forward traffic, and it does this forwarding via LDP since it doesnt particiapte in MBGP and therefre does not have customer VPNv4 routes/prefixes ?

Q3. I read about LDP session protection via targetted LDP. If P/PEs are directly connected (via ethernet), is there any point in running protected LDP sessions ? Im thinking of having two interfaces on each router, ethernet interface 1 (g0/1) and ethernet interface 2 (g0/2). So each router g0/1 will be directly connected via an ethernet switch, and same for g0/2. If we run LDP between loopbacks of the routers, then there is inherent protection if one of the interfaces (say g0/1) goes down, the LDP session does not go down, since the loopbacks will be reachable via the other g0/2 interface ? So in this case is there any point in using session protection ?

thanks

Mark

[Giuseppe Larosa]

Hello Mark,

Q1) I think you still need to use LDP even if they are directly connected:

it is true that penultimate hop popping makes the MPLS frame to use a stack:

implicit-null + VPNv4 label.

But the difference is that the implicit-null label is received on the LDP session and shown in neighbor mpls forwarding table with the action POP TAG.

if no mpls neighbors is detected out an interface the router shouldn't try to forward MPLS frames out of it.

So this is the risk without LDP sessions between the directly connected PE nodes.

q2) your understanding is correct be also aware that the same node can act as PE node for some IP prefixes and as a P node for other prefixes.

q3) this is not useful in your scenario, targeted LDP sessions can be useful for example for EoMPLS signalling setup.

Hope to help

Giuseppe

[Mark Pace Balzan]

thanks Giuseppe,

thats clear.

one other question, if you can help, about RD and RT.

I understand that the RD makes a prefix from a connected CE unique in MP-BGP by prepending the RD to the prefix, so if the same prefix is used by another customer, using a different RD for that customer vrf makes both the prefixes different because of the combinations of RD and prefix.

However even when we export a prefix using an RT in a vrf, this is unique due to the RT, and the exported RT is then used for another PE vrf to decide whether to import it.

So if the RT also makes the prefixes unique and is the parameter used to decide whether to import that prefix on another PE, what exactly is the point in having an RD ? and is is ever really used ?

thanks

Mark

[Giuseppe Larosa]

Hello Mark,

RT is an extended community that provides a "colour" to a VPNv4 prefix.

The VPNv4 prefix is made of RD:IPv4 prefix.

remote PEs decide if a vpnv4 prefix has to be imported on a local VRF if the prefix as at least one RT attribute that matches one of the import RT values.

RD solves the address overlapping issues including what can happen in a single PE node.

using different RDs is very important for multihomed VRF sites (connected to two different PE nodes) in order to have both vpnv4 prefixes propagated by BGP route reflector servers (otherwise only one is propagated everywhere if RD used on the two PE nodes is the same).

RT(s) (one or more can be attached to a VPNv4 prefix) decides if a prefix has to be imported.

you cannot see the RD after the prefix is imported the RD is removed and the resulting IPv4 prefix is injected in the VRF routing table.

But you can see using

sh ip bgp vpnv4 all

this will show you all occurences of the IPv4 prefix in the vpnv4 address families with their respective RD and associated RT(s).

Using multiple RTs help in building extranets and also to implement different connectivity models behind the any to any basic setup.

In other words by only playing with RTs you can emulate an hub and spoke topology if needed.

Hope to help

Giuseppe

[Peter Paluch]

Hello Giuseppe and Mark,

Regarding the RD: everything is exactly as Giuseppe has explained. Personally, when I am asked about why do we need both RD and RT, I need to talk a little about BGP itself.

The BGP is used to convey routing information from multiple VRFs between PE routers. However, originally, it was not designed for this application, and without additional "tricks", it would not be able to do this job. One particular problem is that when it needs to advertise an update to a route that already exists, it just sends it anew - the network, its mask and its attributes. The recipient of this message will replace the old information about this network with the new information.

Now, imagine two VRFs, one with RT 1:1, the second with RT 1:2, both containing the same network 192.0.2.0/24. The RT is a BGP attribute - a property of a network but not its identifier or a part of its address. Now image what would happen if the router advertised the contents from these VRFs to a peer. Say that first, the 192.0.2.0/24 with the RT 1:1 would be advertised. The peer would receive this network and import it to his VRF with the RT 1:1 import target. Then, the 192.0.2.0/24 with the RT 1:2 would be advertised. Now, the peer would receive this advertisement and it would think that this is an update of the previous advertisement - the network and the mask are the same, just the RT attribute has changed from 1:1 to 1:2. So it would remove the network 192.0.2.0/24 from the first VRF and move it to the second VRF with the RT 1:2 import target. In essence, the network would jump from one VRF to another, although it should be in both VRFs because despite looking identical, these two VRFs are totally separate address spaces.

This problem is remedied using the RD. The RD acts like an address extension within BGP messages so that identically numbered networks from various VRFs do not look identical in the BGP communication. If I get back to my example and assign the RD 1:1 to the first VRF and RD 1:2 to the second VRF, I have solved the BGP deficiency: the network from the first VRF will be announced as network 1:1:192.0.2.0/24, the network from the second VRF will be announced as 1:2:192.0.2.0/24, thereby maintaining their distinctiveness and not looking like one updates the other. Speaking more technically, there is a new address family format introduced for BGP that combines the RD and the IPv4 address into a single 96-bit network address.

The RD is simply a hack - a trick - a workaround for BGP. It defines a prefix for all networks within a particular VRF so that identically numbered networks from different VRFs look differently in BGP messages. However, this prefix is used only in BGP communication and only between pairwise between two BGP peers. The actual sorting of received networks among receiver's VRFs is always done by RT attribute, never by RD. The RD is actually not even used by the BGP receiver other than to see that "this network looks differently in its 64-bit prefix (the RD) than this one".

Best regards,

Peter

[Mark Pace Balzan]

Hi Giuseppe and Peter,

thanks for your replies.

ok so in the case mentioned by peter above where two VRFs, one with RT 1:1, the second with RT 1:2, both containing the same network 192.0.2.0/24, the /24 prefix would move from one vrf to the other rather than being in both VRFs because it is considered an attribute change on the same prefix instead of being two different prefixes, and this happens because of the lack of using an RD ?

if so then its clear !

thanks

Mark

[shivlu jain]

Hi Mark

If you want to use the same prefix in both vrf then need to use vrf nat.

regards

shivlu jain

[Peter Paluch · Accepted solution]

Mark,

Completely correct. That's why you need the RD. You can also try debugging it - if you don't specify the RD then the value 0:0 will be taken and you can nicely simulate one network jumping from one VRF to another if you add it to one VRF first, and then to another.

Best regards,

Peter

[Mark Pace Balzan]

brilliant - thanks to all for your help.