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