02-20-2008 12:30 PM - edited 03-10-2019 04:00 AM
An ASA 5520 with an AIM SSM-10 is configured for inline mode but the show events past 2 hours(sensor>sh event past 2:00) from inside the sensor shows and 'entered promicuous mode', "left promicuous mode'.
This AIP SSM-10 only has a gig0/0 and gig0/1 where o/o is shutdown and a default virtual sensor (vs0) is assigned to gig0/1. I see statistics (sensor>sh statisics analysis-engine) for gig0/1 so I am collecting statistics.
If the ASA 5520 configuration has the following inline policy and the events log shows entering and leaving promiscuous mode then how do I verify if I am inspecting/collecting in inline mode?
(ASA>sh run access-list IPS)
access-list IPS extended permit ip DMZ 255.255.255.0 26.26.1.0 255.255.255.0
(ASA>sh run | b class-map)
class-map IPS
match access-list IPS
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect waas
inspect icmp
class IPS
ips inline fail-open
!
service-policy global_policy global
(sensor>sh interfaces)
...
MAC statistics from interface GigabitEthernet0/1
Interface function = Sensing interface
Description =
Media Type = backplane
Default Vlan = 0
Inline Mode = Unpaired
Pair Status = N/A
Hardware Bypass Capable = No
Hardware Bypass Paired = N/A
Link Status = Up
Link Speed = Auto_1000
Link Duplex = Auto_Full
Missed Packet Percentage = 0
Total Packets Received = 95044
Total Bytes Received = 8715230
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 0
Total Receive Errors = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 95044
Total Bytes Transmitted = 9047702
Total Multicast Packets Transmitted = 0
Total Broadcast Packets Transmitted = 0
Total Jumbo Packets Transmitted = 0
Total Undersize Packets Transmitted = 0
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
sensor>sh events last 2:00
evStatus: eventId=1203360411830836145 vendor=Cisco
originator:
hostId: ASA2_IPS
appName: kernel
appInstanceId:
time: 2008/02/20 19:01:46 2008/02/20 19:01:46 UTC
syslogMessage:
description: device ge0_1 entered promiscuous mode
evStatus: eventId=1203360411830836146 vendor=Cisco
originator:
hostId: ASA2_IPS
appName: kernel
appInstanceId:
time: 2008/02/20 19:01:53 2008/02/20 19:01:53 UTC
syslogMessage:
description: device ge0_1 left promiscuous mode
Solved! Go to Solution.
02-20-2008 01:02 PM
The entered and left promiscuous mode status events are usually generated when doing a "packet display" or "packet capture" command on the CLI of the sensor.
The packet command monitoring is promiscuous but is independant of the promiscuous or inline monitoring done by the sensor's analysis engine.
So you could be doing inline monitoring using the sensor's analysis engine.
And still do the cli's packet command for your own promiscuous monitoring of those same packets. These are 2 independant monitorings of the same packets.
If I remember right inline monitored packets always get sent back to the ASA (unless specifically denied), while promiscuous packets do not. So check the statistics on the sensors gig0/1 interface and check the transmit packet count. If the receive and transmit counts are fairly close, then the packets are being InLine monitored by the analysis engine. If the transmit count is zero or very low then the packets are likely promiscuous monitored.
With your ASA configuration you are properly configured for inline monitoring.
So I do think you are monitoring inline, and the status messages are specific to your starting and stopping the "packet" command on the CLI for your own independant promiscuous viewing of the packets.
02-20-2008 01:02 PM
The entered and left promiscuous mode status events are usually generated when doing a "packet display" or "packet capture" command on the CLI of the sensor.
The packet command monitoring is promiscuous but is independant of the promiscuous or inline monitoring done by the sensor's analysis engine.
So you could be doing inline monitoring using the sensor's analysis engine.
And still do the cli's packet command for your own promiscuous monitoring of those same packets. These are 2 independant monitorings of the same packets.
If I remember right inline monitored packets always get sent back to the ASA (unless specifically denied), while promiscuous packets do not. So check the statistics on the sensors gig0/1 interface and check the transmit packet count. If the receive and transmit counts are fairly close, then the packets are being InLine monitored by the analysis engine. If the transmit count is zero or very low then the packets are likely promiscuous monitored.
With your ASA configuration you are properly configured for inline monitoring.
So I do think you are monitoring inline, and the status messages are specific to your starting and stopping the "packet" command on the CLI for your own independant promiscuous viewing of the packets.
02-20-2008 06:02 PM
Before I ran the sensor>sh statistics event last 2:00, I ran sensor>packet display GiabitEthernet0/1 to see the pings I was using to verify the SSM was looking at packets. echo/echo reply packets were traversing gig0/1 on the SSM. So, as you state that is what probably kicked off the enter/left promiscuous mode. Good catch!
Matt
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide