North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: Sprint and peering points
- From: Deepak Jain
- Date: Sat Mar 31 21:43:15 2001
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?
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of
Sent: Saturday, March 31, 2001 11:22 AM
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