DNS can sometimes give you a hint
[my nets snipped]
4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.436 ms 18.309 ms 17.605 ms <------------DS3
5 so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210) 17.607 ms 16.982 ms 16.971 ms <-----OC-48
6 p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5) 17.864 ms 19.491 ms 17.181 ms
7 p5-1-0-3.RAR1.Seattle-WA.us.xo.net (65.106.0.197) 17.723 ms 17.632 ms 19.045 ms
8 65.106.0.50 (65.106.0.50) 38.133 ms 39.197 ms 49.961 ms MPLS Label=101549 CoS=0 TTL=1 S=1
9 p0-0-0d0.RAR1.SanJose-CA.us.xo.net (65.106.1.61) 37.669 ms 38.572 ms 36.517 ms
10 p7-0.DCR1.DC-SanJose-CA.us.xo.net (65.106.2.146) 37.830 ms 36.524 ms 37.743 ms
11 ge1-1.CDR2.DC-SanJose-CA.us.xo.net (209.220.168.10) 38.428 ms 38.050 ms 37.179 ms <-----Gig Ethernet
12 205.158.6.100.ptr.us.xo.net (205.158.6.100) 40.179 ms 39.784 ms 39.444 ms
13 x218.cd9e6c.sj.concentric.net (205.158.108.218) 39.188 ms 39.723 ms 39.895 ms
However MPLS hidden hops may hide internal paths, and any connection may be limited to slower than its line rate, and dns entries may be old…
It’s not publicly available at one source that I’m aware of, and if there is they don’t have my info.
-C
Is it really important to know the link speeds? What good does it do without knowing
about the loading on those links?
I would MUCH rather have an empty T1 than have to contend with a very oversubscribed OC-768.
Tony
Sometimes it can give a hint. However, if the ISPs are following the
�interface name� convention, you�ll get something like P3-1-2, which just
tells you its Packet Over SONET. That can mean anything from OC-3 to OC-192.
�ge� could mean 10 gige 
The "2488M" from glbx is nice, but not too common.
It would be so nice if this were standardized between all providers. But
naming conventions are really political - they sometimes provoke huge fights
even within providers.
Sometimes it can give a hint. However, if the ISPs are following the
�interface name� convention, you�ll get something like P3-1-2, which just
tells you its Packet Over SONET. That can mean anything from OC-3 to OC-192.
�ge� could mean 10 gige
"ge" doesn't usually mean 10ge, for example the Juniper interface name is
"xe". At the very least, you can tell the difference between Juniper and
Cisco (pos2-3 vs. so-2-3-0).
The "2488M" from glbx is nice, but not too common.
Also not always maintained... I've personally submitted about 30 nags for
PTRs which said 622M but which I knew were really 2488M, but I buy transit
from them so I have a vested interest in accurate data.
Note that GX doesn't have that information on peering PTRs. Some other
folks don't maintain capacity information on their backbone links, but do
have it for peering circuits (such as Level 3). Then there are folks that
have slightly obscured, like Verio's p# entries which are STS codes (p1 =
oc3, p4 = oc12, etc).
It would be so nice if this were standardized between all providers. But
naming conventions are really political - they sometimes provoke huge
fights even within providers.
Sounds like a NANOG talk presentation to me. I love a good debate between
airport codes and clli codes (not!).
[...]
At the very least, you can tell the difference between Juniper and
Cisco (pos2-3 vs. so-2-3-0).
...unless you're dealing with networks who uniformly use the "p[os]"
or "so" suffix for Packet-over-SONET interfaces, regardless of what
kind of hardware it's terminating on. In example:
5 so-0-0-0.mp1.Weehawken1.Level3.net (64.159.1.66) 1.065 ms 0.997 ms 1.046 ms
6 so-9-0.hsa2.Weehawken1.Level3.net (209.247.8.14) 1.563 ms 0.984 ms 1.047 ms
Hmmm. Not knowing anything about what kind of hardware this actually
is, and judging solely from TCP fingerprinting and response behavior,
#5 smells like a Juniper and #6 smells like a Cisco.
Then there are those who use the same designator ("s") for SONET
interface as they do for serial/T1 interfaces.
Or those who make a vendor-indicative PTR entry for a PNI, then move
the link to a different platform, and don't bother updating DNS.
Or those who find it cool to have gigabit-speed /30's reverse to
something with "dsl" or "dialup" in it, out of incompetence or
modesty.
Or those who play the old "ip addr ... secondary" game on Cisco gear,
along with bogus /30's and PTR's as the primary address to lie about
link speed in traceroute replies.
Or those who are outright deceptive in what their PTR's say
vs. reality. (Nobody on this list, of course!)
As always, DNS doesn't tell the full story. But we're preaching to
the choir here...
-a