Elke,
Useful features are incorporated into Cisco IOS by engineers using a "wish
list" process, with uRPF the Product Marketing people probably didn't
understand the significance of Barry Greene's request so it was titled a
"featurette" i.e. not a full blown feature, that gets it into Cisco IOS by a
faster path, and that helps us all :-) I stumbled across it after reading
the IOSEssentials doc the other day.
http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement_4.pdf read
this, it answers all your BGP questions.
Did you raise a TAC reference for the "snmp trap bug", TAC would be able to
have an interim maintenance release to you shortly after the issue is
identified. I'm not the correct person to deal with "Bugs" hence the sig.
but if this is still an issue for you I would be happy to get involved, send
me the TAC case number and details of your account team directly.
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
-----Original Message-----
From: CLAEREBOUDT Elke [mailto:ECLAEREB@mail.mobistar.be]
Sent: 09 February 2001 09:42
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.zip 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:27 EDT