On Sep 3, 2008, at 5:30 PM, James Jun wrote:
uRPF was problematic back in PFC2 based platforms (i.e. SUP2) where
it is
further dependent upon unicast routes in FIB TCAM.
uRPF was untenable on SUP2, not problematic. It wasn't possible
above ... 3mb/sec?
Guys, this isn't SOHO routing here. If you can't take a single gig
interface at full burst with your feature, you don't have it.
uRPF currently works fine enough on PFC3 based sups, the only problem
however is currently only "one or the other" mode is supported for the
entire box, as opposed to per interface. For example, configuring
loose-mode uRPF in one interface, then configuring a strict-mode in
another
will result in entire box behaving as strict-mode interface for all
uRPF
enabled interfaces. Other than this caveat, I never had problems
with it.
That's one hell of a caveot, given that you always want strict on your
customers and loose on your transit links.
However, these uRPF issues are fully documented. Reading manuals and
documentation should help you avoid getting into operational
problems such
as "kept falling back and killing the units" scenario.
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.
Control plane policing via cp-policer works quite well on pfc3 based
6500's.
This is ofcourse a very important feature (more important than uRPF in
today's internet IMO) that appears to be missing in f10 gear which
is what
Paul was saying earlier.
Based on what? Other than some idea of "um, we can't meet BCP38 so
lets call it unimportant?"
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
