Strange Teams quality issue WIFI vs. wired

theshmike
Getting noticed

Strange Teams quality issue WIFI vs. wired

We are facing a strange issue where voice and screen sharing quality in MS Teams is bad over 1G wired connection and normal/good on WIFI.

 

Strangely this issue hits only specific clients. The AP and the clients are connected to the same access switch. and the subnets are also routed over the same WAN-connection.

 

I would say, 90% of the calls on wire are bad quality. When the user then disconnects the cable and connects to wifi, everything works fine.

We were able to find out, that Teams is reporting a lot of udp packet loss on those wired calls. We also checked cable length and quality test result of the physical cable from when it was installed (10 yrs ago) and they are fine.

The users are no complaining about any network issues when doing normal work with the computers. The clients are connected d directly to the access switch with no in-between-device like an IP phone or something.

 

We use GPO to set the right DSCP values on teams traffic and we are also setting the DSCP bits when teams traffic enters the access switch or any WIFI AP. Anyways, QoS should not be the point, because any interconnects along the path are far away from traffic congestion...

 

Any ideas how to investigate further? As a next task I would task an external company to reevaluate the quality of the physical cable connection...

10 Replies 10
DarrenOC
Kind of a big deal
Kind of a big deal

That does seem a little odd as you’d think the behaviour would be the other way round with poor quality over wifi.

 

I don’t believe it’s a physical wire issue as your APs are also connected via copper.

 

Are your PCs when wired also connecting wirelessly which is confusing Teams hence the high packet loss? Just a thought 

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
DarrenOC
Kind of a big deal
Kind of a big deal

What does a traceroute show when connected via both mediums?

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
cmr
Kind of a big deal
Kind of a big deal

@theshmike did you use the Meraki cable testing function on the edge switch or something else for the wired clients?

If my answer solves your problem please click Accept as Solution so others can benefit from it.
theshmike
Getting noticed

@DarrenOCyes that's really odd! We disable cable connection when we switch to wifi connection.

I was not thinking about a general cable issue, but maybe of issues with specific wires.

 

@cmryes we did and it reports that everything is ok and a cable length of 31 m which matches the installation documentation.

 

We're going to try what a tracert says...

DarrenOC
Kind of a big deal
Kind of a big deal

Same DNS servers when connected both wired and wirelessly?

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
theshmike
Getting noticed

@DarrenOC yes, same DNS servers on the subnets...

DarrenOC
Kind of a big deal
Kind of a big deal

How are your traceroutes looking? Anything quirky with your routing?

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
PhilipDAth
Kind of a big deal
Kind of a big deal

This smells like a duplex mismatch error to me.

 

Are you sure the switch ports are configured auto/auto and the client is configured auto/auto?

theshmike
Getting noticed

Sorry for not posting any replies this long. Thank you all for your support!

 

It turned out, that the issue seemed to be caused by too much broadcast inside the subnet.

 

Some former dudes in this company made big mistakes in network design and since then the company was mainly using a /16-network for all clients at the headquarter. We started segmenting the network immediately when I entered the company but there are still many clients left in the /16-network - and so are the windows clients.

 

The wireless subnet is a /23 which contains only the wireless windows workstations which explains, why teams connections are fine.

 

We've created a test group and moved them to a separate vlan. As soon as they are in the separate vlan they had a perfect voice and video connection. When we switched them back, the quality was bad again.

 

The interesting thing about it is, that not all clients in the /23-subnet were facing this issue. There are clients that never had problems, and clients that constantly had the problems. Maybe the behaviour is also related to the NIC that the clients are using. Some could maybe handle more broadcast traffic that others do...

 

 

Dunky
Head in the Cloud

"We use GPO to set the right DSCP values on teams traffic and we are also setting the DSCP bits when teams traffic enters the access switch or any WIFI AP."

 

I would be very interested in knowing how you identify the Teams traffic on the AP and switches, as this is something I will need to do shortly.  Does Teams not set the DSCP so all you have to do is trust it?

Get notified when there are additional replies to this discussion.