Thanks Mark What do you use for reflectors, hardware(Cisco/Juniper) or software daemons(Quagga)? 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@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, e.t.c.
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 customers.
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.
Cheers,
Mark.