We have a stack of 3 MS250s which have a 2 port link aggregate to another Ms250.
Users -> switch 02.
We've noted slow performance across this link.
If we patch in a device inside Users and browse to a server on Switch 02 we notice a distinct performance drop compared with connecting directly via switch 02 (plug the laptop in a spare port on that switch).
I've concluded that there's something wrong with the aggregate link. Switch 02 can clearly handle it's present load (performance is good from here). I'm also puzzled why this would be the case. It's an aggregated link that's been in place for a number of months now.
I'm unsure what the next best steps would be.
In addition, I have another switch ready to add to the stack - we have some new users starting soon - I'm keen to be ahead of any bandwidth challenges we could see when these users start.
Can anyone offer any advice?
I'm don't think you can just add an additional port. I think you have to break the aggregate then create a new one with more ports. Have you independently verified the performance issue by looking at the utilization or doing iPerf testing? I'm always hesitant to rely on user reports since it is subjective or could be a variety of other performance related issues.
It's funny you mention iperf because I've run some tests.
iperf appears to show that I'm getting good network speed but the experience is different either side of the LAG.
Connecting to host <target host>, port 5201 [ 4] local <target client> port 15898 connected to <target host> port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 108 MBytes 903 Mbits/sec [ 4] 1.00-2.00 sec 109 MBytes 912 Mbits/sec [ 4] 2.00-3.00 sec 111 MBytes 927 Mbits/sec [ 4] 3.00-4.00 sec 110 MBytes 923 Mbits/sec [ 4] 4.00-5.00 sec 110 MBytes 922 Mbits/sec [ 4] 5.00-6.00 sec 110 MBytes 926 Mbits/sec [ 4] 6.00-7.00 sec 111 MBytes 932 Mbits/sec [ 4] 7.00-8.00 sec 111 MBytes 931 Mbits/sec [ 4] 8.00-9.00 sec 111 MBytes 930 Mbits/sec [ 4] 9.00-10.00 sec 111 MBytes 929 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec sender [ 4] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec receiver iperf Done.
I see comparable results on the target server.
So I don't know what to make of it all. I've got a ticket open with Meraki and they're recommending that I do an upgrade on the switches. Also I noticed the performance issues more in the morning so I'll run iperf then and see if things are different.
The person reporting it is our IT team. If we go to our service desk software it's terrible if we're accessing it from within the user LAN but ok if we use some other route: either directly on the same switch or over WiFi (which also terminates on the distribution switch). I'm not new to networking hence my confusion. If we browse the web the experience is also different. The whole thing is quite confusing.
re: aggregate port question. Thanks for confirming my suspicion. I can schedule time for that.
Interesting. It may be worth 100% verifying your tracert and other methods from those different network locations to make sure the traffic is going the direction you think it is. Pretty easy to do that or some ping's and grab captures on the path to make sure you are seeing those pings go the expected route in both directions. To me, it isn't feeling like a saturation issue but you'll need to keep digging to verify.
Performance to a public website is notoriously difficult to troubleshoot since you have the full path internally, dns, traffic shaping, content filtering, external network path and a whole host of other things that can influence the possible response rate.
I'm assuming this is a two port aggregate link.
Try unplugging one link member at a time, and see if the performance issue happens on just one of the links.
I'm going to give you a quick update.
Last night we installed a new switch into our stack.
Here's the thing...
To complete this work I had to remove an old Dell Poweredge 6248 that we'd been using to provide connectivity to a couple of desks and this switch was uplinked to the stack.
This switch had been hanging off that stack for ages and I'd completely forgotten about it. It's true that we didn't see any performance issues until recently but I'm going out on a limb and blame that switch.