Config Router

You are here: Home / Juniper / CHASSISD_IPC_CONNECTION_DROPPED

CHASSISD_IPC_CONNECTION_DROPPED

by

CHASSISD_IPC_CONNECTION_DROPPED

The chassis process (chassisd) dropped its interprocess communication (IPC) connection to the indicated component (field-replaceable unit, or FRU).
The message is logged whenever the interprocess connection to a component is terminated or reset. This message reports an event, not an error.

Examples of possible entries in the system message file include:

May 25 20:53:20 xxxx-xxx chassisd[771]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 1
 Sep 11 13:03:16.599 2009 xxxx-RE0 chassisd[73897]: %DAEMON-3-CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FEB 2
 Jun 1 02:40:46 xxxx-xxx chassisd[3060]: %DAEMON-3-CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for SFM 0
 Jun 3 19:29:33 xxx-xx chassisd[3118]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for SPMB 1

The message can apply to several components, including the FPC, FEB, SFM, and SPMB components.

There are many possible causes for this event.

The IPC connection message is typically a symptom of a component having issues and being restarted in an attempt to recover. For this reason, it is important to obtain log information to determine the exact cause of the initial trigger.

Possible causes might include one of the following, depending on the source of the connection problem:

  • Memory errors
  • Process errors
  • Clock errors
  • Connection timer timeout

Perform these steps to determine the cause and resolve the problem (if any). Continue through each step until the problem is resolved.

1.Collect the show command output on the Routing Engine.

Capture the output to a file (in case you have to open a technical support case). To do this, configure each SSH client/terminal emulator to log your session.

request support information | no-more
 show log messages | no-more
 show log chassisd | no-more
 show system core-dumps

If the IPC connection message refers to an FPC, obtain the logs from the FPC by issuing the following sets of commands:

start shell pfe network fpc#
 fpc> show syslog messages
 fpc> show nvram
 fpc> exit

OR

request pfe execute command "show syslog messages" target fpc#
 request pfe execute command "show nvram" target fpc#

Note: Replace the ‘#’ character with the number of the FPC that reported the message.

If either an FPC or an FEB card reports this event, collect additional output by issuing the following commands:

show chassis feb
 show chassis fpc
 show chassis fpc pic-status
 show chassis fpc-feb-connectivity.

If the source of the message is an SFM card, collect additional output from the SFM by issuing the following commands:

start shell
 su
 <password>
 vty sfm#
 show nvram
 show syslog messages
 show pfe stat error
 show bchip 0 error
 show bchip 1 error
 show bchip 2 error
 show bchip 3 error
 show bchip 4 error
 show bchip 5 error
 show bchip 6 error
 show bchip 7 error
 exit

Note: Replace the ‘#’ character with the number of the SFM that reported the message.

2.Analyze the show command output.

Review the events that occurred at or just before the appearance of the message (events such as Routing Engine switchover or an interface flap). Do these events help you identify the cause?

Yes – Use these events as the basis for root cause investigation.
No – Continue to Step 2b.

Do the log messages include the time of the initial event message?

Yes – Use these events as the basis for root cause investigation.
No – If the messages log file does not contain this message because the entries occur after the event, check the log messages archive file for this message. For example, the previous messages file can be accessed with this command: show log messages.0.gz | no-more. Continue to Step 2c.

Did the Routing Engine generate a core-dump file with a timestamp corresponding to the moment that the event message appeared?

Yes – Open a case with your technical support representative to investigate the issue further. Attach the information collected above to the case.
No – Continue to Step 2d.

Do the logs contain any memory errors?
Yes – Open a case with your technical support representative to investigate the issue further. Attach the information collected above to the case.
No – Continue to Step 3.

3.Check the configuration. Did it change? Was the software recently upgraded or downgraded?

Yes – The Junos OS will attempt to resolve an issue with hardware associated with this event by automatically resetting the component. Usually, this will resolve the issue. To confirm that the issue is resolved, monitor the situation for one to two weeks to make sure no more of these event messages are reported. If none are reported, no further action is required. Note, however, that you still must collect the log files as soon as possible in case the error persists, so that further investigation can be conducted.

No – Continue to Step 4.

4.Check the hardware. Did it change? Was new hardware introduced?
Yes – The new hardware might be faulty. Open a case with your technical support representative to investigate the issue further.
No – Continue to Step 5.

5.Does the log message persist?
Yes – Reseat the affected hardware (that is, FPC, SFM, FEB).
No – Continue to Step 6.

6.Does the FRU consistently show the IPC message?

Yes – Move that FRU (FPC, FEB, SFM, SPMB, etc.) to a different slot in the chassis to see if the messages follow that FRU.
No – Continue to Step 7.

7.If these efforts do not resolve the problem, contact your technical support representative to investigate the issue further.