Unanswered Question
Sep 7th, 2007

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn about troubleshooting IPS with Cisco expert Marco Caballero. Marco is a Quality Assurance Technical Lead at Cisco Systems, Inc. He specializes in the Cisco IPS 4200 Appliances, Cisco ASA 5500 IPS Modules, Catalyst 6500 IDS Modules, and the Access Router IDS Modules. Marco joined Cisco Systems in 1998 as a result of the Wheelgroup acquisition. Prior to his current position, Marco tested IDS sensors for the Air Force and was a software tester with Wheelgroup.

Remember to use the rating system to let Marco know if you have received an adequate response.

Marco might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through September 21, 2007. Visit this forum often to view responses to your questions and the questions of other community members.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (20 ratings)
darncatman Fri, 09/07/2007 - 12:14

In an enterprise using an in-line IPS deployment with CSM/MARS for mgt/mon of IPS devices/functionality, what is the recommendation for a lab to test IPS changes (signatures,filters,code,etc) in production? Looking for an enterprise perspective.

marcabal Mon, 09/10/2007 - 11:56

when deploying an IPS (inline monitoring) in an Enterprise environment there is always a concern that a new signature update will have a negative affect on your traffic.

The concern I have heard most often from customers is that a false positive for a new signature may cause a deny of legitimate traffic on the network.

To address this concern I would recommend being able to deploy new signature updates first on a test lab sensor before pushing them out to your deployed sensors.

But you need to ensure that you have traffic in your lab that accurately simulates the traffic seen in your network.

If you have a very good understanding of the applications running on your network then you may be able to simulate these services in your lab, and see how the sensor responds to the traffic.

However, quite often there are additional applications that your users may be relying on that you do not have simulated in your lab.

I have seen 2 good methods to account for these additional services.

1) Use a network sniffer to capture a days worth of traffic into in a pcap file. Then use a replay tool to replay the traffic through the lab sensor.

2) Use a network TAP to actively monitor live traffic on the network and simulate running an line sensor connected to the tap. Go ahead and configure the sensor for inline interface pair mode, and plug the 2 interface of the pair into the 2 interface of the network tap. This way you can trick the sensor into thinking it is inline, when in actuallity it is monitoring copies of the packets from tap.

In any of the above test scenarios I would recommend adding in an Event Action Override for Risk Ratings 40-100. Analyze what alerts are triggered before the upgrade, and what alerts are triggered after the upgrade. Any alerts triggered after the upgrade can then be analyzed to determine if it s a new or tuned signature from the update, and if the triggering is from an actual attack or from a false positive.

You can also look in these alerts to see if the traffic would be denied. Any alert that shows a denial should be looked at closely because these are the alerts that may cause a network problem if it is a false positive.

If you do find a false positive, then you have 3 choices.

1) Notify Cisco, and wait for another update with the fix.

2) Deploy the update, and try to follow up immediately with a signature tuning that disables the signature after the update is applied.

3) If you know what specific addresses or ports are triggering the false positive you could first create a filter to filter out the false positive, and then deploy the signature update.

Many users may not realize that you can apply the filter for the new signature even before the signature update is applied.

Tunings of the signature itself must be applied AFTER the signature update, but Filters can be created even BEFORE the signature update.

So if you do have a concern about a False Positive, then you can put in the filter even before you apply the signature update.

Similar methodology can also be used for other upgrade types (Service Packs, Major Updates, and Minor Updates).

Because you are using CSM and CSMARS I also recommend a second set of these boxes in your test lab. Major and Minor updates to the sensors will also generally cause CSM to be upgraded as well. You will similarly want to test the new CSM/MARS versions before deploying them to you live systems.

mhellman Fri, 09/07/2007 - 13:37

I've always struggled with the event counter and alert frequency settings for signatures. I've never quite been able to create settings that are predictable.

Would it be possible to get a good description of these settings and a couple examples of how they work together?

The signature I'm working on currently is 6250-0, FTP Auth Failure. I am trying to tune so that for a given source address we only get 2 alarms per day, the initial alarm and a summary alarm. When I say "per day" I really just mean for some long period of time...say at least an hour (but a day would still be better).

marcabal Mon, 09/10/2007 - 14:43

When discussing the differences between the Event Counter and Alert Frequency configurations I like to use the following 3 terms:

Match - A match happens when the regular expression is seen within a connection.

Inernal Signature Event - This is the internal triggering of the signature. Actions are added and filters are checked against this Internal Signature Event.

Alert - This the writing of the actual alert into the eventStore so a user can see it in the CLI or IDM "show events", or pulled by an event viewer like IEV or MARS.

For most signatures a single Match will generate a single Internal Signature Event. And for most signatures a single Internal Signature Event will generate a single Alert that a user can view.

However, this is not always the case as you have seen with signature 6250-0 FTP Auth Failure.

With 6250-0 one Match does NOT correspond to one Internal Signature Event.

Instead if you look at the Event Counter section for that signature you will see:


event-count: 3

event-count-key: AxBx



What this says is that you have to have 3 Matches instead of 1 before an Internal Signature Event will be created. Those 3 matches have to be within connections that correspond to teh "event-count-key".

The IDM screen provides a better explanation of the event-count-key.

Here are the list of options that you would see in IDM and the CLI:


Attacker address - Axxx

Attacker address and victim port - Axxb

Attacker and victim addresses - AxBx

Attacker and victim addresses and ports - AaBb

Victim address - xxBx

In the case of 6250-0 the event-count-key is set to AxBx. What this means is that the 3 matches have to happen within connections from the same Attacker address to the same Victim address. Since the ports are not included in the key, this means that the 3 matches do not have to happen in the same connection and can instead happen in 3 different connections.

If the key had been AaBb then the 3 matches would have to be seen within the one connection.

The "specify-alert-interval" is set to "No" so this means that the signature is not requiring that the Matches be done with a certain tim period. There is still a limit of time inwhich the 3 matches need to happen, but it is a dynamic limit instead of a configured limit. When a Match is detected the sensor will try to keep that information in its memory for as long as possible. However, if the sensor is heavily loaded then it may need to free up that memory in order to monitor new connections. If the 3 Matches happen fairly close together then the first 2 will likely still be in memory when the 3rd match is seen, but if there are a few minutes between matches then it is possible that the first 2 Matches may no longer be in memory when the 3rd Match is seen so the Internal Signature Event will not be triggered because it sees this 3rd Match as instead being the 1st Match.

