Create 3750 stack from two already configured switches

Unanswered Question
Apr 24th, 2009

We have two 3750G 24 port switches that are also running BGP with our ISP's. Each switch has a physical IP address in the same subnet and we are using HSRP for outbound failover.

I need to keep the L2 configuration in place when I stack the switches and then I can re-create the L3 configuation using the HSRP virtual address as the physcial address of the stack.

I have looked through here and googled for gotcha's but don't really see any.

Any advice on the best way to create the stack with minimal downtime?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

Go into one of the switches (I usually use the one I want as the 1st switch). issue the following command to provision the second switch:

switch 2 provision ws-3750G-24ts (depending on your exact switch model)

once you have done that, you can configure all of the ports of the second switch in this first switch before you connect it. Then once you connect the second switch, the ports will already be configured.


davy.timmermans Sat, 04/25/2009 - 12:26

you're using HSRP between the two switches you want to stack?

if yes:

When you'll stack them you'll end up with one logical switch ( and thus 1 ip/vlan).

To provide the redundancy as before you'll connect an uplink to each stack member.

dennis-bailey Mon, 04/27/2009 - 08:51

what i want to do is eliminate HSRP alltogether.

In a two switch stack, if the master fails, do I lose all of my layer3 configuration and functionality or is that taken over by the remaining switch?

davy.timmermans Mon, 04/27/2009 - 09:00


By stacking a switch you create one logical switch. If one switch fails/reboots, you'll lose only the connections (ports) connected to the failed switch. If you replace the broken by a new switch, the configuration for this ports is maintained.

To say it simple: you won't lose any configuration. Just temporarily physical down ports until switch is fixed/rebooted or replaced.

As I told before, you'll have redundancy by creating a cross-stack portchannel. This means each uplink to a different stack and bundle them into a portchannel. If you reboot one switch or one switch fails, you'll lose only the traffic that was on that moment on the link of the failing link in the port-channel

If you don't create a portchannel, 1 link will be blocked by STP.

Okay, I understand your motivation for stacking the switches. You wouldn't lose layer3 and layer2 connectivity, unless the switches are physically cabled the wrong way.

You just need to make sure the ISP cables plug into separate switches within the stack and any layer 2 redundancy for the access layer. A bigger reason to stack (besides your HSRP loss) would be to eliminate spanning-tress. The cross stack etherchannel rocks. Instead of having 50% of your fiber dead, you can utilize it all and double the bandwidth on the core uplinks.

davy.timmermans Tue, 04/28/2009 - 03:31

that's correct

for the access -- core:

you'll go from 2 SVI to 1 SVI

to have minimum downtime:

draft proposition:

You can disconnect the first switch ( or second as you prefer). Users will use the other switch for intervlan routing or internet access, as they're redundant connected.

You configure the disconnected switch offline:

configure each SVI with the virtual IP as IP

provision the second switch (=virtually add the second switch)

configure the ports of both switches (inclusive the cross-stack portchannel)

configure your peering with the ISP.

Test the connection with ISP (ping)

configure your peering with the other ISP (on the virtual second switch)

Then you can start think of back connecting the uplinks of the access switch to the new switch while disconnecting uplinks towards the other non-stack switch)

if everything is ok, the users have now internet connection via the new configured switch.

Then you can prepare the second switch in order to stack (= check if the IOS is the same,...), connect the stack cables and boot the second switch.


This Discussion