Re: OT - CoPP in the Enterprise

From: Rick Mur <rmur_at_ipexpert.com>
Date: Wed, 5 May 2010 15:39:17 +0200

Usually it's not necessary to implement these features. Of course there are exceptions like Geert mentions.
I've read a test report made by a co-worker for Juniper MX960's and they couldn't make the routing engine crash, just by using the default settings.
With Cisco it varies per platform, since many platforms are CPU or semi-CPU routers, there it would be beneficial, since that would assist in CPU starvation.
For 100% separated control- and data-planes I don't think it's necessary.

-- 
Regards,
Rick Mur
CCIE2 #21946 (R&S / Service Provider)
Sr. Support Engineer  IPexpert, Inc.
URL: http://www.IPexpert.com
On 5 mei 2010, at 15:04, Geert Nijs wrote:
> Good questions:
> 
> * Do i know COPP ? yes
> * Have i deployed it in enterprise ? No
> * Do i know how to deploy ? No, not really. There are some white papers out, but no simple "cut-and-paste" solution for this.
> * Is it needed ?
> 	I am seriously thinking about implementing it. We have run into one particular event where COPP -might- have helped.
> 	Strange thing was that is was not even a security attack, but more a need to protect the network from itself.
> 	One single link on a L3 core switch was flapping (not actually flapping, the interface remained up, but the remote switch was
> 	experiencing a L2 broadcast storm and couldn't keep its OSPF neighbors up because of lack of CPU). So this L3 switch, continuously
> 	saw an OSPF neighbor going down->negotiating->up->down->nego etc. Everytime receiving +/- 2000 routes via OSPF.
> 	This L3 core switch was connected to 7 pairs of distribution switches (14 OSPF connections). Each distribution switch
> 	was connected to a second L3 core switch also. This second L3 core switch had the only remaining link to the majority of the rest of the
> 	network. So each time, the OSPF neighbor flapped on core A, 14 x 2000 = 28.000 LSA updates
> 	were sent to the second L3 core switch. Result: CPU starvation for more than 3 minutes -> result: automatic reboot of C6500.
> 	Result: the complete Layer3 core network was isolated and a broadcast storm occuring on older L2 switches was able to "propagate" to
> 	newer switches who were all running L3 routing procotols (no STP) - which was deemed impossible and one of the reasons why the Layer3 core
> 	network was build. Don't know if with COPP i could have protected the CPU from starvation so that the switch wouldn't have rebooted...
> 
> regards,
> Geert
> CCIE#13729
> 
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Patrick J Greene
> Sent: woensdag 5 mei 2010 0:32
> To: ccielab_at_groupstudy.com
> Subject: OT - CoPP in the Enterprise
> 
> Out of curiousity, do you deploy CoPP within your enterprise?  Do you really
> know how to deploy CoPP within the enterprise?
> 
> I understand it and could deploy it, but honestly have not run into any issues
> where I have needed it nor know any general guidelines around its use.
> 
> Patrick Greene
> Layer 8 Solutions, LLC
> Cell: 704.806.0120
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> _______________________________________________________________________
> Subscription information may be found at: 
> http://www.groupstudy.com/list/CCIELab.html
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> _______________________________________________________________________
> Subscription information may be found at: 
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Wed May 05 2010 - 15:39:17 ART

This archive was generated by hypermail 2.2.0 : Tue Jun 01 2010 - 07:09:52 ART