1) What is int0 on the IDSM-2?
MC> This is a known bug on the IDSM-2. The IDSM-2 loses the mapping for the real interface (int 7 or int 8 in the case the IDSM-2). The interface number inadvertantly gets zeroed out when the sensor does not see all of the fragments for a datagram, and winds up reporting int0.
Which is why "Incomplete Dgram" and "No Initial Frag" are firing with int 0; these alerts are reporting that the sensor is not seeing all the fragments for a datagram which inadvertantly causes the sensor to zero out the the interface number.
(2) What can Interface Group 0 be used for?
MC> All of the sensor interfaces are combined into a single group 0. This way all of the packets from the interfaces in a group are treated as if they are from the same network. In the latest version of the sensors we only support 1 interface group (group 0) so all packets are treated as if they are on the same network.
In a future sensor version you would be able to create multiple interface groups. You could assign specific interfaces/vlans to each interface group. The packets from thoses interfaces/vlans would be treated as one network. You could then have different signatures and filters for each group. In effect you would turn your one physical sensor into a bunch of virtual sensors where each virtual sensor is monitoring a group of interfaces/vlans.
This is still just a plan for a future version, and there is no scheduled release date for the feature.
So you don't Span/Vacl to group 0, your span/vacl to an interface that belongs to group 0.
NOTE: group 0 and int 0 are different things. You are seeing int0 because of a bug.
(3) ... How is this possible? If I were to shutdown int8 as recommended wouldn't that imply that I would miss these events?
MC> Both int7 and int8 will receive broadcast and multi-cast traffic for the vlans they are trunking. Int7 will receive the unicast traffic on the vlans it is trunking that is specifically being marked for capture by the VACL capture feature.
BUT what many don't realize is that int7 and int8 will ALSO receive uni-cast traffic whose destination mac address is not yet in the switch's cam table.
The switch has a cam table that maps MAC Addresses to specific switch ports.
If a packet comes in with a destination MAC Address that is not in the cam table, then the switch will in effect broadcast it to all of the ports on that vlan (including both int7 and int8).
Once the other machine starts responding then the cam table gets updated and the switch sends the additional packets only to the responding machine's port. This also happens every now and then when mac addresses are aged out of the cam table, or if a cam table gets to full and some addresses are automatically removed from the cam table.
So it it possible and even likely that int7 and int8 will every now and then see uni-cast packets that were not specifically marked for capture.
So if both int7 and int8 are seeing the packet then why does the alarm show up as int8? The sensor is liekly able to tell that duplicate packets are seen and is throwing away the duplicate packet. The first packet seen is int8 (because the packet buffers aren't as full as on int7 where other packets are also being captured). So it marks it as an int8 packet. When it sees the same packet on int7 it throws it away. (Remember since both int7 and int8 are in group 0 it treats them as being on the same network and throws away the duplicate packet not caring that it came from another interface because it was in the same group)
So shutting down int8 would not likely cause you to miss these events. The sensor would stop seeing duplicate packets, and would just see the one packet on int7.
