IPS-K9-6.0-3-E1 issues?

cjbogaards · ‎07-26-2007

Has anyone else tried installing the latest patch with multiple virtual sensors with multiple sig configurations, event action rule configurations? I have been fighting this for a couple of days now. What I have found is that any sig/rule configurations other than the default sig0/rules0 are completely deleted by the upgrade. The virtual sensor configuration is kept, meaining that the sensor continues to try to use a sig/rule config that no longer exists.

This does not make for a happy sensor.

I am just curious if this is specific to what we are doing or if others have come across this.

To get a clearer picture of what I am trying to accomplish.

On one physical sensor, with multiple interfaces, I will have 2 virtual sensors.

Call the first one Outside

It will use custom signature config of OUT

It will also use custom event action rule of OUT.

The second one is IN

It will use custom sig config of IN

It will also use custom even action rules of IN.

These are both different than the default witch is called sig0 and rules0.

When the upgrade is performed, everything but sig0 and rules0 are deleted.

The virtual sensor configuration is still set to use the custom sig and rules, however they are no longer there.

Thoughts?

marcabal · ‎07-26-2007

During the testing to prepare for 6.0(3) it was discovered that an upgrade from 6.0(1) to 6.0(2) using IPS-K9-6.0-2-E1.pkg woudl result in the deletion of other sig, rules, and ad configurations.

This was written as DDTS: CSCsj03856

This DDTS was Fixed in 6.0(3) in the IPS-K9-6.0-3-E1.pkg.

So if you have an existing 6.0(1) OR 6.0(2) sensor running multiple virtual sensors with alternate sig, rules, and/or ad configuraitons, then the upgrade to 6.0(3) will carry forward those configurations.

This was a bug in the 6.0(2) Service Pack installation script for carrying forward configuration, that was fixed in the 6.0(3) Service Pack installation script.

Please confirm that you are installing the IPS-K9-6.0-3-E1.pkg upgrade file to go to 6.0(3) directly form either a working 6.0(1) or 6.0(2) sensor.

If you are on a 6.0(1) sensor DO NOT apply 6.0(2) and then 6.0(3), because the application of 6.0(2) will hit that bug and remove the configs. If you are on 6.0(1) you can SKIP 6.0(2) and go directly to 6.0(3) with the IPS-K9-6.0-3-E1.pkg file.

(NOTE: You can even go directly from any 5.x version directly to 6.0(3) by directly installing IPS-K9-6.0-3-E1.pkg on the 5.x sensor.)

In all upgrades remember to save off your configuration to a separate box prior to the upgrade.

It can be very easy to confuse the IPS-K9-6.0-2-E1.pkg and IPS-K9-6.0-3-E1.pkg files. So be sure you are using the 6.0(3) file with the fix and not the older broken 6.0(2) upgrade file.

Also be sure you are not trying to upgrade by installing 6.0(2) and then 6.0(3); instead upgrade direct to 6.0(3).

If you actually are continuing to see this problem specifically with the IPS-K9-6.0-3-E1.pkg, then either the fix somehow didn't make it into the end package, or you are hitting an edge case not covered by the previous fix.

Before doing another upgrade you should both save off your current config, and just before the upgrade attempt go ahead and get a complete "show tech" output and store it away. Do the upgrade. If it works fine then great. If the problem happens again the run another "show tech" immediately after the upgrade.

You would need to open a TAC case and supply the "show tech" from before the upgrade, and the "show tech" from after the upgrade. Also have the actual IPS upgrade file that you used.

cjbogaards · ‎07-27-2007

thanks for the information.

version before the upgrade is 6.0-2 and trying to upgrade to the 6.0-3 using the IPS-K9-6.0-3.pkg file.

so it looks like the fix may have not made it into the latest patch?

I have a current TAC case open, and I will post results if they ever come up with a solition.

I completely understand the aspect of saving off your config before every upgrade, however, if cisco is going to allow for added functionality, like the virtual sensors, then in my opinion the upgrades need to also accomodate that. It is not an option for me to rebuild every one of our 25+ sensors after every patch or upgrade. If the developers writing the patches are unable to write software that will not destroy the configurations of their own sensors, then maybe the added functionality is not really there.

I am not trying to bash the developers, I completely understand that people are going to use these products in very different ways. Some will just plug in out of the box and leave it. Others like us, will use every bit of the sensor capabilities, sometimes to the extreme of over utilizing them. But basic functionality like keeping signature configurations should be addressed in the fore front. Not an after thought when people call complaining.