Wi-Fi Mesh Support: Overview and Howto

Will do. Do you need diagnostic reports for any or all of the APs?

1 Like

I believe the wireless Mesh AP always connects to the same wired Mesh AP, right? If so, the rest are not needed.

1 Like

It has been observed to connect with at least two different wired APs. Disabling and then re-enabling the one it was connected to just now provoked an outage for DHCP assignments across untagged as well as a tagged SSIDs - the VLAN correlation referenced earlier may be a red herring. A a reboot of the mesh AP was required to get it reconnected to the router and the world, again.

Anyway: The ticket is #20120871

Thanks for all your assistance.

Z

1 Like

I believe I’m having the same issue here while playing around with a Max Transit and a wireless AP One Mini. Seems like about 25% of the time when a device connects to the Mini, it does not receive an IP. Never an issue when connecting to the Transit’s internal AP. Only have one SSID and no VLANs.

Also, what is the expected loss of throughput with the mesh? With a gigabit fiber WAN, I typically get 200 Mbps up/down when connected directly to the Transit’s internal AP. But only getting about 70 down and 120 up through the wireless AP One Mini. Controller Mesh Status showing 240M send/receive, fwiw.

@mbrook. Please share the screenshots of Mesh signal strength for Transsit and AC Mini.

1 Like

Can I please get clarification on a few things?

I have a Balance One and an AP One X. I configured according to the instructions above, but the AP One X did not have an “enable” checkbox on the Mesh configuration screen.

The mesh didn’t start working until I logged into the AP One X and went under AP and then Settings to enable the Mesh. It also didn’t seem to start working until I disabled “boost” mode on both the Balance One and the AP One X.

Was any of that necessary? From the instructions it seemed like you only needed to go to AP | Settings and select the Mesh from the router and not from the AP, but I couldn’t get it to work until I did that on both the router and the AP.

I had the same issue as @zegor_mjol (SSID mapped to Tagged VLAN would not receive IP’s but untagged SSID worked fine) for my Peplink Wi-Fi Mesh setup (Balance Core with tagged VLANs, wired Mesh AP (AP One Enterprise), wireless Mesh AP (AP One AC Mini)). My APs were on firmware 3.6.2 build 1938.

After upgrading both wired and wireless Mesh AP to the special firmware “3.6.2s01 build 1940”, tagged VLAN SSID is now working for me :grinning:

Thanks to both of you!

2 Likes

Sorry, just got around to testing this again. Now it seems to be performing better than before. Connected to the wireless AP Mini, getting speeds around 120 Mbps down and up. Connected to the Transit I’m getting around 170 and 120. Tested on an iPhone and a MacBook with a gigabit fiber WAN. These speeds are fine for my application since it’s typically cellular only.


@mbrook, I think the throughput you got still acceptable. Please refer to first post of this forum thread.

You may google some best practices of WIFI Mesh deployment if throughput is your concern. Alternatively, you may get help from your point of purchase. A WIFI survey is needed for a proper WIFI Mesh deployment.

1 Like

I have Balance One WIFI and SoHo MK3.
I tried to create Mesh network, but it doesn’t seem to work as intended. Any suggestion on how to make them mesh together?

I have set Wireless Mesh and enabled on both routers (balance one connected to the Verizon and SoHo MK3 by itself with no wire) and I see no device showing up in the Mesh /WDS screen.

Good day folks !
Is it possible to activate Wi-Fi Mesh feature when the SSIDs are managed from InControl ?
don’t think so … :face_with_raised_eyebrow:

Short answer: yes :slight_smile:

Specific basis for that answer: We have a bunch of APs whose SSIDs are all managed by IC2. Having configured the APs with an enabled mesh functionality (done locally on each device) they are now serving up the IC2 configured SSIDs.

Cheers,

Z

2 Likes

This is great, but is it not available on the UBR-LTE devices??? “Wifi Mesh” doesn’t show up after upgrading the firmware to 8.1.1. Could it please be enabled for them?

Sorry, the UBR-LTE is not compatible with our Mesh feature, as it is 802.11n only.

1 Like

Ok, thanks!
Just to be clear, the Max-HD2 would have that functionality and be supported, yes?
Seems we bought the wrong gadgets.

Correct. The current generation HD2 or HD2 MBX would both support this.

1 Like

Thanks @Travis!
(Sorry for the double post)

Another (maybe naive) question, if you don’t mind:


Would the Peplink Wi-fi Mesh allow routing of traffic between LAN A and LAN B as shown in this drawing?
That is, does the WiFi mesh create routable network interfaces on each AP?
If so, can one configure a PepVPN with speed Fusion between the PepLink devices over this link, potentially bonding it with other WAN interfaces?

I realize this is probably not how PepLink envisioned the use of the Mesh capability. Thinking outside the box here.

by no means am I an expert, but I have been running a mesh since they introduced it. I can take a stab… and I imagine you are right, this was most likely not the intended use case. But, never the less – it will probably do “something”

Just thinking out loud… the mesh creates a layer 2 link between the two APs. I don’t think the mesh works in router mode (but I could very well be wrong), so I don’t think it would “route” the packets; but if somehow it had the IP/mac of the destination in its mac table – it potentially could work. maybe. I imagine we would need to know a bit more about the two LANs. Do the IP ranges overlap/conflict? I imagine it would behave similar to connecting the two lans via ethernet cable.

