Re: whois.internic.net / whois.crsnic.net IPv6 timeouts
Now I'm starting to really wonder- I'm having this trouble over a SixXS tunnel but some of the non-tunnel'd IPv6 environments I have access to are working fine. Perhaps the issue here is actually MTU or MSS related? Possibly. It works fine for me through a HE tunnel, but I think I had problems when I was using a gogonet/freenet6 tunnel. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
Re: google troubles?
That makes sense, I figured it was some type of a CDN caching environment. I've found that youtube.com is in the same boat: Translating "www.youtube.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to youtube-ui.l.google.com (24.156.153.40) [synkro:ROOT](~): jwhois 24.156.153.40 | grep -i orgname OrgName:Rogers Cable Communications Inc. [synkro:ROOT](~): Thanks! - MJ On Wed, Jul 10, 2013 at 2:39 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow > wrote: > > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > >> I just realized that it's not Google IP space (74.125.0.0/16), Rogers > is > >> hijacking the DNS and resolving www.google.com to space within > >> 64.71.240.0/20 which is Rogers IP space! (note the name server set as > >> 8.8.8.8) > >> > > > > so: > > 1) rogers is hijacking traffic to 8.8.8.8 > > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > > information for google properties (at least). > > > > err... any idea if it's lying about other things too? :) > > > > oops, so a polite caller noted that google often ships people at a > local 'google global cache' node if they have one... it seems like > that might be what's going on here with 8.8.8.8 sending you to 64.71 > and/or 66.185 addresses. > > so maybe rogers isn't doing something untoward after all! > > -chris > (thanks for the headslap polite caller) > > >> davinci#traceroute www.google.com > >> > >> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >> > >> Type escape sequence to abort. > >> Tracing the route to www.google.com (66.185.85.29) > >> > >> 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > >> 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS > 812] 8 > >> msec 8 msec 4 msec > >> 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > >> 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > >> 5 * * * > >> 6 * * * > >> 7 * * * > >> 8 * * * > >> 9 * * * > >> 10 * * * > >> > >> TOR2-CORE-R1#show ip bgp 66.185.85.29 > >> BGP routing table entry for 66.185.80.0/20, version 13095115 > >> Paths: (1 available, best #1, table default) > >> Advertised to update-groups: > >> 14 > >> 701 6461 812 > >> 205.205.23.121 from 205.205.23.121 (137.39.8.42) > >> Origin IGP, localpref 100, valid, external, best > >> TOR2-CORE-R1# > >> > >> > >> Thanks, > >> > >> - Mike > >> > >> > >> On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > >> > >>> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > >>> not from Rogers/AS812 in Toronto. I've done a few other test > traceroutes > >>> through Rogers to verify that they didn't filter UDP/ICMP. At this > point > >>> nothing would surprise me from Rogers. > >>> > >>> AS701 > >>> = > >>> > >>> TOR2-CORE-R1#traceroute www.google.com > >>> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >>> > >>> Type escape sequence to abort. > >>> Tracing the route to www.google.com (74.125.26.99) > >>> VRF info: (vrf in name/id, vrf out name/id) > >>> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > >>> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 > msec > >>> 4 msec > >>> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 > msec > >>> 16 msec > >>> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > >>> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > >>> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > >>> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > >>> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > >>> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > >>> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > >>> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > >>> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > >>> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > >>> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 > msec > >>> 9 216.239.48.159 [AS 15169] 36 msec 32 msec > >>> 216.239.48.59 [AS 15169] 32 msec > >>> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > >>> > >>> > >>> > >>> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > >>> === > >>> > >>> *Query:* *tr 64.71.249.45* > >>> > >>> Type escape sequence to abort. > >>> Tracing the route to 64.71.249.45 > >>> > >>> 1 64.71.255.62 0 msec 0 msec 0 msec > >>> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec > 4 msec 4 msec > >>> 3 69.63.250.189 4 msec 4 msec 4 msec > >>> 4 69.63.250.174 4 msec 4 msec 4 msec > >>> 5 * * * > >>> 6 * * * > >>> 7 * * * > >>> 8 * * * > >>> 9 * * * > >>> 10 * * * > >>> 11 * * * > >>> 12 * * * > >>> 13 * * * > >>> 14 * * * >
Re: google troubles?
Hey Chris, long time! >From what I can tell, it's only Google Services (that I've found so far; other things appear to resolve correctly). I'm wondering if they're bouncing Google based traffic through some type of caching / accelerator? Or maybe it's an NSA/DPI box ;) I've tested Maps, Gmail, Translate as well as www.google.com, www.google.caand they're all hijacked replies >> Translating "www.google.com"...domain server (8.8.8.8) [OK] (www.google.com) Type escape sequence to abort. Tracing the route to www.google.com (66.185.84.44) (www.google.ca) Type escape sequence to abort. Tracing the route to www.google.ca (66.185.95.44) (gmail) Type escape sequence to abort. Tracing the route to www3.l.google.com (66.185.85.39) (maps) Type escape sequence to abort. Tracing the route to maps.l.google.com (64.71.249.114) (translate) Type escape sequence to abort. Tracing the route to www3.l.google.com (66.185.84.30) Cheers, - Mike On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > > I just realized that it's not Google IP space (74.125.0.0/16), Rogers is > > hijacking the DNS and resolving www.google.com to space within > > 64.71.240.0/20 which is Rogers IP space! (note the name server set as > > 8.8.8.8) > > > > so: > 1) rogers is hijacking traffic to 8.8.8.8 > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > information for google properties (at least). > > err... any idea if it's lying about other things too? :) > > > davinci#traceroute www.google.com > > > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > > > Type escape sequence to abort. > > Tracing the route to www.google.com (66.185.85.29) > > > > 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > > 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] > 8 > > msec 8 msec 4 msec > > 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > > 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > > 5 * * * > > 6 * * * > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > > > TOR2-CORE-R1#show ip bgp 66.185.85.29 > > BGP routing table entry for 66.185.80.0/20, version 13095115 > > Paths: (1 available, best #1, table default) > > Advertised to update-groups: > > 14 > > 701 6461 812 > > 205.205.23.121 from 205.205.23.121 (137.39.8.42) > > Origin IGP, localpref 100, valid, external, best > > TOR2-CORE-R1# > > > > > > Thanks, > > > > - Mike > > > > > > On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > > > >> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > >> not from Rogers/AS812 in Toronto. I've done a few other test > traceroutes > >> through Rogers to verify that they didn't filter UDP/ICMP. At this > point > >> nothing would surprise me from Rogers. > >> > >> AS701 > >> = > >> > >> TOR2-CORE-R1#traceroute www.google.com > >> Translating "www.google.com"...domain server (8.8.8.8) [OK] > >> > >> Type escape sequence to abort. > >> Tracing the route to www.google.com (74.125.26.99) > >> VRF info: (vrf in name/id, vrf out name/id) > >> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > >> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 > msec > >> 4 msec > >> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 > msec > >> 16 msec > >> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > >> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > >> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > >> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > >> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > >> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > >> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > >> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > >> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > >> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > >> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec > >> 9 216.239.48.159 [AS 15169] 36 msec 32 msec > >> 216.239.48.59 [AS 15169] 32 msec > >> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > >> > >> > >> > >> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > >> === > >> > >> *Query:* *tr 64.71.249.45* > >> > >> Type escape sequence to abort. > >> Tracing the route to 64.71.249.45 > >> > >> 1 64.71.255.62 0 msec 0 msec 0 msec > >> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec > 4 msec 4 msec > >> 3 69.63.250.189 4 msec 4 msec 4 msec > >> 4 69.63.250.174 4 msec 4 msec 4 msec > >> 5 * * * > >> 6 * * * > >> 7 * * * > >> 8 * * * > >> 9 * * * > >> 10 * * * > >> 11 * * * > >> 12 * * * > >> 13 * * * > >> 14 * * * > >> 15 *
Re: whois.internic.net / whois.crsnic.net IPv6 timeouts
* John Levine (jo...@iecc.com) wrote: > "It works fine for me." Very curious. > I've had problems before and would guess that it's a routing issue. > It my impression that they're anycasted. traceroute6's take me to various places, so I think it may just be a simply DNS round-robin rather than anycast. Now I'm starting to really wonder- I'm having this trouble over a SixXS tunnel but some of the non-tunnel'd IPv6 environments I have access to are working fine. Perhaps the issue here is actually MTU or MSS related? I've not had any problem with SSH connections to regular IPv6 hosts (even transferring large files), either inbound or outbound.. Thanks, Stephen signature.asc Description: Digital signature
Re: whois.internic.net / whois.crsnic.net IPv6 timeouts
> Don't know if it'll help or if this is simply old news to most, but > the whois systems (whois.internic.net/whois.crsnic.net) have > records and happily answer TCP/43 requests w/ the usual blurb, but all > the servers I've hit then fail to actually provide data and instead > the whois client (Ubuntu 13.04) simply time-outs. "It works fine for me." I've had problems before and would guess that it's a routing issue. It my impression that they're anycasted. > Anyone from NetSol care? Since they haven't had anything to do with internic.net or crsnic.net for over a decade, probably not. R's, John
Re: whois.internic.net / whois.crsnic.net IPv6 timeouts
* Robert L Mathews (li...@tigertech.com) wrote: > These work for me on multiple IPv6 carriers, using both the Mac OS X and > Debian squeeze whois clients: Interesting.. > Perhaps your WHOIS client is choking on the first type of response > without the "="? WHOIS should work fine via telnet to eliminate possible > WHOIS client issues; you can just: It's Ubuntu 13.04's 5.0.20ubuntu1 client, so it really shouldn't be much different from the Debian whois you're using. Also, whois -h 199.7.50.74 networksolutions.com works just fine (and includes the blurb). > $ telnet 2001:503:5ae2:1060::74 43 > > ... and type "=networksolutions.com" to get the raw response. Doing this results in it just hanging, similar to with the whois client: sfrost@tamriel:/home/sfrost> telnet 2001:503:5ae2:1060::74 43 Trying 2001:503:5ae2:1060::74... Connected to 2001:503:5ae2:1060::74. Escape character is '^]'. =networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. [... hanging here, still ...] > > Anyone from NetSol care? > > Network Solutions hasn't been involved with the running of > whois.internic.net and whois.crsnic.net for many years. They're > currently run by VeriSign Global Registry Services. Ah, yea, good point. :) > > there's a Debian bug #683187 which mentions similar issues from > > nearly a year ago..). > > Right, but other people couldn't duplicate it. I suspect VeriSign uses > rate-limiting; is it possible that your source IP address is just being > rate-limited? It usually tells you that, actually, and so I doubt that's the case. Also, attempting from other IPv6 addresses results in the same hang (even with the telnet approach). Thanks! Stephen signature.asc Description: Digital signature
Re: google troubles?
On Wed, Jul 10, 2013 at 2:41 PM, Mike Jackson wrote: > Hey Chris, long time! > > From what I can tell, it's only Google Services (that I've found so far; > other things appear to resolve correctly). I'm wondering if they're > bouncing Google based traffic through some type of caching / accelerator? > Or maybe it's an NSA/DPI box ;) in .CA? :) don't you mean the meat-helmet-wearing CSE folks? :) > I've tested Maps, Gmail, Translate as well as www.google.com, www.google.ca > and they're all hijacked replies >> > yup... well, not hijacked in a bad sense... it's actually supposed to be making things better. > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > (www.google.com) > > Type escape sequence to abort. > Tracing the route to www.google.com (66.185.84.44) > > (www.google.ca) > > Type escape sequence to abort. > Tracing the route to www.google.ca (66.185.95.44) > > (gmail) > > Type escape sequence to abort. > Tracing the route to www3.l.google.com (66.185.85.39) > > (maps) > > Type escape sequence to abort. > Tracing the route to maps.l.google.com (64.71.249.114) > > (translate) > > Type escape sequence to abort. > Tracing the route to www3.l.google.com (66.185.84.30) those all seem properly done, yes. -chris
Re: google troubles?
On Wed, Jul 10, 2013 at 2:55 PM, Mike Jackson wrote: > That makes sense, I figured it was some type of a CDN caching environment. I forget that we do this at times... :) > I've found that youtube.com is in the same boat: > > Translating "www.youtube.com"...domain server (8.8.8.8) [OK] yup, so this makes sense as well... good.
Re: whois.internic.net / whois.crsnic.net IPv6 timeouts
On 7/10/13 11:45 AM, Stephen Frost wrote: > Don't know if it'll help or if this is simply old news to most, but > the whois systems (whois.internic.net/whois.crsnic.net) have > records and happily answer TCP/43 requests w/ the usual blurb, but all > the servers I've hit then fail to actually provide data and instead > the whois client (Ubuntu 13.04) simply time-outs. > > sfrost@tamriel:/home/sfrost> whois -h 2001:503:5ae2:1060::74 > networksolutions.com These work for me on multiple IPv6 carriers, using both the Mac OS X and Debian squeeze whois clients: $ whois -h 2001:503:5ae2:1060::74 networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. NETWORKSOLUTIONS.COM.RESPECTED.BY.WWW.DNDIALOG.COM NETWORKSOLUTIONS.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record. $ whois -h 2001:503:5ae2:1060::74 =networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Server Name: NETWORKSOLUTIONS.COM.RESPECTED.BY.WWW.DNDIALOG.COM IP Address: 81.177.3.240 Registrar: MONIKER ONLINE SERVICES LLC Whois Server: whois.moniker.com Referral URL: http://www.moniker.com Domain Name: NETWORKSOLUTIONS.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: NS1.NETSOL.COM Name Server: NS2.NETSOL.COM Name Server: NS3.NETSOL.COM [etc.] Perhaps your WHOIS client is choking on the first type of response without the "="? WHOIS should work fine via telnet to eliminate possible WHOIS client issues; you can just: $ telnet 2001:503:5ae2:1060::74 43 ... and type "=networksolutions.com" to get the raw response. > Anyone from NetSol care? Network Solutions hasn't been involved with the running of whois.internic.net and whois.crsnic.net for many years. They're currently run by VeriSign Global Registry Services. > there's a Debian bug #683187 which mentions similar issues from > nearly a year ago..). Right, but other people couldn't duplicate it. I suspect VeriSign uses rate-limiting; is it possible that your source IP address is just being rate-limited? -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
whois.internic.net / whois.crsnic.net IPv6 timeouts
All, Don't know if it'll help or if this is simply old news to most, but the whois systems (whois.internic.net/whois.crsnic.net) have records and happily answer TCP/43 requests w/ the usual blurb, but all the servers I've hit then fail to actually provide data and instead the whois client (Ubuntu 13.04) simply time-outs. sfrost@tamriel:/home/sfrost> whois -h 2001:503:5ae2:1060::74 networksolutions.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Timeout. Servers that I've tried so far (all IPv6 addresses I got through running 'host whois.crsnic.net'): 2001:503:5419:1060::74 2001:503:3227:1060::74 2001:503:6810:1060::74 2001:503:bfb0:1060::74 2001:500:30ff:1060::74 2001:503:7bbf:1060::74 2001:502:be98:1060::74 2001:502:8c25:1060::74 Anyone from NetSol care? It's not the end of the world, but it certainly is quite annoying.. Judging by some complaints on the 'net, looks to be a rather long-standing issue too (there's a Debian bug #683187 which mentions similar issues from nearly a year ago..). Thanks, Stephen signature.asc Description: Digital signature
Re: google troubles?
On Wed, Jul 10, 2013 at 2:18 PM, Christopher Morrow wrote: > On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: >> I just realized that it's not Google IP space (74.125.0.0/16), Rogers is >> hijacking the DNS and resolving www.google.com to space within >> 64.71.240.0/20 which is Rogers IP space! (note the name server set as >> 8.8.8.8) >> > > so: > 1) rogers is hijacking traffic to 8.8.8.8 > 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect > information for google properties (at least). > > err... any idea if it's lying about other things too? :) > oops, so a polite caller noted that google often ships people at a local 'google global cache' node if they have one... it seems like that might be what's going on here with 8.8.8.8 sending you to 64.71 and/or 66.185 addresses. so maybe rogers isn't doing something untoward after all! -chris (thanks for the headslap polite caller) >> davinci#traceroute www.google.com >> >> Translating "www.google.com"...domain server (8.8.8.8) [OK] >> >> Type escape sequence to abort. >> Tracing the route to www.google.com (66.185.85.29) >> >> 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec >> 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 >> msec 8 msec 4 msec >> 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec >> 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> >> TOR2-CORE-R1#show ip bgp 66.185.85.29 >> BGP routing table entry for 66.185.80.0/20, version 13095115 >> Paths: (1 available, best #1, table default) >> Advertised to update-groups: >> 14 >> 701 6461 812 >> 205.205.23.121 from 205.205.23.121 (137.39.8.42) >> Origin IGP, localpref 100, valid, external, best >> TOR2-CORE-R1# >> >> >> Thanks, >> >> - Mike >> >> >> On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: >> >>> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but >>> not from Rogers/AS812 in Toronto. I've done a few other test traceroutes >>> through Rogers to verify that they didn't filter UDP/ICMP. At this point >>> nothing would surprise me from Rogers. >>> >>> AS701 >>> = >>> >>> TOR2-CORE-R1#traceroute www.google.com >>> Translating "www.google.com"...domain server (8.8.8.8) [OK] >>> >>> Type escape sequence to abort. >>> Tracing the route to www.google.com (74.125.26.99) >>> VRF info: (vrf in name/id, vrf out name/id) >>> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec >>> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec >>> 4 msec >>> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec >>> 16 msec >>> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec >>> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec >>> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec >>> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec >>> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec >>> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec >>> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec >>> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec >>> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec >>> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec >>> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec >>> 9 216.239.48.159 [AS 15169] 36 msec 32 msec >>> 216.239.48.59 [AS 15169] 32 msec >>> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec >>> >>> >>> >>> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) >>> === >>> >>> *Query:* *tr 64.71.249.45* >>> >>> Type escape sequence to abort. >>> Tracing the route to 64.71.249.45 >>> >>> 1 64.71.255.62 0 msec 0 msec 0 msec >>> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 >>> msec 4 msec >>> 3 69.63.250.189 4 msec 4 msec 4 msec >>> 4 69.63.250.174 4 msec 4 msec 4 msec >>> 5 * * * >>> 6 * * * >>> 7 * * * >>> 8 * * * >>> 9 * * * >>> 10 * * * >>> 11 * * * >>> 12 * * * >>> 13 * * * >>> 14 * * * >>> 15 * * * >>> 16 * * * >>> 17 * * * >>> 18 * * * >>> 19 * * * >>> 20 * * * >>> 21 * * * >>> 22 * * * >>> 23 * * * >>> 24 * * * >>> 25 * * * >>> 26 * * * >>> 27 * * * >>> 28 * * * >>> 29 * * * >>> 30 * * * >>> >>> >>> Cheers, >>> >>> - MJ >>> >>> >>> -Original Message- From: Grant Ridder [mailto:shortdudey...@gmail.com] Sent: July-10-13 10:57 AM To: John York Cc: nanog@nanog.org Subject: Re: google troubles? Does anyone have traceroutes showing where the issues are? -Grant On Wed, Jul 10, 2013 at 7:45 AM, John York wrote: > We saw the same thing, but seems to be cleared up now. All our
Diverse sub-sea carrier links London / Tokyo
I'm looking for a diverse carrier circuits to/from the following POP's over different sub-sea links. I'm not too comfortable getting diverse path(s) from the same carrier (Hibernia) so I'm interested in getting input from others who have dealt with other carriers in these locations who can offer connectivity over different sub-sea links than my current provider. 755 Secaucus-350 Cermak-Seattle-*PC1 Cable*-Ajigaura-TY3 (Equinix) 755 Secaucus-300 Blvd-111 8th-*AC1 Standard*-Slough-Telehouse North-London Hosting Center (Savvis) Sorry if this is off-list. --RB
Re: google troubles?
On Wed, Jul 10, 2013 at 12:20 PM, Mike Jackson wrote: > I just realized that it's not Google IP space (74.125.0.0/16), Rogers is > hijacking the DNS and resolving www.google.com to space within > 64.71.240.0/20 which is Rogers IP space! (note the name server set as > 8.8.8.8) > so: 1) rogers is hijacking traffic to 8.8.8.8 2) the copy of 8.8.8.8 in rogers-land is replying with incorrect information for google properties (at least). err... any idea if it's lying about other things too? :) > davinci#traceroute www.google.com > > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > Type escape sequence to abort. > Tracing the route to www.google.com (66.185.85.29) > > 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec > 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 > msec 8 msec 4 msec > 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec > 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > TOR2-CORE-R1#show ip bgp 66.185.85.29 > BGP routing table entry for 66.185.80.0/20, version 13095115 > Paths: (1 available, best #1, table default) > Advertised to update-groups: > 14 > 701 6461 812 > 205.205.23.121 from 205.205.23.121 (137.39.8.42) > Origin IGP, localpref 100, valid, external, best > TOR2-CORE-R1# > > > Thanks, > > - Mike > > > On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > >> I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but >> not from Rogers/AS812 in Toronto. I've done a few other test traceroutes >> through Rogers to verify that they didn't filter UDP/ICMP. At this point >> nothing would surprise me from Rogers. >> >> AS701 >> = >> >> TOR2-CORE-R1#traceroute www.google.com >> Translating "www.google.com"...domain server (8.8.8.8) [OK] >> >> Type escape sequence to abort. >> Tracing the route to www.google.com (74.125.26.99) >> VRF info: (vrf in name/id, vrf out name/id) >> 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec >> 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec >> 4 msec >> 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec >> 16 msec >> 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec >> TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec >> TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec >> 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec >> 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec >> 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec >> 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec >> 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec >> 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec >> 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec >> 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec >> 9 216.239.48.159 [AS 15169] 36 msec 32 msec >> 216.239.48.59 [AS 15169] 32 msec >> 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec >> >> >> >> AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) >> === >> >> *Query:* *tr 64.71.249.45* >> >> Type escape sequence to abort. >> Tracing the route to 64.71.249.45 >> >> 1 64.71.255.62 0 msec 0 msec 0 msec >> 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec >> 4 msec >> 3 69.63.250.189 4 msec 4 msec 4 msec >> 4 69.63.250.174 4 msec 4 msec 4 msec >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> 11 * * * >> 12 * * * >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 * * * >> 29 * * * >> 30 * * * >> >> >> Cheers, >> >> - MJ >> >> >> -Original Message- >>> From: Grant Ridder [mailto:shortdudey...@gmail.com] >>> Sent: July-10-13 10:57 AM >>> To: John York >>> Cc: nanog@nanog.org >>> Subject: Re: google troubles? >>> >>> Does anyone have traceroutes showing where the issues are? >>> >>> -Grant >>> >>> On Wed, Jul 10, 2013 at 7:45 AM, John York >>> wrote: >>> >>> > We saw the same thing, but seems to be cleared up now. All our >>> > providers that routed to Google addresses in ATL had the issue. We >>> > have one provider that lands on Google addresses in DFW, and it was >>> working. >>> > >>> > ...And now I see that it isn't completely resolved. Some Google apps >>> > are still inaccessible via the Atlanta routes. >>> > >>> > >>> > >>> > >>> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >>> > >> > >wrote: >>> > >>> > > Seeing lots of reports of people unable to get to many Google >>> services. >>> > > Seems to be affecting Comcast users disproportionately. It's
Re: google troubles?
I just realized that it's not Google IP space (74.125.0.0/16), Rogers is hijacking the DNS and resolving www.google.com to space within 64.71.240.0/20 which is Rogers IP space! (note the name server set as 8.8.8.8) davinci#traceroute www.google.com Translating "www.google.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to www.google.com (66.185.85.29) 1 x.x.x.x [AS 812] 4 msec 4 msec 4 msec 2 so-4-0-2.gw02.ym.phub.net.cable.rogers.com (66.185.82.129) [AS 812] 8 msec 8 msec 4 msec 3 69.63.252.222 [AS 812] 4 msec 0 msec 8 msec 4 69.63.250.162 [AS 812] 4 msec 4 msec 4 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * TOR2-CORE-R1#show ip bgp 66.185.85.29 BGP routing table entry for 66.185.80.0/20, version 13095115 Paths: (1 available, best #1, table default) Advertised to update-groups: 14 701 6461 812 205.205.23.121 from 205.205.23.121 (137.39.8.42) Origin IGP, localpref 100, valid, external, best TOR2-CORE-R1# Thanks, - Mike On Wed, Jul 10, 2013 at 11:28 AM, Mike Jackson wrote: > I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but > not from Rogers/AS812 in Toronto. I've done a few other test traceroutes > through Rogers to verify that they didn't filter UDP/ICMP. At this point > nothing would surprise me from Rogers. > > AS701 > = > > TOR2-CORE-R1#traceroute www.google.com > Translating "www.google.com"...domain server (8.8.8.8) [OK] > > Type escape sequence to abort. > Tracing the route to www.google.com (74.125.26.99) > VRF info: (vrf in name/id, vrf out name/id) > 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec > 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec > 4 msec > 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec > 16 msec > 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec > TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec > TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec > 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec > 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec > 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec > 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec > 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec > 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec > 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec > 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec > 9 216.239.48.159 [AS 15169] 36 msec 32 msec > 216.239.48.59 [AS 15169] 32 msec > 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec > > > > AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) > === > > *Query:* *tr 64.71.249.45* > > Type escape sequence to abort. > Tracing the route to 64.71.249.45 > > 1 64.71.255.62 0 msec 0 msec 0 msec > 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec > 4 msec > 3 69.63.250.189 4 msec 4 msec 4 msec > 4 69.63.250.174 4 msec 4 msec 4 msec > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Cheers, > > - MJ > > > -Original Message- >> From: Grant Ridder [mailto:shortdudey...@gmail.com] >> Sent: July-10-13 10:57 AM >> To: John York >> Cc: nanog@nanog.org >> Subject: Re: google troubles? >> >> Does anyone have traceroutes showing where the issues are? >> >> -Grant >> >> On Wed, Jul 10, 2013 at 7:45 AM, John York >> wrote: >> >> > We saw the same thing, but seems to be cleared up now. All our >> > providers that routed to Google addresses in ATL had the issue. We >> > have one provider that lands on Google addresses in DFW, and it was >> working. >> > >> > ...And now I see that it isn't completely resolved. Some Google apps >> > are still inaccessible via the Atlanta routes. >> > >> > >> > >> > >> > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >> > > > >wrote: >> > >> > > Seeing lots of reports of people unable to get to many Google >> services. >> > > Seems to be affecting Comcast users disproportionately. It's fine >> > > for >> > me, >> > > but a lot of my staff are basically out of luck...but according to >> > > the Google Apps Status page, everything is fine. >> > > >> > > It's anecdotal, but it would seem like there's an issue based on >> > > these reports. >> > > >> > > Oh, and this: >> > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html >> > > >> > > Anyone know what's up? Fiber cut? DC outages? >> > > >> > > -- blair >> > > >> > >> > >> >
google troubles?
I can see the Google IP space (64.71.240.0/20) from Verizon/AS701, but not from Rogers/AS812 in Toronto. I've done a few other test traceroutes through Rogers to verify that they didn't filter UDP/ICMP. At this point nothing would surprise me from Rogers. AS701 = TOR2-CORE-R1#traceroute www.google.com Translating "www.google.com"...domain server (8.8.8.8) [OK] Type escape sequence to abort. Tracing the route to www.google.com (74.125.26.99) VRF info: (vrf in name/id, vrf out name/id) 1 x.x.x.x [AS701] 4 msec 0 msec 0 msec 2 0.ge-11-0-0.XT4.TOR2.ALTER.NET (152.63.133.78) [AS 701] 4 msec 0 msec 4 msec 3 0.so-4-0-3.XT2.NYC4.ALTER.NET (152.63.0.73) [AS 701] 16 msec 16 msec 16 msec 4 TenGigE0-7-1-0.GW8.NYC4.ALTER.NET (152.63.21.125) [AS 701] 20 msec TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73) [AS 701] 16 msec TenGigE0-5-4-0.GW8.NYC4.ALTER.NET (152.63.18.206) [AS 701] 20 msec 5 72.14.238.232 [AS 15169] 16 msec 16 msec 20 msec 6 72.14.236.208 [AS 15169] [MPLS: Label 680976 Exp 4] 16 msec 16 msec 72.14.236.206 [AS 15169] [MPLS: Label 533197 Exp 4] 20 msec 7 209.85.249.11 [AS 15169] [MPLS: Label 16668 Exp 4] 24 msec 72.14.239.93 [AS 15169] [MPLS: Label 14644 Exp 4] 24 msec 209.85.249.11 [AS 15169] [MPLS: Label 13978 Exp 4] 24 msec 8 209.85.243.114 [AS 15169] [MPLS: Label 568789 Exp 4] 32 msec 209.85.241.222 [AS 15169] [MPLS: Label 632535 Exp 4] 32 msec 32 msec 9 216.239.48.159 [AS 15169] 36 msec 32 msec 216.239.48.59 [AS 15169] 32 msec 10 www.google.com (74.125.26.147) [AS 15169] 32 msec 32 msec 32 msec AS812 (Rogers Looking Glass https://supernoc.rogerstelecom.net/lg/) === *Query:* *tr 64.71.249.45* Type escape sequence to abort. Tracing the route to 64.71.249.45 1 64.71.255.62 0 msec 0 msec 0 msec 2 ge-4-3-0.gw02.ym.phub.net.cable.ROGERS.com (66.185.82.237) 4 msec 4 msec 4 msec 3 69.63.250.189 4 msec 4 msec 4 msec 4 69.63.250.174 4 msec 4 msec 4 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Cheers, - MJ -Original Message- > From: Grant Ridder [mailto:shortdudey...@gmail.com] > Sent: July-10-13 10:57 AM > To: John York > Cc: nanog@nanog.org > Subject: Re: google troubles? > > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York > wrote: > > > We saw the same thing, but seems to be cleared up now. All our > > providers that routed to Google addresses in ATL had the issue. We > > have one provider that lands on Google addresses in DFW, and it was > working. > > > > ...And now I see that it isn't completely resolved. Some Google apps > > are still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > > > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google > services. > > > Seems to be affecting Comcast users disproportionately. It's fine > > > for > > me, > > > but a lot of my staff are basically out of luck...but according to > > > the Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on > > > these reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > > > > >
Re: google troubles?
tcptraceroutes working fine too? On Wed, Jul 10, 2013 at 8:16 AM, Milt Aitken wrote: > We (were) peered with Google in Atlanta. > We were unable to bring up web pages for google.com or gmail.com. > Traceroute worked, though. > I shut off the peering & my outbound route switched to Cogent, which > works now. > > I'll try peering again tonight. Maybe they'll have fixed it by then. > > -Original Message- > From: N. Max Pierson [mailto:nmaxpier...@gmail.com] > Sent: Wednesday, July 10, 2013 11:00 AM > To: Grant Ridder > Cc: nanog@nanog.org > Subject: Re: google troubles? > > Traceroutes worked fine for me during the outage. Seems to have been > something at L4-L7. > > -- > max > > On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder > wrote: > > > Does anyone have traceroutes showing where the issues are? > > > > -Grant > > > > On Wed, Jul 10, 2013 at 7:45 AM, John York > > >wrote: > > > > > We saw the same thing, but seems to be cleared up now. All our > providers > > > that routed to Google addresses in ATL had the issue. We have one > > provider > > > that lands on Google addresses in DFW, and it was working. > > > > > > ...And now I see that it isn't completely resolved. Some Google apps > are > > > still inaccessible via the Atlanta routes. > > > > > > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > > > >wrote: > > > > > > > Seeing lots of reports of people unable to get to many Google > services. > > > > Seems to be affecting Comcast users disproportionately. It's > fine for > > > me, > > > > but a lot of my staff are basically out of luck...but according to > the > > > > Google Apps Status page, everything is fine. > > > > > > > > It's anecdotal, but it would seem like there's an issue based on > these > > > > reports. > > > > > > > > Oh, and this: > > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > > > -- blair > > > > > > > > > > > > > > > > -- > > > > > > John York > > > > > > Information Technology | Network Administrator > > > > > > Phone: 615-399-7000 x:333 > > > > > > Griffin Technology > > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > > > This message and any attachments should be treated as confidential > > > information of Griffin Technology, Inc. > > > > > >
RE: google troubles?
We (were) peered with Google in Atlanta. We were unable to bring up web pages for google.com or gmail.com. Traceroute worked, though. I shut off the peering & my outbound route switched to Cogent, which works now. I'll try peering again tonight. Maybe they'll have fixed it by then. -Original Message- From: N. Max Pierson [mailto:nmaxpier...@gmail.com] Sent: Wednesday, July 10, 2013 11:00 AM To: Grant Ridder Cc: nanog@nanog.org Subject: Re: google troubles? Traceroutes worked fine for me during the outage. Seems to have been something at L4-L7. -- max On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder wrote: > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York >wrote: > > > We saw the same thing, but seems to be cleared up now. All our providers > > that routed to Google addresses in ATL had the issue. We have one > provider > > that lands on Google addresses in DFW, and it was working. > > > > ...And now I see that it isn't completely resolved. Some Google apps are > > still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google services. > > > Seems to be affecting Comcast users disproportionately. It's fine for > > me, > > > but a lot of my staff are basically out of luck...but according to the > > > Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on these > > > reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > >
Re: www.att.net ipv6 traceroute
On Mon, Jul 01, 2013 at 04:18:51PM -0400, Jay Borkenhagen wrote: > David Hill writes: > > Anyone else noticing odd ipv6 traceroutes to www.att.net > > (2001:1890:1c01:2::40)? > > > > David, > > We see what's going on. It currently affects only a portion of the v6 > Internet. Working on a fix... > > Jay B. > > Jay - Any update? David pgpLNlC9n6d1Q.pgp Description: PGP signature
Re: google troubles?
Traceroutes worked fine for me during the outage. Seems to have been something at L4-L7. -- max On Wed, Jul 10, 2013 at 9:56 AM, Grant Ridder wrote: > Does anyone have traceroutes showing where the issues are? > > -Grant > > On Wed, Jul 10, 2013 at 7:45 AM, John York >wrote: > > > We saw the same thing, but seems to be cleared up now. All our providers > > that routed to Google addresses in ATL had the issue. We have one > provider > > that lands on Google addresses in DFW, and it was working. > > > > ...And now I see that it isn't completely resolved. Some Google apps are > > still inaccessible via the Atlanta routes. > > > > > > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper > >wrote: > > > > > Seeing lots of reports of people unable to get to many Google services. > > > Seems to be affecting Comcast users disproportionately. It's fine for > > me, > > > but a lot of my staff are basically out of luck...but according to the > > > Google Apps Status page, everything is fine. > > > > > > It's anecdotal, but it would seem like there's an issue based on these > > > reports. > > > > > > Oh, and this: > > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > > > Anyone know what's up? Fiber cut? DC outages? > > > > > > -- blair > > > > > > > > > > > -- > > > > John York > > > > Information Technology | Network Administrator > > > > Phone: 615-399-7000 x:333 > > > > Griffin Technology > > 2030 Lindell Avenue Nashville, TN 37203 USA > > > > This message and any attachments should be treated as confidential > > information of Griffin Technology, Inc. > > >
Re: google troubles?
Does anyone have traceroutes showing where the issues are? -Grant On Wed, Jul 10, 2013 at 7:45 AM, John York wrote: > We saw the same thing, but seems to be cleared up now. All our providers > that routed to Google addresses in ATL had the issue. We have one provider > that lands on Google addresses in DFW, and it was working. > > ...And now I see that it isn't completely resolved. Some Google apps are > still inaccessible via the Atlanta routes. > > > > > On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper >wrote: > > > Seeing lots of reports of people unable to get to many Google services. > > Seems to be affecting Comcast users disproportionately. It's fine for > me, > > but a lot of my staff are basically out of luck...but according to the > > Google Apps Status page, everything is fine. > > > > It's anecdotal, but it would seem like there's an issue based on these > > reports. > > > > Oh, and this: > > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > > > Anyone know what's up? Fiber cut? DC outages? > > > > -- blair > > > > > > -- > > John York > > Information Technology | Network Administrator > > Phone: 615-399-7000 x:333 > > Griffin Technology > 2030 Lindell Avenue Nashville, TN 37203 USA > > This message and any attachments should be treated as confidential > information of Griffin Technology, Inc. >
Re: google troubles?
We saw the same thing, but seems to be cleared up now. All our providers that routed to Google addresses in ATL had the issue. We have one provider that lands on Google addresses in DFW, and it was working. ...And now I see that it isn't completely resolved. Some Google apps are still inaccessible via the Atlanta routes. On Wed, Jul 10, 2013 at 9:28 AM, Blair Trosper wrote: > Seeing lots of reports of people unable to get to many Google services. > Seems to be affecting Comcast users disproportionately. It's fine for me, > but a lot of my staff are basically out of luck...but according to the > Google Apps Status page, everything is fine. > > It's anecdotal, but it would seem like there's an issue based on these > reports. > > Oh, and this: > http://www.cnn.com/2013/07/10/tech/web/google-down/index.html > > Anyone know what's up? Fiber cut? DC outages? > > -- blair > -- John York Information Technology | Network Administrator Phone: 615-399-7000 x:333 Griffin Technology 2030 Lindell Avenue Nashville, TN 37203 USA This message and any attachments should be treated as confidential information of Griffin Technology, Inc.
RE: google troubles?
I did have connectivity issues for mobile devices this AM between 8:00am-10:00am EST. I am in NE Ohio. Seems to be resolved now. -Original Message- From: Blair Trosper [mailto:blair.tros...@gmail.com] Sent: Wednesday, July 10, 2013 10:28 AM To: nanog@nanog.org Subject: google troubles? Seeing lots of reports of people unable to get to many Google services. Seems to be affecting Comcast users disproportionately. It's fine for me, but a lot of my staff are basically out of luck...but according to the Google Apps Status page, everything is fine. It's anecdotal, but it would seem like there's an issue based on these reports. Oh, and this: http://www.cnn.com/2013/07/10/tech/web/google-down/index.html Anyone know what's up? Fiber cut? DC outages? -- blair
RE: What to expect after a cooling failure
This has been a very interesting thread. Google pointed me to this Dell document which specs some of their servers having an expanded operating temperature range *** based on the amount of time spent at the elevated temperature, as a percentage of annual operating hours. *** ftp://ftp.dell.com/Manuals/all-products/esuprt_ser_stor_net/esuprt_poweredge/poweredge-r710_User%27s%20Guide4_en-us.pdf I mention that because the "1% of annual operating hours" at 45 C would be two degrees higher than the 43 C stated as reached in the original email. It would seem that Dell recognizes that there might be situations, such as this, where the "continuous operation" range (35 C) is briefly exceeded. Tony Patti CIO S. Walter Packaging Corp. -Original Message- From: Erik Levinson [mailto:erik.levin...@uberflip.com] Sent: Tuesday, July 09, 2013 11:28 PM To: NANOG mailing list Subject: What to expect after a cooling failure As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com
google troubles?
Seeing lots of reports of people unable to get to many Google services. Seems to be affecting Comcast users disproportionately. It's fine for me, but a lot of my staff are basically out of luck...but according to the Google Apps Status page, everything is fine. It's anecdotal, but it would seem like there's an issue based on these reports. Oh, and this: http://www.cnn.com/2013/07/10/tech/web/google-down/index.html Anyone know what's up? Fiber cut? DC outages? -- blair
Re: What to expect after a cooling failure
Another failure I've seen connected to overheating events is AC power supply failures. On 07/09/2013 10:28 PM, Erik Levinson wrote: As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com
RE: What to expect after a cooling failure
Ugly. If the batteries that were in the facility's power distribution system were affected by the heat, then their life is likely significantly shortened. This is in terms of their capacity to supply power in the event of an outage and a shortened shelf life. Lorell On Jul 9, 2013, at 8:28 PM, "Erik Levinson" wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much longer and some of our gear shutdown automatically due to overheating. We shut down remotely many redundant and non-essential systems in the hotter suite, and transferred remotely some others to the cooler suite, to ensure that we had a minimum of all core systems running in the hotter suite. We waited until the temperatures returned to normal, and brought everything back online. The entire event lasted from approx 18:45 until 01:15. Apparently ambient temperature was above 43 degrees Celcius at one point on the cool side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one expect in terms of long-term impact...should we expect some premature component failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > >
Re: What to expect after a cooling failure
Numbers from memory and filed off a bit for anonymity, but A site I was consulting with had statistically large numbers of x86 servers (say, 3000), SPARC enterprise gear (100), NetApp units (60) and NetApp drives (5000+) go through a roughly 42C excursion. It was much hotter at ceiling level but fortunately high (20 foot) ceilings. Within about 1C of the (wet pipes) sprinkler system head fuse temp... (shudder) Both NetApp and X86 server PSUs had significantly increased failure rates for the next year. Say in rough numbers 10% failed in the year. About 2% were instant fails. Hard drives had a significantly higher fail rate for the next year, also in the 10% range. No change in rate of motherboard or CPU or RAM failures was noted that I recall. George William Herbert Sent from my iPhone On Jul 9, 2013, at 8:28 PM, "Erik Levinson" wrote: > As some may know, yesterday 151 Front St suffered a cooling failure after > Enwave's facilities were flooded. > > One of the suites that we're in recovered quickly but the other took much > longer and some of our gear shutdown automatically due to overheating. We > shut down remotely many redundant and non-essential systems in the hotter > suite, and transferred remotely some others to the cooler suite, to ensure > that we had a minimum of all core systems running in the hotter suite. We > waited until the temperatures returned to normal, and brought everything back > online. The entire event lasted from approx 18:45 until 01:15. Apparently > ambient temperature was above 43 degrees Celcius at one point on the cool > side of cabinets in the hotter suite. > > For those who have gone through such events in the past, what can one expect > in terms of long-term impact...should we expect some premature component > failures? Does anyone have any stats to share? > > Thanks > > -- > Erik Levinson > CTO, Uberflip > 416-900-3830 > 1183 King Street West, Suite 100 > Toronto ON M6K 3C5 > www.uberflip.com > > >
