Things to check.
IS the alarm firing?
The alarm has to fire before the sensor will even attempt a TCP Reset.
Does the alarm show that a TCP Reset was attempted (In the CLI and in IEV there is a new field to show if a TCP Reset was attempted for the alarm)?
If the field is not there, then the sensor has not attempted a TCP Reset.
Check your sensor configuration, and verify that you are configuring a signature that makes sense with a TCP Reset (floods, sweeps, udp attacks etc.. do not make sense with TCP Reset actions).
Does the switch have counters (I am not used to the Cat 4000 so I am not sure what is available)?
If so then reset the counters on the switch for that port.
Execute the attack.
Then check the counters and see if the transmit counter goes up by 200 packets.
Do the packets being sent to the switch have dot1q headers?
Check the vlan entry in the alarm.
If the vlan is set to 0 then the packets were not dot1q trunk packets so the sensor does not know the vlan.
In these situations the vlan assigned to the port needs to match exactly the vlan being monitored. In your case "set vlan 2 4/10"
If the vlan is set to 2 in the alarm then the packets were dot1q trunk packets.
The sensor port then needs to also be a trunk port. In your case:
set vlan 1 4/10 (setting the native vlan to something other than vlan 2)
set trunk 4/10 on dot1q (making the port a dot1q trunk port.)
set trunk 4/10 2 (setting the port to trun vlan 2)
clear trunk 4/10 x,y,z (x,y,z should be the list of all of the vlans not being monitored.)
NOTE: The commands above are for Cat 6000 running traditional Cat OS. The commands on the Cat 4000 may differ.
