In order to facilitate timely signature/system updates, is there a way to stop the AnalysisEngine or the IDS sensor without resetting it? Whenever I attempt to update the system, it says AnalysisEngine is too busy and says to wait. If stopping the sensor is not part of the CLI, it should be, or at least part of the Upgrade process to make this happen when the admin says it should. I have not found this described in any documentation yet.
Neither the user nor the upgrade should stop the analysisEngine to start the upgrade. The reason is that the upgrade itself has to communicate with the analysisEngine in order to even do the update.
There are special messages that have to be passed to analysisEngine for the upgrade to ocurr properly, it is not just a simple replacement of files.
If you run "cids stop" you won't be able to do the upgrade.
We had several problems in previous upgrades where the upgrade was attempted while analysisEngine was busy and the end result was failed updates, and worse yet in some cases there was even file corruption. The file corruption forced users to re-image their sensors to get it working again.
So more recent updates first check to see if analysisEngine is responding before continuing, in order to ensure that the upgrade can proceed.
There is one problem that has been found with the update where the analysisEngine busy error was being reported even though analysisEngine was responding just fine. This was because there was a small mixup in the reporting of the error message and it was a different error that was actually ocurring. This should be fixed in the most recent signature update.
So one of the first things to do is run "show interfaces" on the sensor and see if statistics are being reported for both the command and control interface as well as the sniffing interfaces. AnalysisEngine is the process that reports statistics on the sniffing interfaces. If you get an error that analysisEngine is busy then keep reading below. If the statistics for the sniffing interfaces is reported correctly then try the update again. If it fails with the same error, then you may be running into the error message mixup and either need to on your own try to determine what the other error is, or call the TAC for assistance.
There are several things that can keep analysisEngine from responding (give you the busy error message).
1) You've just rebooted the sensor. It takes a few minutes for the sensor to initialize itself before analysisEngine can respond. So just be patient.
2) You've just reconfigured the sensor. For a short time after a reconfiguration, analysisEngine will be unresponsive at it prepares and implements the new configuration. Once again just be patient.
3) After another Signature Update. Similar to a reconfiguration, analysisEngine may take a little bit to load in the new configuration of the Signature Update. Just be patient.
All of the above 3 are normal and should be expected. In most cases the analysisEngine is responsive again in a few minutes, and in very rare cases (usually only when a large amount of customization has been done) may take up to 20 minutes.
Usually it just means being a little patient.
We are continuing to work on speeding up the reconfiguration and initialization process of analysisEngine.
If after waiting 20 minutes and trying again, the analysisEngine is still unresponsive then try the following:
Execute "show version" and see if analysisEngine is "running".
If analysisEngine is "not running" then you have a problem on your sensor. There are a few issues currently being worked on that will be released in a service pack. Try rebooting your sensor. Give analysisEngine a few minutes to initialize and try the update again. If analysisEngine goes to "not running" again in "show version" then contact the TAC.
If analysisEngine is "running" then execute "show interfaces" and see if it reports an error about not being able to communicate with analysisEngine or sensorApp. Also try executing "show events". If you see new alarms being generated, but no statistics for the sniffing interfaces, then this usually means that the analysisEngine is either responding to another user, or you've come across a bug we don't know about. Try rebooting, waiting for analysisEngine to initialize and try upgrading again.
If no alarms are being generated and "show interface" is producing analysisEngine or sensorApp errors then you have likely run into a bug. To upgrade: reboot, wait for analysisEngine to initialize, and then upgrade. If it happens again that analysisEngine is unreponsive for longer than 20 minutes and does not create new alarms then contact the TAC.
Side Note for you: AnalysisEngine and sensorApp are the same thing. So if I've used both terms above, just realize they are both names for the same process.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...