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
problem
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](~):
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, T
* 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 a
> 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 c
* 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 eli
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 / accelerato
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 t
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 a
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
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 spa
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
co
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
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.
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
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
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
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 fi
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 sa
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 addre
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
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?
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/
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
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
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, "
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
lev
27 matches
Mail list logo
