|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Tue, 20 Jan 2004 19:36:16 -0500 From: haesu@towardex.com To: "Rubens Kuhl Jr." <rubens@email.com> Cc: NANOG <nanog@merit.edu> In-Reply-To: <00aa01c3dfb3$c22599d0$020ba8c0@NOTEBOOK> Errors-To: owner-nanog-outgoing@merit.edu yes in concur.. prefix based ones (like FIB) are fine. unfortunately some models from some vendors (tisk tisk) who use slow process path to reprogram the CAM per flow can be quite painful during situations like random dest. dos attacks and worms.. add the E vendor to your list too.. we had summit48i that loved the worm traffic -J On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote: > > > Not all L3-switches are flow-based; prefix-based ones should do just fine. > Can people add/correct this initial list ? > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > Sup2(A), Sup3(A/BXL) > > > Rubens > > > ----- Original Message ----- > From: <haesu@towardex.com> > To: "Brent Van Dussen" <vandusb@attens.com> > Cc: "NANOG" <nanog@merit.edu> > Sent: Tuesday, January 20, 2004 9:46 PM > Subject: Re: Nachi/Welchia Aftermath > > > > > > lesson learned: > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > L3 core > > > > -J > > > > On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: > > > > > > Well folks, since the middle of August I've been tracking the spread and > > > subsequent efforts by our community to stop the nachia/welchia infection > > > that took down so many networks. > > > > > > Sadly, by my estimations, only about 20-30% of infected hosts were > > > cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) > of > > > remaining infected hosts were rebooted and the worm removed > > > itself. Network traffic has finally returned to normal. > > > > > > What kind of effects did everyone see from this devastating worm and > what > > > lessons did we learn for preventing network downtime in the future? > > > > -- > > James Jun (formerly Haesu) > > TowardEX Technologies, Inc. > > 1740 Massachusetts Ave. > > Boxborough, MA 01719 > > Consulting, IPv4 & IPv6 colocation, web hosting, network design & > implementation > > http://www.towardex.com | james@towardex.com > > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > > Fax: (978)263-0033 | AIM: GigabitEthernet0 > > NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE > > -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | james@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |