• September 22, 2020, 10:24:44 PM
Welcome, Guest. Please login or register. Registration is free.
Did you miss your activation email?

Author Topic: SNMP INFO Cannot communicate with backup CPU  (Read 1395 times)

0 Members and 1 Guest are viewing this topic.

Offline pat2012

  • Sr. Member
  • ****
  • Posts: 156
SNMP INFO Cannot communicate with backup CPU
« on: April 10, 2015, 09:59:42 PM »
Hi guys.

I have a brand new system in the lab.

Card Info :

        Slot#             FrontType         FrontHw    Oper    Admin      BackType   BackHw
                                                   Version     Status  Status                      Version
            1       48X1000BaseTX-R      01            up        up          DPM2           02
            3      12X10GBaseXL-SFP     01            up        up           EEDPM3       02
            4    2x10GB32x1000BaseX   01            up        up           EEDPM3       02

            5                  CPUR           54            up        up           FSFM           51
            6                  CPUR           54    dormant        up           FSFM           51

The card in Slot #1 isn't new.   ;D

The problem is with the CPU in Slot #6 as Master, after some hours I saw this error in the log:

SNMP INFO Cannot communicate with backup CPU

I reset the switch and CPU #5 became Master. On checking the log after some days (this is in a lab so I haven't been working on it much), I saw the same error.

Reset CPU #6 and communication was restored.... for about a minute. Then communication is lost again.

According to the sho tech above, the CPU #6 is UP and is dormant, but the Master cannot communicate with it.

Seeing that these are new CPUs in a new chassis, how can I determine which one is faulty? I'm thinking of using a spare 8895 and a process of elimination. But before I do that, I'm thinking of physically reseating both cards and observing.

Have you guys encountered this before? The CPUs are not running in HA mode. Actually, there isn't any configuration on the switch - besides mgmt IP.

I saw an old post on Michael's blog from 2009, but that referred to CPUs in HA mode. I guess the root of the problem is the same - loss of communication between CPUs.

It would be very disheartening to discover a brand new (expensive) CPU to be defective.  >:( :(

But then again.... Stuff happens.