IDSM-2 Error

I keep receiving theses two errors over and over again in my logs "WebSession::SessionTask(#) TLS exception: handshake imcomplete"
"received fatal_alert: certificate unknown"
Currently I use IPS manager 2.2, and import the devices using TLS (cant import without). I keep receiving these errors but don't know if it has to do with the ciscoworks box or not or how to correct them. Thanks for the help

These errors generally happen when the sensor has generated a new certificate (like after a re-image, or a version 4.x to 5.0 upgrade).
There is a client still trying to connect to the sensor, but has the sensor's old certificate saved away.
This generaly happens with IEV or Security Monitor (within VMS).
How to track it down:
Create a service account.
Login with the service account.
Switch to user root (su -) using the same password as the service account.
Run "ifconfig -a" to determine the interface with the sensor's IP assigned to it.
Execute "tcpdump -i "
Look for what IP Addresses are attempting to connect to port 443 (HTTPS) of the sensor.
Track down these IP Addresses and ensure the software running on these IPs has been updated with the sensor's new certificate.

Similar Messages

IDSM 5.1(1) S222 certificate unknown errors

Hi,
I reimaged my IDSM2 sensor in the following sequence:
1. Installed WS-SVC-IDSM2-K9-sys-1.1-a-5.1-1.bin.gz
2. Installed IPS-sig-S222-minreq-5.0-5.pkg
I am able to launch IDM and work with it. But, I get the following errors when I type "show events" on IDSM-2 CLI.
evError: eventId=1143377080627763538 severity=warning vendor=Cisco
originator:
hostId: RCIPS
appName: cidwebserver
appInstanceId: 2731
time: 2006/03/26 11:45:53 2006/03/26 14:45:53 UTC
errorMessage: name=errWarning received fatal alert: certificate_unknown
evError: eventId=1143377080627763539 severity=error vendor=Cisco
originator:
hostId: RCIPS
appName: cidwebserver
appInstanceId: 2497
time: 2006/03/26 11:45:53 2006/03/26 14:45:53 UTC
errorMessage: name=errTransport WebSession::sessionTask(10) TLS connection exception: handshake incomplete.
I do not see the alerts that I am suppose to see.
Please help. Thanks.

"I do not see the alerts that I am suppose to see."
What type of alerts are you looking for? System events or signature alerts? You don't see alerts from IDM or from the CLI?
The two events you have in your post look certificate related. When you reimaged the IDSM a new TLS certificate was generated, then you'll have to update your TLS trusted-host. Just to start fresh I'd try doing the following, this process has resolved my TLS issues in the past.
sensor# tls generate-key
sensor# sh tls trusted-host (to see if any IP's are currently in the table)
sensor# conf t
If there are any trusted-host IP's in the table, then remove them.
(config)#no tls trusted-host ip-address x.x.x.x
Next, add IP's back into the trusted-host table.
(I have also been able to leave the trusted-host table empty and had cisco works IP's add themselves to the trusted host table automagically, but then other times I've had to manually add them.)
(config)# tls trusted-host ip-address (host IP that you will use to connect to the sensor webserver.)
This will ask if you want to add the host to the trusted host table, you will answer yes.
After that try IDM again. Then from the CLI you can verify that you aren't seeing the TLS events anymore with the "show events" command. And then you can also verify that your getting alerts with the show events alert past hh:mm:ss command. Or alternatively just confirm the IDSM is seeing traffic by logging in as tac, su to root, and then do a tcpdump on the sensing interface.
Maybe a little more information then you needed on verifying the traffic, but hopefully something in the above will help you.

IDSM Error: Cannot communicate with system processes.

Dear all,
We have 6500 Switch which include IDS module.We are facing some different problem while accessing IDS Module. We can able to ping module but when we try to telnet which logout session before we can get in IDSM prompt.Is any one facing same problem .
IDSM Error: Cannot communicate with system processes.
Is it related to memory utilization.How can i get access to IDSM?This is working configuration.Access list is also define properly.
TIA
Regards
SAM

