[149208] in North American Network Operators' Group
Re: Route Management Best Practices
daemon@ATHENA.MIT.EDU (Mark Tinka)
Tue Jan 31 01:39:31 2012
From: Mark Tinka <mtinka@globaltransit.net>
To: nanog@nanog.org
Date: Tue, 31 Jan 2012 14:38:32 +0800
In-Reply-To: <CAGSJx7sm=oZhBnHOmQp8ama_TwPuvzCDTDpbd+kRYcbY5HF9vA@mail.gmail.com>
Reply-To: mtinka@globaltransit.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart34951808.ene9mkTOBG
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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=20
route reflectors make sense for a number of reasons, e.g.,=20
they're always up, they aren't doing anything else, they=20
aren't in the forwarding path, they aren't reachable from=20
outside our AS, they're few enough to manage scalably,=20
e.t.c.
Like you, we attach communities to all originated=20
allocations as the route reflector is announcing them to all=20
iBGP neighbors, and those communities are used to determine=20
how the routes are announced to peers, upstreams and=20
customers.
The problem with originating your routes at the edge=20
(peering or customers) is you'll likely have more of these=20
routers than route reflectors, so redundancy management of=20
route origination will become a huge problem.
Also, failure of your edge routers is probably more likely=20
than your route reflectors just by the very nature of their=20
functions. This is why most advice is not to originate=20
routes on routers that are providing inter-AS connectivity,=20
as it could lead to blackholes due to backhaul link failure.
Cheers,
Mark.
--nextPart34951808.ene9mkTOBG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJPJ4xtAAoJEGcZuYTeKm+G5w0QAJAj6VfKm+WiNUxpCqoCQEsp
t68Qrm+rHso9/5bzZipcG+2sJHFZpxMlYamV6BfEofI7VpP6QXDp0R4ASPYvhjY3
zB/iqjW0F0uNVjMPJzqccP3aZf4eAWWSc7xhPmAymf+iiwhf2abn4YWrczlWLiDf
XTcYAJWyxUDgt4qoQTbmoCwbvQLROfx9AEaEphC4Ckp/aM3x948Wu2iV20XqkruR
KORxg+XvWQ4bh+MqBeOlSjeOOnasvDy2wYM55kMaAt/I2P4xIYksn44BGtrh04mp
KOU1R+boJmbB89M69OmJL9AvA2cj42EVcuaZ3/jgKoluvAS9MckgCQBLUVef/m49
WZY65c4rhh5XMsfIP5LE5u+cReYIxL17U1YgC1WAp4MvMjxbh1oK8jepQ/43O74G
VL5/fMEXs5N+9VphfkNUnMxfyP/2wfLqd5bWAxrb9mm+g0axcThhb5FQ22D8WahS
sUvLQ2403h7pm7GNek6H/E8oeX1PzXg8lA4hFaJDobyvz2o2Y5zZnxcIaVxE6mla
3gIGKjZ1xSezJQxuzSqn3XWMJgPNZCSHz32yAsTmSM89QnQFkvwHTMmYoP9Gc83d
Jijf/zkRz9sL9yEMFkLj27F/IymWS2qzzPM74oy7QxytSrZ432VFpX/T9FBj++0Q
GSUXDDvYy5NDymtpAGfS
=Kn8J
-----END PGP SIGNATURE-----
--nextPart34951808.ene9mkTOBG--
