[c-nsp] Weird Traceroute Issue to Specific Destination

[Heath Jones]

 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
>
> 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<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/
>
>
>
>
>