IDSM-2 not receiving all traffic

Unanswered Question
Feb 21st, 2009

We have an IDSM-2 module running 6.1(2)E3 in a 6500 with a sup-720 supervisor engine running 12.2(18) SXF11. We are using passive VLAN capture in promiscuous mode on the outgoing interfaces on our 6500. the config for the ids is as follows

!

vlan 99

name IDS_LAN

!

intrusion-detection module 1 management-port access-vlan 99

!

vlan access-map IDSMAP 10

match ip address CAPTUREALL

action forward capture

!

vlan filter IDSMAP vlan-list 10-20

vlan internal allocation policy ascending

vlan access-log ratelimit 2000

!

ip access-list standard CAPTUREALL

permit any

!

intrusion-detection module 1 data-port 1 capture

intrusion-detection module 1 data-port 1 capture allowed-vlan 10-20

intrusion-detection module 1 data-port 1 autostate include

intrusion-detection module 1 data-port 1 portfast trunk

Traffic enters the 6500 on several GRE tunnelled routed ports into seperate VRFs. The traffic is de-encapsulated then leaves the 6500 through other routed ports which are configured in separate vlans (which are in the VRFs). The vlans are all passive monitored by our IDS, at least that is the plan. The problem we have is that not all the traffic appears to be getting to the IDS. Using the IDM & eventviewer on our IDS workstation we can see tcp, udp etc but only at a low rate, 20packets/sec. We can test the IDS by looking for echo request/reply successfully. The incoming interfaces all have around 6,000 packets/sec of multicast (streaming video) arriving (this is the main traffic source) and this appears not to be monitored. Are we missing something in our config?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
rhermes Sun, 02/22/2009 - 08:18

The "10" in "vlan access-map IDSMAP 10" is not an identifier like a VLAN number, it's an statement ordering number (like in line numbered programming). that "10" just means it's the first statement. You need to associate IDSMAP with the VLAN:

VLAN 666

name IDSMAP

Then put that VLAN number into your vlan-list:

vlan filter IDSMAP vlan-list 666

vlan internal allocation policy ascending

vlan access-log ratelimit 2000

I've had problems when limiting the "capture allowed-vlan" to just your interesting VLANs, but if your seeing some traffic from each VALN this doesn't seem to be a likely fix for your problem.

intrusion-detection module 1 data-port 1 capture allowed-vlan 1-4094

The other thing to test is to make your standard CAPTUREALL ACL and extended ACL:

ip access-list standard CAPTUREALL

permit ip any any

Once you get this working, then you can worry about sending duplicate packets to your IDSM for inter-VRF traffic. The IDSM will ignore them, but if you're running a lot of traffic, it may create more load on the sensor than necessary.

francisfox Tue, 02/24/2009 - 05:33

I've tried the extended ACL with ip any any and it still didn't work. Do you think the 6.1(2)E3 engine might be the problem?

francisfox Thu, 02/26/2009 - 10:30

We have made a small breakthrough - we've changed our config from VACL to span capture and all of a sudden the IDS is receiving the multicast traffic. The vlans we were previously capturing on are in separate VRFs so we can't explain why IDS capture was working for unicast (ie icmp when testing and enabling the signatures for echo request / reply to show intrusions in the realtime dashboard) but not multicast. We are suspecting that it may be an issue specifically relating to multicast & VRFs and may raise a TAC case. Anyone out there agree?

Actions

This Discussion