3750 Stack software imaging Summary:

The 3750 stack platform offers a unified management interface for multiple switches, reducing management overhead. The overall configuration of the 3750 stack behaves in a fashion like a unified chassis, such as a 6500 series switch. The 3750s are each autonomous systems, however, and issues can arise when trying to replace or insert new switches in an existing stack. The following is meant to act as a brief guide to understanding this behavior, and is intended to be slightly more concise than the cisco technical documentation.

Stacking the 3750s:

Each 3750 comes with a stackwise cable meant to be connected to the two stacking ports on the back of the switch. It is essential that when a stack is created, a full loop is created with stackwise cables. Having a full loop doubles the throughput of the stackwise connections, as well as provides redundancy in a situation where a switch fails and is removed from the loop.

There are multiple ways to accomplish this, but a consistent “Switch 1 (Stackwise 1) -> Switch2 (Stackwise 2) ” cabling scheme is easiest to manage. The last unit in the stack should then be cabled to the open port on the first unit of the stack. Due to stackwise length limitations, all 3750s should all be in the same rack, directly above/below each other.

3750 Config management:

In its simplest configuration, a 3750 stack consists of a switch called the “Stack master” and member switches. The stack master is the switch responsible for maintaining the authoritative configuration for the stack. The stack master periodically copies this config file to other member switches, so in event of master failure, another switch is eligible to maintain the integrity of the stack. The stack Master is chosen with a variety of inputs, the most deterministic of which is the command :


All switches have a default priority of 1. Higher priorities win master elections, so it is a good practice to set a known switch as the stack master.

Elections only occur when a switch is added to a stack. The following two scenarios may result in unexpected behavior, so it is suggested to never expand a stack in these manners:

• Do NOT add a running switch into a live stack.
• Do NOT add a new switch to a powered down stack.
• In both of these situations, it is possible to inadvertently lose the original stack configuration and put the stack into an “unknown state” if the new switch wins the master election.
• It is best practice to add the switches in the following manner:
• Break the stackwise link between the first and last members of the live stack.
• Cable the new switch into the live stack via the StackWise cables, ensuring that there is a full loop once all the connections are made.
• Power on the new switch.

When these procedures are followed, the new switch will be brought online with a default configuration, and the existing stack will not experience any downtime. If it is desired to pre-configure the new switch, this is accomplished in the stack prior to insertion, as explained later.

Factors that affect stack master elections include (In descending order of priority):

• The switch that is currently stack master
• The switch with the highest priority
• Switch with non-default config
• Software version
• Longest uptime
• Lowest MAC address

3750 Stack Management:

Assuming two bare metal 3750s are stacked together, the winner of the Stack Master election becomes switch #1, and the next switch is #2. New switches inserted into a stack become numbered consecutively higher. The easiest way to control this election process is to power on the desired master switch first, then power on switch #2 after a 20-30 second delay delay, and proceed through the stack in this manner. When a switch is added to a stack, a line is inserted near the top of the config corresponding to its position in the stack, and its hardware type.



Once a switch is ‘provisioned’ in the stack, the stack master will now accept port-level configurations for the expected switch. It is possible to manually provision a stack to expect a new member. In this fashion, you can pre-configure the stack when new hardware is anticipated. When a new switch of the corresponding hardware type is inserted in the stack, it picks up the pre-existing configuration.

When a 3750 is added to a stack, the stack master determines if there are any provisioned switches that are not currently live in the stack.

If there is a switch configuration provisioned that matches the number assigned to the new switch, the new switch assumes that number in the stack, and that configuration.

If the new switch has the same number as an existing live switch member in the stack, the new switch assumes the lowest provisioned available number in the stack, and any config in the master switch is applied to the newly provisioned switches.

If there are no more provisioned switches in the stack, the newly inserted switch will retain its existing number, if this number does not already exist in the stack. If the number configured on the switch exists in the stack, the switch will assume the lowest available number. The configuration of ports on this switch will be set to defaults.

Once a switch is “numbered”, it retains that number for the duration of its life, even when it’s removed from a stack. In order to change the numbering of the switch and all of its ports back to 1, it is necessary to configure this manually, with the command:


It is possible to renumber a switch while it is in a stack, but you cannot change it to a number that is currently active in the stack.

When a switch is removed from a stack, it also retains all the provisioned information for the former members of the stack- it is necessary to unprovision the former stack members:


With these parameters in mind, the following best practices should be kept in mind:

When building a stack:

Software Management on a single 3750:

The software available for a 3750 consists of two options through cisco- the raw .bin file, or a .tar file structure that includes not only the .bin file, but a directory hierarchy and files that are intended to be used with the web-based device manager. Working with the .bin files is fairly straight forward- copy the new .bin file to the switch, set the boot statement in config mode, and reboot. This is very similar to the process in place with other cisco devices.

Working with the .tar file is also an easy process- the “archive” command will obtain, decompress, and upgrade the switch relatively painlessly. There are certain parameters available to force a reload after the successful upgrade, as well as either delete the old image or keep it until a successful upgrade has been completed.

The syntax looks as follows:


This would require the engineer to reboot the system after the archive has completed. This is approximately a 10 minute process, largely done without much output to the console- be patient. There are additional flags available that force a reload, or leave the software on the switch entirely.