--- title: How it works ref: how_it_works lang: en --- == Objectives to Achieve - Enable non-expert users to set up a mesh network and perform basic configuration and management via a web interface usable on smartphones - Encourage non-expert users to empower themselves deepening their technical understanding of mesh networks - Scalability - Network segmentation - Layer 2 roaming inside certain areas - Smart gateway selection with redundancy and possibility of user-choice - Compatibility of most of the existing scenarios - A single firmware image for all of your network (for ground level, for backbone, for companies, for quick deployments, etc.) == The Basics The network architecture designed for LibreMesh is based on two layers: === Cloud layer 2 The cloud layer 2 uses the dynamic routing protocol BATMAN-ADV image::/assets/img/bat-adv.png[batmanadv,100,float="left"] ******************* B.A.T.M.A.N. Advanced is a mesh routing protocol that runs in kernel space. Even if the network topology is made of multiple nodes and multiple hops, B.A.T.M.A.N. Advanced abstracts it to a single layer 2 broadcast domain. So from the user's perspective the entire mesh will look like a single LAN. This architecture is robust for roaming purposes, thus TCP and UDP connections are not lost even when moving and changing access points (AP's). ******************* === Network layer 3 The whole network layer 3 uses by default the routing protocol BMX image::/assets/img/bmx7.png[bmx7,100,float="left"] ******************* BMX6 (or the new version BMX7) is an IPv6 native dynamic routing protocol which offers very advanced features and a small network overhead, thanks to the distance-vector strategy and its set of optimizations. Version 7 has, in addition, security routing extensions. ******************* === Mixing layers By default, all nodes are running both routing protocols (BMX and BAT-ADV), but on different VLANs.footnote:[Virtual isolated LAN, for instance wlan0.13]. So the routing is isolated by the MAC layer. [NOTE] ========================= The BMX VLAN is always the same, so all link-layer connected nodes will see each other. ========================= [NOTE] ========================= The BATADV VLAN depends on the cloud identifier which is calculated (by default) using the AP SSID. ========================= [IMPORTANT] ========================= The BMX network will be a single one for all of the mesh, but the BAT-ADV network may be split across several clouds. ========================= image::/assets/img/network1.png[align="center"] **This configuration isolates the layer 2 clouds**. For instance a neighborhood, a company complex, or a street level hotspot network may choose to isolate their LAN from the rest of the network. However at the same time, they will be able to reach the rest of the nodes using the layer 3 routed network. Roaming will be available inside the cloud, so TCP sessions, video streaming, or even a SIP call can be done while moving around. On the other hand, thanks to layer 3 segmentation, the common problems found in a layer 2 bridged network -- such as Broadcast storms or DHCP nightmares -- will not disturb the correct operation of the network. [IMPORTANT] ========================= Everything is automatic and transparent for the end user. ========================= image::/assets/img/network2.png[align="center"] == The Details WiFi Access Points of the same cloud share common parameters: * The SSID (the WiFi AP identification name) * Special anycast.footnote:[IP shared by multiple devices in the network] IPv4 and IPv6 addresses * A special anycast MAC address * The DHCP/RA server to provide valid IPs from the cloud to the clients. Thus a client attached to an AP can move around the mesh without the need to renew their IP configuration. Even the MAC layer will be the same from their point of view. image::/assets/img/network3.png[align="center"] [NOTE] ====================== The DHCP lease file is shared among the cloud to prevent collisions using link:http://en.wiki.guifi.net/wiki/A.L.F.R.E.D.[A.L.F.R.E.D.] As long as all nodes share the same anycast MAC/IP, from the client point of view it is fully transparent. The gateway is always the same even though the mesh node (where they are attached) may change. ====================== image::/assets/img/network4.png[align="center"] When a client wants to go out from the LAN (cloud) to reach the Internet or any other network, it will send the packets to the special anycast gateway address. The node where the client is physically attached will take care of this. [NOTE] ============== An ebtables.footnote:[something like iptables but for network layer 2] rule in the LAN/AP bridge prevents packets sent to the anycast address from propagating through the cloud. The mesh node where the client is associated gets the packet but not the other nodes. ============== image::/assets/img/network5.png[align="center"] The packet is routed through the BMX layer 3 network to the best Internet gateway. It may be a node from the same cloud or any other from another cloud far away. [NOTE] ============= BMX has a powerful smart gateway functionality which automatically selects the best Internet gateway node taking into account the available bandwidth. ============= image::/assets/img/network6.png[align="center"] [NOTE] ============= On the way back the packet will arrive to some node in the cloud but it might not be the same node. Nevertheless the packet will be correctly delivered to the originator. This is because BMX smart gateway uses 1-way tunnels to ensure the selected gateway is used. =============