Solved: Cannot Gain Access To IDSM-2

NotMeHere · ‎05-13-2005

Hello...

Occasionally my IDSM2's will just stop reporting alerts. Their connection status in VMS IDS Monitor will show "Not Connected", and when I try to SSH to the IDSM2 they prompt for a username, and then as soon as I hit enter they will drop the SSH session printing the below error message. When they are doing this, the are also inaccessible via HTTPS. And when I try to session into them via the switch they reside in, they just hang after I enter a username. I usually can reset them via the switch "hw-module" command, and after several times of resetting them they will begin to work again. I'm just curious as to why they are doing this, and if I am doing something to cause it that can be avoided. They are running the latest version of 4 software and signatures, although I've always had a problem with them doing this even in earlier versions. Below is the error message they print out.

<IDSM-NAME> kernel: Assertion failure in do_get_write_access() at transaction.c:721: "(((jh2bh(jh))->b_state & (1UL << BH_Uptodate)) != 0)"

Thanks in advance

gfullage · ‎05-16-2005

This is a known issue with very busy sensors where the hard disk eventually gets out of sync due to its constant use (something hard disks are not really designed for) and the entire system crashes. Basically every alert the IDSM sees is written to a rotating 4Gig log file on the hard disk, and with sensors that are seeing a large number of alerts the hard disk never gets a chance to stop and eventually spins itself out of alignment. The quick, albeit temporary fix, is to shutdown the blade, wait 5 minutes, then power it back on again. The shutdown procedure spins down the hard disk properly and resets it. If the sensor is kept busy though, the problem will occur again.

We have implemented a few fixes to work around this problem. You mention you're running the latest code, but you need to apply the latest service pack patch also to get around this issue.

Patches are obtained from here:

http://www.cisco.com/cgi-bin/tablebuild.pl/ids-patches

The latest one is patch "g", they're cumulative like signature updates so applying this one will get you all the previous ones too. Apply this and you should find everything works a LOT better than it did.

View solution in original post

gfullage · ‎05-16-2005

This is a known issue with very busy sensors where the hard disk eventually gets out of sync due to its constant use (something hard disks are not really designed for) and the entire system crashes. Basically every alert the IDSM sees is written to a rotating 4Gig log file on the hard disk, and with sensors that are seeing a large number of alerts the hard disk never gets a chance to stop and eventually spins itself out of alignment. The quick, albeit temporary fix, is to shutdown the blade, wait 5 minutes, then power it back on again. The shutdown procedure spins down the hard disk properly and resets it. If the sensor is kept busy though, the problem will occur again.

We have implemented a few fixes to work around this problem. You mention you're running the latest code, but you need to apply the latest service pack patch also to get around this issue.

Patches are obtained from here:

http://www.cisco.com/cgi-bin/tablebuild.pl/ids-patches

The latest one is patch "g", they're cumulative like signature updates so applying this one will get you all the previous ones too. Apply this and you should find everything works a LOT better than it did.