Which software version are you using?
check this bug-id: CSCef12198.
Try these links:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/idsm/idsm_2/13074_04.htm#wp71383
http://www.cisco.com/en/US/products/hw/modules/ps2706/prod_configuration_guide09186a00800f24fe.html

Idsm-2 problem: sensor upgrade from 4.1 to 5 or higher

Hi all,
I have a problem with my IDSM-2 module. I'm trying to sensor upgrade from IDS to IPS software (from 4.1 version to 5.x or higher).
If I do this from sensor under "admin user" and use major patch - IPS-K9-maj-5.0-1e-S149.rpm.pkg then I receive error:
"Error: idsPackageMgr: digital signature of the update file was not valid, use CCO to replace corrupted file ".
But file "IPS-K9-maj-5.0-1e-S149.rpm.pkg" is NOT corrupted. I cheked it under "service user" with md5sum utility - checksum is correct.
If I try to upgrade from maintance mode (ie re-image with wipe all information in application partition) then I receive:
"Application image upgrade complete. You can boot the image now.
Partition upgraded successfully"
Next, I'm reboot IDSM-2 module and receive:
"000133: Sep 7 15:10:18.622 MSK/MDD: %HA_EM-6-LOG: Mandatory.go_bootup.tcl: GOLD EEM TCL policy for boot up diagnostic
000134: Sep 7 15:10:18.290 MSK/MDD: %DIAG-SP-3-MAJOR: Module 4: Online Diagnostics detected a Major Error. Please use 'show diagnostic result <target>' to see test results.
000135: Sep 7 15:10:18.294 MSK/MDD: %CONST_DIAG-SP-3-BOOTUP_TEST_FAIL: Module 4: TestPCLoopback failed on port(s) 3-4
000136: Sep 7 15:10:19.170 MSK/MDD: %OIR-SP-3-LC_FAILURE: Module 4 has Major online diagnostic failure, Card will be reset to re-run diagnostic. Please check sup-bootflash diaginfo file for previous detailed diagnostic result.
000137: Sep 7 15:10:19.170 MSK/MDD: %OIR-SP-3-PWRCYCLE: Card in module 4, is being power-cycled 'off (Diagnostic Failure)'
000138: Sep 7 15:10:19.170 MSK/MDD: %C6KPWR-SP-4-DISABLED: power to module in slot 4 set off (Diagnostic Failure)"
ie module go to the "PwrDown" state.
I try to upgrade for next firmware:
IPS-K9-maj-5.0-1e-S149.rpm.pkg
IPS-IDSM2-K9-sys-1.1-a-7.0-5a-E4.bin.gz
IPS-K9-7.0-5a-E4.pkg
IPS-K9-maj-5.0-1e-S149.rpm.pkg
WS-SVC-IDSM2-K9-sys-1.1-a-5.0-1.bin.gz
and did not get success
chassis - 6509-e, sup - VS-S720-10G + VS-F6K-PFC3C, ios - s72033-adventerprisek9_wan-mz.122-33.SXI6.bin
maintance software for IDSM-2 module - 3.4(2)m
Could you please help me? Thanks in advance!

