Eric Stewart: Running Off At The Mouth

Our first two 7706s, powered on

Our 100Gb backbone project involves six Cisco Nexus 7700 series chassis: two 7706s will take on the role of our backbone routers (replacing a couple of Nexus 7009 chassis that are unfortunately running blades not compatible with the 100Gb blades we’d need); our two busiest nodes will get one 7706 each (replacing some old Catalyst 6500 chassis); and two 7710s will go into our data center to provide the core connectivity (also replacing a couple of 6500s).  I opened my mouth early on in the planning stages and said “I’ll do the data center ones.”  Hopefully you’ll see some posts outlining my experiences with the process, including what it takes to upgrade to a Nexus 7700 from a Catalyst 6500.

But before then, we have some playing and testing to do on these units.  There should be a picture of the initial test environment here somewhere – two 7706s (the ones ordered for the nodes) with two of four power supplies plugged in each, with a 100Gb line running between them.

First thing you need to know:

Power starts in “redundant” mode, which means that if you only have two power supplies plugged in (any two), you’ll only get power from one of them.

So, for testing purposes, we needed to:

switch(config)# power redundancy-mode combined force

As in our case what happened was blade two didn’t want to get powered up.  We plan on looking at config options later in order to try and pair up the power supplies so that they are properly redundant for our purposes.

Close up of the 7706 Supervisor Module

Next thing you need to know about Nexus 7K chassis: beware of those seemingly harmless gray module eject buttons.  So far as we know right now, on the full sized blades (IOW, not the supervisors), there are two, and pushing those buttons (which unlocks the mounting levers) also automatically puts the blade into a “graceful shutdown” state.  It is my understanding that on the 6500s, the blade wasn’t powered down until you either commanded it to through IOS, or you physically pulled the blade out.  In other words, it was possible to pop the levers loose, but as long as you didn’t open them fully you could simply just relock the levers and all was well.

Look, we know how geeks can be.  Popping buttons and whatnot.  Just be aware that this is one of those cases where you don’t want to just push any old button.  Especially since the supervisor blades only have one each, and hitting both of those will (we haven’t tested this yet) probably bring your system down completely.  It was discussed among our group while we were powering them on that they should probably be bright red in color and maybe even give you a little shock when you touch them, so that you’d have to be sure you really wanted to power the blade down when you pushed them.

If you’ve popped the lever on a supervisor, it’s possible that pulling the blade out and putting it back in will automagically bring it back up to normal operation (regular blades should just power back up if you relock the lever; this is insufficient for supervisors).  Your other option is to relock the lever and in config mode:

switch(config)# no poweroff module <slot#>

And it should start powering back up (initially indicated by a solid red status light on the supervisor in question, instead of a blinking one).  Supervisors will take quite some time before it’s considered back up and normal.

Finally, we thought we saw some inconsistent behavior between a supervisor that was active, and the one in standby when you hit the eject button: the standby module’s status light would continually blink red, whereas I could have sworn we figured out that the active module would blink red but eventually go solid red, as if it were ready to be removed.  Thing is, I haven’t been able to reproduce this behavior on my own – hitting the eject button on a supervisor module (be it the active or standby module) would just result in the status light blinking red (at least for as long as I was willing to wait for something different to happen).