I have a switch stack of 8 MS350 switches, that are configured as L2 access type switches.
L2 meaning that I have no L3 SVIs on them except the required MGMT IP per switch.
I have this MS stack with L2 trunks going up to my Cisco Catalyst 9K Switch which is configured as an L3 Core with SVI's.
We have a separate windows DHCP server on our server VLAN.
The problem I am seeing is that on the Meraki MS350 switch ports, if a PC is plugged into a user VLAN for example, it keeps getting a 10.X.X.X address with the 10.128.128.128 as its GW and DNS. Sort of like this article
which looks like the private addressing that Meraki gives out.
If we try static addressing on the PC in the user VLAN its plugged into, all network communication works as expected all over and to the internet.
Yes the Cisco 9k Core, has the correct ip-helper in the user vlan SVI to the DHCP servers IP.
So why is it doing this behavior and how to resolve this, so that DHCP broadcast requests, go over the L2 trunks to the correct SVI on my Cisco core 9K instead? Seems like Meraki MS is intercepting this and giving out its private IP instead?
I saw something on enabling routing etc..., but I want these MS switches to be L2 with no VLAN IPs on them, that why I have the Cisco core for.
Also just to mention, we will also have Meraki MR-53 APs also plugged in, which will need this Meraki private IP addressing (10.X.X.X) for its clients to give out for internet. This will sit on the same VLAN as user vlan.
The dashboard should be reporting which DHCP servers it detected in "Switch/DHCP servers & ARP". You could check what is handing out those addresses.
One reason I could think of is, if you have the MR53's connected with two wires, that the APs might be handing out those 10.X.X.X IP-addresses to the wired network. I've seen this happen. In that case check that you're aggregating the correct ports and that the switches have correctly gotten their configuration from the dashboard.
Thank you. I checked this (DHCP/ARP section) and I see multiple MAC addresses that when I click on one of the 30 there, it says, MR53 and never connected to cloud. Our wireless guy has not configured these yet.
I also saw the actually DHCP server on its server vlan these as well.
I cannot see the IP I got in there or the MAC of my PC either so I don't know which of the actual 30 gave the IP but I think you are on to something here.
Is there anyway to specially see which WAP is giving the IP out to the PC?
Also, So are you saying that just having a MR 53 WAP(s) out of the box fresh and just plugged in, can dish out DHCP by default?
How do I stop the WAPs from giving DHCP to wired devices, and just give DHCP to wireless only?
Hi so I was able to shutdown the WAP ports for now to test quickly and the good news is that the PC doesn't get a DHCP address anymore from the 10.X.X.X ranges.
The bad news is that DHCP is still not reaching the server and giving out the DHCP addresses properly.
I have a VLAN 21 which is user VLAN
I have a VLAN 3 which my DHCP sits on.
The meraki switches have a L2 trunk PO to my Cisco core.
On my Cisco 9K core I have the IP-Helper command in the SVI on the VLAN 21 pointing to the correct DHCP server in VLAN 3. VLAN 3 doesn't have a helper under the SVI as I think this is not needed.
Inter-VLAN Routing works bc if I give my PC a static address in VLAN 21, I can PING the server DHCP IP address.
Here is a packet capture of the DHCP request from PC, you can see it get a 169 address afterwards. Please help. Is Meraki MS not passing the DHCP over correctly etc...?
17:17:31.104213 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:d2:44:bf:56:01, length 300
17:17:35.077127 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:d2:44:bf:56:01, length 300
17:17:39.670113 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:d2:44:bf:56:01, length 300
17:17:48.139213 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:d2:44:bf:56:01, length 300
17:17:48.575824 IP 169.254.226.129.5353 > 184.108.40.206.5353: 0 AAAA (QM)? nycapps02.local. (33)
17:17:48.576343 IP 169.254.226.129.137 > 169.254.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:17:48.576398 IP6 fe80::99ca:51cd:e1b2:e281.5353 > ff02::fb.5353: 0 AAAA (QM)? nycapps02.local. (33)
17:17:48.576439 IP6 fe80::99ca:51cd:e1b2:e281.61736 > ff02::1:3.5355: UDP, length 27
17:17:48.576479 IP 169.254.226.129.61736 > 220.127.116.11.5355: UDP, length 27
17:17:48.576517 IP6 fe80::99ca:51cd:e1b2:e281.64892 > ff02::1:3.5355: UDP, length 27
17:17:48.576558 IP 169.254.226.129.64892 > 18.104.22.168.5355: UDP, length 27
17:17:48.943792 IP6 fe80::99ca:51cd:e1b2:e281.61736 > ff02::1:3.5355: UDP, length 27
17:17:48.944330 IP6 fe80::99ca:51cd:e1b2:e281.64892 > ff02::1:3.5355: UDP, length 27
17:17:48.944387 IP 169.254.226.129.61736 > 22.214.171.124.5355: UDP, length 27
17:17:48.944430 IP 169.254.226.129.64892 > 126.96.36.199.5355: UDP, length 27
17:17:49.283919 IP 169.254.226.129.137 > 169.254.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:17:50.042073 IP 169.254.226.129.137 > 169.254.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:17:56.575813 IP 169.254.226.129 > 188.8.131.52: igmp v2 report 184.108.40.206
17:18:01.042116 IP 169.254.226.129 > 220.127.116.11: igmp v2 report 18.104.22.168
17:18:01.042331 IP 169.254.226.129 > 22.214.171.124: igmp v2 report 126.96.36.199
I ran Wireshark.
So if its on the same VLAN as the server it works.
But if the PC is not on the same VLAN, I don't see any DHCP coming in to the server and a 169.254 is giving after the timeout.
Inter-VLAN routing works and I have the ip-helper on that PC SVI VLAN.
The server VLAN SVI doesn't have ip-helper.
What else is missing? or needed? Is there a setting in meraki MS for this?
These are L2 switches with no routing enabled as again why I have these L2 trunked PO to my Core switch.
Hi. I figured out the problem incase this happen again to someone else or another case.
The problem was not on the Meraki's. The issue was actually on the Cisco 9500 Core Switch. Someone must have turned off the DHCP service for some reason. After enabling back on, DHCP across VLANs now work.
So this look to be resolved as of now.
Thank you all again for your time with this!