I have a problem with my IDSM-2 module. I'm trying to sensor upgrade from IDS to IPS software (from 4.1 version to 5.x or higher). If I do this from sensor under "admin user" and use major patch - IPS-K9-maj-5.0-1e-S149.rpm.pkg then I receive error: "Error: idsPackageMgr: digital signature of the update file was not valid, use CCO to replace corrupted file ". But file "IPS-K9-maj-5.0-1e-S149.rpm.pkg" is NOT corrupted. I cheked it under "service user" with md5sum utility - checksum is correct.
It has been a long time since I've seen a sensor running 4.1 or an upgrade to 5.0(1e) . If I recall correctly, there were some issues with upgrading if you were running a release from the 4.1 train earlier than 4.1(4). Additionally, the upgrade from 4.1 -> 5.0 includes a configuration conversion (due to differences between the software trains), which was prone to failure depending on the presence of certain configuration options.
Unless you absolutely need to keep the existing configuration, you would save yourself time and effort by simply re-imaging the sensor directly to the desired release. Modern (supported) releases would be either 7.0(5a)E4 or 6.2(3)E4.
Next, I'm reboot IDSM-2 module and receive:"000133: Sep 7 15:10:18.622 MSK/MDD: %HA_EM-6-LOG: Mandatory.go_bootup.tcl: GOLD EEM TCL policy for boot up diagnostic000134: Sep 7 15:10:18.290 MSK/MDD: %DIAG-SP-3-MAJOR: Module 4: Online Diagnostics detected a Major Error. Please use 'show diagnostic result ' to see test results.000135: Sep 7 15:10:18.294 MSK/MDD: %CONST_DIAG-SP-3-BOOTUP_TEST_FAIL: Module 4: TestPCLoopback failed on port(s) 3-4000136: Sep 7 15:10:19.170 MSK/MDD: %OIR-SP-3-LC_FAILURE: Module 4 has Major online diagnostic failure, Card will be reset to re-run diagnostic. Please check sup-bootflash diaginfo file for previous detailed diagnostic result.000137: Sep 7 15:10:19.170 MSK/MDD: %OIR-SP-3-PWRCYCLE: Card in module 4, is being power-cycled 'off (Diagnostic Failure)'000138: Sep 7 15:10:19.170 MSK/MDD: %C6KPWR-SP-4-DISABLED: power to module in slot 4 set off (Diagnostic Failure)"
I would try re-imaging the sensor once more using the IPS-IDSM2-K9-sys-1.1-a-7.0-5a-E4.bin.gz System Recovery Image file found here, following the procedure described here. If the module still fails to boot after that (still citing a Diagnostic Failure), try moving it to another slot in the chassis (if possible).
What color is the IDSM-2 Status LED (on front of module) when it is in this state? An RMA may be necessary to resolve this.

Trouble Installing license on IDSM-2

Hi,
I got my license for an IDSM-2 that I am installing (used serial number of IDSM to get it). When I go to install it, whether via the CLI or through the web interface I am informed that the license in no good...
Here's the message from the CLI:
Error: setLicenseKey : The license key on the system is invalid.
Here's the output from the "show version" command:
pcsd-suth-ids# sho ver
Application Partition:
Cisco Intrusion Prevention System, Version 5.0(2)S152.0
OS Version 2.4.26-IDS-smp-bigphys
Platform: WS-SVC-IDSM2-BUN
No license present
Sensor up-time is 7 min.
Using 236765184 out of 1983660032 bytes of available memory (11% usage)
system is using 17.3M out of 29.0M bytes of available disk space (59% usage)
application-data is using 28.7M out of 166.8M bytes of available disk space (18
usage)
boot is using 40.5M out of 68.6M bytes of available disk space (62% usage)
application-log is using 530.5M out of 2.8G bytes of available disk space (20%
sage)
MainApp 2005_Mar_04_14.23 (Release) 2005-03-04T14:35:11-0600 Run
ing
AnalysisEngine 2005_Mar_29_16.33 (Release) 2005-03-29T16:45:11-0600 Run
ing
CLI 2005_Mar_04_14.23 (Release) 2005-03-04T14:35:11-0600
Upgrade History:
IDS-K9-sp-5.0-1.2- 14:00:00 UTC Thu Mar 17 2005
Maintenance Partition Version 2.1(2)
Recovery Partition Version 1.1 - 5.0(2)
Any ideas as to where to start? is there any chance that the license file could be no good? I double-checked that it was not modified after receiving it in e-mail...
Thanks,
Tim

This URL should help you:
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00804cf52f.html

IDSM-2 web server crash

Hi all,
i'm experencing troubles with my twofold IDSM-2 sensor installation; the Web Server suddenly crashes, generating a core.XXXXX file in /usr/cids/idsRoot/core/cidwebserver directory.
I never experienced this kind of error before; my sensors are running 4.1(4) release and S160 sig version. Furthermore, my troubles started some days after S160 upgrade application.
Anyone could help me?
Regards,
Paolo

