Layer-2 routing for Mesh networks

We are developing the new mesh system which you can use together with the WDS-mesh mode.

Here is the link to the documentation:
http://wiki.mikrotik.com/wiki/Layer-2_routing_for_Mesh_networks

This feature is added in v3.9.

If you find any problems or ask some questions, please email to support@mikrotik.com or just post into this topic.

What would mean to compare a layer 2 solution like this to a layer 3 solution like OSPF?

Is hard to make an overall judgment, maybe is better to analyze single features:

-Topology change reaction time
-overall link bandwidth
-RB CPU usage
-different media interoperability (mixed wireless, ethernet links): to be more accurate, a mesh wireless network is commonly intended with a router as a “node”, this imply multiple radio on a router. If I would like to dedicate a RB to each radio and bridge RBs ethernet each other to gain a most “CPU powerful” node. Is it possible?
-smart path choice: ability to choice (by algorithm or by configuration) the most bandwidth unloaded alternative path.
-scriptability :slight_smile: : how much this solution is “scriptable” to force a link choice under certain condition…

any answer or reference link to existing documents will be really appreciated.

As far as I understood - it will be better version of RSTP-bridge, that is specially designed for WDS in “static-mesh” and “dynamic-mesh” modes.

What have Layer-3 have to do with WDS??? You cant compare them.

Hi guys,

Recently apply the new “L2 Mesh Protocol” on all my wds-dynamic bridged rstp network to get better performance and stability…

Applying from the MT Server PC x86 at about 20 RBs. The network has more than 800 wireless clients with regulars CPEs.

The MT Server have a bridge interface with 2 ethernet interfaces from the Clients, when i put this bridge like a mesh port, the dhcp-server and hotspot server turn Incorrect in red, when i change to the mesh1 interface in both servers, all is ok but the hotspot is not working, all clients are not detected by the hotspot, and in host i can see all clients PCs without the “P” of bypassed…
Now all my clients can use internet without control.

How is wrong?

I put the bridge interface in each node like a port of the mesh interface and change the interface of the IP address of each node to the mesh interface.

Thanks!

PS: temp solved doing mesh only from the first hop wireless node(RB600) of the network. Is this scenary the correct or may be the MTx86 too in the mesh network like i think? Regards!

thank you for the report.
We will try to fix the issue with invalid dhcp server if you run it on the bridge interface.
For now you can use it on one of the bridge port interfaces.

Thank for the reply Uldis, but is impossible run dhcp-server and hotspot-server in an interface which is a port of a bridge or in a bridge which is a port of a mesh interface :slight_smile:

The results at now are:

With L2 Mesh Protocol all the problems was solved, the network is more stable and the convergence is more fast. But the MT Server x86 is out of the mesh network, is it correct or is an issue to fix?

At now, i can say… Good work guys!

Best Regards!

Hello Uldis, thanks for doing the good job on MESH. The bad thing is, I never can stop studying with you guys far beyond me. I certainly will take a serious look at your thoughts, since it is my conviction MESH is absolutely important now and in near future. Thanks and regards !

Uldis, some additional comment: (I study slowly but read fast :slight_smile:) What I miss in the doc is when you use a router with THREE radios inside: one for the client, one for the ingress traffic and one for the egress traffic. Consider also additional DFS: if something is happening on the channels routers switch their frequnecy immediately. Is this somethin you still are working on? I would like to see a complete config OS for a router using three radios and this DFS stuff…

You can have multiple wireless cards in one AP mesh node. About the DFS mode - it is hard to make as it will not use the same channel as the other nodes uses it and DFS will try to select different channel. You can try to use WDS-Slave mode, maybe that would help you to make a workaround.

If radios are negotiating channels using DFS hopefully this protocol is rapid enough to re-route traffic where links are still good. That said, we rarely if ever see our radios change channels because of DFS.

I see the wiki says that link state monitoring (ping times, signal strength) is not yet part of HWMP+ protocol - Uldis, will this be added later - and Winbox extensions too?

STRIX systems is working that way (3 radio’s in a box: one client on 2.4, one egress traffic, one ingress traffic both on 5GHz) very successfully, with DFS measuring noise floors, but this far i did not manage to build such in MT.

Uldis

I’ve configured two APs as in the wiki. All works well but if I change between static and dynamic mesh modes, the routerboards reboot. (RB133 and RB112) Can you reproduce this?

Also when will all mesh commands be in Winbox?

does it crash with the kernel panic or just watchdog timeout?
How much free RAM you have on the board?

Hello uldis, thank you for your excelent mesh configuration… I’ve been studying a while and have made some tests already.

In the other hand, when I need mobility, how can I configure roaming? If a laptop is within a car and this car is moving from one mesh node to another, how can it makes fast hand-off and guarantees the continuity of the service?

Thank You!
ChiPoLy
Mexico

This kind of roaming is a client feature, you should look how good is the laptops client driver written.

Yes, that is correct. Thank you.
Right now I can move freely in the mesh coverage and hand off happens very quickly.


I have other issues but first let me tell you about my configuration wich is very simple:

I have 6 RB433AH with 2 R52H each. Am using 5.8GHz for the mesh network and have the other miniPCI for 2.4GHz WiFi Coverage, wich is a simple WiFi Access Point.

The radio connected to ISP is configured as mesh-portal=yes in mesh1.
All the wireless links in 5.8GHz are registered, with signal strenght from -60dB to -80dB.

When I get DHCP IP in my laptop Im working very good, but sometimes I am not able to receive IP or navigate… As there is lack of information about the L2 Mesh, I am not capable to determine what is happening.
In some radios I log into winbox or mac telnet, and there is not response when doing pings to some other network devices, or to the DHCP server.

I really would like to have a more complete manual about this L2 Mesh protocol (HWMP+). My actual laboratory is 6 radios only, but I’d like to create a L2 Mesh Network with near 1000 nodes, and I think I need to understand more the functionallity of this network :slight_smile:

I really hope to get some guideance from you.

Regards!
ChiPoLy
Mexico

1000 mesh nodes?

Good plan but impossible mission? :sunglasses:

haha I am serious :slight_smile:

Actually we know some of Tropos PWRP designed for high density Wireless Mesh Networks.

Can you send me more information about this HWMP+ ?
Am going to PM you my email.

Thank You

I posted a topic about this, but after reading this thread this is where Uldis wants the Layer-2 Mesh routing questions to be posted. I think my problems are similar to ChiPoLy.

I’ll call one AP R1 and the other R2. On R1 I have two interfaces, wlan2-mesh, and wds1. On R2 I have three interfaces,ether1, wds1, and wlan1. On both routers I put those interfaces into a mesh named mesh-bridge. R1 is assigned 192.168.3.1, and R2 is assigned 192.168.3.150. If I connect my laptop to R1 and the roam/transfer to R2, then R1 stops responding to pings from the laptop, but R2 can still ping R1. The opposite happens if I connect to R2 and roam to R1. If I disable and re-enable the mesh interface on the AP I was originally connected to it starts working again. I deleted the mesh interface and setup a rtsp bridge with the same ports and everything works correctly with both APs responding even when I roam. What could I possibly be doing wrong?

please upgrade to latest RouterOS version as there were some fixes for the L2 Mesh driver.