We're experiencing very poor quality with You Tube, and it appears we're
subject to a bad entry within a geolocation database somewhere.
When we attempt to view videos, the contact comes back to us from IPs like:
208.117.226.21 (traceroute's through Frankfurt)
173.194.50.47
74.125.100.29
All of those IPs are >125ms away from us (67.217.144.0/20, and
216.14.144.0/20).
However, we've never experienced redirection problems with Google before
(we always land at www.google.com), so I'm not sure where to take our
trouble. The page at:
http://www.google.com/support/websearch/bin/request.py?contact_type=ip
isn't of much help as it assumes the problem is google.com redirection.
Are there any contacts at Youtube who could provide some assistance?
Thanks,
I have had this same problem, followed Google's forms, etc... they never
seem to fix it. Its really annoying.
This is an epic fail on the part of Google in my opinion. My netblocks all
show Seattle in whois... my routing is obviously here... I don't think we
have an official address in the UK listed on anything.
How does Google get this information? Why don't they possibly ever do
anything about it? It makes Google's properties perform abysmally to a
large percentage of our customer base. And then we get blamed for it.
And Google does nothing, even after submitting the web form that clearly
states that they will not get back to us about it but will try to resolve
the issue. Its quite hideous really. Its in everyone's worst interest. How
about maybe trusting my whois data? If whois data leads to incorrect
results then it is in the netblock owners' best interest to update the whois
data if they want to be directed efficiently with gslb/etc that uses whois
data as the source.
And I've been working with ip-geo stuff for years... I understand that a
lot of effort has gone into making it "better" than the whois data... but
every other freaking IP geolocator I type my IP into properly recognizes the
addresses are in Seattle... why not Google?
Anyway, I at the very least commiserate with you if I'm not perhaps making
some passive-aggressive cry for help from Google or anyone else with a clue
bat about this issue. 
Thanks!
--C
I don't know what Google uses but any company using F5 equipment is using Quova geolocation services. You can request updates and check your circuit here:
http://www.quova.com/what/request-ip-update/
The problem is that the F5 devices don't update the database files automatically, they need to be manually updated. Unless I get a specific request at my company I don't bother updating on a regular basis.
-Mike
Quova, Maxmind, and others all return accurate results for everything of
ours I have tested. Some of the IPs in question have been properly assigned
or delegated to us for several years in whois. But yeah, thanks for the
input... I actually hadn't checked Quova until now. Perhaps Google rolls
their own...
--Carl
Quova, Maxmind, and others all return accurate results for everything of
ours I have tested. Some of the IPs in question have been properly assigned
or delegated to us for several years in whois. But yeah, thanks for the
input... I actually hadn't checked Quova until now. Perhaps Google rolls
their own...
I'll have to re-echo your experience, which doesn't bode well for our
chances.
The link below returns accurate information for me too. Our blocks have
been in use for years and we have not experienced even a hint of
geolocation related problems before.
Direct peering would be our ideal solution to this problem, but Google
doesn't appear to play in our smaller market.
I had a similar issue, but it was mainly only over IPv6. According to
someone I spoke to at Google, bumping up the MTU might help (and did
help for me). I don't remember my previous MTU (I think it was 1280),
but once I bumped it up to 1480 or so, my packets stopped getting routed
to Europe (from NY) and worked properly. Maybe a similar issue could be
with their IPv4 routers? Try increasing the MTU.
how has mtu got anything to do with packet path?
-chris
that won't change the destination based routed path, it'll cause the
endpoints to lower their MTU to a mutually agreeable threshold. The
packets will still flow along the same path.
(besides pmtud brings the mtu down, not up... the proposal was to raise the mtu)
-chris
We're experiencing very poor quality with You Tube, and it appears we're
subject to a bad entry within a geolocation database somewhere.
I'm not sure about Youtube, but Google seems to do some some clever but
annoying things with correlating requests going through a recursive
nameserver with the location of those browsers. If a bunch of browsers in
Atlanta use a recursive nameserver in Los Angeles, Google after a while
seems to start offering that nameserver Google server IPs close to Atlanta
to give back to its clients.
This internet draft might be part of a related work:
http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00
When we attempt to view videos, the contact comes back to us from IPs like:
I ran into this problem while running a Tor exit node (which seems to
terribly screw with this mechanism) and played with it for a while. I found
my nameserver being offered Google server IPs all over the globe; one week
it would be London, the next week Germany, then New York, etc.
My problem was first solved by changing my browser to use recursive
nameservers in a different /24 (changing the last octet didn't seem to help)
and later by changing Tor itself to use Google's own 8.8.8.8 nameservers,
which caused the problem to go away for other clients of my nameserver.
Try using nameservers on a different /24 and see if the problem goes away.
-- Aaron
Aaron Hopkins wrote:
Try using nameservers on a different /24 and see if the problem goes
away.
-- Aaron
That's a good point. We've worked with Akamai in the past. Their CDN
solution works via DNS resolution. If your DNS servers are in Kansas,
you'll get the Akamai servers close to Kansas - whether you're there or
not. Akamai uses a combination of GeoIP and network operator contributed
IP ranges. For example, if you have an Akamai cache on your network, you
specifically tell Akamai what IP ranges should be served from that cache
- it doesn't seem to matter if these IP addresses belong to you or not.
I'm not sure how they deal with overlap.
--Blake