2

We have the following set-up:

+------+     +--------+     +--------+
|Router|-----| switch |-----| Meraki |
+------+     +--------+     +--------+
                |
             +---------+
             |wireshark|
             +---------+

The Meraki serves a number of SSIDs, A, B and C. The Meraki is in bridge mode. For all the SSIDs, there is a separate VLAN, 511 for A, 512 for B and 513 for C. On the router (a cisco device), on all the VLANs, there is a DHCP server. In the Meraki console, the option "use VLAN tags" os on for all SSIDsThe switch ports are in trunk mode, with 510 as native VLAN.

The main purpose of the switch was to allow Wireshark on a span port.

C is an open accesspoint. When someone connects to C, he will do a DHCP. It was my understanding that, being in bridge-mode, the DHCP request should be on VLAN 513, and therefore tagged with VLAN 513. However, the router with the DHCP server sees DHCP requests on VLAN 510 (the native VLAN). With Wireshark, we see that the DHCP request is untagged. It is therefore logical that the router sees it on VLAN 510.

For Meraki: On the page "Addressing and traffic",

  • we checked "Bridge mode: Make clients part of the LAN"
  • after "VLAN tagging", we selected "Use VLAN tagging"
  • In the table VLAN ID, we set A to VLAN 511, B to VLAN 512 and C to VLAN 513
  • in that table, the column "VLAN ID" in the row "All other APs: is empty (no value entered here)

On the switch, the relevant part is: 

interface GigabitEthernet2
description LAN Meraki AP
switchport trunk native vlan 510
switchport trunk allowed vlan 1,510-514,1002-1005
switchport mode trunk
no ip address

On the Router, where the DHCP server lives, we have:

ip dhcp pool meraki-base-510
network 10.10.1.0 255.255.255.0
default-router 10.10.1.1
dns-server 8.8.8.8 8.8.4.4

ip dhcp pool meraki-open-513
network 10.10.3.0 255.255.255.0
default-router 10.10.3.1
dns-server 8.8.8.8 8.8.4.4

If we ask the switch where the MAC-id of the phone lives, it is on VLAN 513. So, it will never get an IP address.

When we give the phone a fixed IP address on VLAN 513, it connects as it should.

The router DHCP server produces the following info:

DHCPD: No option 25
DHCPD: DHCPDISCOVER received from client 1111.2222.3333.44 on interface Vlan 510
DHCPD: Allocate an address without class information (10.10.3.0)

(sorry, no traces from wireshark were saved; DHCP Discover was without VLAN tag)

Why does the Meraki put the DHCP request on the native VLAN? And what should I do to get a DHCP request tagged with VLAN 513?

Improve this question
10
  • 1
    This does not sound like normal operation. Could you provide configurations from switchports and from the Meraki platform? My best guess is that you have something misconfigured somewhere so the traffic is landing where it should for some reason. You could also check Meraki support to see if there might be a bug in your version of code affecting your configuration.
    – YLearn
    Nov 29, 2019 at 6:49
  • Meraki support said our config was correct and no bugs. Added additional info to the question.
    – Ljm Dullaart
    Nov 29, 2019 at 17:59
  • Could you also include the configuration of the router interface and the switchport connected to the router. I have seen Meraki installations similar to what you describe that do have functioning DHCP, although I don't have access to them now. As for the Wireshark capture not seeing the VLAN tag, that can have to do with how the span is actually configured and the platform it is on, so isn't direct proof without more information. Beyond these points, the only other note I have is that you mention relevant part but it is possible that something you don't consider relevant is causing issues.
    – YLearn
    Nov 29, 2019 at 19:47
  • 1
    You may not see it as being resistant, but when information is requested and you respond with "...yes, the DHCP packets are really untagged..." or "...I just get annoyed when people start doubting the information that I provide..."" instead of the requested information, that is being resistant. It isn't that we doubt the information you provide, but as professionals we often get told the conclusion when we are hired to fix it and often what we are told may only be part of the truth. You get other opinions precisely because the previous one(s) may have missed or misunderstood something.
    – YLearn
    Dec 1, 2019 at 17:15
  • 1
    When I go to peers/colleagues with a problem I haven't figured out, it is precisely because I have looked at things a hundred times and know I must be missing something. I need the fresh set of eyes to help me notice what I have been missing or where I may have drawn a false conclusion. And that usually requires rehashing and going over the same things I have already gone over a hundred times. Here is an example where I found something in a different way after getting extra info, even through the poster had the issue shown in the OP.
    – YLearn
    Dec 1, 2019 at 17:16

1 Answer 1

Reset to default
3

I believe I have found the problem based on how you have described your configuration, but your description wasn't sufficient to provide the information I needed to notice the problem. I ended up creating a new demo account with Meraki, because I don't currently have an active Meraki installation I can access (my own demo accounts are tied to hardware with expired licenses so the dashboard is disabled).

In the table VLAN ID, we set A to VLAN 511, B to VLAN 512 and C to VLAN 513

The table isn't for setting different VLAN tags to different SSIDs. This is a configuration per SSID which is controlled by a drop down at the top of the page.

Each SSID needs to be configured separately with the bridging and VLAN information. So with the top SSID drop down set to "C", in the table you should really only have one entry for "All other APs" set to 513. For "B", the "All other APs" should be 512, etc.

The entries you add to the table are if you want APs in different locations to use different VLANs for the same configured SSID. So you specify "AP tags" that would get assigned different VLAN IDs.

Improve this answer
1
  • At the moment, I do not have access to the test environment (it is a shared environment); during next week, I will be able to test again.
    – Ljm Dullaart
    Dec 3, 2019 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.