Reset from IDS4210 and IDSM2 dont work

Question

Hallo,
I've following Issue:
Reset from IDS dont work when Reset interface attached to IOS running switch, or IDSM2 Blade is in IOS Switch.
I've found many configuration examples how configure reset from IDS but all of them characterize ONLY
how to configure CAT OS switch,not IOS.
1.I've configured Sygnature to be Reset,
2.I've started Attack from Internet to DMZ Server
3.IDS Matched Attack, send 100 resets in both directions, to server and to me. I can see it on IDS CLI, and on switch port input packets are increase.
4.But the resets packets never arrive me or server.

Answer 1

Native IOS is more restrictive than Cat OS.
If you are monitoring using VACL Capture in Native IOS then the capture is not allowed to receive ingress packets (the tcp resets):
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/swconfig/secure.htm#wp1066900
–The capture port supports only egress traffic. No traffic can enter the switch through a capture port.
The same is also true if you are using Span in Native IOS:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/swconfig/span.htm#wp1020380
When you configure a port as a SPAN destination port, it can no longer receive any traffic.
So a IDS-4210 connected to a Native IOS switch and monitoring with either VACL Capture or Span will not be able to send resets into the switch.
The IDSM-2, however, should not have this issue.
The IDSM-2 does not send resets back out the same port that is being used for monitoring.
Instead the IDSM-2 has a separate reset port.
In Cat OS this reset port is /1, and in Native IOS the user doesn't even see the port since no configuration of the port is necessary.
The reset port is (by default) a 802.1q trunk port of all vlans.
So the IDSM-2 should be able to monitor with either VACL Capture or Span and still be able to send TCP Resets to reset the connections.
We have, however, discovered recently that there is one vlan where this does not work. Vlan 1 traffic is not being properly reset. Vlan 1 is being treated differently by the data port monitoring the traffic, and the reset port. One of the ports is using 802.1q trunk headers for vlan 1 while the other port does not. So the resets are being rejected by the switch.
So if you are monitoring on vlan 1 then the resets won't work, but the resets should work for all other vlans.
(This affects only Native IOS).