Anyone from sbcglobal out there? i'm seeing a routing loop. Please contact me off list thanks.
sourceip: 69.16.137.66
tracert 75.58.215.133
Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net [75.58.215.133]
over a maximum of 30 hops:
1 2 ms <1 ms <1 ms 192.168.113.1
2 1 ms 2 ms 2 ms 69.16.137.66
3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net
[69.16.128
.110]
4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137]
5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161]
6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37]
7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net [69.31.127.29]
8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net
[69.31.127.165]
9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net
[69.31.127.50]
10 11 ms 11 ms 11 ms 151.164.188.139
11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
12 11 ms 11 ms 11 ms 151.164.188.139
13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
14 14 ms 11 ms 11 ms 151.164.188.139
15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
16 11 ms 11 ms 11 ms 151.164.188.139
17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
18 11 ms 11 ms 11 ms 151.164.188.139
19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
20 12 ms 11 ms 11 ms 151.164.188.139
21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
22 11 ms 11 ms 11 ms 151.164.188.139
23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
24 11 ms 11 ms 11 ms 151.164.188.139
25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
26 14 ms 11 ms 12 ms 151.164.188.139
27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
28 12 ms 11 ms 11 ms 151.164.188.139
29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net
[151.164.188.138]
30 11 ms 11 ms 11 ms 151.164.188.139
Trace complete.
Hey we got one too - we're having problems through Level 3.
Hop IP Address Hostname ASN Network Name % Loss Min Latency Latency Avg
Latency Max Latency Std Dev
1 192.168.1.1 192.168.1.1 0 0.37 0.47 0.67 0.06
2 192.168.1.254 192.168.1.254 0 0.66 0.76 1.1 0.07
3 216.31.131.253 s1p20.colo1.lax.ca.us.tierzero.net 11509 TIERZERO-700LA 0
1.98 5.02 133.36 18.37
4 216.31.128.131 asbr2.bsap.lax1.ca.us.tierzero.net 11509 TIERZERO-700LA 0
2.24 6.88 186.29 25.73
5 4.71.142.93 ge-9-23.car2.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.4
11.92 183.51 36.78
6 4.68.20.69 ae-23-79.car3.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.79
7.21 70.62 14.11
7 4.68.110.114 sbc-level3-10ge.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0
2.89 15.72 207.58 35.31
8 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.71 2.77
3.8 21.95 3.22
9 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 76 2.86
36.28 196.96 71.87
10 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.11
2.72 7.12 126.74 21.49
11 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 52 3.06
16.62 138.84 37.11
12 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 13.89
2.91 15.14 160.99 35.24
13 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 48.28
2.93 15 92.22 29.64
14 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 2.63 2.76
8.06 122.75 20.76
15 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54
3.18 11.46 49.49 15.65
16 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.81
8.9 85.47 19.06
17 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 72 3 4
7.61 1.49
18 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 2.75
8.65 142.66 24.57
19 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.24
5.15 11.5 3.19
20 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.91
3.57 9.63 1.06
21 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3
36.53 139.3 57.23
22 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.26 2.94
9.24 198.98 32.15
23 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 55.56
3.23 6.79 39.86 9.99
24 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.43
3.05 7.4 123.63 21.22
25 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.17
41.51 194.34 76.41
26 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 7.32 3
7.36 137.2 21.43
27 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54
3.08 7.36 24.55 7.1
28 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 3.1
7.76 132.98 22.14
29 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3.44
21.86 148.94 48.03
30 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 23.08
3.16 7.74 84.7 17.66
-Justin
Think this may be an ongoing issue... Last night out here in the bay
area, myself and many other SBC/ATT users were experiencing random
blackholed networks. Total PITA!
-Mike
What did your upstream transit supplier advise before you escalated this to
the global audience at NANOG?
This is the second time in 24hrs you have requested assistance here which
could have been handled via other methods.
-ren
I think that's precisely the problem, that the issue could not have
been handled "though other methods".
I agree NANOG is not a replacement for NOCs, but what about when the
NOCs are utterly useless and the issue is global in scope?
Given the parties involved, I'd like to think that Logan tried to go
through standard channels prior to posting. Please realize this is no
slight against nLayer, but rather, "the new AT&T" and their concept of
customer service.
Paul
I think that's precisely the problem, that the issue could not have
been handled "though other methods".
I think it should be clear to those posting here as a last ditch
effort that they should certainly outline the steps they've already
taken -- basically justifying their post to NANOG: "I tried X, waited
Y, got Z, and now I'm here"
I agree NANOG is not a replacement for NOCs, but what about when the
NOCs are utterly useless and the issue is global in scope?
that's definitely one of the reasons *I* think this mailing lists
exists. infact I bet if I wasn't lazy I could find something to that
effect in the charter or nanog.org site.
Given the parties involved, I'd like to think that Logan tried to go
through standard channels prior to posting. Please realize this is no
slight against nLayer, but rather, "the new AT&T" and their concept of
customer service.
SBC/ATT/whatever peering ops was always my absolute favorite to work
with back when I actually worked in a NOC. hopefully that hasn't
changed much in the past year.
Aaron Glenn wrote:
I think it should be clear to those posting here as a last ditch
effort that they should certainly outline the steps they've already
taken -- basically justifying their post to NANOG: "I tried X, waited
Y, got Z, and now I'm here"
To give an example:
http://mailman.nanog.org/pipermail/nanog/2008-June/001452.html
I started with the customer care support line (in a concall with our client who was also their client). Then I moved onto various email contacts. Since my problem was partially DNS related, I tried the SOA mailto address. Since the other part of my problem was email related I tried postmaster@. I also tried to mail the ARIN whois contacts (but a bug in my client software prevented me from getting the record, and since the error appeared to be on the RPs side it looked to be a dead end)
Then I went onto Jared's NOC list, as well as the INOC-DBA directory.
By the time I resorted to posting here, I had exhausted every feasible contact method I could think of. And yes, that meant waiting days for resolution BEFORE posting here, and some additional days AFTER posting here before actually getting the help I needed.
INOC-DBA is still a great idea, BTW, and would be even more useful if it were more widely used: http://www.pch.net/inoc-dba/
Also, to second another poster's point, most "routing loops" aren't really routing problems per-se, as much as localized link failures and the absence of naildown routes (we use the naildowns on all point-to-point circuits for this reason, since we don't run routing protocol on CPE).
> Anyone from sbcglobal out there? i'm seeing a routing
loop. Please
> contact me off list thanks.
What did your upstream transit supplier advise before you
escalated this to the global audience at NANOG?
This is the second time in 24hrs you have requested
assistance here which could have been handled via other methods.
Sounds like he's used to used IRC, not mailing lists.
There used to be an IRC channel where a lot of NANOG
folks hung out. Anyone care to publicize the channel
name and which IRC network carries it?
--Michael Dillon
Sounds like he's used to used IRC, not mailing lists.
There used to be an IRC channel where a lot of NANOG
folks hung out. Anyone care to publicize the channel
name and which IRC network carries it?
--Michael Dillon
from the nanog mailing list...
There's a #nanog on EFNet, and a #nanog on Freenode. I'd recommend the Freenode NANOG as EFNet is pretty well overrun with kiddies.
Andrew
> Sounds like he's used to used IRC, not mailing lists.
> There used to be an IRC channel where a lot of NANOG folks
hung out.
> Anyone care to publicize the channel name and which IRC network
> carries it?
from the nanog mailing list...
Sent: Tuesday, June 22, 2004 12:17 PM
> First and foremost, the #nanog IRC channel has absolutely
nothing to > do with the nanog mailing list, other than it
shares some common > personalities.
Which IRC network? There are dozens of IRC networks and although
you can find channels with the same name on different networks,
they rarely share common personalities.
In any case, I would expect that an IRC channel would contain
mostly front-line NOC people, and except for the smaller networks
where one person wears many hats, I would not expect to find
such people hanging out on the NANOG list.
Now, perhaps #nanog is not the channel I am thinking of, in which
case I think it would be a good idea for someone with first
hand experience to post the channel or channels which do
cover this type of stuff. Same thing goes for Jabber channels
or any other IM network. Is there a place where frontline
network operators hang out, where it is not frowned upon to
ask operational questions about events in progress?
--Michael Dillon
There are many. I suspect some are more public than others (but I don't have
a list, so don't bother asking!). The most useful ones tend to be "by invite
only", otherwise they just get full of people asking inane questions, and the
useful people get bored and go elsewhere.
Simon
I was invited to it once, but do not have it handy now; it is
by-invite-only, and it is *not* #nanog on any network.
Cheers,
-- jra