SSL services not starting after running commit_redundancy script.

[aanelso1]

We have been using the commit_redundancy script for some time between two CSS 11506's (Ver. 7.50). For some unknown reason after the script is run and it runs the byte count between the two, it fails. When I check the two configurations, the only differences that I find are that the service SSL-SLOT3 is in a SUSP/INIT state and the SSL-PROXY-LIST SLOT3 is not active. I can run the RCMD to get these started, but next time the script runs, the sevice and proxy-list end up in same states. Does anybody have a reason that this is happening and what can I do to fix it? Thanks in advance!

[mchin345]

If you are upgrading from a version of WebNS software earlier than version 7.40, be aware of the following Adaptive Session Redundancy (ASR) configuration restrictions in WebNS software versions 7.40 and higher:

If your CSSs have mismatched chassis configurations (a different number of Session Processors (SPs) in each CSS), ASR will not function after the upgrade. Before you upgrade, ensure that both CSS chassis have the same number of SPs.

If your CSSs meet the ASR requirement of having the same number of SPs in each chassis, you must upgrade both CSSs to WebNS Version 7.40.

During the upgrade process, ASR does not function and you lose any sessions that are in progress.

When upgrading the CSS software, you can use the upgrade script or manually enter CLI commands. The upgrade script allows you to upgrade the CSS either automatically or interactively by responding to script prompts. Either way, the tasks that the script performs include:

Checking to see how many installed software versions are installed on the CSS, and if the CSS contains the maximum number of installed software versions, then deleting an older software version.

Archiving the running configuration to the startup configuration.

Copying the new ADI to the CSS boot-image directory.

Unpacking the new ADI.

Copying the scripts and user profiles from the older CSS software to the new software. The copied scripts do not include Cisco-supplied scripts except default-profile.

Setting the primary boot file

http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_750/admgd/upgrade.htm#wp1013418

[jasmina27s]

Hi,

We have the same problem (version 8.20).

Does anyone have a solution or suggestion?

Best regards,

Jasmina

[jasmina27s]

Hi,

Maybe this experience could help someone.

We solved our problem, and the reason was quite silly.

"show run" output on the primary CSS showed that in the SSL proxy list, command "active" was listed as the first command in that confguration segment (proxy list).

During execution of "commit_VipRedundConfig" running configuration on the secondary CSS is cleared and a script called "newconfig" is executed to configure secondary CSS.

The script "newconfig" contains exact configuration commands taken from the primary CSS configuration file, with modified addresses, but order of commands is exactly the same as on the primary CSS (show run), which means that "active" command gets to be executed first under the SSL proxy-list definition.

SSL proxy list cannot be activated before "ssl-server" commands are configured. That is why active command is rejected, all following commands are applied, but "active" command under the service of type ssl, which uses this SSL proxy list, also gets rejected because the proxy list is not activated.

"commit_VipRedundConfig" script does not detect exact problem, but is detects that final configuration files are not identical, and it shows "unsuccessfull" as a result.

The solution is to configure the SSL proxy list on the primary CSS from the begining. Remove all "ssl-server" commands and re-add them. Commant "active"  should be applied at the end, and it should appear at the end of SSL proxy list configuration in "show run".

After this,  "commit_VipRedundConfig" script should be successfull!

It is strange that order of commands causes this problem, and I'm not sure how and why this "active" command appeared on the top of the proxy list (afterwards, I could not reproduce "active" showing at the top of the segment)...

Best regards,

Jasmina