The next question is generally what happens with additional Matches after the 3rd. I have seen a few different scenarios over the past several years. I am not positive how this specific signature is treated for additional matches, but here are a couple of possibilities.

If the additional Match is seen while the first 3 are in sensor memory then the additional Matches may just be counted and never cause any additional Internal Signature Events. Alternatively the engine may have been coded to begin counting again from 1 with the 4th Match. In which case an additional Internal Signature Event may be triggered every 3rd Match. I am not sure which of the 2 approaches has been taken with the latest IPS versions.

Also keep in mind that if the sensor needs more memory for monitoring new connections it may free up older memory and forget about the previous Matches. Any new Matches would then be considered a 1st Match.

marcabal Mon, 09/10/2007 - 14:43

Now that the Internal Signature Event has been created because of 3 Matches, the sensor will now add actions to that Internal Signature Event.

It will first add all of the actions configured for that specific signature, and it will then proceed through the Event Action Overrides and add additional actions if needed.

There are several event actions that can cause an actual Alert to be produced. These actions include:







If any one of these actions are added to the Internal Signature Event then the Alert Frequency configuration of the signature will need to be checked.

If none of these actions have been added to the Internal Signature Event then no Alert will be produced. This is common when you want to deny or tcp reset an attack without generating an actual Alert entry.

The Alert Frequency for 6250-0 is configured as the following:




summary-interval: 15

summary-key: AxBx



The alert frequency has 4 possibilities:

Fire All - where every Internal Signature Event will create a corresponding Alert

Fire Once - where only the First Internal Signature Event will create a corrspending Alert. Additional Internal Signature Events within the same Summary-Key will not generate Alerts.

Summarize - An initial Alert will be generated for the first Internal Signature Event for each Summary Key. Additional Internal Signature Events will be counted but not create additional Alerts, and instead a single Summary Alert will be generated at the end of the interval.

Global Summarize - An initial Alert will be generated for the first Internal Signature Event for that signature. Additional Internal Signature Events will be counted but not create additional Alerts, and instead a single Global Summary Alert will be generated at the end of the interval.

The Summary Key is used in Fire-Once and Summarize modes. Similar to the event-count-key the summary-key will designate when the Internal Signature Events should be counted per attacker address, victim address, etc...

Most of these modes can then also be automatically upgraded to the next higher mode if the Internal Signature Event rate gets to high.

Fire All can be automatically upgraded to Summarize if the summary-threshold is exceeded.

Fire Once can be automatically upgraded to Global Summary if the global-summary-threshold is exceeded.

Summary can be automatically upgraded to Global Summary if the global-summary-threshold is exceeded.

However, remember what I mentioned above about the sensor freeing up memory and forgetting about Matches when it needs the memory for new connections.

The same thing can happen with Fire Once, Summary, and Global Summary modes.

The sensor may need to free up memory and may be forced to forget about some of the prior Internal Signature Events. This can cause the sensor to unexpectedly downgrade back to a lower mode, or for a summary interval to be cut short and for the count to start back again at 0.

In the case of 6250-0 the default setting is in Summary Mode.

The first Internal Signature Event between the same Attacker and Victim addresses will generate an Alert. Additional Internal Signature Events within the next 15 seconds will be counted and instead a Summary Alert will be generated every 15 seconds.

The signature will never upgrade to Global Summary.

For your particular situation I would suggest setting the signature back to defaults, and then change the summary-interval to as large a number as possible.

Because of memory constraints the summary interval may periodicaly be cut short, but it will reduce the number of times an actual Alert is generated.

mhellman Tue, 09/11/2007 - 06:38

Thanks for the detailed response Marco. I think that explains why I've struggled so much. It appears it will be difficult to really create signatures that fire in a predictable way from a timing perspective.

On a related note:

We are running Version 6.0(3a)E1. Why do the summary alarms look like normal alarms (perhaps this is a feature of v6 to deal with the summary alarm filtering issue)? My recollection is that summary alarms used to contain a running count, which was kind of useful.

marcabal Tue, 09/11/2007 - 11:35

The count should be included as part of the details field in the Summary Alarms.

Are you not seeing the counts in your Summary Alarms?

One thing I have seen is that some of the IPS viewers do not always show you all fields of the alert. And it is possible that the viewer is not showing the field that contains the counts.

When checking on issues like this you will want to check on the alert in the "show events" output directly on the CLI.

The CLI will always show you all fields in the alert, and can help determine what might be missing in the alert viewer tool you are using.

If you are not seeing the summary counts in the "show events" output for a Summary Alert then please let me know.

You can send me an email with the "show events" CLI output for that particular Summary Alert along with the output of "show version" and "show configuration" from your sensor. And I can take a look and see what is going on.

Also be sure to not confuse a single alert based off multiple Matches with an actual Summary Alert.

An alert based off multiple Matches will not have the counter, while a true Summary alert Will contain the count.

Also realize that with Summary mode there are 2 alerts that get generated. The first alert gets created (and is not a Summary), and then at the end of the Interval is when you actually get the Summery Alert and it is the Summary Alert that will contain the count.

So if you think it should be in Summary Mode and see a regular alert, then it may just be the first alert for that address set and so will not have any summary information yet.

debashisdey Sat, 09/08/2007 - 22:54

I am Debashis Dey ,My CCNA Certification has expired on 26th April 2007 , And I want it for the CCNP Exam.

How can we get it through

sbarasiscom Sun, 09/09/2007 - 00:14

Dear Marco,

As you are expert in IPS/IDS, I have a small question:

I have two IPS 4260 connected to 3750G switch and I want to load balance between them.

Note: I need two IPS works in promiscuous MODE.


marcabal Mon, 09/10/2007 - 14:56

I am not aware of any method for automatic load balancing of 2 promiscuous sensors when using a 3750G switch.

The only promiscuous sensor appliance load balancing I am aware of with Cisco switches is with the Cat 6K running traditional Cat OS.

Cat OS offers a feature called VACL Capture and functions somewhat similarly to Span.

With VACL Capture you can capture to an Etherchannel of ports. The Etherchannel distribution algorythm can then be used to load balance the traffic on up to 8 switchports (connected to up to 8 sensor appliances).

This capability, however, is limited to VACL Capture and does not work with Span the last time I checked.

