(changing subject line) On Sep 3, 2008, at 7:06 PM, Rubens Kuhl Jr. wrote:
This statement is patently false. The uRPF failures I dealt with were based entirely on the recommended settings, and were confirmed by Cisco. Last I heard (2 months ago) the problems remain. Cisco just isn't being honest with you about them.
Would you mind telling us what is the scenario so we can avoid it ?
That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and various other problems to persist throughout the unit, ie no arp response. We were able to simulate this with two 2 pc's direction connected to a 6500 in a lab. If I remember right, we had to enable CEF to see the problem, but since CEF is a kitchen sink that dozens of other features require you simply couldn't disable it. We also discovered problems related to uRPF and load balanced links, but those were difficult to reproduce in the lab and we couldn't affect their peering, so we had to disable uRPF and ignore so I don't have much details. I kept thinking that this was a serious problem that Cisco would address quickly, but that turns out not to be the case. To this day I've never found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness