http://www.cisco.com/warp/customer/620/roadmap.shtml refers to the software
roadmap and show (at a very high level) where all the code points converge
and diverge. You'll see from the map that many of the release trains will
converge on the 12.2 major release. We then develope new features from the
common code base of 12.2.
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: Jared Mauch [mailto:jared@puck.nether.net]
Sent: 10 February 2001 00:11
To: Barry Raveendran Greene
Cc: Jared Mauch; CLAEREBOUDT Elke; Frank Bruce;
cisco-nsp@puck.nether.net
Subject: Re: [nsp] ip spoofing prevention
On Fri, Feb 09, 2001 at 03:26:10PM -0800, Barry Raveendran Greene wrote:
>
> 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.
Does this mean 12.2S will support all the hardware Cisco
makes and there will be no more "T" trains or similar to pick up new
hardware support? It seems like cisco builds new trains for each
product line. This means features never make it cross platform
that are not platform specific features.
Also, i've been told that 12.0S and 12.1E are not related enough
to make any "cross commits" easy meaning i've had to apply lots of
pressure to get something from one to the other. Sounds like it's
not great code managment if things diverge far enough that it's not
easy when you (cisco) whips up the new platform du-jour.
- Jared
> > -----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.
> >
-- 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