In addition the capability last time I checked worked with Sensor Appliances and the IDSM-2 when using Cat OS, but only worked with IDSM-2 when using Native IOS. I have heard that Native IOS has recently implemented this also for Sensor Appliances, but I have not checked into it.

But from a 3750G perspective I am not aware of any Promiscuous Load Balancing methods.

Now if you were looking for inline mode rather than promiscuous, then there does exist a load balancing option.

You can configure the sensors for inline-vlan-pairing mode where the sensor does inline monitoring between 2 vlans on the same port.

You would configure 2 sensors for inline vlan pair mode using the same 2 vlans on both sensors.

Connect each sensor to the switch and configure the switch port to be a trunk port for the 2 vlans.

You woudl then combine the 2 trunk ports into an EtherChannel, and then the Etherchannel would load balance between the 2 trunk ports (between the 2 sensors).

Why the switch will choose the same physical link in an Etherchannel for returning traffic???

Most of the Catalyst switches implement Src-only or Dst-only Etherchannel load-distribution. This is the global switch setting. Outgoing traffic will choose the link with the inline sensor 1 and incoming traffic - may choose the link with the sensor 2, right?

marcabal Mon, 09/17/2007 - 10:40

To work properly the switch must have it's Etherchannel load balance distribution set to "src-dst-ip".

This way the client packets and corresponding server packets will both be load balanced to the same sensor.

The switch will XOR the 2 addresses together and so packets with source A and dest B get balanced to the same port as packets with source B and dest A.

The other load balance algorithms will not work correctly as you described in your post.

The client packets will get balanced to a different sensor than the server packets for the same connection.

There is one algorithm that might look like it would work better: "src-dst-port" For all packets that contain a full UDP or TCP header this works great, but it has a problem with Fragmented packets. The additional fragments do not have TCP or UDP port information so they fall back to being load balanced by src-dst-ip. This can cause the initial fragment to be load balanced to a different sensor then the remaining fragments.

So not even the "src-dst-port" algorithm will work.

So you will need to set the load balance algorithm to "src-dst-ip" for the IPS load balancing to work properly.

shameerali Mon, 09/10/2007 - 00:11

Dear All

our Corporate Network we have IDS 4215 , Last week I have Upgraded to IPS by IPS-4215-k9-sys-1.1-a-5.1-1.img file , and it is working,

My problem we had lincence for the IDS,

Now This IPS asking for the Licence , Can I use Same Licence for the IPS ( I belive Not ), if i want to Buy new Licence , will i get any benifit for the IDS ( I can upgrade IDS Licence to IPS Licence)

marcabal Mon, 09/10/2007 - 15:09

The difference between IDS and IPS for the Cisco IDS/IPS product lines is primarily just a difference in file and product names, and what feature you turn on when configuring the sensor.

If it is an older product then the name starts with IDS. If it is a newer product then the name starts with IPS.

But the majority of the older IDS and the newer IPS products are all capable of both Promiscuos mode (IDS mode) as well as InLine mode (IPS mode).

So you can have an IDS sensor running in IPS mode.

The exception is only the NM-CIDS which can only run in Promiscuous mode. All other IDS and IPS sensors can run in either IDS or IPS mode.

So with an IDS-4215 running version 5.1 or higher you can choose whether to run it in IDS mode by configuring it with Promiscuous interfaces, or run it in IPS mode by configuring it with inline-interface-pairs or inline-vlan-pairs.

The license itself is not specific to the mode you are running in.

The license does not restrict what features you use on the sensor, instead it only restricts what Signature Updates can be applied to the sensor.

The license has an expiration date that coincides with the expiration date of your Cisco Service for IPS maintenance contract for the sensor.

The license allows you to install any Cisco Signature Update released prior to that expiration date.

Once expired the license will prevent you from installing any newer signature updates.

Because the license does not affect functionality there is no change in the license when upgrading software versions or when switching from Promiscuous(IDS) mode to InLine(IPS) mode.

If you still have your license from version 5.0, then simply install it on your 5.1 sensor (or even upgrade to 6.0 and use the same license).

Just be sure your Cisco Service for IPS maintenance contract is up to date so your license will have an expiration date in the future. This will ensure you can all of the latest signature updates.

I also noticed that you installed the System Image file (has -sys- in the filename).

For normal upgrades from a lower version to a higher version you do not need to use the System Image file. The System Image file will erase your current installation (including the license) and install a fresh version with default configuration.

FOr a normal upgrade you want configuration to be maintained. So for a normal upgrade you want to use one of the upgrade files. The upgrade file will install the same version as the System Image file, but will keep your license and your configuration in tact.

The latest upgrade file for the 5.1 version is IPS-K9-5.1-6-E1.pkg.

The System Image files should rarely be used. They are not intended for upgrades, but rather for emergency situation where the sensor has been corrupted and fresh factory installation is needed.

railgun Mon, 09/10/2007 - 09:05

I in need of advice on the following scenario. We plan to upgrade our replace our Pix512 firewall. We got three options from our vendor to chose from:

The first option is redundant Pix515e UR/fail-over mode and the cheapest solution.

The second is redundant ASA5510 with security plus package that costs a bit more.

The third solution is redundant ASA5520 far the most expensive solution.

We need to provide for at least 100 hosts on our LAN that use outside internet, about 20 VPN's from outside users to the network and VPN tunnel from Pix515 in our another facility. The demand is expected to increase. What would be the best choice for us.

First in terms of hardware. What are the key enhancements in ASA over Pix lines. The pixes uses Intel PIII. Is ASA using different architecture? In particular are the Pix 515e and ASA5510 equivalent in terms of their capabilities.

Second in terms of licensing. I'm kind of new to this stuff and want to be clear with the idea since I worked more with routes and switches. In all three options we need redundancy. With Pix for fail-over I understand that active device has UR type of license and the standby may have fail-over, restricted or unrestricted. If we want to have both devices to share the load then we need both of them under UR license -is that right? Also is the licensing scheme on ASA different than that on PIX. To my knowledge ASA5510 can run in both Active/Active and Active/Standby mode. Is A/A mode do the devices share the workload or one of them waits for the other to fail? We don't want any device not utilized. We get the security plus option for 5510.

Last what is VPN plus option on ASA5520. We need to VPN. Are there any additional requirements for VPN for all three above devices. What is advantage of ASA5520 over ASA5510

marcabal Mon, 09/10/2007 - 15:30