The document IDS Device Manager Administration Tasks has more information on the installation of IDSM2 sensor.
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_installation_and_configuration_guide_chapter09186a00801a0c3c.html#986876

Cisco vms 2.3 can't query to IDSM-2

Hi all,
I use Catalyst 6513 (Router IOS) + IDSM-2 and use Cisco VMS 2.3 to manage IDSM-2. I upgrade IDSM-2 from version 4 to version 5. However, after updating completely, I use Cisco VMS 2.3 to query to IDSM-2, I see a error:
"status: Error importing configuration files from the sensor - Unable to get sensor version from the sensor. Possible reason: X.509 certificate is invalid or sensor version was downgraded. "

Hi,
Normally doing the following fixes the problem.
You need to regenerate the IDSMC Certificate and add the VMS as the trusted host to the sensor.
To generate the certificate do the following.
c:\progra~1\cscopx\mdc\apache\gencert.bat
where c: drive is the drive you installed your VMS.
After this is done, please restart the CiscoWorks Daemon Manager.
You will also need to generate tls key as well as manually re-install the TLS certificate on your sensor.
tls trusted-host from the IPS CLI and specify your VMS's IP address.
tls generate-key
no tls trusted-host ip-address (vms server ip)
tls trusted-host ip-address (vms server ip)
Thanks.
Edward

NeedHelp Is it bug at IDSM-2 with IPS-K9-7.0-2-E3.pkg??

Dear All,
i have idsm with IPS-K9-7.0-2-E3.pkg installed,
i use inline mode for this idsm, and idsm place is front on server farm
but i have some problem that one segment in my network cant access the server
but another segment can access that server,
that server is oracle database aplication (real time)
in this is happend only for that server.
when i filter the traffic with idsm, the result that transaction match with
signature number 7000, evenly that signature dont have action to deny the traffic,
the traffic still cannot bypass, then ill try to disable but nothing impact to that segment
evenly other segment can access that server normally.
anyone can explain to me why this happen??
ill try to downgrade to IPS-K9-7.0-2-E3.pkg with IME but always error..
anyone can help me please..

Hi Josh..
This is my answer
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
First off, you cannot downgrade the version without a re-image. You can only downgrade signatures. Second, you mention 7.0(2)E3 as the version you are on and the version you want to downgrade to. Can you verify what version you are running?
Im not yet downgrade to 7.0(2) because I don’t have yet permission from my bos . And now my isdm still use 7.0(2)E3
This is capture from my isdm
OTIDSM# sh ver
Application Partition:
Cisco Intrusion Prevention System, Version 7.0(2)E3
Host:
    Realm Keys          key1.0
Signature Definition:
    Signature Update    S425.0                   2009-08-17
    Virus Update        V1.4                     2007-03-02
