[c-nsp] Weird Traceroute Issue to Specific Destination

Paul Stewart paul at paulstewart.org
Tue Sep 21 09:54:01 EDT 2010


Hi folks..

 

We have a customer who is connected over DSL who is having issues getting to
a certain remote site more often than not.  Sometime they can reach this
site, but most of the time they cannot.

 

They connect to a 7206VXR, which then connects to a 6509 which then
connections to 6509, 6509, then 7606 out to Internet.  Long story short,
there is no reported issues along this connectivity at all and we can only
replicate this complaint to one remote IP address.  Logically, we would push
this back and say "not our problem" which we're confident it's not *but*
there's one strange thing that is bugging me and I can't put logic around
this (I also have a terrible head cold and not thinking straight).

 

When logged into the 7206VXR where the customer connects via DSL, a
traceroute to the Internet loops normally like this:

 

acs1-con-bb#traceroute www.cnn.com

Translating "www.cnn.com"...domain server (208.67.222.222) [OK]

 

Type escape sequence to abort.

Tracing the route to www.cnn.com (157.166.224.26)

 

  1 xx.xxx.7.65 0 msec 0 msec 0 msec

  2 xx.xx.120.25 8 msec 8 msec 8 msec

  3 core2-rtr-to-ge4-12-vl4.nexicom.net (98.124.0.226) 20 msec 16 msec 88
msec

  4 ge4-0-0.core1.toronto1.nexicom.net (98.124.59.17) 16 msec 20 msec 16
msec

  5 ge-6-1-113.car1.Toronto2.Level3.net (4.59.180.9) 156 msec 176 msec 88
msec

  6 ae-8-8.ebr1.Chicago1.Level3.net (4.69.140.245) 32 msec 32 msec 32 msec

  7 ae-1-100.ebr2.Chicago1.Level3.net (4.69.132.42) 32 msec 28 msec 32 msec

  8 ae-3-3.ebr2.Atlanta2.Level3.net (4.69.132.74) 52 msec 52 msec 72 msec

  9 ae-2-52.edge4.Atlanta2.Level3.net (4.68.103.46) 52 msec 56 msec

    ae-1-51.edge4.Atlanta2.Level3.net (4.68.103.14) 48 msec

 10  *  *

 

 

With this problem destination IP, our traceroutes look like this:

 

acs1-con-bb#traceroute xx.xxx.2.226

 

Type escape sequence to abort.

Tracing the route to xxx.xxx.xxx (xx.xxx.2.226)

 

  1 xx.xxx.7.65 0 msec 0 msec 0 msec

  2  *  *  *

  3  *  *  *

  4  *  *  *

  

 

So, normally with all "*" it would indicate simply that the route is
unreachable. but that's the part that has me puzzled.  The route is
reachable across the Internet *and* at the very least, I should see a
traceroute going to the fourth hop no matter what.  We run OSPF across these
links and have a "default-originate" statement on the 4th hop router.  This
is confirmed via the routing table entry for 0.0.0.0

 

So what makes this particular destination IP act differently than any other
within our IGP is my question??

 

Cheers,

 

Paul

 



More information about the cisco-nsp mailing list