Meraki MR46 and Microsoft DHCP server

Billy
Getting noticed

Meraki MR46 and Microsoft DHCP server

I've got several MR46 APs, for which I've configured trunk ports on Cisco switches similar to this:

!

interface GigabitEthernet2/0/48
description Meraki AP 1
switchport trunk native vlan 555
switchport trunk allowed vlan 555,556,557
switchport mode trunk

!

For the IP assignment I'm using a pair of Microsoft DHCP servers, while the SVI is configured as follows:

interface Vlan555
description WiFi MGMT
no shutdown
no ip redirects
ip address 192.168.117.28/27
no ipv6 redirects
ip ospf passive-interface
ip router ospf 1 area 0.0.0.0
hsrp version 2
hsrp 555
preempt
priority 110
192.168.117.30
ip dhcp relay address 192.168.10.55
ip dhcp relay address 192.168.20.55

 

  • The issue that I have is that while most of the APs work without issues, pick up an IP address and connect to the dashboard, a few of them don't.
  • The same APs that are not able to get an IP address from the Microsoft DHCP server, are able to pick one and connect to the dashboard, if the DHCP is set on the switches.
  • The same issue occurs when using non-Cisco devices too as switches (same trunk config, DHCP relay configuration, some APs pick IPs, some don't)

I tried reset and also tried after getting them upgraded (MR 28.7.1)

 

Any ideas?

10 Replies 10
Brash
Kind of a big deal
Kind of a big deal

Nothing jumps out immediately but a few questions that might help narrow down the issue:
 - Is the port config connecting to the Meraki AP's identical between those that work and those that don't?
 - Do you have working and non-working AP's connecting to the same switch?
 - Do you have spare IP Addresses in your DHCP scope?

Billy
Getting noticed

- Yes, same switch/port tested with different APs. One works, one doesn't.

- Plenty of IPs on the DHCP scope, I'm using a /24 and there are 5 APs up atm.

 

Brash
Kind of a big deal
Kind of a big deal

Are you able to perform a packet capture on the server or on the infrastructure between the AP and the server?

 

You could also try factory resetting the AP's

Billy
Getting noticed

I have already reset those APs multiple times, same result.

I'll try and see if I can get a packet capture during the power up of those APs.

 

alemabrahao
Kind of a big deal
Kind of a big deal

This doesn't seem to be an AP issue but a network issue. In the example configuration, you are showing a /27 address but it says that the network is configured with /24, can you show the actual configuration of the SVI and the ports where the APs are connected?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

The mask must match both the SVI and the configured DHCP scope.

 

 

alemabrahao_0-1667301142335.png

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Sorry for the confusion, those IPs on the example are from a different site. The one that I'm testing is on a /24

Billy
Getting noticed

Update on this issue:
  
The issue turned to be one of the DHCP servers. They were configured as Failover with 50-50 load balance, thus some meraki APs were able to get an IP while others weren't.
 
There was a filter on the server's firewall that was affecting the DHCP process and the issue was resolved once removed.

Hi Billy. I'm experiencing the same issue. What was the issue on the server firewall exactly?

Billy
Getting noticed

In the logs, we would see something like:

 

[0] 0000.0000::11/08/22-09:09:12.1725355 [kernel] bfe_event_c2507 BfeNetEventTrace() - Classify drop: ipProtocol=17; localAddrV4=010.008.157.171; remoteAddrV4=010.250.160.070; localPort=67; remotePort=67; appId=<NULL>; userId=\\\NULL SID; reauthReason=0; originalProfile=0; currentProfile=0; filterId=1373202; layerId=13

Get notified when there are additional replies to this discussion.