1. IPS Sensor
2. Software Version 7.0(2)E3From IPSpedia
1. show version
Show version output is useful for identifying when the last update was applied to the sensor as well as identifying uptime and build. Many performance issues begin after a certain update is applied to the sensor.
2. show interface
Show interface contains several useful pieces of information including link speed, link duplex, missed packet percentage, fifo overruns, jumbo packets, and undersized packets. The link speed and link duplex items should usually read auto_100 (or auto_1000 for gig interfaces) and auto_full for duplex. An auto_half is almost certainly the result of a misconfiguration on the opposite switchport and can cause serious performance issues. Verify that both sides are configured as auto detect if you see this. The missed packet percentage tells you what percentage of the packets received on the interface were dropped. This is essentially the overruns/total packets. If this number is anything greater than 0-1 then there is probably an oversubscription issue in play. Remember to check this value in conjunction with the total packets and FIFO counter as the missed packet percentage may be skewed heavily if there isn’t a significant sample size. Having a very low number of packets processed indicates a more fundamental problem in most cases. High numbers of Jumbo packets could also lead to performance issues due to defects in the IPS software. High numbers of undersized packets could indicate ethernet collisions. This is a very uncommon problem given today’s mostly switched infrastructure but it can still happen. Alternatively, high numbers of undersized packets may also indicate a physical problem with a cable or switch. Either way, these underlying issues could certainly cause blanket performance issues for traffic traversing the sensor.
3. show statistics authentication
Authentication failures can indicate a misconfigured management workstation and in some cases can cause resource issues on a sensor. If this number is more than single digits, investigate which station is initiating the failed authentications and address ie.
4. show statistics analysis-engine
This command contains some useful information regarding which engines are inspecting traffic and how often. When the sensor is having a performance issue, check to see which inspectors are having may calls for a possible lead on which signatures may be causing a problem. This will often lead you to signatures which have been created/modified by the customer.
This output also gives you the uptime of the analysis engine in seconds. This can be useful for calculating various rates since almost all counters on the sensor will be relative to this value unless someone has manually cleared them.
5. show statistics denied-attackers
This output will show which IP addresses have been denied by the sensor. If a particular address (or addresses) are having problems accessing specific resources you can check here to see if it’s simply as a result of a deny action of one of the sensor signatures.
6. show statistics event-store
This output gives a summary of the signatures events that have been created on the sensor. Very large numbers here may indicate that too many signatures are enabled with logging (perhaps meta components) which could lead to performance issues. Also, this output shows the number of status events (non signature events generated by the sensor). A large number of error events may warrant further investigation in the “show tech”
7. show statistics host
8. show statistics virtual-sensor
User have IDSM with 100% inspection load on busy hour and followed by missed packets percentage increasing at that time.
The IDSM interface is setting as promiscuous interface Is it means my network throughput will limited by IDSM max inspection load / throughput which is 600Mbps?
No, the throughput will not be limited in the network when you are in promiscous mode. But your visibility for attacks is highly limited. You should configure your span/capture settings on the 6k5 to only send as much traffic to the IDSM as this module can handle.Just remember that the IDSM-2 is a ten years old system and can't catch up with the typical traffic-demand we are having nowadays. It's time to change the IDSM against an actual external sensor.