* Josh Richards <jrichard@cubicle.net> [20010331 11:23]:
* Roy <garlic@garlic.com> [20010331 08:13]:
Needless to say I am a bit pissed at Sprint for doing this and not telling me. I had been a fan of Sprint until this happened. Anyone else out there seeing the same problems? Any ideas on how to cure it
You could prepend your non-Sprint upstreams.
Oh, you said you're "pissed at Sprint for doing this and not telling me". Routing changes all of the time though depending on topology/contracts/politics/PoPs/peers/etc. I don't see any easy _useful_ way for transit providers to communicate this information to their customers. I also may not be looking hard enough. <thinking out loud> Keep in mind that every multi-homed customer is going to be affected in very different ways by changes such as this. It will depend a lot on who the other transit providers are. I'm not saying that knowledge of these types of changes is not useful, I'm saying that to convey these types of changes in a useful manner would appear to be difficult. For example, supposed Sprintlink conveyed (via Web/e-mail/whatever) the following to you just before making the change: We are bringing up some new private peering connections. As a result we will be migrating much of our existing traffic destined for ASNs 209, 701, and 1 and exchanged on the public fabrics at MAE-West, MAE-Eest, and PAIX to private links. The public links will remain in place with prepending to encourage usage of the private links. We will be prepending three times. Happy route tweaking! Would you have known just how this would effect your other upstreams? Do you know your upstreams' routing policies at every interconnect they have? I guess you could make your public routing policy detailed enough to include specifics on each peer. That might do it -- but realize how long this policy could be for a network of reasonable size (hundreds, if not thousands of BGP neighbors -- from peers to all customers). Actually, what about RADB? I'll also warn you that I've not had any coffee as of yet. I'll go do that now and likely come back to several replies pointing to errors in my reasoning above. :-) </thinking out loud> -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us> Geek Research LLC - <URL:http://www.geekresearch.com/> IP Network Engineering and Consulting