Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Bronze

A couple of questions about deployment new 3850 stack...

Hi, I have a couple of questions about deployment new 3850 stack...
According to the "best practices" (CVD and so on) there is some recomendations about previos 3750 stack:

  1. 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
  2. stack-mac persistent timer 0 -  ensures that the original stack master MAC address is used by any switch in the stack that takes the stack master role after a switchover

I understand that the new stack has a different architecture of redundancy (SSO/NSF, active, hot-standby, member) so

  1. if there is any recomendations of active and hot-standby switch placement?
  2. stack-mac persistent timer 0 -  are "best practices" for 3850 stack too?
  3. when using switch provisioning on the stack is the auto-upgrade feature is not so bad idea?

Will be glad to hear your recommendations...

5 REPLIES
Hall of Fame Super Gold

A couple of questions about deployment new 3850 stack...

if there is any recomendations of active and hot-standby switch placement?

Make sure your clients are dual homed and your uplinks are dual-homed in an etherchannel.

when using switch provisioning on the stack is the auto-upgrade feature is not so bad idea?

I don't see the benefit of this feature.

Bronze

A couple of questions about deployment new 3850 stack...

...thanks, Leo, for your opinion...

Super Bronze

Re: A couple of questions about deployment new 3850 stack...

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


  1. 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
  1. if there is any recomendations of active and hot-standby switch placement?
  2. stack-mac persistent timer 0 -  are "best practices" for 3850 stack too?
  3. 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.

Bronze

Re: A couple of questions about deployment new 3850 stack...

Thanks, JosephDoherty, for the detailed response, I would like to debate with you (if you have time),but unfortunately I do not have more time now... I hope to return to this issue tomorrow...

As for "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" - here for example is one of those documents (Campus Wired LAN Technology Design Guide - August 2013):

http://www.cisco.com/en/US/docs/solutions/CVD/Aug2013/CVD-CampusWiredLANDesignGuide-AUG13.pdf

Page 18:

Super Bronze

Re: A couple of questions about deployment new 3850 stack...

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

Thank you for the reference!!!

That document does, indeed, describe having the stack master as a stack member without uplinks.  Unfortunately, it doesn't describe why it recommends this.  Without any supporting reasoning for such a recommendation, we don't know if there's really a valid consideration or whether whoever drafted the document made it "pretty".  (As a comparison, you'll see diagrams and recommendations how to connect stack ports, but as far as I know, as long as you connect them to create the [dual] ring[s], it doesn't really matter for correct operation.)

Traffic to/from the left most stack member, in figure 10, might flow across the right most stack member's uplink (as least on 3750 stacks, which don't support any kind of VSS like device affinity - as far as I know).  Ditto for the right most stack member's traffic flowing across left most stack member's uplink.  So, since traffic then needs to flow across the stack ring, which might transit the "master", how much of a benefit is there?

If stack master fails, master should be taken over by one of the two remaining switches (no Cisco recommendation for which?).  If you replace the former stack master, unless you reload the whole stack (to cause a stack election), the stack master will stay on one of the other switches.  Is this so bad we need to arrange for a stack reload?  If not so bad, why go to all the trouble to begin with?  So again, it would be nice if Cisco would have also documented why they are recommending that stack master placement.

On stack MAC persistence, LACP was something I hadn't considered (but then we use hard coded Etherchannels).  In any case, something like that does give good reason to use that command.  (So much so, I'm going to pass that along to our standards team - thanks!)

1037
Views
14
Helpful
5
Replies