Failed Connections MR33

[uashraf]

Hi,

I keep getting this error message when clients are connecting to a 802.11x SSID. It's causing clients to drop connections, especially when roaming. Access points firmware is MR 30.7.1. Trunked port with all VLANS allowed plugged into MS225. DNS server is an internal Windows Server 2022. 

Does anyone know what the fix is for this error?

Client made a request to the DNS server, but it did not respond.vlan_id='90' request_proto='ipv4' request_server='10.82.32.21' details='no_dns_response' reassoc='1' radio='0' vap='12' channel='1' rssi='53'

[Mark Elsen]

  - @uashraf                  For starters, is the client using the correct and or designated DNS servers ,
                                     usually obtained through DHCP , coming down too : is DHCP setup correct ?

  M.

[uashraf]

Yes, DHCP is correct and the right DNS servers are being used. It's an intermittent problem.

[Mark Elsen]

   - @uashraf                 Since wireless is layer1&2 only . I doubt the problem is related to wireless ;
                                           you can do some testing  on your PC
                                                ping 10.82.32.21
                                                      nslookup google.com 10.82.32.21
                                                      Resolve-DnsName google.com -Server 10.82.32.21                          (Powershell)
                                                      Resolve-DnsName 10.82.32.21 -Type PTR -Server 10.82.32.21     (Powershell)
                                                     Test-NetConnection -ComputerName 10.82.32.21 -Port 53             (Powershell)

  M.

[uashraf]

I have run all these commands and they all come back normal. 

[Rich R]

You'll need to run packet captures at various points in the network to isolate where the problem is - AP, switch, MX (if it's in the path) and the server itself (and anything else between client and server).

Although Mark is right about APs only being primarily layer 1/2 they are actually layer 3/4 aware and there have been a few bugs on the Cisco APs causing client UDP packet loss (DHCP, DNS etc) on the APs.  Since a lot of code is shared between the Meraki and Cisco APs these days it's possible that you could be hitting such a bug but Meraki does not provide a searchable bug database like Cisco so your only option is to open a case with Meraki TAC to confirm if there are any such known issues.

[uashraf]

I have sent multiple packet captures to Meraki support but they haven't been able to figure out what the problem is. They spent 2 months investigating. 

[Mark Elsen]

  - @uashraf                    Do you have this problem on this particular device or does it also happen for others 
                                                           using the same SSID ?

  M.
  

[uashraf]

This happens on all devices across mulitple SSIDs but mostly affecting 802.11x SSIDs.

[Rich R]

@uashraf - so you should be able to see from those packet captures where the DNS request or response is getting lost.
Where is it getting dropped?

[mloraditch]

Are you sure that error is actually what is causing the clients to drop? The error in question is something Meraki APs do generate but in and of itself it wouldn't actually cause a dissociation from the AP. Or are you meaning a drop as in the client stops passing traffic but not actually dissociating?

If it's the former, are all of your APs  uplink ports set correctly for your environment? If it's the latter, you'd want to be looking at other logs.

The other thing I would add is MR33s are EOL in July. They run older code and support is probably not going to put a ton of effort into debugging an issue that is likely not getting fixed. I would look into refreshing your APs.

[uashraf]

I get a connected but not internet message on devices, it can take up to 5 minutes before the internet works again. Yes, all uplink ports are set correctly. Unfortunately can't afford to replaced the MR33s at the moment due to budget. Meraki log just says DNS failure, no cause identified. 

[mloraditch]

Ok, yeah that's going to require packet captures and support, which you seem to already be doing. Hopefully someone pops up here and perhaps recognizes the issues.