Meraki

Jeroenvdd

Hi everyone,

After several conversations with Microsoft support, our ISPs, and Meraki support, we’re still stuck — so I’m hoping someone here might have additional insights.

Environment

MX95 security appliance
3 × MS210-24P switches (stacked)
9 × MR44 access points

Wireless configuration

Two SSIDs:
- Internal network: DNS over VPN
- Guest network: Direct Internet with 8.8.8.8 DNS (Meraki DHCP for both)
5 GHz only
AP uplinks at full 1 Gbps / full duplex
RF profile: min Tx power 10 / max 19
Meraki dashboard reports 100/100 on RF metrics (no interference or channel overlap)

The problem

Screen sharing in Teams or WebEx from Wi-Fi clients is:

Grey/black screens
Severely delayed (10–15+ seconds)
Often unusable
- Guest network devices (no VPN, no filtering) → same screen-sharing issue

Meanwhile, wired clients have zero issues — instant screen rendering and smooth cursor movement.

What is working perfectly

Voice/video in calls
General Wi-Fi performance
Streaming 4K YouTube
Speed tests ~500 Mbps over Wi-Fi (latency 10–15 ms, sometimes up to ~45 ms)
Ping to Google averages ~10 ms with tight percentiles
Other company sites with identical hardware + configuration → no issues

RaphaelL

What firmware version are you using for all products ?

What is the SSID configuration look like ? Bridge mode , NAT ?

Are the issues with Teams only P2P calls or bridged calls also suffer ?

Have you taken any pcaps ? Teams video , screensharing is easy to see in a pcap.

Jeroenvdd

The latest stable on all products.
have upgraded the MR and MX to the beta and RC too but also no change

the guest network is Meraki AP assigned NAT

the data network is 'External DHCP server assigned' and bridged.

Teams calls themselve have no issues, as in voice or webcam.
Sharing content like screens is where the hiccups start going
(on wifi only)

Ryan_Miles

Do you have MR44s at other sites? If yes are they having the same issue?

Jeroenvdd

same switches, same mx, same mr's same setup = zero issues at other sites

Ryan_Miles

Have you tested with an AP connected to a different switch? Or the switch connected directly to the MX?

Have you tested with an AP connected directly to the MX to bypass the switch?

Is your switch stack functioning properly? Both stack ports are up on all switches in the stack?

PhilipDAth

Anything configured under Wireless traffic shaping?

Jeroenvdd

I've set this now as test:

RaphaelL

You can configure a port range.

Jeroenvdd

yeah wierd if i tipe a range it translates it to host 50040-500059 if is type port 50040-50059 it translates this to host port 50040-50059

but I've entered them one by one, shouldn't make a difference

PhilipDAth

Can you temporarily turn off "Shape traffic on this SSID" to either prove this is or is not the issue.

If it is the issue - how does it compare to other working sites?

Jeroenvdd

I've turned it of at every level in previous attempts to figure out what's going on, to no avail.
I've now done a 'pressure test' with multiple people doing speedtests to differing sources.

the speed is lowered, which doesn't bother me the only thing i do find really high is that download latency.
Then again it's content shared 'from this site' to others that is the problem so upload latency which isn't great but not to the extent..

PhilipDAth

This is a really long shot - I have had issues with MS12x and MS13x switches intermittently failing to resolve DNS (or taking a long time) on MS 17.2.x code.

You could try going back to 16.x, or jumping to 18.x.

This is listed in the 18.1.1 MS release notes - but it definitely affects more than just the MS130.

stgonzo

Hi, just wondering if you have made any progress with this.

We have the same issue on one of our networks, all other networks are fine. We have been working with Meraki and the ISP for a while on this, but no resolution yet. Interestingly, this network is the only one that uses MX95 appliances. For a test we created a small test network on site using a different model of MX (MX67), from the trial it seemed like the issue was resolved, although this was a smaller network with fewer users due to the sizing of the smaller MX. Our next step is to try to source an MX105 to test on this network.

Thanks

Jeroenvdd

Not completly but after the meraki ticket the issue did disappear.

What was 'good' is:

it can't be ISP since on a switch = everything OK

on an accespoint = nok

-> try pinging to google with a packet size of a 1000 we couldn't do that on the wifi (972 was our largest packet that went trough)

so if you do ping 8.8.8.8 -t -l 1000 and that times out only over wifi -> you have the same issue we had

stgonzo

Thanks

The pings seem to reply okay using a packet size of 1000. I believe the issue for us happens on both wired and wireless connections.

RaphaelL

Well a MTU of 1000 on the wireless wouldn't make any sense for that kind of issues. It would break more things than Webex and Teams. TCP TLS packets are (always?) sent with DF bit set, so they would be dropped and nothing would work.

Jeroenvdd

well here our max mtu on wireless was 792 beforer timeouts, and wierdly enough for about a month,

the only issue was sharing screens