12.0ST gets it from being committed to 12.0S.
This uRPF Enhancement was also committed to 12.1E for the CAT6K. It is in
the coding queue. There was an internal issue that was resolved this week
that delayed a coding date. We should have a version number for 12.1E next
week. Unicast RPF in the CAT6K is different from the other platforms in that
the MTRE happens in parallel (in hardware) to the forwarding MTRE look-up.
Makes for zero performance impact. So there are a few tweaks that needed to
be done for the 12.1E flavor of the enhancements.
We're working to insure all the ISP Security features get dual committed
into 12.0S and 12.1E. That would make life easier during the 12.2S
migration. If you are submitted a ISP related feature question, make sure
you ask for 12.0S + 12.1E commitment.
Barry
> -----Original Message-----
> From: Jared Mauch [mailto:jared@puck.nether.net]
> Sent: Friday, February 09, 2001 3:17 PM
> To: Barry Raveendran Greene
> Cc: CLAEREBOUDT Elke; Frank Bruce; cisco-nsp@puck.nether.net
> Subject: Re: [nsp] ip spoofing prevention
>
>
>
> What plans are there for these enhancements in other IOS
> software other than S train? Because of cisco software+hardware roadmap
> you leave important features out of other platforms (650x for example)
> which make this feature unavailabe on the OSR and other devices.
>
> - Jared
>
> On Fri, Feb 09, 2001 at 02:59:47PM -0800, Barry Raveendran Greene wrote:
> > Hello Elke,
> >
> > The new enhancements went are in 12.0(14)S. Let me know if you have
> > questions.
> >
> > Barry
> >
> >
> > > -----Original Message-----
> > > From: CLAEREBOUDT Elke [mailto:ECLAEREB@mail.mobistar.be]
> > > Sent: Friday, February 09, 2001 1:46 AM
> > > To: Frank Bruce
> > > Cc: cisco-nsp@puck.nether.net
> > > Subject: RE: [nsp] ip spoofing prevention
> > >
> > >
> > > 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
> > >
> > >
> > >
>
> --
> Jared Mauch | pgp key available via finger from jared@puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements are
> only mine.
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:28 EDT