My network has grown large enough that maintaining my prefix announcements
to the rest of the world has become increasingly difficult.
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.
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?
What do you use for reflectors, hardware(Cisco/Juniper)
or software daemons(Quagga)?
We operate 2x networks.
One of them runs Cisco 7201 routers as route reflectors,
while the other runs Juniper M120 routers.
The large Juniper routers were due to particular BGP AFI's
that Cisco IOS does not support (yet).
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.
You can certainly use any device in your network to
originate your allocations. We just use the route reflectors
because it is a natural fit, but you can use any device
provided it would be as stable and independent as a route
reflector.
The last thing you want is a blackhole or a route going away
because your backhaul failed or your customer DoS'ed your
edge router :-).
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.
There was a time when networks were ran without prefix
lists, BGP communities or even route maps. I'm too young to
have ever experienced those times, but I always joke with a
friend (from those times) about how good we have it today,
and how hard life must have been for Internet engineers of
old :-).
If you have the opportunity, I'd advise against operating
without these very useful tools.
Has anyone tried this, or is it suicide?
I'm sure there are several networks out there that are
intimidated by additional BGP features such as communities,
advanced routing policy, e.t.c. They do survive without
having to deal with this, probably because they're networks
are small and the pain is better than trying something new.
But I certainly wouldn't recommend it to anyone (except, as
Randy would say, my competitors).
Mark.
Thanks Mark,
This helps and definitely shows Im heading in the right direction.
Thanks,
To elaborate slightly on what others have said in terms of protecting
against leaks;
it's a good idea to filter outbound in a conservative way such that you
only send
what you "expect" in terms of community values and/or prefixes and/or
AS-paths.
For instance, if something gets into your BGP that isn't tagged with one of
your expected
communities (e.g. applied where you inject your aggs), don't re-advertise
it.
If something has the right community, but not an expected AS-path (e.g.
contains the AS
of one of your transit providers), don't re-advertise.
Implicitly deny all unexpected cases.
Building that kind of restrictive logic will be less likely to you becoming
a path for traffic you
didn't expect (and might swamp you) and also you'll be a better citizen in
general.
Cheers,
Tony
Thanks for the advice. Filtering and route manipulation hasn’t been a
problem for me. I’m very careful to prevent leakage, etc. My current issue
is scaling my management of our prefix announcements. Every time I add a
new block, I need to modify all of my edge routers etc. I understand I can
use IRR etc. to automate prefix-list deployments, but the blocks need to
still be injected into the network? So my thought was to use a routeserver
(quagga or a 7200) to do this.
Im looking to understand how others handle this.