[nsp] ip verify unicast reverse-path confirmation?

[Tim Stevenson]

Comments inline:

At 06:59 PM 12/4/2003, cisco-nsp-request at puck.nether.net remarked:
>Message: 11
>Date: Thu, 4 Dec 2003 21:46:41 -0500
>From: Jared Mauch <jared at puck.nether.net>
>Subject: Re: [nsp] ip verify unicast reverse-path confirmation?
>To: lee.e.rian at census.gov
>Cc: cisco-nsp at puck.nether.net
>Message-ID: <20031205024641.GN45524 at puck.nether.net>
>Content-Type: text/plain; charset=us-ascii
>
>On Thu, Dec 04, 2003 at 04:02:00PM -0500, lee.e.rian at census.gov wrote:
>> I think uRPF handling depends on the hardware
>> - Sup 1: everything gets forwarded to the MSFC
>> - Sup 2: handled in hardware
>> 
>
>     Ok.
>
>     Hold the phone here.
>
>     Here's the scoop:
>
>     sup1(a), u-rpf handled in software on the MFSC

Right.

>     sup2, u-rpf is GLOBAL.  You set strict on one interface,
>it sets strict on all interfaces that u-rpf is configured.  This
>is quite different from all other cisco platforms.  BEWARE.  I've
>seen people innocently break things by setting strict on an
>interface and it changes an unrelated interface from loose
>to strict.  This was a pain to track down since we were
>looking at tacacs logs and couldn't find it.

That is correct. Basically, there is a "global hardware mode" - any uRPF check enabled interfaces use that mode. If you set the mode on interface A (say, strict mode) and then set a different mode (say loose) on interface B, both interface A & B will be running loose mode. There is a DDTS on this, in R state: CSCec39733.

However, the current release note (12/5) on cisco.com is misleading, coupled with the R state. The resolution is just to print a warning. I updated the RN to say:

***
Entering a new uRPF mode on an interface changes the ip verify statement on 
global basis (all interfaces with uRPF check enabled are changed to the new
mode).

This is expected behavior for this platform. 

The resolution for this DDTS is to print a warning message at the CLI prompt
when the global mode is changed:

"Changing uRPF check mode on all uRPF interfaces to this mode."
***

>     I can't remember what the sup3 (720) does off the top of
>my head, I seem to recall asking cisco but not recalling the answer
>I received.  Use caution.


Sup720 does the same thing. The main difference between sup2 & sup720 is that sup2 can only do uRPF in hardware for a single reverse path interface per prefix. So if you have load sharing paths back to a prefix, only one of the LS interfaces gets uRPF check in hardware; the other gets it in software.

On sup720, we can do up to 6 LS paths in hardware - 2 by default for all prefixes and up to 4 additional interfaces with some additional config.

Hope that clarifies.

Tim


>     - Jared


Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.