Extending LAN Wired and Wireless via Mesh network

[plwskip]

Hello All - 

Hoping the community might be able to give me some help.  I was using this document (https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireles...) to setup 2 MR86 devices to MESH and extend the wired and wireless LANs across the street to another site about 50 yards away.

Main Building has:

MX84

Multiple MS210 switches

4 MR33s

MR86 - for point-to-point Mesh connection

Second building:

2 MR44

1 MS210

1 MR86 - for point-to-point mesh connection.

I have followed the diagram closest to the bottom of the document under "Extending the Lan with Segmentation for Wired and Wireless clients".  I was able to get the MESH to work between the MR86 devices and get the MS210 on the other side up and working.  Meraki support changed our settings to allow multiple The only hang up is DHCP.  It does not go across the link - this was confirmed by support.  They said that DHCP must come from the remote side switch for any networks that will be on the remote side.  Unfortunately, while the MS210 CAN have SVI interfaces, it cannot do DHCP.   While I can statically assign the APs - if I want to have an SSID or clients on that side -I'll need DHCP.

Has anybody else experienced this?  Trying to look for options without purchasing a new MS250 to facilitate the DHCP.  Did I receive bad info and this CAN be done?  Attach a small DHCP server to switch on remote side?  Put remote equipment in another Meraki Network and add an MX to that side?  Use different point-to-point devices to facilitate the link?

Appreciate any info or experience anyone has had with this.  

Thx!

[Mloraditch]

We use other bridge products because of the limitations of Meraki's options, but have you tried doing relay and seeing if that works? Not sure how they code the blocking of dhcp, but I would suspect it would be broadcast traffic and a relay turns it into unicast.

[Ryan_Miles]

DHCP relay on a MS210 in this design works. See this diagram.

You mentioned Meraki Support enabled multi-VLAN mesh? That is a different thing from LAN extension for repeater side LAN APs. The latter is the L3 switch design.

Multi-VLAN mesh is simply converting the mesh link to a trunk. So, the repeater side switch can support multiple L2 VLANs extended from the gateway AP side/network.

When you have repeater side LAN AP(s) you need the L3 switch whether DHCP is sourced on that remote side or relayed to the gateway side of the network. The risk I see with the DHCP relay design is if the relay fails the AP(s) will attempt to mesh and potentially cause issues. I prefer to make the repeater side switch and AP(s) a separate network not only for visual/mgmt clarity but it also then allows you to disable mesh (on network wide page) so those AP(s) don't attempt to mesh. 

The multi-VLAN mesh (Support enablement) and L3 switch (because of repeater side AP) designs can be combined. Example.

[plwskip]

Yes - that map is exactly what I was doing (I think I found your youtube video) - but the APs were doing exactly as you said - it was not getting an IP so it tried to MESH - which it was successful in doing and then the switch moved over to it for its uplink. 

I think I have most of the settings the same and working - the remote side switch was online and its SVI interfaces were routing out - so not sure why DHCP was not working for it.  We were thinking of just putting a separate DHCP server connected to the remote switch as a stop gap - guessing this would work also.  Frustrating Meraki support just said it doesn't work and closed case - but if you say it works - I will go back and follow that diagram.  I must have missed something.  I was thinking maybe firewall rules on the MX?  Does the transit network need to be able to comm with all those networks in order to server DHCP?

Thanks all

[Ryan_Miles]

You can definitely put a DHCP server on the far end and that's what documentation recommends. Or, swap to a switch that supports DHCP server itself. But the relay design works too. Is it supported per documentation? Well, that's another matter that I cannot address. 

The SSID you have configured as the "Clients wired directly to Meraki access points" under the network wide page is the VLAN the repeater's eth port will be mapped to. So, if that SSID is tagged with a VLAN ID traffic on the repeater eth will be on that VLAN. If the SSID is untagged then it will use whatever the gateway side AP's native VLAN is per the switch trunk port it's connected to. So, if you use a dedicated SSID for this mesh link purpose you might consider editing the config and have it tagged for a specific VLAN to ensure the mesh link is on the intended transit VLAN.

But this also brings into question how you want the switch mgmt IP to function. This diagram in documentation shows VLAN 20 being the mesh SSID VLAN and hence the repeater side switch is on VLAN 20 for its mgmt IP and its "transit" VLAN SVI for the next hop back to the MX. Why documentation shows that switchport being a trunk, native 20, allow 20 I'm not sure. That's just the same as access VLAN 20. And, the repeater eth port isn't a trunk anyway in that diagram.

If you want a unique switch mgmt VLAN different from the mesh/transit VLAN then you need to have Support enable multi-VLAN mesh. And the diagram here covers this design. In your case Support has already enabled multi-VLAN mesh per your Support case. I also have a slide of this topology with more detailed config bits than official documentation. This is exactly what I have running in my lab today.

So I would build this out link by link and make sure each step works. When you bring up the repeater and switch ensure the switch gets an IP (or static) and you can ping back to the MX SVIs. The MX should be able to ping all the SVIs on the switch assuming you have the static routes in place on the MX. If that all works maybe first try a wired client on the switch and make sure it can get an IP via relay back to the MX. If that's not working no reason to jump to adding APs on that far end as something isn't configured correctly.

[GIdenJoe]

I am personally very interested to see how a Cisco URWB bridge would work in this situation since that solution can handle all the normal LAN extention features like VLANs and broadcasts.