cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
824
Views
5
Helpful
5
Replies

2950 span port inserts VLAN tags?

ibsenj
Level 1
Level 1

I am having a problem getting my IDS to see any packets coming from the SPAN port on my 2950 switch running IOS 12.0(5.3). Although the span port light is blinking like crazy, and I know 35 Mbits of data are flowing through the monitored ports, all I see is some 802.1d STP data on my IDS.

I suspect that the frames coming out the monitor port are 802.1Q vlan tagged and my IDS does not recognize them - can anyone confim this, and how do I fix the problem?

5 Replies 5

marcabal
Cisco Employee
Cisco Employee

The Solaris snoop command on the sensor will not understand 802.1Q packets.

The IDS nr.packetd executable on the sensor understands and can analyze 802.1Q packets just fine.

There is one known issue with the NIC driver on the IDS-4210, IDS-4220, and IDS-4230 problems, however. The 802.1Q headers can push the packet size above what it is normal for typical ethernet packets. The standard NIC driver drops these larger packets so that nr.packetd never sees them. In order for nr.packetd to monitor these larger packets, you will need to load an engineering NIC driver.

Refer to Active Update #7:

http://www.cisco.com/warp/customer/779/largeent/issues/security/idsnws/archive.html

NOTE: The IDS-4235 and IDS-4250 can monitor the larger packets with their standard NIC driver so the engineering NIC driver is not needed on these models.

To see if the sensor is receiving packets you will not be able to use the snoop command. Instead generate traffic which causes the sensor to create alarms.

Some fairly easy ones to try:

1) ping - generates the 2004 Echo Request and 2000 Echo Reply alarms (These are normally turned off, set them to a High severity to use in a quick test)

2) telnet to another bix and execute "export IFS=/" - generates 3401 IFS=/ alarm

If the sensor is alarming on the packets, then the sensor is likely working just fine.

robert.lau
Level 1
Level 1

We ran into this a while ago. Upgrading the 2950 to IOS 12.1.11.EA1 (released 2002/08/30) fixed the tagged packet problem. One of the new SPAN options enables dot1q encapsulation, tis of by default. Note, SPAN config under IOS 12.1.x uses the 'monitor session' syntax instead of 'port monitor'.

basicitone
Level 1
Level 1

We just ran into this problem as well with a 3640 running IOS ver 12.2 with 16 port switching mod. It seem as if the switch mod does not strip the tags and the IDS will not read the 802.1q tags. We threw a temp solution at the problem by adding a 3550 in between the two devices by sending monitoring traffic to the 3550 then sending monitoring traffic from 3550 to the IDS. If 12.1 code fixed the problem on a2950 it isn't fixed on a 3640 running 12.2.

grimish
Level 1
Level 1

Hi,

I am currently experincing the same issues. The temporary solution is to actually revert back to a version of IOS that uses the port monitor command on the interface and not as a global configuration option.

- Yes Cisco know about this but have still not resolved it - last I saw. Hopefully this will be addressed soon.

Reverting back to a older IOS was not an option as it would break other features and fixes that we upgraded to solve.