Password Recovery on Cisco Catalyst Switch - Introduction

If you are a LAN Switching engineer and mostly working on Cisco Catalyst Switches, one of the tasks that you should know is Password Recovery. This is something that is very easy to do, but very risky as well.

Easy? Well, Password Recovery is all procedural, and has the same concept in all Cisco Catalyst Switches. Yes, it is very risky too. Especially, if you get too confident, and forgot to do some verifications... or in my own words - "checkpoints". The worst case scenario on doing password recovery is if you overwrite the saved or start-up configuration file and there's no backup. Nice huh?! =)

For this topic, I've divided it into 3 parts:

• Password Recovery on Fixed Switches (Small Boxes)
• Password Recovery on Modular Switches Running CatOS
• Password Recovery on Modular Switches Running IOS
  

The last part can actually be divided further into another 3 parts:

• Password Recovery on 4500 running IOS
• Password Recovery on Catalyst 6500 with Hybrid IOS (MSFC IOS)
• Password Recovery on Catalyst 6500 with Native IOS
  

The reason these 3 are on a single category is that they have a lot of similarities, and we just need to take note of the minor differences.


Concept of Password Recovery

First of all, why do we need to do Password Recovery? Well, it's either you are too old to remember simple passwords, or you've used to many passwords in a short span of time. =P Kidding aside, there's a lot of situations wherein Password Recovery is needed. The best example is when a new network administrator took over a new network with poor documentation. Password Recovery also enables us to resume management of the Catalyst Switch without resetting to factory default (we don't want to lose the current configuration).

Now, as I said earlier, Password Recovery has the same concept in all Cisco Catalyst Switches (and even with Cisco Routers). In Password Recovery, you actually want to bypass the password set on a Catalyst Switch. Most of the time, we want to bypass both the console and enable-mode (Privilege EXEC) passwords. In order for us to bypass the password, we need to bypass the saved or start-up configuration. Why? Well, the console and enable-mode passwords are actually part of the start-up configuration.

Bypassing the start-up configuration is similar to resetting the Catalyst Switch back to factory default, BUT without losing or overwriting the current configuration. We will actually restore the start-up configuration before we can change or remove the passwords.

The steps on how to bypass the passwords or the start-up configurations are actually the main differences in doing Password Recovery on Fixed Switches, Modular Switch Running CatOS, and Modular Switches Running IOS.


Limitations / Considerations

The main limitation on doing Password Recovery on Cisco Catalyst Switches is that you cannot do it remotely (i.e. telnet). Meaning, you should be physically onsite where the Catalyst Switch is, in order to accomplish the Password Recovery procedures. You need to be directly connected to the Catalyst Switch thru console, and to do some manual work, like doing cold reboot.

I guess that's all for now, and wait for the next part. =)

Power Supply Redundancy in Cisco Catalyst 6500

Case Study

I’ve been doing case reviews again, and I came across a case about Power Supply Redundancy in Cisco Catalyst 6500. The customer wanted to add another linecard (module) in their Catalyst 6500, but when the linecard was inserted, the Cat6500 showed a 'power denied' message. The Cat6500 is currently using 2 2500W power supplies in redundant mode, and the customer wanted to replace it with their spare 3000W power supplies. To minimize/prevent service interruption, the customer is asking us if he can inter-mix power supplies with different capacity. He's planning to change power supplies one at a time.

This should have been an easy case to answer. But then, it showed that even if I gained a lot of experience thru the years, I could still show some stupidity. And mind you, this one is a long-standing stupidity.

You see, the engineer who handled the case was quick and confident on his answer. He simply said yes that the Cat6500 would be able to support the redundancy of power supplies with unequal capacities. He even informed the customer that in a scenario where there are power supplies with unequal capacity, the Switch would operate using the limit of the lower capacity power supply to ensure complete power redundancy.

