Strange indeed. I have seen a similar problem with the default route + CEF bug. But that was on C10K.
You could try to add a static /32 route to the BADIP on the xx.xx.120.25 box, just to exclude some default route issue. Also to create a specific CEF entry. Have you done some ip packet debugging when tracerouting etc? On Tue, Sep 21, 2010 at 9:02 PM, Heath Jones <[email protected]> wrote: > 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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
