Prefered method to control VLAN captures on IDSM?

[rsumidacisco]

Hello All,

We recently added IDSM2s to our core using VACLs to capture traffic. How are others controlling which VLANS the IDSMs can inspect? Currently I have it set up where only certain VLANs are mapped on the VACL and allowed on the trunk. e.g. map VACL to vlans 1,2,3 and allow vlans 1,2,3 on trunk to the IDSM. Would it be a bad idea to allow all vlans on the trunk and just specify certain vlans on the VACL? Or vice versa, map all vlans to the VACL and specify allowed VLANS on the trunk? Any advice is appreciated.

Thanks,

Ryan

[gfullage · Accepted solution]

There's no preferred way, certainly either works just as well.

I guess the issue I've seen with leaving all VLAN's on the trunk to the IDSM is that you actually get broadcast and multicast traffic on this trunk from VLAN's that you're not capturing in you VACL. Basically broadcast's and multicasts (and even unicast MAC addresses without an associated CAM table entry) are forwarded within a switch out every port in that VLAN, even trunks. If your VACL is only monitoring VLAN's 2 and 3, but the switch sees a broadcast on VLAN 4 it will forward it on that trunk port to the IDSM because that is the nature of packet forwarding/flooding. For certain signatures (like the ARP-related sigs), these can even then set off alerts, so you get alerts on VLAN 4, even though your VACL is only specifying VLAN's 2 and 3. It doesn't happen very often, but it's important to be aware of it.

If you go and remove all VLAN's from the IDSM trunk except those that are in your VACL then you will no longer see these broadcasts/multicasts from other VLAN's. This is your current setup going by your description and will work fine for you.

[marcabal · Accepted solution]

Removing the other vlans from the trunk is a good practice IF your switch/msfc is NOT routing between vlans.

IF your switch/msfc IS routing between vlans, then you need to be aware of the interaction between VACL Capture and inter vlan routing by the switch/msfc.

If a packet comes in on vlan 1 where a VACL Capure ACL has been placed, but is then routed to vlan 10 where no VACL exists, then that packet will usually be marked as a vlan 10 capture packet. It gets marked as a vlan 10 capture packet even though there is not VACL on vlan 10 and the VACL is only on vlan 1. This weird interaction happens because of MLS (Multi-Layer Switching). It combines as many features of the switch as possible so as to reduce the number of times that a packet traverses the backplane of the switch. In this case the packet is both marked for capture and routed to vlan 10 at the same time.

You need to understand that with VACL Capture the packet is Not actually copied to the VACL Capture port by the supervisor (unlike span where a copy is sent to the span port). Instead the supervisor just adds a single capture bit to the internal switch packet header, and sends the packet down the backplane of the switch. So when the packet goes to the backplane of the switch it has already been routed from vlan 1 to vlan 10, and is a vlan 10 packet with a capture bit. The VACL Capture port is watching out for these packets with the capture bit set. When it sees one it compares the vlan of the packet to the vlans the capture port is trunking. If there is a match then at this point it copies it on to the sensor. It is the end capture port and not the supervisor doing the copying. If there is not a match then it ignores the packet.

So even though you put the VACL on vlan 1, you will still need to monitor vlan 10 to see the packets routed to vlan 10. Even though there is no VACL on vlan 10.

So when you have routing between all of the vlans in the switch you might as well just go ahead and trunk all possible vlans. This way you are also covered if any additional vlans get added.

Another thing to keep in mind is that in Native IOS on the switch a similar thing can happen with ports where the switch has an ip address configured directly on it's port instead of placing them on a user configured vlan. I specifically say "user configured vlan" because internally the switch also has what many term "hidden vlans". When the user puts an ip address on a port instead of making it part of a user configured vlan; internally the switch actually creates it's own "hidden vlan" and puts that port on the hidden vlan. The ip address the user configured on the port then actually gets applied to that "hidden vlan". The "hidden vlan" is a vlan number that switch chooses from the list of vlan numbers that the user is not already using.

And so with routing combined with VACL Capture you can have packets being marked for capture on even these "hidden vlans".

Since you won't know which vlan number will be the "hidden vlan" it is best to go ahead and trunk All vlans.

[j.docio]

Hi,

great post!!!

I know that is a "very old" post, but if you see my post, please, could you put a link with the detailed explanation of your post?

I never read this "details" of VACLS.

thnks.

[rm2017]

Is there a certain version of IOS where you can do a show access-list "xxx" - where xxx is an access-list referenced in a vacl and actually see counter/hits information?