[c-nsp] Weird Traceroute Issue to Specific Destination

[Heath Jones]

I need a coffee or 2, I am misreading absolutely everything today!!

Ok so that IP is not the customer IP - it's the destination on the other
side of the net somewhere..
Gert is correct, the routing and forwarding tables will show you what is
different about that ip.





On 21 September 2010 16:23, Heath Jones <hj1980 at gmail.com> wrote:

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