Route Management Best Practices
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.
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.
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.
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.
Thanks Mark, This helps and definitely shows Im heading in the right direction. Thanks, On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka <mtinka@globaltransit.net>wrote:
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.
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 On Tue, Jan 31, 2012 at 1:52 PM, Joe Marr <jimmy.changa007@gmail.com> wrote:
Thanks Mark,
This helps and definitely shows Im heading in the right direction.
Thanks,
On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka <mtinka@globaltransit.net
wrote:
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.
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@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 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
On Tue, Jan 31, 2012 at 1:52 PM, Joe Marr <jimmy.changa007@gmail.com>wrote:
Thanks Mark,
This helps and definitely shows Im heading in the right direction.
Thanks,
On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka <mtinka@globaltransit.net
wrote:
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.
participants (3)
-
Joe Marr -
Mark Tinka -
Tony Tauber