If I had this case, I would have given the same answer. And then, it hit us in our face when the customer replied. Apparently, the customer took our word for it and tried swapping one of the power supplies. We’re correct on the part that it will be just fine to inter-mix power supplies of unequal capacity. It’s on the second part that we were proven wrong when the customer showed us a ‘show power’ command output.

The command output showed that the Cat6500 Switch assumed the limit of the higher capacity. When I saw this part from the case, I got surprised and my first thought is that this could be a bug! I have known/accepted it for a long time that in power redundancy, a Switch will assume the lower limit. It’s what I learned when I was first taught about power redundancy in Cat6500.

Being curious, I searched for the updated document for Power Supply Redundancy. After getting into the correct link, I then realized my stupidity. It specifically noted that for Cat6500 running IOS (Native), the power supplies with unequal capacities will both come up, and the Switch’s total power (wattage) is equal to the output of the power supply with the higher capacity.

Redundant and Non-redundant Power Supply Configurations

The table below will summarize the possible power supply configuration scenarios on a Catalyst 6500 Switch.

Power Supplies	Redundancy	Outcome
Equal Power Output (Wattage)	Enabled	Since both will have equal power drawn, one power supply can support the whole chassis load, when the other power supply fails. Also, load sharing will be in effect wherein each power supply will provide half of the total power requirement of the chassis.
Unequal Power Output (Wattage)	Enabled	In CatOS (Hybrid), if the output difference between the power supplies is less than 10%, redundancy will still be enabled. But if the difference is greater than 10%, redundancy will be disabled wherein only the power supply with the higher output will be enabled. In Native IOS, both power supplies will be up, and the total power rating of the Switch will be equal to the output of the power supply with higher capacity.
Equal or Unequal Power Output (Wattage)	Disabled	The power available to the Switch will be equal to the combined power output of the power supplies, regardless if they have equal or unequal power outputs.

Final Note

Now, you may ask what will happen if the 'active' power supply with higher capacity fails. How will the redundant power supply (with lower capacity) support the Catalyst 6500 Switch? Well, if the current power requirement of the whole Switch (chassis, supervisor(s), fan tray, and linecards) is lower than the capacity of the remaining power supply, there won't be any problem. But if the remaining power supply's capacity is not enough, the switch will shutdown (power-deny) components in this order:

• Power over Ethernet (PoE) devices. The Switch (or the supervisor - being the intelligent component) will shutdown PoE devices from high-numbered ports to low-numbered ports on modules from highest-numbered slots to the lowest-numbered slots (descending order).
• Modules (Linecards). The Switch will shutdown modules from the highest-numbered slots to the lowest-numbered slots (descending order) until the total power requirement will be less than the capacity of the remaining power supply. Supervisor linecards (or supervisor engines) and Switch Fabric Modules (SFMs) will be exempted or bypassed.

Need to know more? Visit this link on Power Supply Redundancy in Catalyst 6500.

EtherChannel Load Balancing

Whew! We just had a very busy week prior to the Thanksgiving weekend. I got loads to do, and currently stuck with case reviews. Part of my job is to do case reviews so that I can check if any of my engineers is stuck in a particular case. If I find one, I review it and try to figure out how I can best help my engineer to move forward with that case.

I haven’t done a lot yet when I reviewed a case from one of my newest engineers. He’s been stuck with a customer who wanted to ‘equally’ load-balance Switch traffic between two switch ports connected to another switch. The customer is currently having 100% utilization in one link, and only 10% in another link.

