SSP 3.3

An SSP appears to become the main successfully, but it cannot issue the basic ssp commands which would control the Sun Enterprise[TM] 10000 platform. Commands such as netcon and power do not work. Also, you can't bring up a domain. The SSP becomes the main just fine and all daemons start up fine, including straps and cbs.

SYMPTOMS:

The only message that is seen in the /var/opt/SUNWssp/adm/messages file which indicates an issue is occurring is:

actioncb: cannot get the master control board number from the snmpd agent.

SSP 3.5

An SSP appears to become the main successfully, but it cannot issue the basic ssp commands which would control the Sun Enterprise 10000 platform. Commands such as netcon and power do not work, but showfailover, setfailover, showdatasync, and setdatasync do work. The SSP becomes the main just fine and all daemons start up fine, including straps and cbs.

SYMPTOMS:

1. The following message is seen in the /var/opt/SUNWssp/adm/messages file upon startup of the SSP as the main:

actioncb: [ID 702911 local0.info] Cannot get the configured control board list.

2. The netcon command shows that it is "trying to connect..." for at least 10 minutes (the user got tired of waiting after ten minutes and killed off netcon). A check of the /var/opt/SUNWssp/adm/messages file after the netcon was run showed the following error message:

syslog: [ID 702911 local0.warning] edd: WARNING: ResponseConfigMgr.cc, 1041: Problem encountered to determine if domain <domain_name> has a valid list of systems boards in its system board list

3. After typing in the command power, the command runs for quite awhile and finally errors:

error:failed to determine the system board configuration

Check to make sure that the SSP does not have an IP address which ends in .255 even if the netmask for that particular subnet allows the .255 address to be used.

For example, using an IP address of 166.37.154.255 as the public network address assigned to the physical ssp with a netmask of 255.255.254.0 is okay from a networking standpoint (this netmask bridges two subnets, and thus this .255 address is not the broadcast address). However, it will break the SSP's functionality as an SSP. Once the IP address is changed so that it ends in something other than .255, the error messages should cease and the SSP functionality should return.

It is assumed that a non-standard class C IP address breaks the communication between the CB and the SSP, even if the IP address which ends in .255 is the IP of the SSP on its public (non-CB private) network. This IP address situation is not documented in any SSP installation guides at this time (the reason Bug ID 4719984 was filed). This bug details the testing that took place to identify the problem and is filed not to fix SSP to allow for usage of the .255 address, but to fix the SSP documentation to reflect that this address can not be used.

Keywords: E10K, SSP

• joshua.freeman@central
• HAS team web page