Cisco Cisco IPS 4255 Sensor 백서

 

 

White Paper 

 

All contents are Copyright © 1992–2007 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. 

Page 2 of 3 

Different environments have different characteristics that each can have a large impact on the 

relative performance of an IPS processing that traffic. Some of these factors include; protocol of 

traffic (stateful or stateless; TCP vs UDP), number of new connections per second, number of 

concurrent connections being tracked, amount of data being sent, amount of data being 

requested, number of transactions per connection, application being inspected (HTTP vs FTP), 

and others. Changes in any one of these metrics can change the tested performance of the box.  

What type of traffic should be used? The best traffic is your specific network’s real traffic. Since 

that isn’t always feasible or even advisable, the next best thing is the closest traffic you can get to 

your real traffic. Using test tools to approximate real traffic can be difficult. Basic test tools are 

often stateless, or do not properly replicate a TCP/IP stack. For example, when testing TCP, the 

tools need to be accepting of a lost packet and it needs to resend that packet. The behavior of the 

protocol needs to mimic a real conversation as much as possible. 

Given that on most typical networks, HTTP traffic makes up a large percentage of the traffic, it 

makes sense that it make up most or all of the test traffic. This doubly tests IPS systems as HTTP 

has many relevant attacks, and has characteristics that make it difficult to process: connection 

based so state must be tracked, large amounts of data to parse, and often short lived so large 

amounts of new connections are required. This makes HTTP an excellent protocol for background 

traffic for testing IPS systems. The industry standard tool used to generate this traffic is Spirent’s 

Web Avalanche/Reflector tool. 

Using traffic replays to generate background traffic will in most cases generate erroneous results, 

because in nearly every case, the replayed traffic does not realistically mimic stateful bidirectional 

protocol and application behavior. For example, replay tools can be flawed because the replay will 

use the same sequence numbering over and over or it won’t be tolerant of packets that get 

dropped because of congestion, etc. 

Different IPS vendors take different stances on the issue of which detection services to enable 

during testing. Cisco believes that the recommended attack detection profile should be the same 

one used in performance testing. Otherwise you really have no idea how the sensor will behave 

when put into actual production. To that end the Cisco IPS is tested with its default and 

recommended signature policy and inspections during all performance testing. 

The two different test environments used to test IPS are defined in terms of the parameters used 

to reproduce them on a Spirent Web Avalanche/Reflector pair.  

Characteristics of Media-Rich and Transactional test environments 

HTTP 

HTTP 

100 bytes 

100 bytes 

Low 

High 

Multiple 

One 

Large 

Small 

765 bytes 

440 bytes