IDSM traffic calculation

[jerryd]

We have recently deployed the IDSM in our 6509 switches. Ive looked through the documentation and I came across a section to calculate how much traffic to sent to the capture port. My sensor is in slot 9. According to this documentation I should be able to do a "show top pkts N" to show the number of packets and bytes being sent to the capture port and then calculate the traffic, however when I issue this command my sensor capture or control port dont show in this list. Currently I think I may be over subscribing the sensor but Im not sure. It was working fine but now Im getting sig 933 and Im getting 100% packet miss counts but I dont believe this is correct. Im using VACL to capture traffic and have a permit ip any any capture. If I look at the traffic on the specific vlans Im capturing on the msfc and total all those input and output totals shown for 5mins I dont get more than 100Mbit. Im running the 3.0(2)S6 version of the software on this IDSM. Is there another way of seeing what traffic is being sent to the IDSM blades so I can make sure Im not oversubscribing them?

Thanks

Jerry

[marcabal]

It appears that later version of Cat OS may have a bug which prevents show top from showing the counts for the IDSM ports. We are looking into it, and will hopefully have it fixed in a future build.

WorkAround:

Until then would it be possible to downgrade to version 6.1.1b for a short period while you use top and then upgrade back to your current version once you've been able to analyze how much traffic is going to the IDSM?

As for anothe way of seeing the traffic being sent to the IDSM:

Attach a sniffer to the switch.

Configure the sniffer port in the switch with the same configuration you used for port 1 of the IDSM.

Now both the IDSM and sniffer should be seeing the exact same traffic.

Marco

[jerryd]

Downgrading the Cat OS software is not an option as we are collecting netflow data and using this for billing purposes. We will have to wait for the future release of the Cat OS where the show top commands are fixed. In the meantime we have spanned the same Vlans and looked at the traffic with the sniffer.

After looking at the traffic with the sniffer we arent sending too much traffic to the IDSM, so the triggering of the 933 signature is incorrect. I also had to reinstall the application partition as it wouldnt see any events after the 933 signature was triggered, even if I disabled the 933 sig. All is working fine as long as I dont enable the 933 sig.

Thanks for the response

Jerry

[suzanne.nichol]

We have got a similar problem after upgrading one of the IDSMs to version 3.0(2)S6, we are getting 100% missed packet count. Is this a known problem and is there a fix??

[lathem]

There are a couple of known bugs that can cause the IDSM to stop processing packets. This will result in continuous messages that 100% of the packets are being dropped. These bugs are fixed in the 3.0(2)S10 release which should be on CCO by the middle of next week.

If you see varying percentages of dropped packets, the IDSM is still processing packets, but is overloaded.

If these are small isolated bursts of dropped packets, you may tune the 993 signature to only alarm if the absolute number of dropped packets or the percentage is above a threshold, which is zero by default.

If you see continual alarms (but not 100%) you need to consider reducing the amount of traffic sent to the IDSM by changing the VACLs or SPANs in the switch.

[jeff.gift]

Since the S13 update, I notice Sig 993 alarming with somtimes 0% or 1% missed packet count. My IDSM will run for about 6-8 hours and then start alarming at 100% missed packet. The IDSM just stops sending any events to the CSPM. I have calculated that via SPAN the IDSM port 1 is monitoring between 20-30 mbps during the day. I am using CSPM 2.3.3, IDSM 3.0(3)S10 and have selected in CSPM 3.0(2)S10 as advised in another response. Any advice on this matter before I call the TAC. Thank you!

[marcabal]

Please call the TAC and reference DDTS:CSCdv77620.

There will be certain command outputs they will need from you, and will be able to get you engineering and diagnostic images to help us in determining the cause of your issue.

Marco