My expertise and experience is with the IPS product line. I have dealt with the ASA as part of my testing of the IPS modules for the ASA (the SSM-AIP-10 and SSM-AIP-20), but my knowledge is fairly limited to the interaction of the ASA with the IPS module.

I will attempt to answer some of your questions with my understanding from some past conversations with others, but you may want to confirm this with others more familiar with the ASA and Pix firewalls.

My understanding is that Pix 515e is a good box, but the ASA family is the targeted future replacement for all of the Pix firewall models.

Also the ASA has several features not available in the older Pix hardware. The ASA has a module slot which can be used for an IPS module, or a virus filtering module, (or additional interfaces).

As far as dual ASA deployments, the difference between Active/Standby and Active/Active will be the number and configuration of the security contexts.

For any 1 security context, only one of the ASAs will be active and the other will be standby. If you are not running multiple security contexts then your configuration is forced to be Active/Standby. If you are running multiple security contexts, then half of your contexts can be configured to be Active on the first ASA and standby in the second ASA, while the other half of your contexts are active on the second ASA and standby on the first ASA.

So the first ASA is active for half the contexts and the second ASA is active for the other half of the contexts. If a failure of either ASA ocurrs then the other ASA becomes active for all contexts.

Unfortunately I am not very familiar with the licensing mechanisms in the ASA. But my understanding is that with the ASA you need the same license on both ASAs. Unlike the Pix that used to have a special redundant only license that could be used on the second Pix; the ASA I do not think offers this type of license.

As for what the VPM plus option is, and whether a 5510 or 5520 is better for your deployment; you are beyond by experience of the ASA.

I would suggest re-posting your questions on the Firewalling NetPro Forum:

As I said my expertise is in IPS, and so you may be able to get better clarification on the Firewalling forum from some Pix and ASA experts.

sebastan_bach Mon, 09/10/2007 - 22:51

hi marcabal great to u in the forum.

hi marcabal i would like to know can we use the event action override when we are running the ids in promiscious mode.



marcabal Tue, 09/11/2007 - 10:17

Yes, the event action overrides are fully functional in promiscuous mode.

They can be used to add event actions that are applicable to promiscuous mode.

They can also add deny actions that only take affect in inline mode, but instead of doing the deny the alert will just state that deny was requested but not executed. This can be handy when planning a transition from promiscuous to inline. You can see which attacks would get denied once you do change to inline mode.

mohamed_makled Tue, 09/11/2007 - 02:22

Dear Marco

I will install IPS sensor between an ISA server and PIX 525 (in inline mode) i need your advice to know the following :

-the monitoring interfaces of the sensor should be connected to the outside interface of the ISA server and the inside interface of the PIX or not???



marcabal Tue, 09/11/2007 - 11:21

I assume you are referring to the Microsoft Internet Security and Acceleration (ISA) Server?

If so, then you need to understand what ISA features you are currently using.

If the ISA features are not modifying the packets/connections (encryption or compression); then placing the InLine Sensor between the Pix and ISA Server should work just fine. Plug one interface into the Pix, and one interface into the ISA and in the sensor configuration create an InLine Interface Pair for the 2 sensor interfaces.

However, if the ISA is modifying packets/connections then you may want to deploy the InLine sensor on the inside of the ISA server between the ISA server and your internal network.

The ISA server provides features such as encrypted VPN tunnels, as well as compression and caching of web pages.

If the sensor deployed between the Pix and ISA Server it will not see the packets/connections in the same way that an end user box behind the ISA Server will see the packets. The sensor won't be able to decrypt and/or decompress the data.

To ensure the sensor gets the same view of the data as the end user boxes you would need to deploy the InLine sensor between the ISA server and your Internal Network (aka between the ISA-Server and the switch for your Internal network.)

coolpopsun Wed, 09/12/2007 - 01:02

Hi Sir,

I want to know that in given cisco switch ,How can I used the fibre port ,what converter(with part number) will used and what are the connectivity ,is there possible to use fibre port in given switch .how......... please also explain can we used 2 uplink as a fibre ... also if possible please send me the link so that i can see the pic.


? 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active)

? 1 RU fixed-configuration

? LAN Base Image installed


Sunil Sharma

[email protected]

marcabal Wed, 09/12/2007 - 11:33

I am not specifically familiar with the WS-C2960-24TC-L, but I looked up the data sheet and here is what I have been able to understand.

The C2960-24TC comes with 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active)

SO you will need to configure the switch to use the SFP-based Gigabit Ethernet port (check the switch configuration on what commands are needed, or it may be automatic with an SFP is installed).

You will also need to plug in an SFP that is compatible with the sensor fiber ports.

All of our sensor fiber interfaces are 1000BASE-SX (Short Haul) Gigabit fiber interfaces.

So you will need to use an SFP that is also 1000BASE-SX (short haul).

In you case that would mean purchasing a GLC-SX-MM= which is the part number for the 1000BASE-SX SFP.

Understand that when dealing with fiber interfaces there is generally:

A) a 2 letter abbreviation for the optics distance, (SX for short haul, LX for long haul, as well as a few other ones as well)

B) a 2 letter abbreviation for the mode of the fiber cable (MM for Multi-mode fiber, and SM for Single-mode fiber), and

C) a 2 to 4 letter abbreviation for the type of physical connector (SC, LC, MTRJ as well as a few other options) (This is primarily just the plastic connector around the fiber and does not affect the data traveling within the fiber)

The GLC-SX-MM= is a SX (short haul) transceiver using MM fiber (Multi-Mode) with an LC style connector.

All of our sensors are SX (short haul) and use MM fiber (Multi-Mode).

The style of connector is different depending on which sensor you are talking about.

The IDS-4250-SX uses an SC style connector.

The IDS-4250-XL uses a MTRJ style connector.

The IDS-4260 uses a LC style connector.

So if you want to connect your switch to a IDS-4250-SX you would need a Multi-Mode fiber cable with an LC connector on one end of the cable and an SC connector on the other end of the cable.

So be sure to purcahse a Multi-mode and not a Single-mode fiber cable, and be sure the 2 connectors on the cable will match the 2 boxes you are connecting. LC on one side for your switch, and then other connector will be determined by the sensor interface you are using.

As far as the capabilities of the switch port and the sensor port from a sofwtare feature standpoint, you will need to read your switch configuration.

