cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
343
Views
0
Helpful
6
Replies

Redundant Sup II+ not initializing all the way

p-blake
Level 1
Level 1

I am having a problem with a 4507R. I have 2 SUP II+ modules installed in it and the SUP that should be the standby is not booting all the way. If I have one SUP inserted, either one, it boots fine but when both are inserted one becomes active and the other sits waiting to check packet buffer memory. If I remove the active sup then the other one continues the boot process but that is not how they should be working. Any ideas out there?

Thanks..

6 Replies 6

Danilo Dy
VIP Alumni
VIP Alumni

Hi,

Your Supervisor Engine Redundancy may not configured properly. Please post "show redundancy states" or follow this link http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/20ew/configuration/guide/RPR.html

Regards,

Dandy

I thought about that. When I had each SUP installed in the chassis alone I set it to either RPR or SSO then removed it and did the same thing to the other SUP. Once they were each set to the same redundancy mode I powered the switch down, inserted both SUPS and powered it back up. It made no difference on how the redundancy was configured.

When I leave both SUPs in the chassis and try to enter config mode I get a message stating that the PARSER has locked the config and I am unable to make changes as long as the second SUP is installed in the chassis. The Gig interface on the SUP works fine though.

Are the code versions exactly the same ? In rpr mode the standby will not boot up all the way . This link might shed some light on standbys and how to configure .

http://cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/40sg/configuration/guide/RPR.html

Should the second SUP initialize enough to be able to get to the SlaveBootFlash: and other Slave File systems? The Gig link on the second SUP is active but I am unable to get to any of the SLAVE file systems.

Thanks for your help.

Yes I would think so because the standby supervisor pulls its code from those locations. Other words you can't do a "dir on say slavebootflash: ??? Yeah its sounds like something is not quite right but I am not sure what without being able to see it , but I think you should be to get to them because I have upgraded the standby supervisor from the active supervisor before and the stanby was only in rpr mode . You might want to plug into standby console and then reset or pull the stanby out in reinsert it and watch and see if you see anything in the logs. I have never tried to session a standby so I don't know if that is possible or not , maybe someone else could elaborate.

Here is a copy of the log file while the standby SUP boots. It comes to a point in the process that the active SUP checks PACKET BUFFERS. The standby SUP just sits there and does nothing. In the case of this log file the SUP reset itself and stopped at the same place again.

The 2 log files are as follows: One is with a SUP already installed in slot 1 and the standby sup in slot 2. The other is with the Slot 1 SUP removed and only the Slot 2 SUP installed.

Thanks for any insight.

Review Cisco Networking products for a $25 gift card