Hello Elke,
I would not recommend using the loopback as a drop interface. The Loopback
in CEF is treated as a "real" interface. So with the loose check mode
active, uRPF would pass the traffic with a next-hop pointing to a loopback.
Null0 is not a "real" interface in CEF. So a next-hop pointing to Null0
would be invalid - hence failing. Also, since it is not a real interface,
CEF will use a tool to aggressively drop the packets vs sending them to an
interface, then dropping them.
I'm updating the white up, so I'll include this advice in the write up. At
one time, a long time a go, black holing packets to Null0 were sent up to
the processor - forcing CPU interrupts. Hence, people black holed packets to
the Loopback. That was a long time ago before CEF. With CEF everything
changed. Null0 is a special adjacency and not a valid interface. Hence, the
drops are all done in the LC/VIP/edge at CEF speeds - punting packets to the
RP/GRP.
Barry
>
> Hi,
>
> I have a question about the enhancements to uRPF.
> Normally they should be available in 12.0.15(S).
> Is somebody already using 12.0(15)S ? We tried it but hit a bug
> concerning
> snmp atm traps which crashed the router.
> I checked in the new features for 12.0.15S but they don't say
> anything about
> enhancements on urpf.
> Are we correct if we conclude that with urpf in 12.0(14)S wa cannot
> configure an incoming route-map attached to a bgppeer saying that
> all trafic
> which matches the acl should have the next hop set to null, and
> put urpf on
> our incoming interface, so that all networks included in the acl would be
> dropped because of next-hop null.
> Can we configure set next-hop loopback1 which is a fake loopback
> that isn't
> used ?
>
> For example
>
> router bgp www
> neighbor x.x.x.x remote-as zzz
> neighbor x.x.x.x route-map set-next-hop-null
> !
> route-map set-next-hop-null
> match ip address yyy
> set ip next-hop 192.0.2.1
> !
> ip route 192.0.2.1 255.255.255.255 null0
>
> Thanks
>
> Elke
> -----Original Message-----
> From: Frank Bruce [mailto:fbruce@cisco.com]
> Sent: Friday 9 February 2001 10:18
> To: Andrew; Jared Mauch; Brian; vac@antarix.net
> Cc: Eric Chan; cisco-nsp@puck.nether.net
> Subject: RE: [nsp] ip spoofing prevention
>
>
>
> Have a look at
> http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zi
> p for the
> template configs, including details on uRPF checks,
> http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement_4.
> pdf adds
> to this talking about the ISP-ISP edge. You might also look at
> RFC2267 BCP
> 38 & RFC 3013 BCP 46.
>
> You'll find this featurette in 12.0(14)S released on CCO on 13-Nov-00 and
> derivatives (http://www.cisco.com/warp/customer/620/roadmap.shtml), This
> uRPF option would be used on the ISP peering routers with other ISPs.
> Packets which have not been allocated on the Internet, yet which are used
> for spoofed source addresses, would be dropped. Other packets
> which have an
> entry in the FIB would be passed.
>
> Unicast RPF
> - Check only if source is in the Forwarding Information Base
> (FIB) hence the
> requirement for Cisco Express Forwarding (CEF)
>
> * New mode of operation - "exists-only"
> In this mode, a source address need only be present in the FIB
> table, be resolved and reachable via a "real" interface to be
> verified. The new command is
>
> ip verify unicast source reachable-via any [allow-default]
>
> The allow-default flag means allow the lookup to match the default
> route and use it for verification. Note, this is today's
> behaviour,
> so is implicit with the old command format (see below).
>
> * Close ping DoS hole
> There is a hole in the verification check to allow the router to
> ping its own interface. This is a denial-of-service hole. You
> must
> now specify allow-self-ping in the command to enable this hole.
>
> * Allow secondary address pings
> There was a bug in the self-ping hole, which prevented the router
> pinging a secondary address. This is fixed. Note you must use
> the
> new allow-self-ping flag to make this work.
>
> * New command syntax
> A new, extendable syntax is used to support the new modes of
> operation. It is:
> ip verify unicast reverse-path [allow-self-ping] [<list>]
> ip verify unicast source reachable-via (rx|any) [allow-default]
> [allow-self-ping] [<list>]
>
> I hope you find this update useful.
>
> Regards
>
> Frank Bruce
> Consulting SE, NSP West
> Cisco Systems Ltd
> ---------------------------------------------------------------
> | | | 3 The Square, Stockley Park
> :|: :|: | Uxbridge, England. UX11 1BN
> :|||: :|||: | Office : +44(0)20-87568000
> .:|||||||:..:|||||||:. | The Views Expressed Are My Own
> C i s c o S y s t e m s | And May Not Reflect Cisco's
> ---------------------------------------------------------------
> All Cisco technical support should be conducted via the TAC.
>
> How to use the Cisco TAC
> http://www.cisco.com/public/support/help.shtml
> TAC Newsletter
> http://www.cisco.com/public/news_training/itsnews/subscribe.shtml
>
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:28 EDT