Most Cisco switches are able to treat those uplink ports similar to the other 24 ports of the switch. So it likely can be configured as a span port for promiscuous monitoring, an access port for one interface of an inline interface pair, or a trunk for doing inline vlan pairs.

From the sensor configuration the fiber ports are capable of all the same features as the copper ports (with the exception of setting speeds of 10 or 100 of course)

zlabovic Tue, 09/11/2007 - 08:20


Is it possible to change rule set for virtual sensor after the creation of one? I have the situtation where I have rule0 associated with one virtual sensor and I would like to change the association to another rule.

marcabal Tue, 09/11/2007 - 11:27

Yes, you can change the event-action-rules configuration instance applied to user created virtual sensor.

Create a new event-action-rules configuration instance first.

Then edit the virtual sensor itself, and tell it to use the new event-action-rules configuration instance.

The same can also be done for signature-definition configuraiton instances, and anomaly-detection configuration instances.

NOTE: rules0 is the default event-action-rules configuration instance. On any platfrom supporting multiple virtual sensor the user can create additional instances using any name that the user wants (some character limitations apply). For example: rules1, myrules, dmzrules, etc..

This ability, however, is limited to only those additional virtual sensors that the user creates. The default virtual sensor vs0 can not be changed to use other configuration instances. The default virtual sensor vs0 MUST use the default sig0, rules0, and ad0 configuration instances.

DSmirnov Tue, 09/11/2007 - 10:44


can you share any new features or direction in upcoming versions of Cisco IPS?

Technical questions:

- SQL injection related signatures: is it possible to improve 'SQL in HTTP' signatures to reduce a number of false-positive alerts (for example specify the type of served pages .jsp, .asp, etc or rewrite regex, etc)?

- Will it be a good idea to have one more brute-force related signature for FTP?

For example 6250 is looking for multiple failures in the same FTP session. Same time looks like attackers are using separate sessions for each auth. attempt. Currently 3171 is currently doing something similar but it detects both brute-force and normal 'Admin' connections. Is it possible to improve?

marcabal Tue, 09/11/2007 - 12:00

Unfortunately I am unable to discuss any new features in Cisco IPS on this public forum.

We have plenty of cool features coming up, but our Marketing team makes the call on when they can be announced and discussed on Public Forums such as NetPro.

For improvements on SQL in HTTP signatures I will need to spend some time discussing this with our signature development team.

6250 looks for 3 530 responses (typically means a failed login) coming from an FTP Server. The 3 530 responses do Not have to be in the same session, the respones can be on 3 separate sessions.

Be sure you have the latest signature update loaded and then look at the event count key for the signature. An event count key of attacker and victim means the 3 reponses just need to be seen between the attacker and victim address on any numner of connections.

If the event count key had been attacker and victim addresses "and ports", then it would all have to be on the same session.

I remember some discussion on this several months ago, so it is possible that this event count kwy may have changed within the past couple of months. So be sure you have the latest sig update on your sensor.

Is there something beyond this that you are wanting to search for.

As for the 3171 signature it is technically only looking for a single attempt to login as root or admin. unline 6250 that requires 3 failures before triggering an Internal Signature Event, the 3171 will trigger an Internal Signature Event on each and every login attempt by root or admin.

You could get 6250 to act similarly by just changing the event count to 1 instead of 3.

Some other possibilities you could consider.

You could CLONE the 6250 signature to a custom signature. In the custom signature change the event count key to be just Attacker address, and set the event count key to 5 (or any other number). Then it will monitor for that Attacker address failing 5 login attempts to ANY victim ftp server.

But keep in mind that slow attacks may not build up the counts enough to trigger the signature.

The sensor is limited by memory. It will try to remember Matches for as long as it can, but if it needs the memory to monitor incoming connections it will be forced to forget about those older Matches.

So if you have 2 Matches and are waiting on the 3rd Match to trigger the signature. If the 3rd Match comes quickly the signature will trigger because all 3 Matches are in memory. But if the 3rd Match comes in minutes later, then the first 2 may have been removed from sensor memory if the memory was needed for monitoring newer connections.

If these are concerns for you, then be sure to purchase sensors rated higher than you need for your network. The higher the rated sensor, the higher the amount of memory and the longer the Matches can be maintained in memory when monitoring your lower bandwidths.

mspoerr Tue, 09/11/2007 - 12:31

Hello Marco,

I have not found this in the ASA / AIP-SSM documentation:

When we only want some sessions to be inspected by the AIP-SSM module we define the sessions with an ACL. Is the returning traffic also inspected by the IPS module or do we need to specify it in the ACL?



marcabal Tue, 09/11/2007 - 12:50

Hopefully the following link will help answer your question:

The second Example in the "Inspect Specific Traffic with the AIP-SSM" goes into a little more detail.

In the case of TCP if the SYN packet for the connection is sent to the SSM for analysis, then because of the ASA's ability to TCP state tracking it will also send the corresponding SYN ACK from the server regardless of whether or not the ACL would have matched the SYN ACK packet.

So for TCP the return traffic is also inspected.

For ICMP, however, the ASA does not do statefull tracking. So with ICMP if an echo request is matched by the ACL and sent to the SSM, this does not automatically mean that the echo response will be sent to the SSM. The ACL must indpendantly match the echo response to send the response to the SSM.

What I am not sure about is what happens if the SYN packet does NOT match the ACL (or is denied by the ACL), but the SYN ACK packet DOES match the ACL (permitted by the ACL).

I am not sure if the entire TCP Session will or will not be sent to the SSM, or if half of the TCP session would be sent to the SSM.

I believe UDP is treated similarly to TCP where the first UDP packet between the addresses/ports will be treated similar to the SYN packet of a TCP connection. So if the first UDP packet is matched and sent to the SSM, then UDP packets being returned from the server will also be sent to the SSM.

However, I have not specifically tested it, and so am not 100% sure.

My recommendation has generally been to go ahead and specifically state it in the ACL.

So when creating a permit entry for one direction of traffic, to go ahead and create a second permit entry for the opposite direction of traffic.

By following this recommendation you can be more assured that both directions of traffic will make it to the SSM regardless of whether it is TCP, UDP, or ICMP traffic.

When I tested AIP-SSM in 7.2(1) I found that ASA incorrectly passes packets to the AIP-SSM if NAT is involved:

For Outside->DMZ AIP-SSM sees:

