IDS mailing list archives
Re: IPS Reliability/Availability
From: "David W. Goodrum" <dgoodrum () nfr com>
Date: Fri, 17 Feb 2006 11:47:24 -0500
Hi David,Sorry for the late post. I will chime in that we here at NFR have tested, and are now shipping, this architecture for our multigigabit sensors. I know you're looking for 3rd party testing, but I can tell you that we looked at a number of architectures before finally choosing this model to run our multigig solution. Here's what our benchmarking found.
Question 1: Our benchmarks have shown, with the basic 7 processor model, that it can sustain over 2Gbps of actual customer traffic (not fake traffic, but actual customer data), and that using this architecture we can actually scale the product with more processors to hit the 10G mark.
Question 2: The only two IPS companies I know of that use this technology are NFR and SourceFire so far. But, I know that other industries are using it also for their applications.
Question 3: Pros of this architecture:- upgrade paths are a big one. We can be very flexible in software, because we aren't putting any code down into hardware. IPv6 is a great example of this. It was easy for us to add IPv6 capability via software. If we had to do it in hardware, we'd probably be years away from producing something due to the nature of programming in hardware. Using this model, our customers can retain all their existing hardware to support the new functionality, and with no performance loss. - One of the other nice features was redundancy. We can hot swap CPU's in the event of some strange hardware failure. - Also, thanks to this hot swap, we can simply add more processors to an existing system to let the system grow with bandwidth requirements. So, the 7 processor model might work for you today. But, in two years, you might need more performance, so you can simply add more processors to make it keep up. - Oh, and CPU redundancy means that we don't have to worry about any single processor becoming a bottleneck. Meaning that inline prevention has even less likelihood of becoming a potential failure point on the network.
Cons of this architecture- it's hard to convince people that this solution is actaully as fast (or faster) than an ASIC solution for the same price. ASICs have been around a long time, and people have a kind of warm fuzzy from that older technology.
You can go to http://www.bivio.net to read the details.I want to point out that we do still ship x86 based sensors for customers who don't need this type of performance. The x86 architecture is still the least expensive architecture out there, and it hits the low bandwidth budget very well. This RISC architecture was great because it let us take the years of development we did on the x86 platform and cut it over to this RISC model very cleanly, with little development time or cost.
I have a 3 page powerpoint that we provide customers when they ask about the differences between our RISC architecture vs ASIC. I don't think I can post attachments to the list, so I'll send it to you separately. If anybody is actually interested, contact me off-list and I'll send it to you as well.
thanks, -Dave
Actually, I'm seeing other vendors, SourceFire being one of the ones in the eval list below, who have not gone the ASIC route, but have gone with a kind of RISC architecture to get speed. Their pitch is that they get the performance of the ASIC vendors by using multiple RISC chips (I think the base model that does a gig inline has 6 RISC processors) to handle the load (plus an extra processor to handle the management end of things... so 7 all together). They are claiming performance of an ASIC but the flexibility of software. Not sure how valid that claim is. Question 1 : I'm wondering if anybody has tested these or stacked them up next to the ASIC brands to test perfomance, and if so, can they provide some feedback. Question 2: Does anybody have a list of which vendors are using ASICs for performance and which are using this RISC type architecture for performance? Question 3: Not so much a question, but a general request; I'd be interested in a "pro vs con" for each if anybody gets their hands on them. -d On 2/6/06, Andrew Plato <andrew.plato () anitian com> wrote:Most of these devices are pretty good for reliability. The only exception I would make is SourceFire, which back when we sold it had abysmal reliability (3 out of 4 boxes we sold to a customer show up dead or died soon after installation). TippingPoint sells a zero-power bypass add-on for their IPS. If the IPS fails in anyway, traffic is passed through the zero-power device. Its very easy to add. Juniper does something similar. ----------------------------------------------- Andrew Plato, CISSP, CISM President/Principal Consultant Anitian Enterprise Security ----------------------------------------------- -----Original Message----- From: geek_brigades () yahoo com [mailto:geek_brigades () yahoo com] Sent: Thursday, February 02, 2006 8:27 AM To: focus-ids () securityfocus com Subject: IPS Reliability/Availability I am working on a big IPS project and I am very concerned about installing an inline device in a core enterprise network, where these devices have the potential to create big time network outages. Can you, please, share your possible bad experiences about the reliability of the following inline IPS products: ISS TippingPoint Juniper IPS Sourcefire McAfee IntruShield Have you had any issues with the availability of these devices, such as fail close crashes or do you have any experience with bypass switches that would mitigate the availability issue? Thanks, Mike ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------ _________________________________________________ NOTICE: This email may contain confidential information, and is for the sole use of the intended recipient. If you are not the intended recipient, please reply to the message and inform the sender of the error and delete the email and any attachments from your computer. _________________________________________________ ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly?Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.------------------------------------------------------------------------
------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly?Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
------------------------------------------------------------------------
Current thread:
- Re: IPS Reliability/Availability, (continued)
- Re: IPS Reliability/Availability Martin Roesch (Feb 21)
- RE: IPS Reliability/Availability Alan Shimel (Feb 21)
- Re: IPS Reliability/Availability Martin Roesch (Feb 21)
- Re: IPS Reliability/Availability Bob Walder (Feb 22)
- Re: IPS Reliability/Availability Sap . (Feb 24)
- Re: IPS Reliability/Availability Bob Walder (Feb 24)
- Re: IPS Reliability/Availability Gwendolynn ferch Elydyr (Feb 26)
- RE: IPS Reliability/Availability Mike Barkett (Feb 19)
- RE: IPS Reliability/Availability Alan Shimel (Feb 21)
- Re: IPS Reliability/Availability Bob Walder (Feb 22)
- Re: IPS Reliability/Availability David W. Goodrum (Feb 19)
- Re: IPS Reliability/Availability Mike Smith (Feb 22)
- RE: IPS Reliability/Availability Alan Shimel (Feb 21)