Can I 'monitor session' trunk ports to a Cisco IDS?

Question

I ran across an existing config that has two trunk ports on a 3560 being port monitored to another port which is plugged in to a port on an ids 4515. Will the IDS be able to interpret that trunk traffic? The customer is complaining that they aren't able to see events on a local network (VLAN 1) and this is suppose to be the port they get that traffic from.
Not sure why they chose to monitor trunk ports and I'm not sure it's even possible. I want to change the monitored port to some other local VLAN port that makes sense.
Here are the existing lines:
interface G0/47
switchport turn encap dot1q
switchport mode trunk
interface G0/48
switchport turn encap dot1q
switchport mode trunk
monitor session 2 source interface Gi0/47 - 48
monitor session 2 destination interface Gi0/20
...port 20 goes to the ids.

Answer 1

There are 3 modes of sensing supported on the sensors: promiscuous, inline interface pair, and inline vlan pair.
Each mode interacts with vlan headers slightly differently.
Promiscuous:
A promiscuous sensor is fully capable of analyzing 802.1q trunk packets. The vlan will also be reported in any alerts generated.
The trick when monitoring using a trunk is to ensure the span (or vacl capture) configuration is correct on the switch to get the packets you are expecting.
Many types of switches have special caveats when a trunk is a source or destination port in the span.
We also even support Vlan Group subinterfaces on the promiscuous interface.
This allows sets of vlans on the same monitoring port to be monitored by different virtual sensors.
So you could take vlans 1-10 and monitor with vs0, and then take vlans 11-20 and monitor with vs1, etc....
However, to use this feature the switch must be very consistent in how packets are sent to the sensor. When monitoring a connection the sensor needs to see both client and server traffic. And when using Vlan Groups the sensor needs to see the client and server traffic ON THE SAME VLAN. It is this on the same vlan requirement that is not always possible with some span configurations when the switch itself is routing between vlans. Most switches are deployed with routing between vlans by the switch, and so in many cases you won't see the client and server traffic on the same vlans. This is very switch code dependant so you would need to do some research on your specific switch.
Inline Interface Pair:
With an inline interface you are pairing 2 physical interfaces together. A common deployment is to place the inline interface pair in the middle of an existing 802.1q trunk port. Interface 1 would be plugged into the switch, and interface 2 plugged into the other switch or other type of device (like router or firewall).
In this setup the sensor is fully capable of monitoring these packets with 802.1q headers.
However, there is something to keep in mind in these deployments. Often that other device (router, firewall, or switch) will route packets between vlans. So a packet going through the sensor on vlan 10 could be routed right back through the sensor again on vlan 20. Seeing the same packet again can cause TCP tracking confusion on the sensor (especially when the other device is doing small modifications to the packet like sequence number randomization).
To address these we have 2 features.
On InLine Interface Pairs we have the same Vlan Group feature as I discussed above in Promiscuous mode. (Do not confuse Vlan Groups with InLine Vlan Pairs discussed later in this response).
So with Vlan Groups you could separate the vlans across virtual sensors. So if the packet gets routed back into the sensor you could configure it so that packet gets monitored by a separate virtual sensor and it will prevent the sensor confusion with state tracking.
However, there will still be some situations where the packet may still need to cross the same virtual sensor twice. For this deployment scenario we have a configuration setting where you can tell the sensor to track tcp sessions uniquely per vlan. So long as the return packet is on a different vlan this should prevent the tcp tracking confusion. BUT there is a bug this code right now. It should be fixed in an upcoming service pack. The workaround is to go ahead and create a unique Vlan Group for each vlan (one vlan per group instead of multiple vlans in a group), and assign all of the Vlan Groups to the virtual sensor(s).
And then you InLine Vlan Pairs:
With InLine Vlan Pairs the monitoring interface Must be an 802.1q trunk port.
Instead taking packets in one interface and passing to the next interface, the sensor actually takes packets in on one vlan and then sends it back on the other vlan of the pair on the same interface. It does this by modifying the vlan number in the 802.1q header.