Cisco expert needed RE: 3750 switch stack.

[paradigm]

Right, to cut a long story short, I've got a 3-switch stack of 3750-24TS-1U switches, and need to change the default "system mtu routing 1500" to "system mtu jumbo 9000" (switch is dedicated iSCSI fabric for a Dell Powervault MD3200i, MTU of 9000 is best practice here for throughput).

Obviously I can run the command no problem, but this requires a reboot of the whole stack?

[FONT=&quot]ISCSI-SWITCH(config)#system mtu jumbo 9000[/FONT]
[FONT=&quot]Changes to the system jumbo MTU will not take effect until the next reload is done[/FONT]
[FONT=&quot]ISCSI-SWITCH(config)#[/FONT]
[FONT=&quot]ISCSI-SWITCH#copy run start
[/FONT][FONT=&quot]Destination filename [startup-config]?[/FONT]
[FONT=&quot]Building configuration...[/FONT]
[FONT=&quot][OK][/FONT]
​

Can these be done one at a time? How do stacked switches handle their startup-configs in the event of being rebooted individually (using "reload slot x" command)? Will an individually reloaded stack-member switch take the running-config of the master, or come up with previously built and saved startup-config?

Cisco's documentation doesn't seem to cover the specifics of startup-configs for reloading individual slots, so I'm struggling to work out the impact of issuing the reload command.

Essentially I guess I'm trying to ask, can I maintain a degree of service availability by reloading 1 or 2 switches at a time? (all three are essentially redundant links for SAN > Host connectivity, so in essence, losing 2 of 3 switches should only result in bandwidth loss rather than downtime), or do I need to reload the stack as a whole?

As a side note, is there actually any benefit from these switches being in a stack? This whole reload process would have been simplified were they 3 individual switches, sure, the management would end up being negligibly more complex, but I can't help but think that them being stacked is a pointless exercise ?

Any help appreciated guys

 

[Chief Wiggum]

Hi Fella,
You can boot them individually and they will inherit the config from the master, if you bounce the master, the secondary becomes the new master until such time that the switch is stable enough and it then re-inherits the role.

If you bounce them all, then they come up to a certain point and then they elect the master switch and the config is downloaded (that's why it's best to set priority and membership when they're first setup). You can easily insert extra switches this way, just by breaking the umbilical and linking one in - obviously setting the membership and priority before it's inserted so it doesn't come up as master! oh, and making sure that the software version is the same...

The only thing that I'm not sure about is major changes like MTU, which may require a complete restart in one go, but the configuration guide may give some answers (I'll take a look later)

In terms of benefits:
The umbilical link is backplane speed, so you can link up to 9 switches all at backplane without using up ports or SFP connections, which can support 10gb connections on some of the 3750 platforms. Also it gives you the option to ether-channel across multiple switches, for resilience or just capacity, you couldn't do that easily without the umbilical, so it's nice to be able to treat them as a 45/65k in that respect plus ease of management and spanning-tree too...


edit - looking at the cisco guides, it's not exactly clear. It seems to allude to the fact that the command will change all gig interfaces at reboot, so I would put a change in to bounce one of them and see what happens - BUT I would also plan the same change to do a complete outage if it goes pear-shaped, that way you know you're going to be able to bounce the whole lot. That way your covered for the worst and won't get strung up in the morning!