| | | | | | | | |
|
|
|
You're here: Home |
On 14-Jul-2006, at 06:00, Alo Anesi wrote:
So from everything we discusses at the previous PACNOGs, it seems splitting up prefix advertisements is the best (only?) way to split inbound traffic when dealing with two different upstreams.
Many people do this. Often it is the only mechanism available to do the kind of thing you're trying to do.
The downside, as Woody, Philip, Gaurab and Alastair have pointed out, is that you are contributing to the amount of information in the global routing table that everybody else has to pay for (e.g. in CPU, convergence time, etc).
As Gaurab pointed out, you might try adjusting the as-path prepending you're doing on your /20 first to see whether you can get a better balance of traffic without deaggregating. If that doesn't work (you may already have tried it), then some amount of deaggregation is going to be needed in order to attract traffic to the empty link.
In an ideal world, nobody would do it. In practice, however, I would say go for it; people who are upset by the extra routes can always filter.
My question is, can I go as far as splitting at the /22 boundary for my /20? I could split at the /21 boundary, but with the way we've been allocating customer addresses 90% of my usage occurs in the first half of my /20.
The only really widespread practice in filtering BGP advertisements from peers is to refuse prefixes which have a length greater than 24 (i.e. a /24 is the longest prefix you should expect people to accept).
Take your /20 and identify traffic sinks within it that fit into one or more covered prefixes (/21 to /24). We'll call these your traffic- engineering (TE) routes.
Advertise one of the TE routes to the ISP that you want to draw more traffic through, whilst still sending the /20 to both transit providers. Keeping the /20 route exactly as it is right now is important: it gives you the ability to experiment with different TE routes without the risk that someone will filter them and leave chunks of your customers without connectivity.
Wait a day, and see what that does to your traffic profile. If you still have room to fill on the backup transit provider link, try changing the set of TE routes you're sending them (e.g. send a second one as well, or send a /23 instead of /24). If the backup transit provider link is too full, withdraw the TE route you sent that way and try again with a different one.
This is a hit-and-miss, trial-and-error process, and if you want to keep your traffic as evenly-distributed as possible you'll need to repeat the exercise every so often.
Joe
