4507R with redundant sup - lost communicaton

Unanswered Question
Sep 15th, 2008
User Badges:


for security I did some configuration steps. The supervisories lost communication and now is one module disabled.

Which protocol they use to communicate with each other? VTP? BOOTP?


000160: Sep 15 12:01:32.823 MEST: %SYS-CLUSTER_MEMBER_14-6-CLOCKUPDATE: System clock has been updated from 12:01:32 UTC Mon Sep 15 2008 to 12:01:32 MEST Mon Sep 15 2008, configured from console by console.

000161: Sep 15 12:01:32.995 MEST: %SW_VLAN-CLUSTER_MEMBER_14-6-VTP_MODE_CHANGE: VLAN manager changing device mode from SERVER to TRANSPARENT.

000162: Sep 15 12:01:35.379 MEST: %C4K_REDUNDANCY-CLUSTER_MEMBER_14-6-INIT: Initializing as ACTIVE supervisor

000163: Sep 15 12:01:35.383 MEST: %C4K_REDUNDANCY-CLUSTER_MEMBER_14-3-COMMUNICATION: Communication with the peer Supervisor has been lost

greetings from bulgaria

richard riemer

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Mon, 09/15/2008 - 11:24
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Richard,

you have probably defined a receive ACL or CPP control plane policy.

inside a single chassis addresses of type 127.0.0.x are used to communicate in a cisco 6500 and likely in a 4500.

you can start by adding a permit statement for net to itself

permit ip

the protocols used are likely SNMP, ICMP, telnet and others.

Hope to help


richi3161 Mon, 09/15/2008 - 20:41
User Badges:

Hello Giuseppe,

looking after the disabled supervisor, I found it in the ROMMON. Perhaps there was a misconfiguration with config reg 0x2101 without boot file path given.

I planned to install a ACL, but not used it.

Why was the formerly active SUP rebooted?

After booting the disabled SUP now is everything working with SSO.

Thanks for helping, Richi.

Giuseppe Larosa Mon, 09/15/2008 - 22:16
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Richard,

good news that you solved your issue.

I had problems in using receive ACL so I guessed you have done something similar.

>> Why was the formerly active SUP rebooted?

It is difficult to undestand this, but it is possible that protocols that manage supervisor redundancy have this behaviour to reboot the supervisor changing state from active to standby in order to assure that it will synchronized with the new active supervisor.

Best Regards



This Discussion