Attacker-IP -> Private-Server-IP (after de-NATing)

For returning traffic AIP-SSM sees:

Public-Server-IP (NATed IP) -> Attacker-IP.

This happened when service-policy is applied to an ASA interface (for global_policy sensor always sees Private-Server-IP).

Has it been corrected and in what PIX OS release?

marcabal Mon, 09/17/2007 - 10:49

This has always been the case. The actual packets will contain the local address in one direction and the translated address in the other direction.

However, this does Not cause a problem for the SSM.

The SSM does not look at the addresses in the packet itself.

The ASA attaches an additional header to each packet. This additional header is not viewable without special software (the sensor analysis software is able to read the additional header). The driver will strip off this special header when sending packets to the "packet display" comand in the CLI or the "tcpdump" run through the service account.

This additional header contains the local addresses and ports for both the source and destination addresses. This way the sensor will analyze the packet based on the local addresses regardless of whether or not the tranlated address is seen in the packet.

I think this will cause problems for the applications like IEV or MARS and for the security staff, for example, when "direction" is set to "FromService". In this case an attack is detected when traffic is returning from the server. If our servers are behind the NAT or PAT (port redirection) those applications will see public (NATed) IP (and the SAME IP if PAT is used for all of the servers). This is inconvenient to say the least.

marcabal Tue, 09/18/2007 - 20:16

I am not sure if I am understanding your concern. The SSM should be reporting the alert with the real address of the server and not the translated address/port.

The SSM receives the packet with the translated address, but the special packet header from the ASA contains the real address and the SSM analysis will be done using the real address and not the translated address in the packet.

The alert will contain the real address.

However, if you have configured "produce-verbose-alert" event action then the trigger packet itself may contain the translated address.

It is kind of weird but you could see an alert containing the real address, but the trigger packet having the translated address.

Was I unclear before and you thought alerts would show the translated address? Or are you actually wanting the translated address in the alert?

Or are you seeing something different in your network? The alerts should contain the real IPs and not the translated IPs. If your alerts are showing the translated IPs then let me know what verion of the ASA software and IPS software you are running and what signature IDs you are seeing this on. You may have found a bug we did not know about.

I tested it some time ago and saw translated IP in IP session logs (log-pair-packets action). Don't remember exactly about alerts :( If alert contains the real IP - we can leave with such behaviour, but, I agree, this is little bit weird.

The problem is that the order of operation of Adaptive Security Algorithm is not very well documented. This is really confusing to see the real IP in IP session logs when a service-policy is applied globally and translated IP when the same policy is applied to the ASA interface. It would be better to always see Private (real) IP in alerts, logs, and captured packets.

vironet Tue, 09/11/2007 - 17:22

I have a server which is under attack with i think DDoS with syn flood, i installed a IPS but i only see a 1307 Sig ID, i still continue affect my server, in a router y put tcp intercept whithout changes, what would you reccomend me to do?

i?m desesparate.


marcabal Wed, 09/12/2007 - 10:49

Have you checked your router with the "show tcp intercept connections" and "show tcp inercept statistics" to determine if the router is actually intercepting the tcp connections?

If not you may need to tune the ACL used in your tcp intercept comnmands to ensure it is matching the connections you are concerned about.

Or tune one of the other tcp intercept commands to get the intercept feature to work the way you need to.

Here is a link discussing the tcp intercept feature that may help you:

One thign to also check is that it is in fact a Syn Flood causing the Denial of Service.

A Syn Flood is a specific type of Denial of Service where the Syn packets are spoofed by the client. The attacker masquerades as other IP addresses sending Syn packets, and the connections never establish, because the spoofed client will never send an ACK packet in response to the server's SYN ACK packet.

There is, however, other forms of Denial of Service. The attacker may be executing valid TCP connections to your server from real clients under full control by the attacker. The clients may simply be sending or requesting large amounts of data that is just overwhelming your server. In this form of Denial of Service all of the connections are valid TCP connections, and the tcp intercept (or any other standard Syn Flood protection mechanisms) will not protect against them. The tcp intercept will only prevent invalid connections where the Syn is spoofed, and can not prevent valid TCP connections where the tcp connection is able to fully establish from a real client.

