Home page logo

nanog logo nanog mailing list archives

RE: Cogent --> Google Public DNS routing issue
From: "Dennis Burgess" <dmburgess () linktechs net>
Date: Wed, 17 Aug 2011 11:27:35 -0500

The .129 is our peer to cogent, it just drops the traffic now..

Tracing route to google-public-dns-a.google.com []
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms
  2     1 ms     1 ms     1 ms
  3  reports: Destination host unreachable.

Trace complete.

Dennis Burgess, Mikrotik Certified Trainer 
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net
LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"

-----Original Message-----
From: David Miller [mailto:dmiller () tiggee com]
Sent: Wednesday, August 17, 2011 11:02 AM
To: nanog () nanog org
Subject: Re: Cogent --> Google Public DNS routing issue

On 8/17/2011 9:13 AM, Patrick W. Gilmore wrote:
On Aug 17, 2011, at 1:07 AM, Christopher Morrow wrote:
On Wed, Aug 17, 2011 at 12:09 AM, Robert Glover<robertg () garlic com>

We have noticed that from our Cogent link (as well as from ALL
based points we tested via the Cogent Looking Glass:
http://www.cogentco.com/en/network/looking-glass), traceroutes to and all seem to go over to Europe: ain't the driods you are looking for...
In the traceroute appended to the original post, he did trace to

While it did go all over, I don't see the problem - it got to the

Anycast is OK for some things, but it depends on BGP.  BGP has zero
concept of latency, loss, or geography.  Expecting anycast to
guarantee an
optimal path or location is a grave error.

There are two basic types of anycast:
1. Simple anycast - announce an anycast prefix to whoever/wherever in
more than one location.
2. Global anycast + careful configuration - announce an anycast prefix
particular providers at specific geographically disparate locations
and using
other options to achieve geographic and/or performant inbound traffic

Perhaps we need a new term for 2.

Google is clearly attempting to implement 2 and not 1 for their
resolving DNS
service.  Based on Google's claims of speed (and my testing of their
times), they have either found a way to exceed the speed of light with
packets or they are managing to keep most of their traffic "local ish"
to the

To say that anycast "relies on BGP" and therefore expecting an optimal
is an error - is disengenuous (I want a better word, but this one will
do).  The
internet as a whole "relies on BGP" and yet we expect mostly optimal
While it is true that BGP has no capacity to account for latency or
loss, IGPs
which can take into account these factors end at the borders of
(where prefixes are passed using BGP).  This is what makes up the

If you were tracing from a host in Ashburn to a unicast host in NYC
and your
path passed through San Jose, then you would say that was an issue.
same would be true with an anycast destination address.

As to geography, IGPs don't have a concept of geography either.  A
router in
NYC doesn't know or care that the router at the other end of a link is
in CHI.
All it knows is the prefixes that it gets from that router and metrics
to choose
a best path for them.  BGP combined with "proper" (i.e. distributed)
of networks does provide performant paths for traffic.  In an anycast
configuration the "careful configuration" is selecting providers to
anycast prefixes to and communities that you put on the prefixes to
Global anycast + careful configuration can and does provide mostly
performant paths and a very high level of geographic fidelity -
granted, not "guaranteed" (at least not guaranteed at a higher level
unicast prefixes).

You can't "guarantee" performant paths ever (regardless of anycast or
unicast) if any path between the source and destination crosses the
between two networks because some networks will choose a "primary"
upstream (single homed or heavily pref'ed) that only picks up a prefix
in a
particular area and sends all of the traffic there.  The originator of
the prefix
can depref that provider to try to influence path selection, but some
networks will doggedly prefer to send packets to that network despite
efforts of the originator.  The only thing to do then is to ask why
this network
selected that particular upstream and then to explain to them why that
not have been the best choice, if they want performant paths...

The possible reasons for this are nearly innumerable.  Perhaps
Google is congested in the US so one or the other prefers EU?  Perhaps
is some IGP metric messed up inside Cogent that prefers the EU?
more nefarious problems, such as Google de-peering Cogent in the US?

You may be able to find out if you look, and you may not (I didn't
even try).
But even if you do figure out the answer, you can't fix it.  Only
Cogent and/or
Google can.

My traces show all the Cogent locations in the US that I traced from
going to
Telia in EU and then to Google.

My traces from Telia locations in the US all (properly) reach Google
destinations in the US.

So, Cogent is only receiving/using/preferring these two prefixes from
peering(s) with Telia in EU.

As to the root cause of that... only the players in that game can say.

Moreover, you can see things like this with anycast even when there
is no

The OP believes that it is a problem.  You *can* see this with
anycast, but I
would say that this *is* a "problem" (for my definition of "problem"
admittedly may be different from others).  There are many potential
solutions to the problem, the most obvious is for the OP to stop
preferring to
send traffic to these prefixes over Cogent.

To the OP: I have to wonder what factors were used to decide "primary"
vs "backup" provider.  If "price", then you should expect issues with
performant routing.  If "quality", then what measures were used to
determine a "quality" ranking?  I am also curious as to who the
is (but that is just morbid curiousity).


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]