We haven't seen this one yet. So lets dig in to find out what is happening.
I've forward this to the DE to see if it is a bug. If yes, then we'll open a
DDTS to fix it. Lets take the rest of this off-line. Can you send a show
tech on the router (privately)?
A couple of notes about Unicast RPF .....
Note 1 -> the Unicast RFP code has changed in 12.0(14)S. This change is part
of a overhaul on Unicast RPF to all it to work on the ISP-ISP edge of the
network. 12.0(14)S has the new "loose check" option - which only check if
the source packet exist in the FIB - no matter which interface it came down.
So Unicast RPF can be used on the ISP <-> ISP edge to drop packets whose
source addresses are not in the FIB. It can also be used to target valid
source addresses that are part of an attack - using BGP to update all the
router's drop list (which is a combination of the FIB, BGP Next Hop, and a
static to Null0).
Check out the following whitepaper for details:
Note 2 -> the "ACL" option is not needed to configure Unicast RPF to work
with asymmetrical flows on the Customer <-> ISP edge. In fact, we thinking
about dropping this ACL in the phase 3 update of Unicast RPF (let me know if
you really need the ACL). This is documented in the ISP/IOS Essentials
ISP Essentials Whitepaper
ISP Essentials Seminar Slides
Philip and I are working on a updated security section that has the new uRPF
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of Miguel A.L.
> Sent: Tuesday, December 19, 2000 6:32 AM
> To: firstname.lastname@example.org
> Subject: [nsp] "verify unicast reverse-path" with acl causes
> On 12.0(14)S, and previously on 12.0(9), enabling "ip verify unicast
> reverse-path" with an access list on 7206 serial intefaces causes:
> %SYS-3-INVMEMINT: Invalid memory action (free) at interrupt level
> -Traceback= 6046257C 60540C70 6053F2A4 60541218 6034C078 6035D670
> 603772C4 600ED1B8 600F4780 600F60A8 600F8810
> The access list only permits all and logs, since I just want to
> "catch" packets
> that are asymmetric, or maybe DoS.
> Known problem? Is it the logging perhaps?
> http://www.internet.org.ph Internet and ISP's in the
> http://www.ASARproject.org Artists for Social Action
> and Response
> GSM Mobile: +63-917-810-9728
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:23 EDT