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