[nsp] ip verify unicast reverse-path confirmation?

[Tim Stevenson]

Ah, forgot the one other difference, which is that enabling uRPF on Sup2 halves the size of the available FIB TCAM, which is not the case on Sup720.

Tim

At 11:01 AM 12/5/2003, Tim Stevenson remarked:
>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.


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.