[nsp] ip verify unicast reverse-path confirmation?

[Robert A. Hayden]

Actually, that "print a warning" half-way resolution came from me (or at
least I submitted a ticket that asked for this).  I got tripped up by this
a couple months ago since the change is being made at the interface level
but is being global on the switch.  Obviously, this violates CLI logic and 
I opened up a case per that.

It's good to see it's out there now.  It makes me feel a little bit like 
Company C listens from time to time, which is good :-)

On Fri, 5 Dec 2003, Tim Stevenson wrote:

> 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.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>