To differentiate between the 2 you would need to sniff the traffic and determine if you are winding up with half open tcp connections (SYN from client, SYN ACK from server, but no ACK from client), or if you are seeing full tcp connections (SYN, SYN ACK, ACK, followed by the rest of the connection's packets).

A Denial of Service using valid TCP Connections is much harder to defend against because the network devices are unable to determine if the connection is coming from a valid user, or from an Attacker.

Rate limiting the number of connections to the server may help, but may also prevent legitimate users from accessing the server.

The Cisco IPS sensors do have signature 3050 that can detect a Syn Flood attack (but will not detect an attack using valid connections).

The signature is on by default, but the number of incomplete connections being watched for may be too high for your specific server.

You can tune the 3050 signature by modifying the "SYN flood max embrionic" parameter.

By default it looks for 5000 embrionic (SYN, SYN ACK, without ACK) connections before firing, but you may want to tune this down to only a few hundred depending on the capability of your server.

If you are running inline mode, the 3050 signature can also do SYN Flood protection similar to the router's "tcp intercept" feature. Configure the signature with a "modify-packet-inline" action.

It works for most of the IPS Appliances, but does have a performance impact on the sensor. Last I heard it is not working yet on the IDSM-2 or IDS-4250-XL. It also does not function with the ASA-SSMs because the ASA itself can do the SYN Flood protection.

Just an FYI:

The methodogy for SYN Flood protection used by both the modify-packet-inline event action for sig 3050 and the tcp intercept feature of the router is more generally known as SYN Cookies.

So if you determine that it is a Syn Flood, and you are using an inline sensor you do have the option of using "modify-packet-inline" on signature 3050.

BUT because of the performance impact, and the fact you are already trying to use tcp intercept; my recommendation would be to continue trying to get tcp intercept to work prope

zaidumer Wed, 09/12/2007 - 01:50

Dear marco,

i have an ASA-5520 with an AIP-SSM10 module,

the time on the ASA device is manually set to my local time. but the time on the AIP-SSM10 module is different and i cant seem to change it using the IDM GUI.

how can i manually change the time on the module, cause ive tried the clock set command ant it turns out that its not supported on the AIP-SSM10 module. i really need to chuse otherwise i cant make out the the logs im getting for tuning the signatures accoring to my traffic type.



marcabal Wed, 09/12/2007 - 12:02

You can not directly set the time on the SSMs. The SSMs do not have a battery and so can not maintain the correct time should the SSM be powered off and on.

So instead the SSM must gets its time using 1 of 2 methods.

The first method is the default and it will sync with the ASA on bootup and will re-sync with the ASA anytime the ASA time changes.

The second method is to configure an NTP server and set the SSM to sync to the NTP server.

So in your situation if the ASA is properly set to your local time, then the SSM should also have sync'd to the same time when the ASA time was changed.

First thing to check is the timezones on your boxes.

The common problem is that the timezones have not been configured properly on both the ASA and the SSM. A big reason for this is that the ASA configures it's timezone using HOURS offset from UTC while the sensor uses MINUTES offset from UTC.

So for example, if the ASA is configured with a local time zone of CST with an offset of -6, then the SSM should also be configured with a time zone of CST but the offset needs to be -360 because on the SSM it is in minutes instead of hours.

Another area of confusion is the summer-time (daylight savings time) settings. You need to ensure that if it is configured, then it needs to be configured on both the ASA and SSM.

If the configuration of the ASA and SSM are in sync and the time is still incorrect on the SSM then proceed below.

There is the very small possibility that the SSM may have had communication problems with the ASA chassis during the last time the ASA clock was updated.

Try resetting the SSM and see if it re-syncs the time with the ASA.

If after the reset it does properly reset, then just watch the SSM for the next couple of weeks and see if it stays in sync. If it gets out of sync then contact the TAC because you may be running into a new bug and development may need to look into it.

If it does not sync up with the reboot, then check to ensure that the ASA is recognizing that the SSM has rebooted and is back up and active.

You might try upgrading the version on the ASA and SSM to ensure you have all of the latest bug fixes. If the times still do not sync, then contact the TAC for assistance in trying to further debug the problem. You could also send me your ASA and SSM configurations and I can check to see if the time configurations are correct for the 2.

bradatcyber Wed, 09/12/2007 - 08:21

I am currently testing a software upgrade that updates rule sets to both Cisco and Juniper routers simultaneously through a custom interface to gain better management of firewalls and security. Since this is fairly new to me, I wanted to know what else I would need in order to prevent intrusive attacks. Thanks!

marcabal Wed, 09/12/2007 - 13:52

I assume that "software upgrade" in the above paragraph is for something other than the Cisco IPS software on Sensor Appliances and Modules. Because the sensor Appliances and Modules do not support modification of configuration on Juniper devices.

From your statement I am assuming you have built your own tool to do the configuration modification on the routers.

I also assume that tool is primarily modifying access control lists, and possibly rate limit policies to prevent or rate limit certain types of traffic into your network.

So the question becomes what are you using as input to decide when and what to change on the router configrations.

You might be reading through daily postings or email lists discussing the latest vulnerabilities. In which case you could be blocking entire ports because of vulernability known in a particular service.

But often these vulnerabilities are in commonly used services. SO you can't simply block the ports to all traffic.

This is where an InLine IPS becomes the tool of choice.

The Routers access lists are often based solely on the port, and so you can not differentiate between valid traffic on the port and attack traffic on the port.

Some routers do come with advanced features to look further into the traffic at a layer 3 or higher level, and determine what specifically is going on. Depending on what you are trying to prevent you might be able to detect it using these advanced features of the router.

However, some of these advanced router features may be too performance intensive for the router to handle, or may not be detailed enough in nature to look for the specific attacks you want to detect and defend against. Most are looking at the service level, to allow or disallow what can be done at a service level without digging into the actual data passed within the service.

This is where an InLine IPS comes into play. The IPS software is purpose built to dig into these higher layers looking for the attack itself within the data. The IPS is then able to Deny the connection where the attack was detected.

This way the valid traffic will continue through the sensor, and only the attack connection would be Denied.

So the InLine IPS is best deployed in conjunction with your routers (or firewalls). Where the router does the initial filtering of ports/protocols that you do not want into your network, and possibly some advanced service level filtering to control the types of services allowed into your network.

While the InLine IPS digs deeper in to the traffic that the router does allow to ensure that an attack is not taking place within that traffic.

There are also additional devices and software that provide even more protection possibilities. An example would be Cisco Security Agent which gets installed on your end hosts which helps protects against those attacks that are not detectable by the InLine Network IPS.

There are numeruous other security appliances offering additional protection in different areas.

What you see is that Cisco's security recommendation is not a single product. It is a suite of security products. Each product provides more and more granular control of different areas of your network.

You will just need to determine what level of security your orgnization is needing and discuss with your Cisco Sales Representative to determine the suite of products to get your to your desired security level.

I am not sure if this answers your question.

If you are looking for different information, then please expand and let me know what you want to discuss.

josephium Thu, 09/13/2007 - 01:59

Dear marcabal,

its great to have an expert like you on this forum, i have 2 ASA 5540 with AIP-SSM 20

and i have 2 questions plz:

1- how to test the IPS, a lot refer to metasploit, can you give me a detailed exploit to try or a detailed test you do when testing or auditing an IPS.

2- each time i do a major upgrade on the AIP-SSM for example from img 6.02 to 6.03 the AIP will restart at the end of the upgrade and this triggers the ASA to do a Failover, is there a way to bypass that?

thank you very much for your time

twwagne Thu, 09/13/2007 - 11:45

I would like to use the 60 day Trial-License on my 4215. When I purchase a valid license later, what issues will I face entering that valid license in a production device? Will the box go down while the new key is entered? Will performance be affected, etc.?


marcabal Mon, 09/17/2007 - 10:56

There is no problem in going from the 60 day trial license to the purchased license.

The sensor should experience no noticeable downtime or performance affect when the new license is installed.

The only affect is the extremely small amount of cpu to read and validate the new license and write it to the compact flash (or harddrive).

You woudl have to have very sensitive test equipment to detect any affect on the sensor performance, and it would be less of an affect than most configuration changes.

The license does not affect the daily functioning of the sensor. The sensor functions just fine with no license installed.

The license is only used when loading a signature update. The signature update will check the trial or purchased license on the sensor, and will only install if the signature update was originally released within the expiration date of the license (or in the case of the purchased license it must be within expiration date of the license, or within the following 60 day grace period after the license expiration).

Hi Marco,

Glad to hear from you in this forum.

1. I'd like to know how to diagnose situations when a sensor is unable to handle traffic load. Which of the following Cisco monitoring applications can show/sort/search thru Status events to show me such important events as "Missed packet perc. thr. exceeded" or "Inline Bypass started"? IEV? MARS? CiscoWorks? Etc?

2. Is it correct that traffic is passed uninspected if the sensor cannot handle the load? If yes, can this be changed with bypass-mode set to OFF?


marcabal Mon, 09/17/2007 - 11:18

Unfortunately none of the current event monitoring tools have the capability to notify you when the sensor is oversubscribed, or if ByPass kicks on.

IDM's home page does have an entry for the Missed Packet Percentage as well as the current ByPass setting. So if using IDM, then you can watch the home page to see if packets are being missed.

I haven't tested it myself, but I believe that the sensor is able to generate SNMP Traps when the sensor is oversubscribed or InLine ByPass is started. There are error events for these, hand the SNMP agent can be configured to send traps for error events.

However, the teams have heard users requests for this type of monitoring. And I know that designs are be considered to improve the health and welfare monitoring of the sensor by the management tools (which includes the items you mentioned).

As for what happens when the sensor is oversubscribed, the sensor will NOT pass uninspected traffic so long as the sensorApp process is still running. If the sensorApp process is not able to analyze the traffic then it drops the packets and you start to see the Missed Packet Percentage increasing.

So the ByPass setting has no affect on oversubscribed packets. So long as sensorApp is running, the ByPass configuration does not matter. The ByPass setting only has an effect when sensorApp goes down.

If sensorApp goes down (because of a bug, or an upgrade or config change intentionally bringing sensorApp down), then the user's configuration for ByPass will be checked. If the ByPass is set to Auto then ALL traffic will be passed uninspected while sensorApp is down. If the ByPass is set to Off then NO traffic will be passed while sensorApp is down (and the sensor will Link down it's interfaces).