OS Version:             2.4.30-IDS-smp-bigphys
Platform:               WS-SVC-IDSM-2
Serial Number:          SAD132802TL
Licensed, expires:      20-Oct-2010 UTC
Sensor up-time is 2 days.
Using 1415421952 out of 1983504384 bytes of available memory (71% usage)
system is using 17.4M out of 38.5M bytes of available disk space (45% usage)
application-data is using 38.6M out of 166.8M bytes of available disk space (24% usage)
boot is using 41.5M out of 68.6M bytes of available disk space (64% usage)
MainApp            B-BEAU_2009_OCT_15_08_07_7_0_1_111   (Ipsbuild)   2009-10-15T08:09:06-0500   Running
AnalysisEngine     B-BEAU_2009_OCT_15_08_07_7_0_1_111   (Ipsbuild)   2009-10-15T08:09:06-0500   Running
CollaborationApp   B-BEAU_2009_OCT_15_08_07_7_0_1_111   (Ipsbuild)   2009-10-15T08:09:06-0500   Running
CLI                B-BEAU_2009_OCT_15_08_07_7_0_1_111   (Ipsbuild)   2009-10-15T08:09:06-0500
Upgrade History:
IPS-K9-7.0-2-E3   07:43:07 UTC Thu Oct 15 2009
Maintenance Partition Version 2.1(3)
Recovery Partition Version 1.1 - 7.0(2)E3
Host Certificate Valid from: 27-Apr-2010 to 27-Apr-2012
On the traffic not passing issue, if you put the sensor in bypass does that resolve the issue. That will eliminate any signature related actions from impacting the traffic. If you are still unable to access the servers then you should look for a routing or network layer issue
What you mean about bypass? Is it to released the idsm from network? If that so, I had do that and the server can access from segment that before cant access it. I had done to check the network layer problem but everything is ok,
And I want to clarify the other segment that cant access the server only for some application (real time application) in that server but the server can ping and telnet from that segment ( I think this is to clarify the network issue problem)
If that clears things up, the next step would be to create an Event Action Override to produce alert for all signatures. Then you can review IME for any signatures firing related to these servers. Please remove the Override once you are done testing as this can have a performance impact on the sensor over time and should only be used temporarily to troubleshoot a specific issue.
Well, I will try your suggestion, But I will wait permission to execute it. I hope this is work for my idsm-2
If you are still having trouble, if may help to get some info about the config of the sensor and the switch. Specifically, how the VLAN or Interface Pairs are setup, etc.
Oke, I will…
Btw, thanks for your help boss
GBU …

IDSM CPU 1 High Probleme

Hi everyone.
My name is wan tae kim in korea.
I have the question to idsm problem.
Is using idsm by ips mode in our customer.
Cpu1 will be continued in 100% state but does not know cause.
Is used by Inline mode but need Configuration verification.
I want to receive steers of many persons.
I ask counsel whether take Configuration.
IDSM Configuration:
service interface
exit
service authentication
exit
service event-action-rules rules0
overrides deny-packet-inline
override-item-status Enabled
risk-rating-range 90-100
exit
general
global-overrides-status Enabled
exit
exit
service host
network-settings
host-ip x.x.x.x/25,x.x.x.x.
host-name R_Core2_IDSM
telnet-option enabled
access-list x.x.x.0/24
access-list x.x.x.0/24
access-list x.x.x.0/24
access-list x.x.x.x/32
exit
time-zone-settings
offset 540
standard-time-zone-name GMT+09:00
exit
exit
service logger
exit
service network-access
exit
service notification
exit
service signature-definition sig0
signatures 2152 0
engine flood-host
rate 100
exit
exit
signatures 5684 2
alert-severity medium
exit
signatures 13003 0
engine traffic-anomaly
event-action produce-alert
exit
exit
signatures 13003 1
engine traffic-anomaly
event-action produce-alert
exit
exit
exit
service ssh-known-hosts
exit
service trusted-certificates
exit
service web-server
exit
service anomaly-detection ad0
exit
service external-product-interface
exit
service analysis-engine
virtual-sensor vs0
description default virtual sensor
physical-interface GigabitEthernet0/7
physical-interface GigabitEthernet0/8
exit
switch Configuration:
monitor session 3 source vlan 305
monitor session 3 destination intrusion-detection-module 9 data-port 1
Thank you.

