|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: selective prepends...one more time
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 01 Oct 2002 00:07, [email protected] 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 deny 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 buy the pipe to suit the traffic that comes down it, but that doesn't really work as there can be quite sudden shifts in traffic from one provider to another. Customer controlled selective pre-pends offer a way to combat this effectively and in a controlled manner. It does take time to get to grips with them and the effects the changes you make have but in our case there is no way that our upstreams could or would be willing to manage this for us. However I must admit that as the number of prefixes we announce has grown it has become a little easier to manage the scenario where upstreams don't provide this level of control although it is still extremely useful where it is provided. When we only had one or two prefixes it would have been very tempting for us to de-aggregate our address blocks without the control provided by the selective prepend mechanisms we had available to us. (A temptation I'm glad to say we were able to resist) And as for the suggestion that managing different providers methods of presenting communities is difficult - it's not - we use a generic script and a mappings file for each provider which maps the effect we want to the community tags required. For each route we announce we then choose the annoucement profile we want per transit - the script then generates the appropriate config for each router. Regards Mark - -- Mark Vevers. [email protected] / [email protected] Principal Internet Engineer, Internet for Learning, Research Machines Plc. (AS5503) - -- GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3 Fingerprint: 85BA 30C4 9EC8 1792 4C8C C31E 58B5 3D1C B08F 3CA3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9nAonWLU9HLCPPKMRAu5sAJ9vdcM3A+LA89Fm8t5U1LIH8gimpACfQj3E rUmYouI85QLm9wi73gcJtOY= =pxOZ -----END PGP SIGNATURE-----
|