Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
- stack master placement in a switch stack - when three or more switches are configured as a stack, configure the stack master switch functionality on a switch that does not have uplinks configured
Per chance, do you have a reference link?
I understand that the new stack has a different architecture of redundancy (SSO/NSF, active, hot-standby, member) so- if there is any recomendations of active and hot-standby switch placement?
- stack-mac persistent timer 0 - are "best practices" for 3850 stack too?
- when using switch provisioning on the stack is the auto-upgrade feature is not so bad idea?
#1 I'm guessing the reason for any concern, as the active master's has some additional "work" managing the stack, and as uplinks also impose some additional "work", the thinking might be to better balance member CPU load across the stack. If so, unsure, even if true, it's worth such an effort.
Consider, traffic to/from and uplinks may pass through the stack master's edge ports and/or stack ports, so how much "work" is avoided? Also consider, most forwarding on any stack member should be performed by member ASICs, so how much load difference is there for uplink ports? Lastly, consider stack elections (at least on 3750s) don't preempt, i.e. it's possible the stack master isn't where you want it.
#2 Yes, if you're concerned about a stack master election changing master's MAC, impacting connected devices. The 3750s, I believe, sends out a gratuitous ARP, but it's possible not all devices will process it. Stack-mac persistent timer avoids problems with hosts that don't process the gratuitous ARP.
BTW, another approach to the same problem is to use HSRP (with not gateway peers), as it uses a virtual MAC (which will also be the same across a stack reboot - which might not be the case with a persistent MAC).
#3 Well, personally, I get a bit nervous with some of Cisco's "auto" features, especially as they might change a little across IOS versions.
As stack building requires at least the "hands on" for connecting stack members, and it's not something usually done routinely, I don't see much effort in insuring the switch I might be adding has a correct IOS as part of the check list for adding a stack member. So, when I add stack member, auto-upgrade should be a non-issue, and so I don't use it or count on it.
Does this mean it should be disabled? I don't bother doing that either. I just leave it set to whatever its default is. Again, this because I never use it or count on it. However, one might say if you're never going to use it, it should be explicitly disabled as a best practice.
Of course, if you want to use it, you'll need to insure it's enabled.
