Route Management Best Practices
jimmy.changa007 at gmail.com
Tue Jan 31 01:04:15 CST 2012
What do you use for reflectors, hardware(Cisco/Juniper) or software
I've been toying with the idea of using Quagga route servers to announce
our prefixes to our edge routers and redistribute BGP annoucements learned
from downstream customers. Only drawback is the lack of support for tagged
static routes, so it looks like I'm going to have to use a network
statement w/ route-map to set the attributes.
Has anyone tried this, or is it suicide?
On Tue, Jan 31, 2012 at 1:38 AM, Mark Tinka <mtinka at globaltransit.net>wrote:
> On Tuesday, January 31, 2012 01:01:30 AM Joe Marr wrote:
> > I currently use static routes and tags on my edge routers
> > to inject route into BGP. The tags correspond to
> > communities that reflect how the routes are announced
> > per region.
> > I would love to heat from others on how they handle this.
> We originate our allocations from our route reflectors. The
> route reflectors make sense for a number of reasons, e.g.,
> they're always up, they aren't doing anything else, they
> aren't in the forwarding path, they aren't reachable from
> outside our AS, they're few enough to manage scalably,
> Like you, we attach communities to all originated
> allocations as the route reflector is announcing them to all
> iBGP neighbors, and those communities are used to determine
> how the routes are announced to peers, upstreams and
> The problem with originating your routes at the edge
> (peering or customers) is you'll likely have more of these
> routers than route reflectors, so redundancy management of
> route origination will become a huge problem.
> Also, failure of your edge routers is probably more likely
> than your route reflectors just by the very nature of their
> functions. This is why most advice is not to originate
> routes on routers that are providing inter-AS connectivity,
> as it could lead to blackholes due to backhaul link failure.
More information about the NANOG