Hi Wan Tae Kim,
The 100% CPU utilization is actually expected behavior and should not be cause for concern. To confirm the actual load on the sensor you can use the command:
show stat virt
and check the line "Processing Load Percentage ="
Additionally, you can check the output of:
show int
and verify that the number of "Receive FIFO Overruns" is low/zero, indicating that the sensor is able to keep up with the rate of traffic being sent to it via your SPAN session.
Here are examples of both outputs with the important lines in bold
sensor# show stat virt
Virtual Sensor Statistics
   Statistics for Virtual Sensor vs0
      Name of current Signature-Defintion instance = sig0
      Name of current Event-Action-Rules instance = rules0
      List of interfaces monitored by this virtual sensor = InterfacePair0 subinterface 0,GigabitEthernet0/3 subinterface 0
      General Statistics for this Virtual Sensor
         Number of seconds since a reset of the statistics = 1627117
         MemoryAlloPercent = 31
         MemoryUsedPercent = 31
         MemoryMaxCapacity = 1800000
         MemoryMaxHighUsed = 634880
         MemoryCurrentAllo = 566529
         MemoryCurrentUsed = 561597
         Processing Load Percentage = 1
         Total packets processed since reset = 7875642
         Total IP packets processed since reset = 3782287
         Total IPv4 packets processed since reset = 3755319
         Total IPv6 packets processed since reset = 26968
         Total IPv6 AH packets processed since reset = 0
         Total IPv6 ESP packets processed since reset = 0
         Total IPv6 Fragment packets processed since reset = 0
         Total IPv6 Routing Header packets processed since reset = 0
         Total IPv6 ICMP packets processed since reset = 94
         Total packets that were not IP processed since reset = 4093355
         Total TCP packets processed since reset = 204508
         Total UDP packets processed since reset = 2252490
         Total ICMP packets processed since reset = 14688
         Total packets that were not TCP, UDP, or ICMP processed since reset = 1310601
         Total ARP packets processed since reset = 2923053
         Total ISL encapsulated packets processed since reset = 0
         Total 802.1q encapsulated packets processed since reset = 0
         Total packets with bad IP checksums processed since reset = 0
         Total packets with bad layer 4 checksums processed since reset = 268
         Total number of bytes processed since reset = 1029553988
         The rate of packets per second since reset = 4
         The rate of bytes per second since reset = 632
         The average bytes per packet since reset = 130
      Denied Address Information
         Number of Active Denied Attackers = 0
         Number of Denied Attackers Inserted = 0
         Number of Denied Attacker Victim Pairs Inserted = 0
         Number of Denied Attacker Service Pairs Inserted = 0
         Number of Denied Attackers Total Hits = 0
         Number of times max-denied-attackers limited creation of new entry = 0
         Number of exec Clear commands during uptime = 0
      Denied Attackers and hit count for each.
      Denied Attackers with percent denied and hit count for each.
sensor# show int
Interface Statistics
   Total Packets Received = 29934896
   Total Bytes Received = 4010927826
   Missed Packet Percentage = 0
   Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/0
   Interface function = Sensing interface
   Description = Connected to Attacker Switch
   Media Type = TX
   Default Vlan = 0
   Inline Mode = Paired with interface GigabitEthernet0/1
   Pair Status = Up
   Hardware Bypass Capable = No
   Hardware Bypass Paired = N/A
   Link Status = Up
   Admin Enabled Status = Enabled
   Link Speed = Auto_100
   Link Duplex = Auto_Full
   Missed Packet Percentage = 0
   Total Packets Received = 4095925
   Total Bytes Received = 298897396
   Total Multicast Packets Received = 3431616
   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 = 664379
   Total Bytes Transmitted = 42520256
   Total Multicast Packets Transmitted = 0
   Total Broadcast Packets Transmitted = 0
   Total Jumbo Packets Transmitted = 0
   Total Undersize Packets Transmitted = 0
   Total Transmit Errors = 0
Best Regards,
Justin

IDSM-2(5.0)inline mode- Pair Status=down??

I have trouble with configuring idsm-2 inline mode(5.0).
it seems that traffic doesn't go through idsm.
I chechked it on command: sh interfac gi0/7(idsm mode)
the 'pair Status=down'(below) shows that, i think.
moreover, total packet received doesn't increase.
how do i solve it?
Please help!
xxsystems# sh int gigabitEthernet0/7
MAC statistics from interface GigabitEthernet0/7
Media Type = backplane
Missed Packet Percentage = 0
Inline Mode = Paired with interface GigabitEthernet0/8
Pair Status = Down
Link Status = Up
Link Speed = Auto_1000
Link Duplex = Auto_Full
Total Packets Received = 38
Total Bytes Received = 2584
Total Multicast Packets Received = 38
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 = 12
Total Bytes Transmitted = 1152
Total Multicast Packets Transmitted = 0
Total Broadcast Packets Transmitted = 12
Total Jumbo Packets Transmitted = 0
Total Undersize Packets Transmitted = 0
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0

