Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
9

Keep RD unique to a PE or not?

We operate a small mpls core, which I’m pretty green at.

Currently the setup is that every PE will use the same RD for customer1, and another for customer2. Recently we have had a consultant in who said that the RD should be unique per customer and per PE.

I’m going to lab this up to see what differences it makes, just wondering how you would usually see this in production?

I’ve had issues recently dual-homing bgp with clients - unable to use the same AS on the 2 pe bgp sessions in our environment as only one will learn routes. This is making me think it’s due to both PEs having the same RD set for that customer, meaning the vpnv4 route is not unique

15 comments
91% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1

Yep that's the difference. We keep RDs as <lo0 ip>:<id>, id is just a incremental number we don't try to match it to anything

level 2

I use this method. It helps me quickly identify which PE originated the route.

level 1

We're in a similar situation and I came to a similar conclusion. The basic issue is that BGP will tend to only advertise it's best route for a given RD:Prefix combination. This applies also to route-reflectors. And the RR's idea of "best" has nothing to do with the PEs it's advertising to, especially if you're down to 'IGP Metric' as a tie-breaker. There are ways to force BGP to advertise and handle multiple paths to the same NLRI, but it seems like the "right" answer is usually to just make the NLRIs distinct to begin with. Here's a discussion of these topics I found useful: http://brbccie.blogspot.com/2014/08/bgp-pic-and-add-path.html

One concept I remember coming across was a "per-customer/per-POP" model, instead of "per-customer/per-PE", but off the top of my head I don't really remember the pros/cons.

level 2
Original Poster1 point · 8 days ago

We had a similar answer from the consultant in regards to RR’s. if it receives 2 routes to the same destination with the same RD it will only learn, keep and advertise one, RD needs to be unique in this situation to have a standby route ready to advertise.

level 2
Original Poster1 point · 8 days ago

A quote from a link I found and referenced in a previous reply:

The RD is more or less locally significant, considering the example of two PEs originating the same prefix with the same RD, one of the paths from one PE was not visible to other PEs, so this has only affected routing to prefixes originated from that PE; thus it can be said that the RD is locally significant to that PE only with regards to reachability of prefixes originated from that PE. Perhaps it would be more accurate to say it has a global impact on reachability on locally originated prefixes.

level 1
1 point · 7 days ago

RD globally unique, usually <loopback>:<vpn-id>. Target same for each vpn, usually <local-as>:<vpn-id>.

People will tell you it doesn’t matter, that it’s locally significant, don’t listen to them. It totally matters, especially when you get large enough to announce the same prefixes to multiple geo diverse PEs, and want to route the closet PE.

level 1

In my large ISP world each customer has one global RD. We build out per-PE RDs when customers need duplicate routes within their VRF, as in the case of BGP multipath. Even then, its only changed on the "hub" sites that require multi path, and the remote sites remain untouched.

level 2
Original Poster1 point · 4 days ago

With multipath bgp are you using the same AS on your pe routers? I’m having issues with using the same AS when customer has more than one link from a site through our mpls

level 1

The RD is just a locally unique value to separate routing tables. It can be whatever you want, unique per PE or not, I don't think it should make any difference.

It's the RT that you need to be careful with since that determines route import/export.

level 2
Original Poster3 points · 8 days ago

Within an mpls the rd is definitely distributed as part of mp-bgp so it’s not as locally significant as you think

level 3

Out of curiosity, have a link/guide explaining this behavior?

level 4
Original Poster2 points · 8 days ago

Also here you can see the rd being sent in the bgp update message:

http://packetlife.net/blog/2013/jun/10/route-distinguishers-and-route-targets/

level 5

It's sent in the update message but all its used for is uniqueness of the prepended ipv4 prefix, I think this is what ends up confusing people because sometimes they assume for example that it has some purpose to route import / export where that function is the purpose of the route target.

We use type 1 distinguishers (loopback:distinguisher) as you don't have any knobs to turn on the RR to advertise all vpnv4 routes it learns not just the best one which it would do if your each PE advertising the same route with the same VPNv4 prepended.

E.g.

If VRF A RD is 123456:7890 on PE1 and PE2, advertising 10.0.0.0/16

VPNv4 prefix advertised by PE1 and PE2 is

123456:7890:10.0.0.0/16

A route reflector would then advertise out whichever one was best (lowest metric or highest router-ID). This means on failure of PE1 you have to wait for the BGP process to advertise the next best route before you use can use it, causing a blackholing of traffic until it converges.

If VRF A RD is 1.1.1.1:7890 on PE1, and 2.2.2.2 on PE2 advertising 10.0.0.0/16 then

VPNv4 prefix advertised by PE1 is

1.1.1.1:7890:10.0.0.0/16

VPNv4 prefix advertised by PE2 is

2.2.2.2:7890:10.0.0.0/16

Route reflector will then advertise both of these routes to the rest of the network as they are unique in VPNv4, PE3 would import both routes (using the route target which is th extended community attached to the route to facilitate import / export) and it means that on failure of PE1, all it would have to do is remove the route out of its IPv4 rib and it has another backup path immediately, speeding up convergence, it also means any packets still on the network during the process will be tromboned back via PE1 to PE2 before the whole network has converged, keeps traffic up and stops anything being dropped.

Of course, without route reflectors this isn't really an issue (as with a full mesh you send every copy of everything to every router anyway) but it's easier to set this up and move to a RR setup when you grow in the future than it is to attempt this in the future.

Like someone has mentioned earlier, there are work arounds (shadow RRs / advertising backup path of received routes on RR etc) but these are tweaks to the standard process I probably wouldn't recommend at scale.

level 3
DRINK-IE and LINKSYS-IE1 point · 7 days ago

Within an mpls the rd is definitely distributed as part of mp-bgp so it’s not as locally significant as you think

It is only distributed between MP-BGP peers that are speaking the MPLS VPN services (ipv4 vpn/vpnv4, ipv6 vpn/vpnv6, l2vpn) for the sole reason of disambiguation of routes. They are also used locally on the router as a disambiguator between routing tables as well.

Community Details

127k

Subscribers

1.1k

Online

###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
1.
Rule #1: No Home Networking.
2.
Rule #2: No Certification Brain Dumps / Cheating.
3.
Rule #3: No BlogSpam / Traffic re-direction.
4.
Rule #4: No Low Quality Posts.
5.
Rule #5: No Early Career Advice.
6.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.