Try as he may, my engineer was having a hard time explaining to the customer that it is impossible to load-balance EtherChannel links in exact 50-50 split. I see a coaching opportunity here since EtherChannel is one of the fundamental topics that we train our new hire engineers on. To think that I even reinforced it with a special training session! =(

Enough of the angry outburst for now, and let me share what I know about EtherChannel Load Balancing in general.


EtherChannel Introduction

Before we delve into the EtherChannel Load Balancing topic, let’s have an introduction first on what is EtherChannel, and why do we need it on our Switches.

By definition, EtherChannel (EC) offers bandwidth scalability within a Local Area Network (LAN) by providing up to 800 Mbps, 8 Gbps, or 80 Gbps of aggregate bandwidth for a Fast EtherChannel (FEC), Gigabit EtherChannel (GEC), or 10 Gigabit EtherChannel (10GEC) connection, respectively.

Under normal (default) configuration, redundant connection between Switches will be dealt by Spanning Tree Protocol (STP). STP, which prevents ‘switching loops’, will block any redundant connection until there’s only a single connection or link between the Switches. You can just imagine that these blocked links are potential additional bandwidth, but are currently wasted since no traffic will be allowed to pass through them.

With EtherChannel, these redundant links will be aggregated (or ‘channelized’) in order to maximize bandwidth utilization. Switches will treat EC links as a single logical connection, thus it can function as either an access or a trunk ‘logical’ port. EC will also show up as a single port in STP, and therefore, the redundant ports under an EC link will have the same STP state.

Aside from better bandwidth utilization, EtherChannel will also offer ‘built-in redundancy’. This means that if any of the links aggregated by EC fails, the other links will stay up and pick up the traffic from the failed link. This results to negligible traffic loss whenever a link fails. Better yet, there won’t be any STP re-convergence that will take place since STP still treat these aggregated ports as a single logical link.


EtherChannel Load Balancing

To implement Load Balancing, EtherChannel translates the addresses in a packet (either the MAC address, the IP address, or the port number) from their binary form to a numerical value. This numerical value corresponds to one of the links in the EC in order to distribute packets in all the links in the EC.

EtherChannel Load Balancing (or frame distribution) uses a Cisco−proprietary hashing algorithm. This algorithm is deterministic that when you use the same addresses and session information, you always hash to the same port in the EC. This will prevent out−of−order packet delivery.

The hash algorithm calculates a numerical value between 0 and 7. Switch ports in the EtherChannel will then correspond to these numerical values. The port setup includes a mask which indicates which values the port accepts for transmission. If an EC uses the maximum number of switch ports in a single EtherChannel (8 ports), each port accepts only one value. But if you have less number of switch ports in the EC, each port accepts more than one value. The table below shows the number of numerical values that will correspond to switch ports (based on the number of switch ports on a given EC link):

No. of Ports in an EC link	Load Balancing
8	1:1:1:1:1:1:1:1
7	2:1:1:1:1:1:1
6	2:2:1:1:1:1
5	2:2:2:1:1
4	2:2:2:2
3	3:3:2
2	4:4

EtherChannel will only aggregate the bandwidth of up to eight compatible or similarly configured switch ports into a single logical link. And in newer Cisco Catalyst Switches, the Load Balancing policy can be based on MAC address (L2), on IP address (L3), or on a port number (L4). Aside from that, the policy can also be based on either the source address, destination address, or both.

Please note that you cannot specify or manually choose a link that a particular traffic flow uses. You can only influence the Load Balancing by choosing a ‘distribution method’ that will give the best distribution. If you’ll ask about the hash algorithm, this cannot be configured or changed to load balance the traffic among the links in an EtherChannel. In the end, there’s a need to experiment a bit in order to select the best distribution method for a specific EtherChannel.


Related Commands

Here are some of the commands that will with your EtherChannel Load Balancing needs:

For CatOS:

Check Load Balancing (Frame Distribution) Policy

show port channel info

Determine the port for use in the EC to forward traffic

show channel hash < {src_ip_addr | dest_ip_addr | src_mac_addr | dest_mac_addr | src_port | dest_port} [dest_ip_addr | dest_mac_addr | dest_port]>


For IOS:

Check Load Balancing (Frame Distribution) Policy

show etherchannel load−balance

Determine the port for use in the EC to forward traffic

test etherchannel load−balance interface number> <{ip | l4port | mac} [source_ip_add | source_mac_add | source_l4_port] [dest_ip_add | dest_mac_add | dest_l4_port]>


*For more information, you can visit this link from Cisco.com