IDSM2 Packet Display Expression

[rmeans]

I have several IPS devices (4250 and IDMS2). I am trying to capture some specific live data. I am using the packet display command. When I add the expression command to the IDSM2, I get no data displayed versus a similar command on the 4250 displays data as expected. The command I am using is...

packet display gi0/7 expression host 10.10.0.1

On the IDSM2, if I omit the expression (display all), plenty of data is captured (to much).

Is there something about the IDSM that does not display/handle expressions? The 4250 and IDSM2 are running the same version 6.0 sig level 302.

Thanks for the help.

[marcabal · Accepted solution]

The typical difference between a 4250 and IDSM-2 is that the IDSM-2 typically monitors 802.1q trunk packets while the 4250 generally sees packets without 802.1q trunk headers (connected to an access port rather than a trunk port).

If the 4250 had also been receiving 802.1q trunk packets then the same issue would also be seen on the 4250.

The problem is that the filter is being applied without taking into account the trunk header, and so the packets are not being seen as IP packets and the IP Address is not in the position in the packet where the filter is expecting it.

So you need to add the following at the front of your filter: "vlan and". This tells the filter to expect an 802.1q trunk header and look for the IP header after that.

So for your command you would use:

"packet display Gi0/7 expression vlan and host 10.10.0.1"

NOTE: You can extend this further and even limit the fitlering to a specific vlan by adding the vlan number after the vlan option.

For example:

"packet display Gi0/7 expression vlan 201 and host 10.10.0.1"

So the cause is not unique to the IDSM-2 (it affects all sensors monitoring trunk packets), and is not unique to a software version.

It is a limitation in how filters work within the packet command.

The packet command is actually just a CLI wrapper around tcpdump, and so the expression is passed to tcpdump. The limitation is in how tcpdump's filters work.

You can search the web for more information on the filters within tcpdump. You will see a similar limitation also exists for filtering mpls packets.

[rmeans]

Great information. Your suggestions worked.

Interestingly, my 4250 monitors a trunk port but does not need the key word 'vlan' added to the expression statement. I am adding a sections of my config in case you can see something that explains this.

6500 config for the IDMS-2

intrusion-detection module 8 management-port access-vlan 251

intrusion-detection module 8 data-port 1 capture

intrusion-detection module 8 data-port 1 capture allowed-vlan 1-1000

!

vlan access-map IDSM2 10

match ip address 199

action forward capture

vlan access-map IDSM2 20

match ip address 198

action forward

!

vlan filter IDSM2 vlan-list 998 (vlan 998 connects my 6500's to my PIX firewalls - inside interface)

Extended IP access list 199

10 deny ip any x.x.105.0 0.0.0.255

15 deny ip any x.x.145.0 0.0.0.255

20 deny ip any x.x.0.0 0.0.255.255

30 deny ip any host x.x.8.10

40 deny ip any host x.x.65.10

50 deny ip any host x.x.4.36

60 deny ip any 192.168.56.0 0.0.0.255

70 deny ip any 192.168.57.0 0.0.0.255

80 deny ip any 192.168.58.0 0.0.0.255

90 deny ip any 192.168.100.192 0.0.0.3

100 deny ip any x.x.137.0 0.0.0.255

110 deny ip x.x.105.0 0.0.0.255 any

115 deny ip x.x.145.0 0.0.0.255 any

120 deny ip x.x.0.0 0.0.255.255 any

130 deny ip host x.x.8.10 any

140 deny ip host x.x.65.10 any

150 deny ip host x.x.4.36 any

160 deny ip 192.168.56.0 0.0.0.255 any

170 deny ip 192.168.57.0 0.0.0.255 any

180 deny ip 192.168.58.0 0.0.0.255 any

190 deny ip 192.168.100.192 0.0.0.3 any

200 deny ip x.x.137.0 0.0.0.255 any

210 permit ip any any

Extended IP access list 198

10 permit ip any any

6500 config for the IPS 4250

monitor session 1 source interface Gi13/17

monitor session 1 destination interface Gi10/48

interface GigabitEthernet13/17

description primary pix gig 1 ethernet interface trunks dmz vlans

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 56-58,137,145,999

switchport mode trunk

no ip address

interface GigabitEthernet10/48

description monitoring interface netrangr4

switchport

switchport mode access

no ip address

speed 100

duplex full

spanning-tree portfast

Thanks again for the assistance

[marcabal]

Your 4250 is monitoring a trunk port, but the packets sent to the 4250 do not contain trunk headers.

In the 6500 it does not matter what port is being monitored, instead it matters what the destination port is configured as.

In the case of a 6500 switch, when a trunk is spanned (monitored) to an access port, then the switch itself will remove the trunk header as it sends the packet out of the access port to the sensor. So the sensor sess the pacekts withOUT the 802.1q header.

Whether or not the sensor will see an 802.1q header is NOT dependant on the source port where the real packet entered or left the switch, but is instead dependant on the configuration of the destination port itself. If the destination port is an access port, then the packets will not have 802.1q headers regardless of which port or vlan they came from. If the destination ports is a trunk port, then packets coming from vlans other than the native vlan of the trunk (typically vlan 1) will have trunk headers regardless of how they entered or left the switch.

So the "switchport mode access" on the Gig10/48 is what keeps your 4250 from seeing 802.1q headers.

Understand, however, that this is NOT true for all Cisco switches. The above is true for the Cat 6500, but some other Cisco switches have different rules about whether or not the spanned packets have headers. Some will require special options on the monitor command while others will always keep the packet (with or without headers) exactly as it appeared on the source port.

The IDSM-2 when configured as a promiscuous port (either VACL Capture port, or span destination port) will be internally set as an 802.1q trunk port, all packets will be encapsulated (except maybe vlan 1 packets, in some switch versions the IDSM-2's native vlan is set to 1, in others no native vlan is set for the IDSM-2 ports).

The IDSM-2 when configured as a trunk port for inline vlan pair mode will be internally configured as an 802.1q trunk port. All packets will be 802.1q encapsulated.

The IDSM-2 when configured as access ports for inline interface pair mode will be internally configured as access ports. It is the only IDSM-2 configuration where all packets will Not be trunk encapsulated.

[rmeans]

A couple more similar questions

I am now trying to view the entire packet. I add the keyword 'snaplen 1500' but get nothing.

packet display gi0/7 snaplen 1500 expression vlan and host 10.10.0.1

What am I missing?

Also I will likely want to view the data with wireshark. How should I get the data from the 4200?

[marcabal]

The packet display will usually just show you header information. You can look through tcpdump help pages and may find other tcpdump options to add additional information to the output (add the tcpdump options to the expression command). The snaplen setting won't really affect the normal viewing through "packet display".

To view the packets in wireshark you want to do a "packet capture" rather than "packet display". The capure command will capture the packets to a file. Once you are done capturing then you can use the copy command to copy the packet file to an ftp server. Then you can get it to your desktop for loading in wireshark.

Now the snaplen can affect the capture since the entire packet is logged. You would want to use a snaplen 1600 to account for any 802.1q headers that may be added to the packets.