One issue though, from what I understand the mesh will only be connected if the path to the gateway is down. I don’t think it will even try to establish the mesh while both APs have an ethernet connection to it’s respective gateway. And then, if it did connect – all the devices on LANB (assuming routerB went down) would start pulling DHCP addresses from RouterA (in essence turning LANB into LANA-extended).

Now, that being said – I am sure if you put your mind to it – you can make it do “something”. Whether it is the most effective way to accomplish that “something” is a different question entirely. there is always more than one way to skin a cat – but, the cat ain’t gonna like any of them.

Potentially, you could set up LANB as a secondary LAN in RouterA, and also set up LANA as a secondary network in RouterB (Peplink supports multiple untagged IP networks now). This could potentially be a way to provide a brute force type of HA/failover pair for each LAN. The only problem is that you would need RouterA and RouterB to both be the same IP to keep the default gateway the same for the clients. Here is what I am thinking…

RouterA - Main untagged LAN - 192.168.1.0/24 - 192.168.1.1
Secondary untagged LAN - 192.168.2.0/24 - 192.168.2.1
RouterB - Main untagged LAN - 192.168.2.0/24 - 192.168.2.1
Secondary untagged LAN - 192.168.1.0/24 - 192.168.1.1
Mesh configured on two separate APs - 1 attached via ethernet to RouterA (AP-A), 1 to RouterB (AP-B)

While AP-A can communicate with RouterA - no mesh will be formed
While AP-B can communicate with RouterB - no mesh will be formed
if AP-A cannot communicate with RouterA (RouterA failed) - mesh will be established and new mac for default gateway IP on RouterB discovered. All traffic from LANA destined to the default gateway should go to RouterB secondary LAN and should make it to the internet.
If AP-B cannot communicate with RouterB (RouterB failed) - mesh will be established and new mac for default gateway IP on RouterA discovered. All traffic from LANB destined to the default gateway should go to RouterA secondary LAN and should make it to the internet.

I don’t see how it would ever auto recover, as soon as either router comes back online - there is going to be a mac address conflict and two DHCP servers fighting over the same subnet address space. In theory, I am sure you could come up with an order of operations to recover from failures without everything going to crap - but, is it worth it? Is there a better way? there is probably a better way to provide redundancy for SpeedFusion links.

Sorry in advance if I missed the mark on what you are asking. It sounded like a neat proposition and I wanted to go through it in my head. Most of my speed fusion stuff has been done on the routers and not inside the APs, so when the router goes offline - so does the speed fusion connections. Now, if both routers on both LANs had SpeedFusion going all the time, the traffic from each LAN could potentially make it to “A” SpeedFusion tunnel, but it would be provided from the other router.

For what it is worth, I have not played around with the secondary LAN stuff at all. I also have not tried any kind of routing/speedfusion from the AP. All of my stuff runs in bridge mode and has an uplink to the router. If it were me, I would set up a WAN->WAN link between the two LAN gateways and set up proper routing between the two LANs, you could set it up to be a standby link for fault tolerance. You could use IP-Passthrough and OSPF/BGP on that link to avoid NAT between the two LANs.

I would be interested to find out what happens if you ever try this set up.

2 Likes

I cannot tell you, @jmjones, how thankful I am for this lengthy and thoughtful response. It gives me a lot to think about and will take some time to digest.

If it’s true that the Mesh link is not created unless the Cellular Link is down, then the mesh is going to be worthless for my application.

Maybe I’ll explain the real scenario and see if you or others have thoughts about how to accomplish it.

I have two mobile platforms whose networks I need to connect as reliably and cost-effectively as possible. They could be on the same subnet (so the link could be layer 2), but it could also work with different subnets.

With PepLink devices, I have three possible ways to pass data between the platforms, Cellular, Wifi and a third party proprietary point-to-point radio system which provides a layer-2 link (and could be connected to WAN ports on each PepLink device). For Cellular, we would use fixed routable IP addresses for a point-to-point link.

What I was hoping to do is use the Speed Fusion technology to bond the fixed cost links (Wifi and radio system), and fail-over to the Cellular link when the other two are not available. But what I’ve found is that Speed Fusion is only implemented to work over “WAN” classified links (Wifi Client, Cellular or WAN-labeled ports). PepLink, it seems never envisioned that one might want to connect PepLink device to PepLink directly by Wifi and include this in the bonding. It simply cannot be configured for a Wifi AP, so it seems there is no way to configure this setup.

I was hoping the new Mesh technology might effectively provide another WAN interface, enabling the ability to use point-to-point Wifi links in bonding, overcoming the current limitation. Even if the mesh link did not provide a WAN interface and was layer 2 only, I think data would preferentially pass over wifi before being routed via the other links. But if the mesh links are only created when the gateway route is not available, then I think none of these solutions will be possible.

1 Like

I am wondering if this mesh is behaving as it should… I expect the Mesh to include lines from the non-wired to the wired AP, but I wasn’t expecting the connection between the two non-wired APs. Are they supposed to be doing this?

Screen Shot 2021-01-29 at 11.32.58 AM
I am referring to the dotted line between the two red circles. The lines from red to blue are expected, but not the line from red to red.

1 Like