Expand Configuration and Management Manual (G06.24+)

Troubleshooting
Expand Configuration and Management Manual—523347-008
21-30
Multi-CPU Path Problems
Common Multi-CPU Path Problems
The following is a list of common multi-CPU path problems:
•
You received the following EMS message during load balancing: “Network
Requests Aborted.” This message does not indicate that a problem exists; it is
generated when an Expand line-handler process pair is changed and messages
that were in transit are aborted. These messages are retried by the file system.
•
You tried to rebalance the multi-CPU path several times, but the load factors (LFs)
indicate that the paths are still not balanced. First, wait a few minutes; it might take
a while for the ETFs to stabilize at their new values. If the ETFs are still not
Table 21-16. Multi-CPU Path Problem Resolution Procedures
Task Procedure
Check that the multi-CPU path is
enabled.
Use the following SCF command to see if the paths
you expect to be part of the multi-CPU path are actually
configured:
INFO PROCESS $NCP, LINESET
If some of the paths do not display an “S” next to the
LINESET number, then either the local or remote
Expand line-handler process does not have the
SUPERPATH modifier enabled. Use the following SCF
command on both the local and remote Expand line-
handler processes to determine which line-handler
process configuration is in error:
INFO PATH $device_name, DETAIL
Determine if the traffic is balanced
over all paths in the multi-CPU
path
Use the following SCF command to find the base time
factor (TF) effective time factor (ETF) for all paths that
are part of the multi-CPU path:
INFO PATH $NCP, SUPERPATH
The load factors (LFs) of all the paths in the multi-CPU
path should be roughly the same. (The LF is the ETF
divided by the base TF.) If they are not, rebalance the
paths using the following SCF command:
ACTIVATE PROCESS $NCP, REBALANCE
\system_name
where system_name identifies the multi-CPU path to
be rebalanced.
Caution. A Superpath rebalance can introduce a temporary disruption in the network, similar
to but in general less than that caused by an Expand path change. For that reason we
recommend limiting rebalances to off-peak hours unless an imbalance is clearly causing
immediate problems.