[c-nsp] Weird Traceroute Issue to Specific Destination
Heath Jones
hj1980 at gmail.com
Tue Sep 21 10:04:33 EDT 2010
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/
>
More information about the cisco-nsp
mailing list