Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Abt save changes from Device Manager

HI, yall.

I am just wondering, everytime when i make changes to the sensor configurations, eg: signature configs or user configs, the device manager will be unavailable for a few minutes.

During these few minutes, does the sensor actually do a cold boot or warm boot to reload the configurations into memory?

During these few minutes, does the sensor actually stop its sniffing? If yes, how long?

As far as I know IDS in general every sensor when updating their signatures, will have to halt its sniffing for a while to load the new sigs into memory.

Since all configurations are on the sensor, does it mean that every type of configuration change will halt the sensor for those few minutes?



Cisco Employee

Re: Abt save changes from Device Manager

A very basic list of what happens in version 4.1:

The sensorApp process receives the modified configuration.

SensorApp does some initial evaluation on the config to make sure it is valid.

SensorApp stops monitoring traffic and builds new state tables for any modifications made to regular expressions (state tables are also rebuilt if signatures using regexes are enabled or disabled).

Once the new state tables are built the sensorApp responds back to the configuration tool (in the CLI you notice the command is complete).

Now sensorApp restarts itself with the new validated configuraiton.

NOTE: This is just sensorApp restarting and not any of the other processes. Processes trying to communicate with sensorApp (like IDM asking for the current sensorApp configuration) will timeout or receive an error while sensorApp is busy generating the new state tables or restarting with the new configuration.

If no regex tables have to be built then the reconfiguration goes fairly quickly (less than a minute). But if there are multiple regex modifications or if there are multiple signatures enabled or disabled that use regex, then it takes quite a while longer. Depending on the changes made the modification could take a minute to 20 minutes (on the low end platforms).

NOTE: In version 4.0 we use to keep traffic going while the sensor rebuilt the state tables. This caused the rebuild to take much longer than it does now in 4.1.

NOTE: In version 3.1 the new config files would be written and packetd would restart itself to read the new configurationss. Packetd would then also build these same state tables. The difference in 4.1 and 3.1 is that 4.1 doesn't respond back that the config was accepted until after the state tables were built, but in 3.1 packetd would accept the config and restart before building the state tables.

We are working on this and trying to speed up this reconfiguration process.

This same process also takes place when a signature update is done on version 4.1 sensors.

CreatePlease to create content