[52480] in North American Network Operators' Group
Re: selective prepends...one more time
daemon@ATHENA.MIT.EDU (Mark Vevers)
Thu Oct 3 05:13:57 2002
From: Mark Vevers <mark@vevers.net>
Reply-To: mark@vevers.net
To: nanog@merit.edu
Date: Thu, 3 Oct 2002 10:13:11 +0100
Cc: jlewis@lewis.org
In-Reply-To: <Pine.LNX.4.44.0209301858160.20657-100000@redhat1.mmaero.com>
Errors-To: owner-nanog-outgoing@merit.edu
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 01 Oct 2002 00:07, jlewis@lewis.org wrote:
> Some NOCs, even ones that support this on their network, don't understand
> it...or at least have staff that don't even come close to grasping it. It
> wouldn't surprise me at all if it's beyond a great many customers.
Too true. Their salesmen understand it even less and often categorically d=
eny=20
they offer selective prepends despite evidence to the contrary.
> Consider a network with several transit providers. Each transit pipe is
> incapable of handling all that network's traffic. The pipes may even be
> of wildly different sizes. Letting BGP decide where traffic goes (or
> comes from) with no tuning just won't work. You'd end up with some pipes
> overutilized and others underutilized. In this case, selective prepends
> make it possible to shift traffic around or decide "we're going to try
> forcing all ASxyz traffic to come to us over pipe A."
That's exactly the case where I work - some people suggest that you just bu=
y=20
the pipe to suit the traffic that comes down it, but that doesn't really wo=
rk=20
as there can be quite sudden shifts in traffic from one provider to another=
=2E =20
Customer controlled selective pre-pends offer a way to combat this effectiv=
ely=20
and in a controlled manner. It does take time to get to grips with them an=
d=20
the effects the changes you make have but in our case there is no way that=
=20
our upstreams could or would be willing to manage this for us. =20
However I must admit that as the number of prefixes we announce has grown i=
t=20
has become a little easier to manage the scenario where upstreams don't=20
provide this level of control although it is still extremely useful where i=
t=20
is provided. When we only had one or two prefixes it would have been very=20
tempting for us to de-aggregate our address blocks without the control=20
provided by the selective prepend mechanisms we had available to us. (A=20
temptation I'm glad to say we were able to resist)
And as for the suggestion that managing different providers methods of=20
presenting communities is difficult - it's not - we use a generic script an=
d=20
a mappings file for each provider which maps the effect we want to the=20
community tags required. For each route we announce we then choose the=20
annoucement profile we want per transit - the script then generates the=20
appropriate config for each router.
Regards
Mark
=2D --=20
Mark Vevers. mark@ifl.net / mark@vevers.net
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
=2D --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB08F3CA3
=46ingerprint: 85BA 30C4 9EC8 1792 4C8C C31E 58B5 3D1C B08F 3CA3
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9nAonWLU9HLCPPKMRAu5sAJ9vdcM3A+LA89Fm8t5U1LIH8gimpACfQj3E
rUmYouI85QLm9wi73gcJtOY=3D
=3DpxOZ
=2D----END PGP SIGNATURE-----
