Route Reflector Client Design Question

Sun May 6 05:33:43 UTC 2018

Mark,

Your solutions sounds like the best one.

We have just started to mess with Selective download and we have only turned it on for one of the PE’s in our network. I am in the process of upgrading our Core routers from Cisco12410 to ASR9906’s, before I turn this one. Having the PE decide what to import is a better solution than trying to do router filtering on the core routers.

Thanks for the info

Erik

From: Mark Tinka [mailto:mark.tinka at seacom.mu]
Sent: Saturday, May 5, 2018 6:38 PM
To: Erik Sundberg <ESundberg at nitelusa.com>; NANOG <nanog at nanog.org>
Subject: Re: Route Reflector Client Design Question

On 4/May/18 08:01, Erik Sundberg wrote:

My questions is how do I get traffic to go directly between the PE's without going to the Core Routers?

1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model?

You could do, but then you lose the point of the RR in the first place, as it's likely your Metro-E nodes will continue to grow, making this iBGP mesh thing, well, messy.

2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring.

You could do, but adds unnecessary routing complexity since the role of an RR is to, well, reflect.

3. Is this one of the down sides to U Rings?

Not really a downside, just the perks of extending IP/MPLS all the way into the Access (I drink to the death of Layer 2 Metro-E networks - my liver will probably give out before I do, though...).

4. Leave it alone and move on to bigger and better things....

Now where's the fun in that :-)?

So we've solved this problem by using BGP-SD (Selective Download):

  *   For every prefix each Metro-E node handles, originate that toward both RR's with NEXT_HOP=self.

  *   Attach a BGP community along with the routes originated toward the RR's. For maximum saving of your precious FIB in your Metro-E nodes, use a BGP community that is unique to the ring. This way, you don't need to accept routes into each Metro-E's FIB that don't require the "local" forwarding.

  *   Ensure the RR's reflect the routes they learn from each Metro-E node to the other Metro-E nodes.

  *   Setup BGP-SD on each Metro-E node. Match the ring-specific BGP community you added to each Metro-E node's prefix origination. Accept those routes into FIB + default. Reject everything else (from populating the FIB).

That should give you local forwarding within the ring, while maintaining very sparse population of your Metro-E nodes' FIB's.

Mark.

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.