3750G and multi chassis link aggregation

[mitchelg]

We currently have a single stack of 3750Gs, running IP services. We have a leaf switch on one of our floors running 2 uplinks in a LAG (for a 2Gb connection), back to the existing stack.

We would like to split the stack into 2 (for some redundancy) independant stacks (in different racks too). We would then like to take the LAG from the leaf switch, and put one connection into stack 1, and the other into stack 2 (ideally in link aggregation mode, so we can keep the 2Gb connection).

Is this possible with the 3750Gs? If so, what is the minimum IOS rev that we need?

If we can't run LAG into 2 separate stacks, can we run 802.1q from the leaf switch into both stacks - and let STP deal with the results?

Unfortunately our budget won't stretch to a pair of 6500s with VSS, and we need to work with the 3750Gs we currently have.

Thanks for any help and advice.

G

[Reza Sharifi]

Connecting the leaf switch to 2 differnt stacks using Etherchannel will not work.  The devices have to be logically one.  So, one stack of 3750s or a pair of 6500 in VSS.  The same thing for the 802.1q scenario, Etherchannel to different stacks that are logically 2 separate units will not work.

[mitchelg]

> Etherchannel to different stacks that are logically 2 separate units will not work

Thanks for the info... I thought that we could use multi chassis LACP (mLACP) - I presume that this is not supported on the 3750Gs?

G

[Joseph W. Doherty]

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

STP would be your alternative if you split the 3750 stack.

PS:

How much do you figure splitting the stack is going to improve redundancy?  Splitting the stack does have negatives.

[mitchelg]

> How much do you figure splitting the stack is going to improve redundancy?

Not 100% sure, but we are trying to exercise an abundance of paranoia. Recently we've had a couple of incidents happen that 'couldn't possibly happen' (non network related), so now I'm looking at all our server setups, and their connection into the network, and our single stack is a single point of failure for us - all our floor leaf switches and all our servers in the machine room connect to this stack.

> Splitting the stack does have negatives

Could you give a brief outline/list of the negatives. Obviously we're going to have to administer the 2 stacks separately, but what other issues am I missing?

Thanks for your help

G

[Jon Marshall]

MEC (Multichassis etherchannel) is supported on 3750Gs but it needs to be to the same stack. If you split the stack in 2 you now have 2 stacks so they are like 2 separate switches in effect so you cannot run the same etherchannel across both stacks.

As for splitting them up, the main issue is that you reduce bandwidth between the individual switches because in a stack they can use Stackwise (32Gbps if i remember correctly). If you split the stack into 2 you will not then be able to interconnect the 2 stacks with 32Gbps connectivity.

So it is a tradeoff really.

Jon

[Ven Taylor]

If properly powered, ups'ed, stacked, and uplinked, the stack does not represent a single point of failure.

Take a look at your physical setup prior to adding possibly unecessary complexity.

If your switches go to separate circuits, and have redundant ups, and have redundant connections to your core, you should be fine.  If properly stacked, even a switch loss will not bring your entire stack down.  Granted, you'll lose whatever connections you have to that particular switch, but that's the beauty of MEC.  Your leaf switches are connected to two separate switches.  No failure! 

Ven

[mitchelg]

> Your leaf switches are connected to two separate switches.  No failure

I know we don't have that set at the moment - something I'll look into.

One other question - when we come to replace the switch and pull it from the stack, I presume that we're going to have some downtime on the stack, since it's daisy chained? Or will the fact that the chain goes in both directions mean that we can do it live with no downtime? (Assuming that we can get the switch in and out past the mess of cables).

G

[Ven Taylor]

Your leaf switches should DEFINITELY be connected to separate switches in that stack.  Otherwise, you're definitely creating a single point of failure.  Your switches should have a meshed stack and should NOT be daisy-chained.

Example:

Each switch has two stack ports. Call them 1 & 2.

Assume you have 4 switches in a stack.

Switch 1, stack 1 to Switch 4, stack 2.

Switch 1, stack 2 to Switch 2, stack 1.

Switch 2, stack 1 to Switch 1, stack 2.

Switch 2, stack 2 to Switch 3, stack 1.

Switch 3, stack 1 to Switch 2, stack 2.

Switch 3, stack 2 to Switch 4, stack 1.

Switch 4, stack 1 to Switch 3, stack 2.

Switch 4, stack 2 to Switch 1, stack 1.

I usually put my core uplink fibers on the very top and very bottom switches.

This gives you an uninterrupted loop that avoids any single points of failure within the stack.

To answer your question, yes it is bi-directional.  Your switch downtime will be dictated by your leaf switch uplink configuration (VTP, bpdu's etc).

Ven

[mitchelg]

> Your switches should have a meshed stack and should NOT be daisy-chained.

Looking at your pic, that is how we have the stack set up - my fault for using bad terminology I'm afraid - I'd call that a daisy chain (1 to 2, 2 to 3, 3 to 4 etc) - but we DO have the loop back from the last switch on the stack to the first one.

> Your leaf switches should DEFINITELY be connected to separate switches in that stack.

That's what we don't have I suspect - I know from experience on setting up LAGs on the servers that our network guy configured them on the same switch, as there was always an issue when I wanted another 4 ports set up in an LAG, as there were never enough ports on an individual switch.

And to answer your previous question, the switches do have redundant power, connected to separate UPSs, so I think we are good there - but I am going to double check.

G

[Ven Taylor]

I would recommend scheduling some outages to free up appropriate ports on your stack to ensure you can Etherchannel your leaf switches to separate switches in the stack.  This will save you in the long run.

Also, if you can, move any devices off this stack that don't HAVE to be there.  If they can sit elsewhere, move them.

It sounds like this stack is more of a distro switch than an access switch.

Ven

[mitchelg]

> I would recommend scheduling some outages to free up appropriate ports

We are planning on pretty much gutting and rebuilding the machine room in a few weeks to accommodate a new SAN installation, so that would be a good time to organize that I think.

> It sounds like this stack is more of a distro switch than an access switch.

It's pretty much at the core of our network here. If it goes down, we're in a whole lot of pain. All the leaf switches connect to it, all the servers in the machine room connect to it. It also routes traffic out to our 7204VXR, which then handles all the external routing for us (we have multiple T1s as well as an MPLS), tho we do have a separate 2921 for our internet connection.

G

[Joseph W. Doherty]

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

"our single stack is a single point of failure for us"

One of the major feature of a 3750 stack, it is not supposed to be single point of failure.

"Could you give a brief outline/list of the negatives."

(Overlapping with others, including yours) two devices to manage, loss of stackplus 32 Gbps bandwidth, STP required for redundancy, loss of MEC bandwidth, possibility of unicast flooding, possibly more complex configuration (e.g. FHRP, routing, uplink load balancing), possibly slower convergence.

[mitchelg]

Thanks for the reply - looks like there are a whole lot more negatives than positives, so I think we'll stay how we are.

One final question (hopefully) - will we have any issues if we're also doing VLANs over the link? Each of our floors is on it's own subnet and VLAN. I've spoken to one of the guys, and he said that they looked at setting this up a couple of years ago, but couldn't make it work (and he speculated it was because of the LAG and VLAN).

G

[Joseph W. Doherty]

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

You should be able to use VLANs with links connected to the stack.  Should work with or without trunks, and with or without MEC.  Functionally, the stack should behave as one device.

If earlier this was an issue with LAG and/or VLANs, you do want to make sure both support the same versions.  These can be especially true on Cisco equipment because often Cisco has a proprietary version that pre-dates the standards version.