You can only pair interfaces on your sensor if your sensor is capable of inline monitoring.
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_installation_and_configuration_guide_chapter09186a00803eb069.html

Error on login....how do I fix this?

So, I have a IDSM-2 module in a 6513 switch. When I try to login to the device I get the follow error:
login: PAM Failure, aborting: Critical error - immediate abort
This looks like a Linux error, at least Google searchs show that it happens in linux systems...which, I believe, the IDSM-2 is built upon.
So, how do I fix it?
Thanks,
Mike

Your order of operations are:
1. Reload the IDSM-2 (from the host router, "hw-module module N reset")
2. Reload the IDSM from the maintenance pratition:
"hw-module module N reset cf:1" (to boot the maintenance partition)
and either upgrade (url of your file server holding a new image required) or restore.

IDSM-2 - upgrade issue - 5.x to 6.x

Hello All,
I have an issue upgrading the IDSM-2 module I'm playing with.
It is currently running version 5.0(2).
The thing is when I try to upgrade the image to the latest 6.x version using the .bin.gz file, I get the follwing error message :
The filename IPS-IDSM2-K9-sys-1.1-a-6.1-2-E3.bin.gz is not a valid upgrade file type.
Continue with upgrade? []:
There is no image file that is not .bin.gz on the download section of the website. Only recovery images have the .pkg extension.
Does anybody how to troubleshoot this simple(I guess) upgrade issue?
Regards,
Thibault.

You are trying to "upgrade" using a "System Image" (-sys-) file instead of an Upgrade file.
The upgrade file for the IDSM-2 is the standard upgrade file used across almost all IPS/IDS models:
IPS-K9-6.1-2-E3.pkg
It can be downloaded here:
http://www.cisco.com/cgi-bin/tablebuild.pl/ips6

IDSM-2 & V6.1

I recently upgraded my IDSM-2 to 6.1. It resides in a 7609 running 12.2(18)SXF8. Mode is just as a sensor (promiscous) and does not block. All the VLANs in the 7609 are spanned to the sensor port.
Since upgrading to 6.1 and monitoring with the IME it has been hanging on a daily basis. Even while trying to access it via CLI, it's hung. Only way to restore communications is to reboot the IDSM (HW Command in the 7609).
Before I open a TAC case on it, has anyone else out there had similar experiences?
Thanks

The only way I was able to see it is in a Sho Tech. There does not appear to be an actual command that gives you the error log. It appears the log is part of the LINUX Kernel running as the blade OS. This is what the error output looks like:
20May2008 10:48:51.900 0.024 sensorApp[812] sensorApp/W errWarn IpLogProcessor::addIpLog: Ran out of file descriptors
There were literally hundreds of these errors. TAC was the one making the decision this was the issue. They only appeared after the 6.0 to 6.1 upgrade.
HTH
Jim

IDSM-2 Inline Vlan Pair - Duplicate Packets

Dear All
We have a setup where two IDSM-2 modules are ether-channeled together in a single 6513 Chassis.
There is an FWSM module also, which acts as the default gateway for all internal VLANs.
Problem: IDSM show stat virtual-sensor command is showing tons of 'Duplicate Packets'
show statistics virtual-sensor | inc Duplic
Duplicate Packets = 2950967
Inline TCP Tracking Mode: Interface and VLAN
Topology:
Assume Client VLAN = 10 and Server VLAN = 60
IPS Inline VLAN Pairs:
10 >> 110 (Client VLAN)
60 >> 160 (Server VLAN)
Client >> Server Flow: (Layer 2):
[ClientPC] >>>> Access Switch (VLAN 10) >>>> Core SW >>>> IDSM-2 (VLAN 10--110 Pair) >>>> Core Sw >>>> FWSM VLAN 110 >>>>
FWSM VLAN 160 >>>> Core Sw >>>> IDSM-2 (VLAN 160--60 Pair) >>>> Server Switch (VLAN 60) >>>> [Server]
Core Switch IPS Etherchannel Setup:
Group 5: IDSM(A) and IDSM(B) Port x/7
Group 6: IDSM(A) and IDSM(B) Port x/8
Some VLAN Pair(s) are on interface x/7 and others are on x/8
Because of the above issue, we see a lot of TCP normalization signatures being fired (as the IPS gets confused with duplicate packets seen for the same flow). Specially signatures 1330:12 :17 and :18.
It is also causing some applications to break (e.g. Veritas Netbackup 6.5). When I removed the DENY action from these signatures, our IPS started having stability issues (This could also be due to E3 upgrade)
Should we change the Tracking mode to 'VLAN' only, OR any other possible solution?. Should not the 'interface and vlan' setting be sufficient?.
Regards
Farrukh

