OOB warning during IPS 4260 signature update via CSM

[cashqoo]

Hi,

During the recent IPS signatures updates via CSM, i have noticed that there was warning (below).

>OOB change detected - Out of Band(OOB)and sensor configuration change happened on device. But you selected to continue deployment in case of OOB. Continuing...

what is the cause & impact of such event?

As i suspected there is a mismatch of configuration, my inline interfaces are no longer applied to the virtual sensor 'VS0'. Could it be due to the mis-synchronisation?

Apprepriate for any advice.

thanks

cash

[smalkeric]

Before you upgrade your sensors to Cisco IPS 6.0(4), make sure you perform the following tasks:

•Upgrade all version 4.x or earlier sensors to IPS 5.0(1) before applying the IPS 6.0(4) service pack.

•Make sure you have a valid Cisco Service for IPS service contract per sensor so that you can apply software upgrades.

If you are using SNMP set and/or get features, you must configure the read-only-community and read-write-community parameters before upgrading to IPS 6.0(4).

In IPS 5.x, the read-only-community was set to public by default, and the read-write-community was set to private by default. In IPS 6.0(4) these two options do not have default values. If you were not using SNMP gets and sets with IPS 5.x (for example, enable-set-get was set to false), there is no problem upgrading to IPS 6.0(4). If you were using SNMP gets and sets with IPS 5.x (for example, enable-set-get was set to true), you must configure the read-only-community and read-write-community parameters to specific values or the IPS 6.0(4) upgrade fails

[cashqoo]

Is there anyone from Cisco might have any idea or advice?

[marcabal]

CSM keeps an internal copy of the configuration it last pushed to the sensor.

Each portion of the configuration has a configToken assigned to it by the sensor. The config token is a base 64 encoding of that configuration portion.

Each time CSM goes to push a new configuration it will compare the configToken of it's previously saved configuration for that sensor against the configToken of the configuration currently on the sensor.

If the 2 configTokens match, then no configuration change has been made since the last time that CSM pushed a configuration to the sensor. CSM can safely push the new configuration to the sensor.

If the 2 configTokens do not match, then an Out Of Band (OOB) configuration change has been made to the sensor. This means that the sensor's configuration has been modified by something other than CSM. This may have been a user changing something through the CLI or IDM instead of using CSM.

In these situations CSM gives you the option of either stopping the push of the new configuration so the detected changes can be imported and evaluated by the user, or to go ahead and push the changes to the sensor.

If you decide to go ahead and push the changes to the sensor, the outcome of the configuration change is not guaranteed.

The sensor may wind up merging the OOB changes in with the new configuration from CSM, or the CSM changes may wind up overwriting the OOB changes.

So telling CSM to push the new configuration even when OOB changes have been detected can be risky and can cause loss of some of your configuration.

I fyou will be making changes with CLI or IDM, then it is always best to import those changes into CSM before making further configuration changes in CSM.

[cashqoo]

Hi Marcabal,

Thanks for your reply. Probably answer what i need to know.

However, my initial action is to update IPS's signature. So my impression of the signature update precess now is, CSM will compare the configuration (using configToken). If they are different, CSM will then prompt for 'proceed or stop'. If proceed, CSM will copy the new signature and the CSM's last save config over to the IPS.

Please correct me if i am wrong.

I do not understand the purpose of such CSM action. and may i know if this happens to be documented and available on cisco website?

regards

cash