Perhaps I'm confused, but the only potential brokenness demonstrated in your
traceroute output is that Sprint is announcing Verio routes to AS3847/BBN
(formerly Genuity). The latter of the two traceroute outputs seems quite
reasonable. That is, BBN/GTEI providing transit to Genuity.
I'm not sure exactly where BBN/Genuity or Verio would be at fault here, with
the exception of BBN/Genuity accepting some random prefixes from Sprint.
While NANOG posts will likely result in a "clueful person from BBN" promptly
contacting you, usually, it doesn't take quite a entire week to reach them via
their NOC.
-danny
Perhaps I'm confused, but the only potential brokenness demonstrated in your
traceroute output is that Sprint is announcing Verio routes to AS3847/BBN
(formerly Genuity).
This is but one example. I'm seeing similar results via uunet, cw,
etc. This is the newest twist, the Sprint announcement problem.
The latter of the two traceroute outputs seems quite
reasonable. That is, BBN/GTEI providing transit to Genuity.
My problem with that though is the route it takes to go from NYC to
NYC. Internally BBN is sloshing all our traffic out to the west coast and
back, which leads to suboptimal performance and traceroutes that are
rather difficult to explain to customers.
I'm not sure exactly where BBN/Genuity or Verio would be at fault here, with
the exception of BBN/Genuity accepting some random prefixes from Sprint.
The problem is two-fold. The sprint issue and the issue of all traffic
going out west for no reason. For example, look at this trace from BBN's
route server in Mass.:
1 e0-1-5.burlma1-ops1.bbnplanet.net (4.2.34.162) [AS 65307] 0 msec 4
msec 0 msec
2 fa1-0-0.burlma1-ops2.bbnplanet.net (4.2.34.58) [AS 65307] 4 msec 0
msec 0 msec
3 s11-0-0.cambridge1-br1.bbnplanet.net (4.0.2.25) 4 msec 4 msec 4 msec
4 p1-3.cambridge1-nbr1.bbnplanet.net (4.0.1.21) 4 msec 0 msec 4 msec
5 p5-0.washdc3-ba2.bbnplanet.net (4.0.5.41) 12 msec 12 msec 12 msec
6 *
p7-0.washdc3-br2.bbnplanet.net (4.24.4.142) 44 msec *
7 p3-0.lsanca1-br2.bbnplanet.net (4.24.5.134) 120 msec 116 msec *
CALI ^^^^^^
8 p7-0.lsanca1-ba2.bbnplanet.net (4.24.4.37) 116 msec 116 msec *
9 p1-0-0.lsanca1-bp1.bbnplanet.net (4.24.5.182) 124 msec 120 msec 116
msec
10 s0-0-0.phnyaz2-cr1.bbnplanet.net (4.24.4.70) 132 msec 132 msec 128
msec
11 fa8-1-0.phxcolo-core2.bbnplanet.net (4.1.110.238) 128 msec * 128 msec
PHOENIX ^^^^^^
12 128.11.124.53 [AS 3847] 208 msec 212 msec 212 msec
13 f12-0.nyccolo-border1.bbnplanet.net (207.240.1.82) 204 msec 208 msec
208 msec
14 ptp-46.100fe10-0.nyc1.genuity.net (207.240.48.46) 208 msec * 212 msec
15 S0-inch-gw.inch.com (207.240.128.230) 212 msec 212 msec 212 msec
16 *
www.inch.com (207.240.140.100) 216 msec 212 msec
While NANOG posts will likely result in a "clueful person from BBN"
promptly contacting you, usually, it doesn't take quite a entire week
to reach them via their NOC.
I can reach the NOC fine, I just can't get the issue resolved... I feel
like I'm dealing with a telco here.
Charles
Perhaps I'm confused, but the only potential brokenness demonstrated in your
traceroute output is that Sprint is announcing Verio routes to AS3847/BBN
(formerly Genuity). The latter of the two traceroute outputs seems quite
reasonable. That is, BBN/GTEI providing transit to Genuity.
I'm not sure exactly where BBN/Genuity or Verio would be at fault here, with
the exception of BBN/Genuity accepting some random prefixes from Sprint.
You don't see the NY -> Cali -> NY path? That is a bad thing (tm).