[107486] in North American Network Operators' Group
Cisco uRPF failures
daemon@ATHENA.MIT.EDU (Jo Rhett)
Thu Sep 4 12:35:48 2008
From: Jo Rhett <jrhett@netconsonance.com>
To: "Rubens Kuhl Jr." <rubensk@gmail.com>
In-Reply-To: <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com>
Date: Thu, 4 Sep 2008 09:35:34 -0700
Cc: NANOG <nanog@merit.edu>
Errors-To: nanog-bounces@nanog.org
(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
