Thanks - very interesting.... So I tried some hostnames below and above (server#.domainname.co.uk) and they all went through... then I seen your suggestion about IP (why I didn't think of that I have no idea) and interestingly enough one IP below OR one IP above works perfectly fine. So on the surface it appears that only a single /32 is causing us all this grief.
The CEF version was taken before the reboot - so it's pretty low again ... Paul -----Original Message----- From: Heath Jones [mailto:[email protected]] Sent: September-21-10 3:03 PM To: Paul Stewart Cc: [email protected] Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination What happens when you try BADIP+1 or something close to it? Also if you happened to have assigned this BADIP to a dsl customer (or in a routed network via radius attribute behind it), and had the config on the lns cause the next hop to be the 6500 (policy routing, vrf etc).. I noticed the cef version was pretty high also. Was that before the reboot, or because of a lot of users coming and going? I have a headache because of this problem now ;) On 21 September 2010 19:39, Paul Stewart <[email protected]> wrote: > Thanks to everyone... yeah, this is a very strange issue. We've tested > about 150 destinations through that path so far and only one of the > destination IP's has given us the weird timeouts in the traceroute (which > results in the traffic not passing specific to that destination). > > Last night, we had the opportunity to do a maintenance window and rebooted > the 6500 and 7206VXR closest to the customer - no change. They had been up > for about a year... > > No, there isn't any security related devices sitting along there - we have > them, just not in that part of the network. They are not inline neither... > > We'll keep poking away - appreciate it.. > > Paul _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
