Hi all Please see comments in line
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Paul Stewart > Sent: martedì 21 settembre 2010 17.48 > To: 'Heath Jones' > Cc: [email protected] > 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:[email protected]] > Sent: Tuesday, September 21, 2010 11:38 AM > To: Paul Stewart > Cc: [email protected] > 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 <[email protected]> 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 <[email protected]> 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:[email protected]] > Sent: Tuesday, September 21, 2010 11:00 AM > > > To: Paul Stewart > Cc: [email protected] > 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 <[email protected]> wrote: > > Thank you - good thinking but I checked and there's nothing > in there to > limit ICMP at all..;) > > > > Paul > > > > > > From: Heath Jones [mailto:[email protected]] > Sent: Tuesday, September 21, 2010 10:05 AM > To: Paul Stewart > Cc: [email protected] > 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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
