North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Force10 Gear - Opinions

  • From: Jo Rhett
  • Date: Wed Sep 03 20:41:47 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 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