Sprint and peering points
Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others) I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections. The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points. 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 Roy Engehausen
* 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. -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
* 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
I am not exactly clear on the impact. For peers that HAVE private interconnections with Sprint, the traffic will still pass to Sprint. For networks that only have public interconnections with Sprint, Sprint customer traffic will traverse normally as well. The networks that fall outside of this category are networks that you don't have a direct customer connection with, which are choosing amongst your N available transit providers to pass traffic to you. If any of these networks had a private interconnect with Sprint, there would be no effect. So, if I logic'd this out correctly, the networks that are affected HAVE peering with Sprint, but ONLY at public access points. I'm assuming this is really significant to your traffic flow. What would Sprint notifying you of this change do for you? Deepak Jain AiNET -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Roy Sent: Saturday, March 31, 2001 11:22 AM To: nanog@merit.edu Subject: Sprint and peering points Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others) I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections. The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points. 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 Roy Engehausen
You basically have it correct. An entity that peers with UUNET and Sprint at a public point would now see 1239 1239 20001 701 20001 This then effectively shifts the load to one of my other transit providers (701) instead of splitting it between 1239 and 701. A worse case is would be if I was using 701 for backup and the route was 701 20001 20001. So by making the change Sprint unilaterally shifts the transit packets from a public peering point away from themselves. What would have been nice is for Sprint to tell its customers it was doing this. Then I would have expected the change in inbound traffic flows and taken action. As it was, I opened a trouble report and wasted a lot of time looking for a problem. Deepak Jain wrote:
I am not exactly clear on the impact. For peers that HAVE private interconnections with Sprint, the traffic will still pass to Sprint. For networks that only have public interconnections with Sprint, Sprint customer traffic will traverse normally as well.
The networks that fall outside of this category are networks that you don't have a direct customer connection with, which are choosing amongst your N available transit providers to pass traffic to you. If any of these networks had a private interconnect with Sprint, there would be no effect.
So, if I logic'd this out correctly, the networks that are affected HAVE peering with Sprint, but ONLY at public access points. I'm assuming this is really significant to your traffic flow. What would Sprint notifying you of this change do for you?
Deepak Jain AiNET
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Roy Sent: Saturday, March 31, 2001 11:22 AM To: nanog@merit.edu Subject: Sprint and peering points
Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others)
I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections.
The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points.
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
Roy Engehausen
Sprint does not prepend its AS at public or private peering points. What other providers do with the AS Path at their ingress is not under our control. Jeff Loughridge Operations Engineering Backbone Operations On Sat, 31 Mar 2001, Roy wrote:
You basically have it correct.
An entity that peers with UUNET and Sprint at a public point would now see
1239 1239 20001 701 20001
This then effectively shifts the load to one of my other transit providers (701) instead of splitting it between 1239 and 701. A worse case is would be if I was using 701 for backup and the route was 701 20001 20001.
So by making the change Sprint unilaterally shifts the transit packets from a public peering point away from themselves.
What would have been nice is for Sprint to tell its customers it was doing this. Then I would have expected the change in inbound traffic flows and taken action. As it was, I opened a trouble report and wasted a lot of time looking for a problem.
Deepak Jain wrote:
I am not exactly clear on the impact. For peers that HAVE private interconnections with Sprint, the traffic will still pass to Sprint. For networks that only have public interconnections with Sprint, Sprint customer traffic will traverse normally as well.
The networks that fall outside of this category are networks that you don't have a direct customer connection with, which are choosing amongst your N available transit providers to pass traffic to you. If any of these networks had a private interconnect with Sprint, there would be no effect.
So, if I logic'd this out correctly, the networks that are affected HAVE peering with Sprint, but ONLY at public access points. I'm assuming this is really significant to your traffic flow. What would Sprint notifying you of this change do for you?
Deepak Jain AiNET
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Roy Sent: Saturday, March 31, 2001 11:22 AM To: nanog@merit.edu Subject: Sprint and peering points
Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others)
I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections.
The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points.
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
Roy Engehausen
I am not exactly clear on the impact. For peers that HAVE private interconnections with Sprint, the traffic will still pass to Sprint. For networks that only have public interconnections with Sprint, Sprint customer traffic will traverse normally as well.
The networks that fall outside of this category are networks that you don't have a direct customer connection with, which are choosing amongst your N available transit providers to pass traffic to you. If any of these networks had a private interconnect with Sprint, there would be no effect.
So, if I logic'd this out correctly, the networks that are affected HAVE peering with Sprint, but ONLY at public access points. I'm assuming this is really significant to your traffic flow. What would Sprint notifying you of this change do for you?
Deepak Jain AiNET
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Roy Sent: Saturday, March 31, 2001 11:22 AM To: nanog@merit.edu Subject: Sprint and peering points
Since I am located in what PacBell thinks is a rural area, I have to contend with using multiple T1s. This forces me to play with the AS paths in order to load balance between my upstreams (Sprint and others)
I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections.
The result is that now my other upstreams that send out the normal "701 20001" get the brunt of the traffic from the public exchange points.
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
Maybe I am mistaken, but I thought route-path selection of equal AS length prefixes is done by numerical value of the AS or next-hop or something. I haven't had to worry about that for a while. My guess is that this provider that is receiving the routes is prepending from Sprint. Deepak Jain AiNET -----Original Message----- From: Roy [mailto:garlic@garlic.com] Sent: Sunday, April 01, 2001 1:47 AM To: deepak@ai.net Cc: nanog@merit.edu Subject: Re: Sprint and peering points You basically have it correct. An entity that peers with UUNET and Sprint at a public point would now see 1239 1239 20001 701 20001 This then effectively shifts the load to one of my other transit providers (701) instead of splitting it between 1239 and 701. A worse case is would be if I was using 701 for backup and the route was 701 20001 20001. So by making the change Sprint unilaterally shifts the transit packets from a public peering point away from themselves. What would have been nice is for Sprint to tell its customers it was doing this. Then I would have expected the change in inbound traffic flows and taken action. As it was, I opened a trouble report and wasted a lot of time looking for a problem. Deepak Jain wrote: there
seeing the same problems? Any ideas on how to cure it
Roy Engehausen
I have found that Sprint is prepending their AS when sending routes to many of the public exchanges (example "1239 1239 20001") in order to "shift load" to private peer connections.
...
Needless to say I am a bit pissed at Sprint for doing this and not telling me.
It's arguable that they _did_ tell you; in the truest sense, the BGP update. -alan ....
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
Roy Engehausen
participants (5)
-
Alan Hannan -
Deepak Jain -
Jeff Loughridge -
Josh Richards -
Roy