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
I tried reset and also tried after getting them upgraded (MR 28.7.1)
Any ideas?
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?
- 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.
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
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.
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?
The mask must match both the SVI and the configured DHCP scope.
Sorry for the confusion, those IPs on the example are from a different site. The one that I'm testing is on a /24
Hi Billy. I'm experiencing the same issue. What was the issue on the server firewall exactly?
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