Force10 Gear - Opinions
jrhett at netconsonance.com
Wed Sep 3 19:36:45 CDT 2008
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
> will result in entire box behaving as strict-mode interface for all
> 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
> 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?"
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
More information about the NANOG