I have a question regarding information on my ISP's peering relationships.
Are the speeds of some or all peering relationships public knowledge, and if
so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps,
1Gbps, etc.). I am trying to transfer large stuff from my AS, through my
ISP, through another ISP, to another AS, and I'm wondering how fast the
peering point is between the ISPs. I'm working with my provider to get this
information as we speak, but I'm wondering if it's available publicly
anywhere. If it were, this could be one way to evaluate providers in the
future, I guess.
Erik Amundson
A+, N+, CCNA, CCNP
IT and Network Manager
Open Access Technology Int'l, Inc.
Phone (763) 201-2005
Fax (763) 553-2813 mailto:erik.amundson@oati.net
I have a question regarding information on my ISP's peering relationships.
> Are the speeds of some or all peering relationships public knowledge, and if
> so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps,
> 1Gbps, etc.). I am trying to transfer large stuff from my AS, through my
> ISP, through another ISP, to another AS, and I'm wondering how fast the
> peering point is between the ISPs.
ISPs don't register it or publish it anywhere, generally, and if you ask
salescritters, they're likely to say "At the speed of LIGHT!!!" or some
such. But the two methods people would generally use to determine this
externally would be first to do a bidirectional traceroute and look
closely at the in-addr DNS names associated with the router interfaces on
the IX or crossconnect, which, if you trust them, may give you some
indication of speed. Next, if you have time, you could run pathchar
across the link.
> <head>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 11
> (filtered medium)">
> <o:SmartTagType =
> namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
> name=3D"PersonName"/>
> <!--[if !mso]>
> <style>
> st1\:*{behavior:url(#default#ieooui) }
> </style>
>
<snip>
>
> . I am trying to
> transfer large stuff from my AS, through my ISP, through
> another ISP, to
> another AS, and I’m wondering how fast the peering point is =
> between the
> ISPs. I’m
Turn off the HTML formatting and your "stuff" will get there much faster.
Of course, the big issue isn't the size of the links - its utilization. Most
private peering links today are OC-12 to OC-192. Most big ISPs do this in a
half dozen locations - sometimes more, occasionally less. Of course, you'll
use the closest exit between ISPs.
Ask your ISP what the utilization of that link is - or what the packet loss
is, historically. They are much more likely to tell you that.
Its funny, you always see people asking about peering link sizes or
locations on RFP's, but they never ask about peering utilization or packet
loss. The former is both NDA and meaningless - the latter is terribly
important.
Date: Thu, 01 Jul 2004 21:57:55 -0400
From: Daniel Golding
Its funny, you always see people asking about peering link
sizes or locations on RFP's, but they never ask about peering
utilization or packet loss. The former is both NDA and
meaningless - the latter is terribly important.
It's ANES -- Armchair Network Engineer Syndrome. The same people
fuss arbitrarily about traceroute hop count.
ISPs don't register it or publish it anywhere, generally, and if you ask
salescritters, they're likely to say "At the speed of LIGHT!!!" or some
such. But the two methods people would generally use to determine this
externally would be first to do a bidirectional traceroute and look
closely at the in-addr DNS names associated with the router interfaces on
the IX or crossconnect, which, if you trust them, may give you some
indication of speed. Next, if you have time, you could run pathchar
across the link.
-Bill
um, pathchar will attempt to do a capacity-per-link over a whole
forward path, but it struggles with the complexities of real world
infrastructure (alas, who doesn't) after about 1997, when it was
last supported. van let caida index the tool at http://www.caida.org/tools/utilities/others/pathchar/
it is 100% van's knightly work. but i think van moved on to
other things after concluding that the task of accurately
identifying capacities of links many hops away via layer 3
measurement on the global Internet was 'sub-possible.'
a few others agree w him.
professor constantine dovrolis and his amazing grad students
ravi and manish at GA tech have taken on a slightly smaller
windmill: measurement of capacity and available bandwidth for a
given -path- (which means the narrow and tight links along the path,
see http://www.pathrate.org for excellent brief description and
source codes). note that neither tool requires root privileges
but both require installing software at both ends of the path,
which render them less useful for the specific application above.
see constantine's IEEE Network paper http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/Papers/NetDov0248.pdf
if you want high signal techie survey paper on the field,
including a table listing a bunch of tools on page 12.
caida has a summer student from UNC this year working
on evaluating the accuracy of some of these tools in a
controlled lab setting.
i personally can't believe you knights put up with not being
able to measure capacity and available bandwidth of your peers'
paths, but i guess it puts the anycast drama into perspective.
the bottom line is that the research community has made some
progress in the field in the last 5 years, but it's a harder
problem than it seems. and it seems pretty bloody hard.
as an operator the best thing you can do to advance this particular
research ball is to use these tools on paths where you actually
know the available bandwidths, and give the tool authors feedback
to help make them more accurate or otherwise more conducive to
your needs. it's the single largest barrier standing between
these tools and these tools being more useful to you.
(besides funding and strong-stomached coders of course)
In addition to some of the other answers, you can sometimes discover
peering relationships and even infer some routing policing at public
exchanges if you 1) have access to a host on each of the provider's
networks (near the exchange preferably) and 2) you can rely on the
public address scheme provided by the exchange operator to be used
for peering.
So for example, if you have a host on provider X's network, run a series
of traceroutes to each of the exchange IP space. If the traceroute
reaches the far side, you can infer that peering is established. If not
traceroute results in a TTL failure or unreachable message, you can infer
that peering is not established.
Finding hosts behind each network is often as easy as finding publicly
accessible traceroute pages such as those found on traceroute.org.
Note, this is far from full proof. For a number of reasons there will
be false positives and false negatives if you try to rely on this as the
only source of info for peering discovery.
lkA & lkD are "hidden" from external view. if you are
a customer of ISP which owns lkA, they -may- tell you
what the characteristics of lkA are ... "today". No
assurances that it will remain the same for any given
period of time. And the ISP with lkA is unlikely to be able
to judge/interpret the accuate value of lkD, although this
may be infered from their peering SLAs... which are generally
NDA'ed.
if ther exists a "possibleIX", there is the strong case
that the interconnects are one of the possible ehternet
formats, e.g. 10Mbps in full or half duplex, 100Mbps in
either full or hald duplex, or 1Gbps, generall full duplex.
Yes, there are some other varients... And there is no
assurance that lkB and lkC are the same!
in the case where there is no "possibleIX" and the links
lkB and lkC are the two sides of a point2point link, then
more choices arise and the potential for determining
the actual "speed" of the link.
then there are the other "tweekable" characteristics of
a specific link (MTU, MSS, etc.) which will affect throughput/goodput
of that specific link.
