[c-nsp] Weird Traceroute Issue to Specific Destination

Tue Sep 21 12:40:32 EDT 2010

Hi all

Please see comments in line

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
> Sent: martedì 21 settembre 2010 17.48
> To: 'Heath Jones'
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination
> 
> Hehe. yeah, I hear ya.. At first I thought this is just one 
> of those "hey,
> dummy look at the routing table"..;)
> 
>  
> 
> What's killing me is that every hop from the 7200 right to 
> our Internet edge
> shows the 0.0.0.0/0 OSPF route as preferred which is what's expected.
> 
>  
> 
> dis2-rtr-mb#show ip route xx.xxx.2.226
> 
> % Network not in table
> 
> dis2-rtr-mb#show ip cef xx.xxx.2.226
> 
> 0.0.0.0/0, version 8684984, epoch 1, cached adjacency xx.xxx.0.226
> 
> 0 packets, 0 bytes
> 
>   via xx.xxx.0.226, Vlan4, 0 dependencies
> 
>     next hop xx.xxx.0.226, Vlan4
> 
>     valid cached adjacency
> 

You may want to try 
sh ip cef exact-route with source and destination to see if it changes, 
as well as the sh mls cef flavours on the 6500/7600s
and don't forget to check labels if you have mpls.

Brian

> 
>  
> 
> Paul
> 
>  
> 
>  
> 
> From: Heath Jones [mailto:hj1980 at gmail.com] 
> Sent: Tuesday, September 21, 2010 11:38 AM
> To: Paul Stewart
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination
> 
>  
> 
> 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 <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/
> 
>  
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> 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/
> 