Depech Mode - Policy of Truth. Well, thanks for the update, but I certainly hope that this "incident" doesn't get glossed over, euphemized, or simply down-played into non-existence like the Network Solutions problems (earlier) did. I'm still waiting for a rational explanation for that one, and all I've seen is bullsh#t. I won't settle for ludicrous euphemisms of what really happened. Nor should any rational, technically inclined engineer. These problems need to be identified, examined technically, and then, perhaps, we can revisit the technical issues which affect all of us. Having said that, this appeared to clearly be more than a simple "glitch" -- and I'd like to see it explained in the sprirt of truthfulness, openess, and the Tao of the 'net. We can't shadow-dance with half-truths, but we can fix real problems when they are acknowledged. Personally, I'm kind of feeling like a mushroom right now -- fed a bunch of sh#t and kept in the dark. - ferg -- Mark Owen <mr.markowen@gmail.com> wrote: Everything is back up now. Guess it was a router glitch somewhere to compliment Google's DNS issue. On 5/7/05, Jonathan M. Slivko <jonathan@slivko.org> wrote:
Looks OK to me (from Verizon DSL in NY):
Traceroute to (64.112.229.131) 1 * (10.32.19.1) 20 ms 22 ms 22 ms 2 * (130.81.11.161) 22 ms 22 ms 22 ms 3 so-6-0-0-0.BB-RTR2.NY325.verizon-gni.net (130.81.18.90) 22 ms 22 ms 22 ms 4 so-6-0-0-0.BB-RTR2.NY60.verizon-gni.net (130.81.7.201) 22 ms 24 ms 22 ms 5 so-2-0-0-0.PEER-RTR1.NY60.verizon-gni.net (130.81.4.214) 24 ms 22 ms 22 ms 6 jfk-edge-20.inet.qwest.net (65.116.172.85) 22 ms 22 ms 22 ms 7 jfk-core-01.inet.qwest.net (205.171.230.14) 22 ms 22 ms 22 ms 8 stl-core-01.inet.qwest.net (205.171.5.81) 94 ms 122 ms 94 ms 9 egn-core-01.inet.qwest.net (205.171.5.126) 100 ms 100 ms 100 ms 10 eug-edge-02.inet.qwest.net (205.171.150.18) 102 ms 100 ms 100 ms 11 * (207.109.243.74) 100 ms 100 ms 102 ms 12 64-112-224-3-ips-eug-or-core02.tcpipservices.net (64.112.224.3) 116 ms 116 ms 118 ms 13 64-112-227-69-ips-eug-or-lb01-2.tcpipservices.net (64.112.227.69) 116 ms 118 ms 118 ms 14 maverick31.sans.org (64.112.229.131) 142 ms 116 ms 118 ms
Mark Owen wrote:
Hi All,
Not sure where the problem is at but several packets are being dropped to several different hosts from the DC area. (This is not the Google DNS problem) I tried connecting to several different known sites with roughly 40% being unresponsive from two seperate ISPs (Speakeasy and Comcast.)
Traceroute to sans.org via Comcast: ~~~~~~~~~~~~~ 1 <1 ms <1 ms <1 ms 192.168.20.1 2 12 ms 15 ms 6 ms 10.84.240.1 3 21 ms 11 ms 7 ms ge-2-3-ur02.lanham.md.bad.comcast.net [68.87.131 .125] 4 8 ms 12 ms 32 ms te-9-1-ur01.lanham.md.bad.comcast.net [68.87.129 .61] 5 11 ms 21 ms 9 ms te-9-1-ur01.bowie.md.bad.comcast.net [68.87.128. 177] 6 8 ms 6 ms 27 ms te-8-2-ar01.capitolhghts.md.bad.comcast.net [68. 87.128.182] 7 7 ms 8 ms 8 ms 68.87.16.165 8 15 ms 9 ms 7 ms 12.118.122.9 9 8 ms 9 ms 9 ms tbr1-p010401.wswdc.ip.att.net [12.123.9.106] 10 7 ms 8 ms 8 ms ggr2-p300.wswdc.ip.att.net [12.123.9.81] 11 10 ms 9 ms 12 ms att-gw.dc.sprint.net [192.205.32.166] 12 27 ms 13 ms 9 ms sl-bb26-rly-5-0.sprintlink.net [144.232.20.149]
13 39 ms 33 ms 32 ms sl-bb25-chi-3-0.sprintlink.net [144.232.20.89] 14 78 ms 76 ms 84 ms sl-bb21-sea-1-0.sprintlink.net [144.232.20.156]
15 75 ms 77 ms 74 ms sl-bb20-sea-15-0.sprintlink.net [144.232.6.89] 16 75 ms 74 ms 81 ms sl-bb22-tac-6-0.sprintlink.net [144.232.9.151] 17 77 ms 75 ms 75 ms sl-bb21-tac-4-0.sprintlink.net [144.232.17.93] 18 76 ms 76 ms 76 ms sl-gw6-tac-10-0.sprintlink.net [144.232.17.1] 19 88 ms 83 ms 86 ms sl-micro23-1-0-0.sprintlink.net [160.81.243.66]
20 82 ms 80 ms 83 ms 64-112-224-3-ips-eug-or-core02.tcpipservices.net [64.112.224.3] 21 86 ms 85 ms 84 ms 64-112-227-69-ips-eug-or-lb01-2.tcpipservices.ne t [64.112.227.69] 22 maverick32.sans.org [64.112.229.132] reports: Destination host unreachable.
~~~~~~~~~~~~~~~~~~~~~~~ Traceroute via Speakeasy would timeout.
Same thing goes for other sites ubuntulinux.org www.osvdb.org for example.
Anyone else having similar problems?
-- Mark Owen -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/