Cisco Support Community
Community Member

Unique RD and LSR memory consumption


It is a best practice to follow unique per-VRF/ per-LSR Route Distinguisher to allow load-balancing for dual-homed customer sites (when dual-homing is to two separate PEs).

Let's say you have a large customer which connects to many PEs and you follow the per-VRF/per-LSR approach for him. For the ease of deployment you choose RD to be in a format of

IP Address:Value when IP Address is a loopback address used for BGP update-source. Loopback IP address is different on each LSR. Value could be a running number from 1 to max. If you make sure that Customer VRF gets a different Value on each ingress/egress LSR, you will get completely different RD each time.

Now let's say you have LSRA that gets MP-BGP updates with Customer prefixes from many other LSR. Since RDs on the incoming updates will be different from RD assigned to Customer VRF on LSRA, LSRA will import the prefixes into proper Customer VRF and also place them into Null BGP table (Null VRF), this is per normal behavior.

Customer routing will work OK, but with many prefixes received it will cause huge memory consuptions because each prefix will be saved twice. Now take into account many Customers working in this manner...

How do MPLS/VPN Service Providers deal with this? Maybe they do not follow unique RD on a per-VRF/per-LSR bases for all the Customers...




Re: Unique RD and LSR memory consumption


The provider's I've dealt with choose to use a single RD for a customer/VPN across all PEs. In fact, most of them use the AS: format for the RD...

As such, they don't run into the issue that you have described since all of the imported prefixes will be stored only in the Customer VRF on any given PE.

Hope that helps - pls rate the post if it does.


Re: Unique RD and LSR memory consumption


while agreeing with Paresh, I would like to add another point of view. From a customer perspective load sharing might be attractive - my experience is in fact, that it really is (for whatever reason...).

So the feature can be used as a service differentiator for the SP.

As you already pointed out, the need for memory will double (at least) on a PE. But memory is not always a limiting factor, but number of interfaces and CPU etc.

And while a PE today has 256 or more MB RAM, an average customer with less than 1000 routes does not really create a memory hog. So in brief: utilizing more memory is not such a strong argument that I would skip the whole feature in my opinion. But every SP has to make his own decision.

Hope this helps! Please rate all posts.

Regards, Martin

CreatePlease to create content