nanog mailing list archives
RE: Sprint and peering points
From: "Deepak Jain" <deepak () ai net>
Date: Mon, 2 Apr 2001 06:52:04 -0400
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:
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
Current thread:
- Re: Sprint and peering points Roy (Mar 31)
- Re: Sprint and peering points Jeff Loughridge (Mar 31)
- RE: Sprint and peering points Deepak Jain (Apr 02)
- <Possible follow-ups>
- Re: Sprint and peering points Sean M. Doran (Mar 31)
- Re: Sprint and peering points Miguel A.L. Paraz (Apr 01)
- Re: Sprint and peering points Alan Hannan (Mar 31)