This will take some traffic analysis to determine what is going wrong.
You might need to place a sniffer to watch the traffic on the client where the backup software is running at the same time that you capture the traffic on the sensor.
Look to see if there are any differences in the traffic.
Look for any anomalies in the traffic.
Look to see if maybe the backup software is not using a standard TCP connection (is it jumping the tcp sequence numbers in any abnormal way?)
You might also try some things on the sensor to determine if the sensor itself might have an issue.
Determine if the connction passes through 2 connections (inline vlan pairs) monitored by the sensor.
If you can, you might try removing both of the pairs from the virtual sensor. (don't delete the pairs, just remove them from the virtual sensor so they won't be analyzed)
And see if the backup works.
If it does then just add in one pair, and see if it keeps working.
If it has errors with just the one pair, then the problem is likely not because of the connection being monitored twice.
Something else must be weird about the connection.
If the problems are only seen when having both pairs in the same virtual sensor, then try placing the pairs in different virtual sensors and see if the problem goes away.
If the problem goes away when in different virtual sensors, then there may be an error in the inline tcp session tracking code that should track connections separately for each interface/vlan.

IDSM-2 inspection load high

We have an IDSM-2 installed in our core switch and we are facing problem now, The module is hanging randomly and we can not login through session or GUI at that time. The version running is 7.0(4) E4 and we need to restart the module to recover the same. After the reload we have found that the Inspection load is touching 100 % continuosly , It is working in promiscous mode and only two vlans (server vlans behing FWSM) are monitoring. One of the Vlan is having more number of servers when I removed the same Vlan from the capture the inspection load comes back to normal ... Did some one face this problem before ? Is it really a through put issue ?? How can I confirm that ? Or is it due to any bug?

Hello Dustin,
Thanks for the reply, I have checked the interface status aqd found that FIFO overuns in the sensing interface 0/7 but it is not increasing. Also found that inspection load normal at this point of time, I think when it reaches 100 % it will increase the FIFO counters. Below are the interface status..
IDSM2_Secondary# sh interfaces | in Missed
   Missed Packet Percentage = 0
   Missed Packet Percentage = 0
   Missed Packet Percentage = 0
IDSM2_Secondary# sh interfaces | in Errors
   Total Receive Errors = 0
   Total Transmit Errors = 0
   Total Receive Errors = 1
   Total Transmit Errors = 0
   Total Receive Errors = 0
   Total Transmit Errors = 0
IDSM2_Secondary# sh interfaces | in FIFO
   Total Receive FIFO Overruns = 0
   Total Transmit FIFO Overruns = 0
   Total Receive FIFO Overruns = 11828560
   Total Transmit FIFO Overruns = 0
   Total Receive FIFO Overruns = 3
   Total Transmit FIFO Overruns = 0
IDSM2_Secondary# sh interfaces | in FIFO
   Total Receive FIFO Overruns = 0
   Total Transmit FIFO Overruns = 0
   Total Receive FIFO Overruns = 11828560
   Total Transmit FIFO Overruns = 0
   Total Receive FIFO Overruns = 3
   Total Transmit FIFO Overruns = 0

IDSM-2 Error

Similar Messages

Maybe you are looking for