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_at_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_at_yahoo.com [mailto:geek_brigades_at_yahoo.com]
>>Sent: Thursday, February 02, 2006 8:27 AM
>>To: focus-ids_at_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.
------------------------------------------------------------------------
Received on Feb 19 2006
Intro
