[c-nsp] Weird Traceroute Issue to Specific Destination

Tue Sep 21 11:37:41 EDT 2010

Thank you - the customer is reporting that they cannot reach a particular
remote website.  The closest visibility we have is the 7206VXR and 6500
physically in the same town - in that town we also have access to a customer
network.  On that customer network (fiber fed) they are unable to reach this
website neither.

That location connects back to our location where we can always reach this
website.  I have checked each hop along the way and cannot find any null
routes etc that would be blocking this traffic.

So my question is really to confirm - even if the remote site that is
unreachable was going something "funky" I should still see a full traceroute
at least across the igp correct?  

With that in mind, I'm puzzled . maybe it's simply a matter of "sit back and
take a good long look" as Gert just suggested ;)

Thanks folks .

Paul

From: Heath Jones [mailto:hj1980 at gmail.com] 
Sent: Tuesday, September 21, 2010 11:24 AM
To: Paul Stewart
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination

If my understanding is correct here, then the DSL user is probably blocking
inbound icmp so you would expect the traceroutes you see.. (just constant
timeouts).

Lets take a step back here... What problem is the customer reporting?

On 21 September 2010 16:04, Paul Stewart <paul at paulstewart.org> wrote:

Yes, loopback is in place and the source . yes, loopback in routing table
(redistributed via OSPF).  This 7206VXR has been in production for over 4
years and we have no issues reaching any other websites.

I'm confident that if the remote IP was blocking us or something of that
nature that the traceroute would at least transverse our igp properly . 

Thanks,

Paul

From: Heath Jones [mailto:hj1980 at gmail.com] 
Sent: Tuesday, September 21, 2010 11:00 AM 

To: Paul Stewart
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination

If it's not a firewall, its probably routing.. Is the 7206VXR using a
loopback for the source of the icmp request packets, and do you have a route
back to this ip in your igp?

On 21 September 2010 15:17, Paul Stewart <paul at paulstewart.org> wrote:

Thank you - good thinking but I checked and there's nothing in there to
limit ICMP at all..;)

Paul

From: Heath Jones [mailto:hj1980 at gmail.com] 
Sent: Tuesday, September 21, 2010 10:05 AM
To: Paul Stewart
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination

Hi Paul - perhaps you have a firewall filter preventing the ingress icmp
replies (to the 7206VXR)..?

On 21 September 2010 14:54, Paul Stewart <paul at paulstewart.org> wrote:

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 <http://www.cnn.com/> 

Translating "www.cnn.com <http://www.cnn.com/> "...domain server
(208.67.222.222) [OK]

Type escape sequence to abort.

Tracing the route to www.cnn.com <http://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
<http://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
<http://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
<http://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 <http://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
<http://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 <http://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
<http://ae-2-52.edge4.atlanta2.level3.net/>  (4.68.103.46) 52 msec 56 msec

   ae-1-51.edge4.Atlanta2.Level3.net
<http://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

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/