Well, it's getting interesting! What happens with the TCP session if some packets of this session could not be processed by the sensor and the sensor is in the inline mode? How will normalizer react on this? Will the session hang? Will the norm. wait for retransmition of those packets? Or, will the norm. resync with sequence numbers?

Taking above into consideration, what max. level of oversubscription is allowed for IPS sensors? Any practical guidelines? Are marketing numbers for sensors bandwidth real (65 Mbps for 4215)?

One more question.

In 5.x Missed-percentage-threshold is 0. Does this mean that the sensor will not notify me in case of oversubscription?

And thx. a lot for your answers!

marcabal Tue, 09/18/2007 - 20:51

In an InLine sensor, if the sensor is oversubscribed and drops the packets, then the packets do not make it to the end destination host.

In the case of TCP, the source host will resend the TCP packets because it fails to receive the acknowledgement from the destination host. The sensor will simply analyze the retransmissions.

In the case of UDP, the source address does not know the end host did not get the packets. UDP is not guaranteed transmission so the UDP protocol is not used when guaranteed transmission is needed. OR the service using UDP has implemented its own guarantee in which case the service should retransmit similar to how TCP would retransmit.

However, BYPASS ON or BYPASS AUTO ON is a different situation.

When the sensor goes into ByPass mode by either the user manually setting it to On, or by it switching automatically to On (like during a sig update), the sensorApp process is aware that a ByPass event took place. the normalizer knows that a ByPass event took place and knows that some TCP packets may have legitimately passed through the sensor while in ByPass. It will automatically re-sync its sequence number tracking on the first packets for each connection after the ByPass event. Once it does that initial sync it will once again start doing normal tcp sequence tracking.

As far as what oversubscription should be acceptable that is going to be up to individual users. A good rule of thumb is if the sensor is constantly oversubscribed (constantly dropping packets), then you might try manually retiring some signatures. But if the drop percentage is over more than 5% you might want to go ahead and budget for a faster sensor, or look for load balancing possibilities.

If the sensor is only rarely oversubscribed then a few configuration changes may correct it. Or you may choose to live with the occasional 1 - 5% drop during the oversubscription.

Creating custom signatures (especially ones with *s in them) can use up memory and slow sensor performance. Try temporarilly removing custom signatures and see if the oversubscription goes away. If so then you can either keep them in and accept the drops they will cause, or retire some Cisco signatures to make room for your custom signatures, or see if you can write the custom signatures in such a way that you can remove the wildcard characters like *.

You might also try watching for when the oversubscription happens. There may be a daily database backup from your datacenter servers taking place which oversubscribes the sensor. You might try routing that traffic around the sensor, or intentionally putting the sensor into ByPass while the database backup takes place.

marcabal Tue, 09/18/2007 - 20:51

As for whether or not the marketing numbers are real. The answer is that your mileage will vary. The marketing number is based off HTTP Connections which are the most common connections on the internet. With each connection pulling down a 10,000 byte file.

No real world network will traffic that exactly matches this profile because every network has a wide range of protocols and in HTTP the connections will pull down a wide range of file sizes. But when this was researched a few years ago it was determined that the traffic mix we use places a similar load on the sensor as the traffic mix in real world networks. So it is not an exact match, but does supply a similar load to the sensor as many real world networks.

HOWEVER, keep in mind that not all real world networks are the same. We have seen several real world networks where the traffic mix created even less load on the sensor and the sensor was able to perform even above it's rated performance when placed on those networks. While we have also seen networks with a traffic mix that places even a heavier load on the sensor, and the sensor could perform quite a bit lower than it's rated performance.

So the marketing number is a calculated estimate on how we expect the sensor to perform in an average real world network. And is not a guarantee that it can perform at that speed for all network situations.

As for missed packet percentage threshold being "0", it has been awhile since I have dealt with that configuration option. But if my memory is correct, that setting means to generate an error event any time there are drops since the drops will cause the percentage to be greater than 0.

However, I can't remember if the software does rounding or not. If it does not do rounding then a drop of a single packet will cause a drop percentage greater than 0 (even if it is just 0.0000001) and would generate an error event. But if it does rounding (and I think it might) then it would take 0.5% or more because it would be rounded up to 1% which is higher than 0%. At 0.49% it would round down to 0% and not generate the error event.

So a 0% setting WILL cause an oversubscription event to still be generated, but I just can't remember if it is a single packet drop or 0.5% drop that has to happen to have the percent be over 0%.


This Discussion