Route Management Best Practices
jimmy.changa007 at gmail.com
Tue Jan 31 15:02:11 CST 2012
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.
On Tue, Jan 31, 2012 at 2:59 PM, Tony Tauber <ttauber at 1-4-5.net> wrote:
> 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
> 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
> 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
> On Tue, Jan 31, 2012 at 1:52 PM, Joe Marr <jimmy.changa007 at gmail.com>wrote:
>> Thanks Mark,
>> This helps and definitely shows Im heading in the right direction.
>> On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka <mtinka at globaltransit.net
>> > On Tuesday, January 31, 2012 03:04:15 PM Joe Marr wrote:
>> > > 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.
More information about the NANOG