Mac clients not finding DHCP, but on is some areas..

[MattTaylorTas]

Hi all,

I have a set of clients (specifically macbooks) that are struggling to pick up a DHCP addresses when connecting via access points hanging off just one of our switches (which was new in the last few weeks).

When they are in other parts of the network there is no issue connecting and picking up a DHCP address.

This DCHP range is served by the Core Meraki stack, so the request never leaves the mearki environment.

I have checked

 - Scope, plenty of room, and it functions on 70% of the network ok

 - Uplink ports, all uplink ports are trunk ports will all vlans allowed

 - Device's have an active lease

of note:

- This is the only DHCP range that is served by the Mearki devices, others relay to our AD servers (no idea why, this setup preceeded me)

- The switch was replaced in the last few weeks, however same firmware version as others in use

Any tips?

[Ryan_Miles]

Opening a Support case would likely get this resolved faster as they can see your dashboard config. 

What was new as of a few weeks ago? The switch, the APs, the entire setup?

Are non Macs having issues?

[MattTaylorTas]

Thank Ryan, I have a support case open as well as this thread.  Non macs are spot on, I can see 8 clients on that vlan active on the troublesome AP right now.

It was the switch that these APs hang off that was replaced during out last student term break.

[Brash]

Is the issue only seen with Macbooks?
Ie. Do other clients (Windows, Android, IOS) see the same issue when connecting to the same access points?

Are other clients being served from that same DHCP pool on the Meraki core?

When you say the switch was replaced, was this simply a like-for-like hardware swap with no changes to configuration?

[MattTaylorTas]

It looks to be only macbooks with the issue, my IOS connected ok, as do windows (I don't have an android handy to test).

The switch that the APs hang off was replaced of late, with the base setup created with a clone of an existing switch.

All of our BYOD devices serve from the same DHCP pool, I can see 70ish % free so not running out of address.

Interestingly, I just added a LAN device to test, and it didn't pull and address.  All of my uplink ports are untagged on management and all other vlans allowed.

[MattTaylorTas]

soooo futher testing no confirms

- Any client connecting on this VLAN that is not Windows (OSX, iOS, Android) either on LAN or WLAN will not pick up an IP, wait for it... ONLY when connected to an edge switch.

- When connected directly to the core, either on LAN or via AP connected directly to Core  (where the DHCP scope sits) we get an IP ok regardless of OS.

[BlakeRichardson]

Thats an odd one.

1. What are your event logs saying?

2. Have you got mandatory DHCP enabled on that SSID? If so does turning it off make any difference?

3. As a temporary solution you could setup a different DHCP server to get around the issue while you trouble shoot it. 

[MattTaylorTas]

OK! So I think I have this sorted!

Being a VLAN for our BYOD devices (we are a school) I had some ACL rules in place to keep the filthy byod devices to themselves, with some basic allows to let DHCP, DNS, paper cut printing and the like through, then an overarching deny to block 10.10.18.0/24 from accessing the rest of our internal network being 10.0.0.0/8.

Turns out, windows clients can pull an IP from 10.10.18.1 while this rule is in place, where others can not.

If I split the rule into separate rules, denying each of our internal vlans 

Deny 10.10.18.0/24 -> 10.10.10.0/24

Deny 10.10.18.0/24 -> 10.10.11.0/24

Deny 10.10.18.0/24 -> 10.10.12.0/24

ect ect

and then remove the overall deny rule , all clients can pull an IP..

so odd!