Archived Content: This information is no longer maintained and is provided "as is" for your convenience.
Summary
Question
10.00 was released with a change to the gateways to support IPV6. An IPV6 address is represented using : as the delimiter. An example IPv6 address fe80::20c:29ff:fe75:c359
This causes a problem if an IPv6 address is used in a gateway configuration as the : character was already being used. For example 192.168.1.10:SPIN now appears as an ambiguous specification fe80::20c:29ff:fe75:c359:SPIN
The change put in 10.00/.01 was to replace the : character with @, so we have fe80::20c:29ff:fe75:c359@SPIN, however in doing so it created this satellite backward compatibility regression that was not detected until prior to the release of 10.10 where the defect was first corrected. The back port of this defect was made available in the 10.02 cord.
The opswgw binaries must communicate with the same parsing knowledge. A mismatch will result in a gateway connectivity problem as represented in the following matrix.
|
Core |
Satellite |
Connectivity |
| 10.00 / 10.01 | 9.1x | NO |
| 10.00 / 10.01 | 10.00 | YES |
| 10.00 / 10.01 | 10.01 | YES |
| 10.00 / 10.01 | >= 10.02 | NO |
| >= 10.02 | 9.1x | YES |
| >= 10.02 | 10.00 | NO |
| >= 10.02 | 10.01 | NO |
| >= 10.02 | >= 10.02 | YES |
Answer
Actions to get around this problem
1. When upgrading from 9.1x customers should plan their migration straight to 10.10 or 10.20 and avoid the 10.00 release.
2. An upgrade of the core from 10.00/10.01 to 10.02 should plan on upgrading ALL satellites to 10.02
3. An upgrade of the core from 10.00/10.01 to 10.10/10.20 should plan on upgrading ALL satellites to 10.10/10.20
For use cases 2 and 3 an alternative to a full upgrade of the satellite is to copy the opswgw file from the core running 10.02/10.10/10.20 and replacing the same file on the satellite. Yielding a 10.00/10.01 satellite with a opswgw binary that is compatible with that running on the core. The file is also available from HP Support.
Summary:
|
Upgrade from: |
Upgrade to: |
Actions |
| 9.1x | 10.00 or 10.01 | Avoid upgrading to 10.00 or 10.01. Upgrade to 10.1 or 10.2 directly |
| 10.00, 10.01 | 10.02 |
Upgrade all satellites communicating to core to 10.02 when core is upgraded to 10.02. Alternatively bring down the satellite rename the opswgw file and copy the opswgw file from core running 10.02 to satellite and restart. |
| 10.00, 10.01 | 10.1 or above (e.g. 10.2) |
Upgrade all satellites communicating to core to 10.02 when core is upgraded to 10.02. Alternatively bring down the satellite rename the opswgw file and copy the opswgw file from core running 10.02, 10.1 or 10.2 to satellite and restart. |
Example:
A customer with a primary and secondary SA Core and multiple satellites pointing the cores, all on SA 10.00 would like to upgrade to SA 10.1.
Steps:
1. Point all satellites to secondary SA Core (all on SA 10.00).
2. After primary core is upgraded then apply the hotfix patch on Satellites and point all satellites to primary core.
3. Start upgrade secondary core.
3. Apply the opswgw file from SA 10.1 to satellites. Point satellites to upgraded primary core and re-start satellites.
4. Split the satelites to point to secondary and primary.