The first step in diagnosing a dependent node problem is verifying that both the node and associated adapter have been properly configured and are operating correctly. To do this, perform steps 1, 2, and 3 here. You can optionally perform step 4.
splstnodes -t dependent node_number reliable_host_name\ management_agent_hostname extension_node_identifier snmp_community_name
splstadapters -t node_number netaddr netmask
SDRGetObjects switch_responds
You should receive output similar to the following:
node_number switch_responds autojoin isolated adapter_config_status 1 0 0 0 css_ready 3 0 0 0 css_ready 4 0 0 0 css_ready 5 0 0 0 css_ready 6 0 0 0 css_ready 7 0 0 0 css_ready
See the online help for an explanation of the notebook associated with the IP Node. Review the information associated with the node to verify that it is operating correctly.
Verify that these configuration parameters are correct. If you find errors here with any values other than the node number, use the endefnode and endefadapter commands to change those values. If the node number is incorrect, remove the node number and replace it with a correct node number. To remove it, use the enrmnode command or the enrmadapter command.
The next step is to determine what state your dependent node is in on the SP Switch. Use the SDRGetObjects switch_responds command to determine this. Here is an example of the output from this command, showing several dependent nodes in various states:
node_number switch_responds autojoin isolated adapter_config_status
1 0 0 0 not_configured
2 0 0 0 css_ready
3 0 0 0 micro_code_load_failed
4 0 0 1 css_ready
5 0 1 1 css_ready
6 1 0 0 css_ready
An examination of each of these six nodes and their states will help to diagnose problems.
Dependent Node 1, in the previous example, is in the state of a newly-defined dependent node. This state means that the configuration is not complete, or there is no communication via SNMP to the node. See SNMP configuration diagnosis for more information on diagnosing and correcting SNMP communication problems.
Dependent Node 2 is in the state of a dependent node after its dependent adapter has been defined and the node has been reconfigured.
Dependent Node 2 now shows the adapter_config_status is css_ready. This means that the configuration information has been delivered to and accepted by the node via SNMP. This node is ready to become active on the SP Switch network. If this reconfiguration was not successful, the adapter_config_status would either remain not_configured or become micro_code_load_failed, as seen with Dependent Node 3.
Dependent Node 3's micro_code_load_failed adapter_config_status could also indicate that the node is still resetting the SP Switch Router Adapter in its chassis and has not finished. This reconfiguration can take some time, and should be checked again. If you suspect that your configuration information is not being properly transmitted via SNMP to the node, check that the SP Switch Router Adapter is in the same slot as defined in the adapter definition.
Dependent Nodes 4 and 5 are fenced and ready to be unfenced and brought onto the SP Switch network. The only difference is that Dependent Node 5 has autojoin turned on. This means that whenever a reconfigure of the SP Switch Router Adapter occurs in this node, it will automatically unfence. Dependent Node 4 will have to be unfenced manually by issuing the Eunfence 4 command on the control workstation.
Dependent Node 6 indicates the active state of a properly configured dependent node. If you are unable to attain this state with a dependent node, and you cannot discover any SP-related configuration or SNMP network-related problems, then you will have to open an administrative telnet session to the node to diagnose problems there.