In answer to 1:
In most cases it is a simple preference of the user, but there are a few specific cases where one is better than the other.
Personally I prefer to use VACL Capture. It provides more granularity at the IP layer to determine what I want monitored.
Other users, however, prefer to use Span for these in configuration. Also Span is well understood by most network administrators and has been used for several years, while VACL Capture is still fairly new to most users.
The situations where VACL Capture have an advantage are generally where more than one sensor will be deployed. There are a limited number of span sessions that are supported by the switch. Because of the IDS sensor's need to see both directions for a TCP connection (client->server, and server->client) this many times requires a Both (TX+RX) span session. The Cat 6500 has a limit of 2 Span sessions when doing Both TX and RX.
With VACL Capture, however, the limitation is generally a one sensor per vlan limitation (when the switch is not routing - read more below). So if you have 10 vlans then you could have 10 sensors with each sensor monitoring just one of the vlans.
With Span you are usually limited to 2 sensors, but with VACL Capture you are generally limited by the number of vlans being monitored.
However, the one exception to the above is when the switch (or the MSFC) is doing routing between vlans. The routing interacts with VACL Capture in some unique ways. Instead of being able to capture both client->server traffic and server->client traffic on the same vlan; the client->server traffic is captured on the server vlan, and the server->client traffic is captured on the client vlan.
Since the sensor needs to see both sides of the connection the sensor needs to monitor both vlans. Expand this to a situation where multiple vlans are being routed between and you have a situation where one sensor must monitor All of the vlans. You can no longer monitor each vlan with a different sensor. This is one situation where span has a small advantage. With VACL Capture you are limited to one sensor and have to use the VACL to limit the packets being captured, but with Span you can at least increase this to 2 sensors for monitoring.
In answer to question 2:
The IDSM2 is built off a standard base hardware that is used in multiple different service modules in the Cat 6500 switch. Each service module had different requirements for the number of ports. So the hardware development decided to implement the maximum number of required ports and let the software team decide which ports would be populated and used.
In the IDSM-2 there are only 4 ports that are needed and used.
Port 1 is what we call the TCP Reset Port
Port 2 is the command and control Port
Ports 3-6 are not used by the IDSM-2
Ports 7 and 8 are the sniffing ports.
Port 2 is the command and control port and is the interface on which you assign an ip address. In the switch configuration you assign this port to your command and control vlan.
Ports 7 and 8 are both sniffing interfaces. In most scenarios a user really only needs to configure port 7. In most cases users can clear all the vlans off port 8's configuration and leave it alone (clearing the vlans will prevent it from seeing multicast and broadcast packets you aren't wanting to monitor).
So in most situations there is not need to load balance across ports 7 and 8, and instead just use 7.
There are only a few cases where port 8 needs to be configured. If you are attempting to use VACL Capture to monitor one set of vlans, and span to monitor another set of vlans or ports; then you can set port 7 as the VACL Capture port, and port 8 as the span destination port.
Occasionally the switch's buffer on port 7 may be overrun during high bursts of traffic. In these situations a user could set up port 7 to monitor some of the vlans, and port 8 to monitor the other half of the vlans. This doesn't increase the performance of the IDSM2, but does allow the sensor to see packets that the switch might otherwise have dropped. IN many cases though, if port 7 is overrun the sensor is already overwhelmed and adding port 8 doesn't really help.
Ports 7 and 8 do not have the ability to send packets. For this we had to have another port. This is why port 1 is the TCP Reset port, and is only used for sending TCP Resets. So do not configure this port as a VACL Capture or Span destination port.
As for configuration, the easiest method is to simply stay with the default allowing it to trunk all vlans. If you want to minimize the configuration then you can set it to trunk only the vlans being monitored by both ports 7 and 8.
One side note here. Some users have changed the native vlans of ports 7 and 8 using the "set vlan" command. If you choose to do this, then you will need to set the same native vlan on ports 1, 7, and 8. This is because the native vlan traffic will be sent to the sensor without vlan headers, and so the TCP Resets that may result will also not have vlan headers. The only way to get the TCP Resets onto the correct vlan is to have all 3 ports configured for the same native vlan.
In answer to question number 3:
I am not sure which manual you are referring to. Cisco has published a standard for third party vendors to connect to Cisco sensors and pull events. NetForensics has implemented this standard as well as a few other vendors. You can contact NIE and other vendors and ask if they have implemented an RDEP client to connect to and pull events from a Cisco version 4.x sensor.
Of course Cisco's own VMS with Security Monitor can be used to view the version 4.x events. VMS can be purchased at an additional cost and can pull events from multiple sensors.
Or you can download the Intrusion Detection Event Viewer (IEV) which is available at no extra charge and can be used to view events from up to 5 sensors.
Some users have even chosen to implement their own RDEP client to connect to and pull events from the sensor.
If you are interested in this option then contact the TAC and ask for a link to the RDEP specification. There are a few up front questions you have to answer before getting access.
I would give you the link now, but I can't remember what it is right now.
In answer to question 4:
Failover is not currently supported. I have heard of users implementing a sort of failover. Both IDSM-2s are configured to monitor the same traffic, and both IDSM2s are generating alarms for the same traffic. They set up their event viewer program to pull the alarms from the primary IDSM-2. If for some reason the primary IDSM-2 stops responding, then they go look at the alarms from the secondary IDSM-2. Some users will have the alarms already being collected from the second IDSM-2 and may just ignore these alarms until the primary goes down, or even manage them alongside the alarms for the primary sensor. Other users will wait until the primary sensor goes down, and then in their event viewer will configure to connect to the secondary IDSM2. In configuring it to connect to the second IDSM2 the viewer often has the ability to pull in older alarms. The user will find the time of the last alarms from the primary and begin querying the secondary from that time forward.
