Poor Performance across aggregate link?

[GavinMcMenemy]

Hi,

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.

• I can't figure out if there's an easy way to add an additional port on the stack to the aggregated link.
  • The Users stack is made up of 3 MS250s. 2 ports on switch 1 in this stack are dedicated to the aggregated link.
• Can I add a port from another switch to the aggregate link?
• I'm thinking it might help to spread the load across the switches in the stack.

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?

[Adam]

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. 

[GavinMcMenemy]

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.

For example.

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.

[Adam]

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. 

[PhilipDAth]

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.

[GavinMcMenemy]

Hi Everyone,

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.

Mea Culpa.