Force10 Gear - Opinions

[jrhett at netconsonance.com (Jo Rhett)]

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