Difference between revisions of "Manual:Interface/HWMPplus"

From MikroTik Wiki
Jump to: navigation, search
m
m (Example)
 
(18 intermediate revisions by 6 users not shown)
Line 1: Line 1:
''Prerequisites for this article: you understand what WDS is and why to use it''
+
{{Versions|3, v4+}}
 +
 
 +
== Summary ==
 +
<p id="shbox"><b>Sub-menu:</b> <code>/interface mesh</code><br /></p>
  
== Overview ==
 
  
 
HWMP+ is a MikroTik specific layer-2 routing protocol for wireless mesh networks. It is based on Hybrid Wireless Mesh Protocol (HWMP) from IEEE 802.11s draft standard. It can be used instead of (Rapid) Spanning Tree protocols in mesh setups to ensure loop-free optimal routing.
 
HWMP+ is a MikroTik specific layer-2 routing protocol for wireless mesh networks. It is based on Hybrid Wireless Mesh Protocol (HWMP) from IEEE 802.11s draft standard. It can be used instead of (Rapid) Spanning Tree protocols in mesh setups to ensure loop-free optimal routing.
Line 9: Line 11:
 
Note that the distribution system you use for your network need not to be Wireless Distribution System (WDS). HWMP+ mesh routing supports not only WDS interfaces, but also Ethernet interfaces inside the mesh. So you can use simple Ethernet based distribution system, or you can combine both WDS and Ethernet links!
 
Note that the distribution system you use for your network need not to be Wireless Distribution System (WDS). HWMP+ mesh routing supports not only WDS interfaces, but also Ethernet interfaces inside the mesh. So you can use simple Ethernet based distribution system, or you can combine both WDS and Ethernet links!
  
== Configuration ==
+
{{Note|Prerequisites for this article: you understand what WDS is and why to use it!<br>
 +
Software versions: <b>3.28+</b> (earlier versions are incompatible)}}
 +
 
 +
==Mesh Properties==
 +
 
 +
{{Mr-arg-table-h
 +
|prop=Property
 +
|desc=Description
 +
}}
 +
 
 +
{{Mr-arg-table
 +
|arg=admin-mac
 +
|type=MAC address
 +
|default=00:00:00:00:00:00
 +
|desc=administratively assigned MAC address, used when '''auto-mac''' setting is disabled
 +
}}
 +
 
 +
{{Mr-arg-table
 +
|arg=arp
 +
|type=disabled {{!}} enabled {{!}} proxy-arp {{!}} reply-only
 +
|default=enabled
 +
|desc=Address Resolution Protocol setting
 +
}}
 +
 
 +
{{Mr-arg-table
 +
|arg=auto-mac
 +
|type=boolean
 +
|default=no
 +
|desc=if disabled, then value from '''admin-mac''' will be used as the MAC address of the mesh interface; else address of some port will be used if ports are present
 +
}}
 +
 
 +
{{Mr-arg-table
 +
|arg=hwmp-default-hoplimit
 +
|type=integer: 1..255
 +
|default=
 +
|desc=maximum hop count for generated routing protocol packets; after a HWMP+ packet is forwarded "hoplimit" times, it is dropped
 +
}}
  
=== /interface mesh ===
+
{{Mr-arg-table
 +
|arg=hwmp-prep-lifetime
 +
|type=time
 +
|default=5m
 +
|desc=lifetime for routes created from received PREP or PREQ messages
 +
}}
  
Configure mesh interface.
+
{{Mr-arg-table
 +
|arg=hwmp-preq-destination-only
 +
|type=boolean
 +
|default=yes
 +
|desc=whether only destination can respond to HWMP+ PREQ message
 +
}}
  
'''admin-mac''' (MAC address, default: 00:00:00:00:00:00) -- administratively assigned MAC address, used when '''auto-mac''' setting is disabled
+
{{Mr-arg-table
 +
|arg=hwmp-preq-reply-and-forward
 +
|type=boolean
 +
|default=yes
 +
|desc=whether intermediate nodes should forward HWMP+ PREQ message after responding to it. Useful only when '''hwmp-preq-destination-only''' is disabled
 +
}}
  
'''arp''' (disabled | enabled | proxy-arp | reply-only; default: enabled) - address resolution protocol setting
+
{{Mr-arg-table
 +
|arg=hwmp-preq-retries
 +
|type=integer
 +
|default=2
 +
|desc=how many times to retry a route discovery to a specific MAC address before the address is considered unreachable
 +
}}
  
'''auto-mac''' (boolean, default: no) -- if disabled, then value from '''admin-mac''' will be used as the MAC address of the mesh interface; else address of some port will be used if ports are present
+
{{Mr-arg-table
 +
|arg=hwmp-preq-waiting-time
 +
|type=time
 +
|default=4s
 +
|desc=how long to wait for a response to the first PREQ message. Note that for subsequent PREQs the waiting time is increased exponentially
 +
}}
  
'''hwmp-default-hoplimit''' (integer: 1..255) -- maximum hop count for generated routing protocol packets; after a HWMP+ packet is forwarded "hoplimit" times, it is dropped
+
{{Mr-arg-table
 +
|arg=hwmp-rann-interval
 +
|type=time
 +
|default=10s
 +
|desc=how often to send out HWMP+ RANN messages
 +
}}
  
'''hwmp-prep-lifetime''' (time, default: 5m) -- lifetime for routes created from received PREP or PREQ messages
+
{{Mr-arg-table
 +
|arg=hwmp-rann-lifetime
 +
|type=time
 +
|default=1s
 +
|desc=lifetime for routes created from received RANN messages
 +
}}
  
'''hwmp-preq-destination-only''' (boolean, default: yes) -- whether only destination can respond to HWMP+ PREQ message
+
{{Mr-arg-table
 +
|arg=hwmp-rann-propagation-delay
 +
|type=number
 +
|default=0.5
 +
|desc=how long to wait before propagating a RANN message. Value in seconds
 +
}}
  
'''hwmp-preq-reply-and-forward''' (boolean, default: yes) -- whether intermediate nodes should forward HWMP+ PREQ message after responding to it. Useful only when '''hwmp-preq-destination-only''' is disabled
+
{{Mr-arg-table
 +
|arg=mesh-portal
 +
|type=boolean
 +
|default=no
 +
|desc=whether this interface is a portal in the mesh network
 +
}}
  
'''hwmp-preq-retries''' (integer, default: 2) -- how much times to retry route discovery to a specific MAC address before the address is considered unreachable
+
{{Mr-arg-table
 +
|arg=mtu
 +
|type=number
 +
|default=1500
 +
|desc=maximum transmission unit size
 +
}}
  
'''hwmp-preq-waiting-time''' (time, default: 4s) -- how long to wait for a response to the first PREQ message. Note that for subsequent PREQs the waiting time is increased exponentially
+
{{Mr-arg-table
 +
|arg=name
 +
|type=string
 +
|default=
 +
|desc=interface name
 +
}}
  
'''hwmp-rann-interval''' (time, default: 10s) -- how often to send out HWMP+ RANN messages
+
{{Mr-arg-table-end
 +
|arg=reoptimize-paths
 +
|type=boolean
 +
|default=no
 +
|desc=whether to send out periodic PREQ messages asking for known MAC addresses. Turing on this setting is useful if network topology is changing often. Note that if no reply is received to a reoptimization PREQ, the existing path is kept anyway (until it timeouts itself)
 +
}}
  
'''hwmp-rann-lifetime''' (time, default: 1s) -- lifetime for routes created from received RANN messages
 
  
'''hwmp-rann-propagation-delay''' (number, default: 0.5) -- how long to wait before propagating a RANN message. Value in seconds
+
=== Configure mesh interface ports ===
 +
<p id="shbox"><b>Sub-menu:</b> <code>/interface mesh port</code><br /></p>
  
'''mesh-portal''' (boolean, default: no) -- whether this interface is a portal in the mesh network
+
===Port Properties===
  
'''mtu''' (number, default: 1500) -- maximum transmit units
+
{{Mr-arg-table-h
 +
|prop=Property
 +
|desc=Description
 +
}}
  
'''name''' (string) -- interface name
+
{{Mr-arg-table
 +
|arg=active-port-type
 +
|type=read-only: wireless {{!}} WDS {{!}} ethernet-mesh {{!}} ethernet-bridge {{!}} ethernet-mixed
 +
|default=
 +
|desc=port type and state actually used
 +
}}
  
'''reoptimize-paths''' (boolean, default: no) -- whether to send out periodic PREQ messages asking for known MAC addresses. Turing on this setting is useful if network topology is changing often. Note that if no reply is received to a reoptimization PREQ, the existing path is kept anyway (until it timeouts itself)
+
{{Mr-arg-table
 +
|arg=hello-interval
 +
|type=time
 +
|default=10s
 +
|desc=maximum interval between sending out HWMP+ Hello messages. Used only for Ethernet type ports
 +
}}
  
=== /interface mesh port ===
+
{{Mr-arg-table
 +
|arg=interface
 +
|type=interface name
 +
|default=
 +
|desc=interface name, which is to be included in a mesh
 +
}}
  
Configure mesh interface ports.
+
{{Mr-arg-table
 +
|arg=mesh
 +
|type=interface name
 +
|default=
 +
|desc=mesh interface this port belongs to
 +
}}
  
'''hello-interval''' (time, default: 10s) -- maximum interval between sending out HWMP+ Hello messages. Used only for Ethernet type ports
+
{{Mr-arg-table
 +
|arg=path-cost
 +
|type=integer: 0..65535
 +
|default=10
 +
|desc=path cost to the interface, used by routing protocol to determine the 'best' path
 +
}}
  
'''interface''' (interface name) -- interface name, which is to be included in a mesh
+
{{Mr-arg-table-end
 +
|arg=port-type
 +
|type=WDS {{!}} auto {{!}} ethernet {{!}} wireless
 +
|default=
 +
|desc=port type to use
 +
*   <var>auto</var> - port type is determined automatically based on the underlying interface's type
 +
*   <var>WDS</var> - a Wireless Distribution System interface. Remote MAC address is learnt from wireless connection data
 +
*   <var>ethernet</var> - Remote MAC addresses are learnt either from HWMP+ Hello messages or from source MAC addresses in received or forwarded traffic
 +
*   <var>wireless</var> - Remote MAC addresses are learnt from wireless connection data
 +
}}
  
'''mesh''' (interface name) -- mesh interface this port belongs to
 
  
'''path-cost''' (integer: 0..65535; default: 10) -- path cost to the interface, used by routing protocol to determine the 'best' path
+
==Mesh fdb Status==
 +
<p id="shbox"><b>Sub-menu:</b> <code>/interface mesh fdb</code><br /></p>
  
'''port-type''' (WDS | auto | ethernet | wireless) -- port type to use
 
*   '''auto''' - port type is determined automatically based on the underlying interface's type
 
*   '''WDS''' - a Wireless Distribution System interface, kind of point-to-point wireless link. Remote MAC address is known from wireless connection data
 
*   '''ethernet''' - Remote MAC addresses are learned either from HWMP+ Hello messages or from source MAC addresses in received or forwarded traffic
 
*   '''wireless''' - Remote MAC addresses are known from wireless connection data
 
  
'''active-port-type''' (read-only, wireless | WDS | ethernet-mesh | ethernet-bridge | ethernet-mixed) -- port type and state actually used
+
'''Properties:'''
  
=== /interface mesh fdb ===
+
{{Mr-arg-table-h
 +
|prop=Property
 +
|desc=Description
 +
}}
  
Read-only status of the mesh interface Forwarding Database (FDB).
+
{{Mr-arg-ro-table
 +
|arg=mac-address
 +
|type=MAC address
 +
|desc=MAC address corresponding for this FDB entry
 +
}}
  
'''mac-address''' (MAC address) -- MAC address corresponding for this FDB entry
+
{{Mr-arg-ro-table
 +
|arg=seq-number
 +
|type=integer
 +
|desc=sequence number used in routing protocol to avoid loops
 +
}}
  
'''seq-number''' (integer) -- sequence number used in routing protocol to avoid loops
+
{{Mr-arg-ro-table
 +
|arg=type
 +
|type=integer
 +
|desc=sequence number used in routing protocol to avoid loops
 +
}}
  
'''type''' (local | outsider | direct | mesh | neighbor | larval | unknown) -- type of this FDB entry
+
{{Mr-arg-ro-table
*    '''local''' -- MAC address belongs to the local router itself
+
|arg=interface
*    '''outsider''' -- MAC address belongs to a device external to the mesh network
+
|type=local {{!}} outsider {{!}} direct {{!}} mesh {{!}} neighbor {{!}} larval {{!}} unknown
*    '''direct''' -- MAC address belongs to a wireless client on an interface that is in the mesh network
+
|desc=type of this FDB entry
*    '''mesh''' -- MAC address belongs to a device reachable over the mesh network; it can be either internal or external to the mesh network
+
*    <var>local</var> -- MAC address belongs to the local router itself
*    '''neighbor''' -- MAC address belongs to a mesh router that is direct neighbor to this router
+
*    <var>outsider</var> -- MAC address belongs to a device external to the mesh network
*    '''larval''' -- MAC address belongs to an unknown device that is reachable over the mesh network
+
*    <var>direct</var> -- MAC address belongs to a wireless client on an interface that is in the mesh network
*    '''unknown''' -- MAC address belongs to an unknown device
+
*    <var>mesh</var> -- MAC address belongs to a device reachable over the mesh network; it can be either internal or external to the mesh network
 +
*    <var>neighbor</var> -- MAC address belongs to a mesh router that is direct neighbor to this router
 +
*    <var>larval</var> -- MAC address belongs to an unknown device that is reachable over the mesh network
 +
*    <var>unknown</var> -- MAC address belongs to an unknown device
 +
}}
  
'''mesh''' (interface name) -- the mesh interface this FDB entry belongs to
+
{{Mr-arg-ro-table
 +
|arg=mesh
 +
|type=interface name
 +
|desc=the mesh interface this FDB entry belongs to
 +
}}
  
'''on-interface''' (interface name) -- mesh port used for traffic forwarding, kind of a next-hop value
+
{{Mr-arg-ro-table
 +
|arg=on-interface
 +
|type=interface name
 +
|desc=mesh port used for traffic forwarding, kind of a next-hop value
 +
}}
  
'''lifetime''' (time) -- time remaining to live if this entry is not used for traffic forwarding  
+
{{Mr-arg-ro-table
 +
|arg=lifetime
 +
|type=time
 +
|desc=time remaining to live if this entry is not used for traffic forwarding
 +
}}
  
'''age''' (time) -- age of this FDB entry
+
{{Mr-arg-ro-table
 +
|arg=age
 +
|type=time
 +
|desc=age of this FDB entry
 +
}}
  
'''metric''' (integer) -- metric value used by routing protocol to determine the 'best' path
+
{{Mr-arg-ro-table-end
 +
|arg=metric
 +
|type=integer
 +
|desc=metric value used by routing protocol to determine the 'best' path
 +
}}
  
=== Additional wireless configuration ===
+
== Additional wireless configuration ==
  
 
Use '''wds-default-cost''' and '''wds-cost-range''' wireless interface parameters for controlling the metric that is used in the routing protocol. The WDS cost will be used as '''path-cost''' for ports dynamically added to the mesh interface.
 
Use '''wds-default-cost''' and '''wds-cost-range''' wireless interface parameters for controlling the metric that is used in the routing protocol. The WDS cost will be used as '''path-cost''' for ports dynamically added to the mesh interface.
Line 102: Line 271:
 
[[Image:mesh_ex1.jpg]]  
 
[[Image:mesh_ex1.jpg]]  
  
This example uses static WDS links that are dynamically added as mesh ports when they become active. Two different frequencies are used: one for AP interconnections, and one for client connections to APs, so the AP must have at least two wireless interfaces.
+
This example uses static WDS links that are dynamically added as mesh ports when they become active. Two different frequencies are used: one for AP interconnections, and one for client connections to APs, so the AP must have at least two wireless interfaces. Of course, the same frequency for all connections also could be used, but that might not work as good because of potential interference issues.
  
 
Repeat this configuration on all APs:
 
Repeat this configuration on all APs:
Line 112: Line 281:
 
  &nbsp;
 
  &nbsp;
 
  # interface used for AP interconnections  
 
  # interface used for AP interconnections  
  /interface wireless set wlan1 disabled=no ssid=mesh frequency=2437 band=2.4ghz-b/g mode=ap-bridge \
+
  /interface wireless set wlan1 disabled=no ssid=mesh frequency=2437 band=2.4ghz-b/g/n mode=ap-bridge \
 
   wds-mode=static-mesh wds-default-bridge=mesh1
 
   wds-mode=static-mesh wds-default-bridge=mesh1
 
  &nbsp;
 
  &nbsp;
 
  # interface used for client connections
 
  # interface used for client connections
  /interface wireless set wlan2 disabled=no ssid=mesh-clients frequency=5180 band=5ghz mode=ap-bridge  
+
  /interface wireless set wlan2 disabled=no ssid=mesh-clients frequency=5180 band=5ghz-a/n/ac mode=ap-bridge  
 
  &nbsp;
 
  &nbsp;
 
  # a static WDS interface for each AP you want to connect to
 
  # a static WDS interface for each AP you want to connect to
Line 122: Line 291:
 
   wds-address=<MAC address of remote end>
 
   wds-address=<MAC address of remote end>
  
Note that here WDS interface is added manually, because static WDS mode is used. If you are using '''wds-mode'''=dynamic-mesh, all WDS interfaces will be created automatically.
+
Here WDS interface is added manually, because static WDS mode is used. If you are using '''wds-mode'''=dynamic-mesh, all WDS interfaces will be created automatically. The '''frequency''' and '''band''' parameters are specified here only to produce valid example configuration; mesh protocol operations is by no means limited to, or optimized for, these particular values.
 +
 
 +
{{Note|You may want to increase '''disconnect-timeout''' wireless interface option to make the protocol more stable.}}
  
In real world setups you also should take care of securing the wireless connections, using '''/interface wireless security-profile'''. For simplicity that configuration it's not shown here.
+
In real world setups you also should take care of securing the wireless connections, using '''/interface wireless security-profile'''. For simplicity that configuration is not shown here.
  
Results on router A (there is one client is connected to wlan2):
+
Results on router A (there is one client connected to wlan2):
  
  [admin@A] > /interface mesh pr
+
  [admin@A] > /interface mesh print
 
  Flags: X - disabled, R - running
 
  Flags: X - disabled, R - running
 
   0  R name="mesh1" mtu=1500 arp=enabled mac-address=00:0C:42:0C:B5:A4 auto-mac=yes
 
   0  R name="mesh1" mtu=1500 arp=enabled mac-address=00:0C:42:0C:B5:A4 auto-mac=yes
Line 136: Line 307:
 
       hwmp-rann-propagation-delay=1s hwmp-rann-lifetime=22s
 
       hwmp-rann-propagation-delay=1s hwmp-rann-lifetime=22s
 
  &nbsp;
 
  &nbsp;
  [admin@A] > interface mesh port p detail
+
  [admin@A] > /interface mesh port print detail
 
  Flags: X - disabled, I - inactive, D - dynamic
 
  Flags: X - disabled, I - inactive, D - dynamic
 
   0    interface=wlan1 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
 
   0    interface=wlan1 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
Line 143: Line 314:
 
   3  D interface=router_D mesh=mesh1 path-cost=76 hello-interval=10s port-type=auto port-type-used=WDS
 
   3  D interface=router_D mesh=mesh1 path-cost=76 hello-interval=10s port-type=auto port-type-used=WDS
  
The FDB (Forwarding Database) at the moment contains information only about local MAC addresses, non-mesh nodes reachable through local interface, and direct mesh neighbors:
+
The FDB (Forwarding Database) at the moment contains information only about local MAC addresses, non-mesh nodes reachable through local interface and direct mesh neighbors:
  
  [admin@A] /interface mesh> fdb print
+
  [admin@A] /interface mesh fdb print
 
  Flags: A - active, R - root
 
  Flags: A - active, R - root
 
     MESH        TYPE    MAC-ADDRESS      ON-INTERFACE      LIFETIME    AGE
 
     MESH        TYPE    MAC-ADDRESS      ON-INTERFACE      LIFETIME    AGE
Line 154: Line 325:
 
  A  mesh1      local    00:0C:42:0C:B5:A4                                2m56s
 
  A  mesh1      local    00:0C:42:0C:B5:A4                                2m56s
 
  &nbsp;
 
  &nbsp;
  [admin@A] /interface mesh> fdb print detail
+
  [admin@A] /interface mesh fdb print detail
 
  Flags: A - active, R - root
 
  Flags: A - active, R - root
 
   A  mac-address=00:0C:42:00:00:AA type=local age=3m21s mesh=mesh1 metric=0
 
   A  mac-address=00:0C:42:00:00:AA type=local age=3m21s mesh=mesh1 metric=0
Line 166: Line 337:
 
   A  mac-address=00:0C:42:0C:B5:A4 type=local age=3m mesh=mesh1 metric=0 seqnum=0
 
   A  mac-address=00:0C:42:0C:B5:A4 type=local age=3m mesh=mesh1 metric=0 seqnum=0
  
Test that ping works:
+
Test if ping works:
 
  [admin@A] > /ping 00:0C:42:00:00:CC
 
  [admin@A] > /ping 00:0C:42:00:00:CC
 
  00:0C:42:00:00:CC 64 byte ping time=108 ms
 
  00:0C:42:00:00:CC 64 byte ping time=108 ms
Line 175: Line 346:
 
  round-trip min/avg/max = 39/60.2/108 ms
 
  round-trip min/avg/max = 39/60.2/108 ms
  
Router A had to discover path to Router C first, hence the slightly larger time for the first ping.
+
Router A had to discover path to Router C first, hence the slightly larger time for the first ping. Now the FDB also contains an entry for 00:0C:42:00:00:CC, with type "mesh".
  
 
Also test that ARP resolving works and so does IP level ping:
 
Also test that ARP resolving works and so does IP level ping:
Line 184: Line 355:
 
  3 packets transmitted, 3 packets received, 0% packet loss
 
  3 packets transmitted, 3 packets received, 0% packet loss
 
  round-trip min/avg/max = 46/85.6/163 ms
 
  round-trip min/avg/max = 46/85.6/163 ms
 +
 +
=== Mesh traceroute ===
 +
 +
There is also mesh traceroute command, that can help you to determine which paths are used for routing.
 +
 +
For example, for this network:
 +
[admin@1] /interface mesh fdb print
 +
Flags: A - active, R - root
 +
    MESH        TYPE    MAC-ADDRESS      ON-INTERFACE      LIFETIME    AGE
 +
A  mesh1      local    00:0C:42:00:00:01                                7m1s
 +
A  mesh1      mesh    00:0C:42:00:00:02 wds4              17s          4s
 +
A  mesh1      mesh    00:0C:42:00:00:12 wds4              4m58s        1s
 +
A  mesh1      mesh    00:0C:42:00:00:13 wds4              19s          2s
 +
A  mesh1      neighbor 00:0C:42:00:00:16 wds4                            7m1s
 +
A  mesh1      mesh    00:0C:42:00:00:24 wds4              18s          3s
 +
 +
Traceroute to 00:0C:42:00:00:12 shows:
 +
[admin@1] /interface mesh traceroute mesh1 00:0C:42:00:00:12
 +
ADDRESS          TIME        STATUS
 +
00:0C:42:00:00:16 1ms          ttl-exceeded
 +
00:0C:42:00:00:02 2ms          ttl-exceeded
 +
00:0C:42:00:00:24 4ms          ttl-exceeded
 +
00:0C:42:00:00:13 6ms          ttl-exceeded
 +
00:0C:42:00:00:12 6ms          success
  
 
== Protocol description ==
 
== Protocol description ==
Line 193: Line 388:
 
[[Image:hwmp_reactive_b.png|center|thumb|520px|Router C sends unicast response to A]]
 
[[Image:hwmp_reactive_b.png|center|thumb|520px|Router C sends unicast response to A]]
  
In reactive mode HWMP+ is very much like AODV (Ad-hoc On-demand Distance Vector). All path are discovered on demand, by flooding Path Request (PREQ) message in the network. The destination node or some router that has a path to the destionation will reply with a Path Response (PREP). Note that if the destination address belongs to a client, the AP this client is connected to will serve as proxy for him (i.e. reply to PREQs on his behalf).
+
In reactive mode HWMP+ is very much like AODV (Ad-hoc On-demand Distance Vector). All paths are discovered on demand, by flooding Path Request (PREQ) message in the network. The destination node or some router that has a path to the destination will reply with a Path Response (PREP). Note that if the destination address belongs to a client, the AP this client is connected to will serve as a proxy for him (i.e. reply to PREQs on his behalf).
  
 
This mode is best suited for mobile networks, and/or when most of the communication happens between intra-mesh nodes.
 
This mode is best suited for mobile networks, and/or when most of the communication happens between intra-mesh nodes.
Line 207: Line 402:
 
The portals will announce their presence by flooding Root Announcement (RANN) message in the network. Internal nodes will reply with a Path Registration (PREG) message. The result of this process will be routing trees with roots in the portal.
 
The portals will announce their presence by flooding Root Announcement (RANN) message in the network. Internal nodes will reply with a Path Registration (PREG) message. The result of this process will be routing trees with roots in the portal.
  
Routes to portals will serve as a kind of default routes. If an internal router does not know path to a particular destination, it will forward all data to its closest portal. The portal will then discover path on behalf of the router, if needed. The data afterwards will flow through the portal. This may lead to suboptimal routing, unless the data is addressed to the portal itself or some external network the portals has interfaces to.
+
Routes to portals will serve as a kind of default route. If an internal router does not know path to a particular destination, it will forward all data to its closest portal. The portal will then discover path on behalf of the router, if needed. The data afterwards will flow through the portal. This may lead to sub-optimal routing, unless the data is addressed to the portal itself or some external network the portals has interfaces to.
  
 
Proactive mode is best suited when most of traffic goes between internal mesh nodes and a few portal nodes.
 
Proactive mode is best suited when most of traffic goes between internal mesh nodes and a few portal nodes.
Line 229: Line 424:
 
A. The route with best metric is always selected after the discovery process. There is also a configuration option to periodically reoptimize already known routes.
 
A. The route with best metric is always selected after the discovery process. There is also a configuration option to periodically reoptimize already known routes.
  
Route metric is calculated as sum of individual link metrics.
+
Route metric is calculated as the sum of individual link metrics.
  
 
Link metric is calculated in the same way as for (R)STP protocols:
 
Link metric is calculated in the same way as for (R)STP protocols:
* For Ethernet links the metric is configured statically (like for OSPF, for example).
+
* For Ethernet links the metric is configured statically (same as for OSPF, for example).
 
* For WDS links the metric is updated dynamically depending on actual link bandwidth, which in turn is influenced by wireless signal strength, and the selected data transfer rate.
 
* For WDS links the metric is updated dynamically depending on actual link bandwidth, which in turn is influenced by wireless signal strength, and the selected data transfer rate.
  
Line 240: Line 435:
  
 
A. WDS networks usually are bridged, not routed. The ability to self-configure is important for mesh networks; and routing generally requires much more configuration than bridging.
 
A. WDS networks usually are bridged, not routed. The ability to self-configure is important for mesh networks; and routing generally requires much more configuration than bridging.
Of you course, you always can run any L3 routing protocol over a bridged network, but for mesh networks that usually makes little sense.
+
Of course, you can always run any L3 routing protocol over a bridged network, but for mesh networks that usually makes little sense.
 +
<br />
 +
{{Note|Since optimized layer-2 multicast forwarding is not included in the mesh protocol, it is better to avoid forwarding any multicast traffic (including OSPF) over meshed networks. If you need OSPF, then you have to configure [[OSPF-reference#NBMA_Neighbor | OSPF NBMA]] neighbors that uses unicast mode instead.}}
  
 
'''Q. What about performance/CPU requirements?'''
 
'''Q. What about performance/CPU requirements?'''
Line 248: Line 445:
 
'''Q. How does it work together with existing mesh setups that are using RSTP?'''
 
'''Q. How does it work together with existing mesh setups that are using RSTP?'''
  
A. The internal structure of a mesh network that is running HWMP is transparent to RSTP. It will see the path between two entry points in network a a single segment.
+
A. The internal structure of a RSTP network is transparent to the mesh protocol (because mesh hello packets are forwarded inside RSTP network). The mesh will see the path between two entry points in the RSTP network as a single segment. On the other hand, a mesh network is not transparent to the RSTP, since RSTP hello packets are not be forwarded inside the mesh network. ''(This is the behaviour since v3.26)''
 +
 
 +
{{Warning|Routing loops are possible, if a mesh network is attached to a RSTP network in two or more points!}}
  
Note that if you have a WDS link between two access points, then both ends must have the same configuration (should be either in a mesh on both  
+
Note that if you have a WDS link between two access points, then both ends must have the same configuration (either as ports in a mesh on both ends, or as ports in a bridge interface on both ends).
ends; or in a bridge interface on both ends)
 
  
Since RouterOS version 3.10 you can put a bridge interface as a mesh port. This way you can combine both technologies on a single router.
+
You can also put a bridge interface as a mesh port (to be able to use bridge firewall, for example).
  
 
'''Q. Can I have multiple entry/exit points to the network?'''
 
'''Q. Can I have multiple entry/exit points to the network?'''
Line 263: Line 461:
 
A. At the moment the only way is to use bridge firewall. Create a bridge interface, put the WDS interfaces and/or Ethernets in that bridge, and put that bridge in a mesh interface. Then configure bridge firewall rules.
 
A. At the moment the only way is to use bridge firewall. Create a bridge interface, put the WDS interfaces and/or Ethernets in that bridge, and put that bridge in a mesh interface. Then configure bridge firewall rules.
  
To match MAC protocol used for mesh traffic encapsulation, use protocol number 0x9AAA.
+
To match MAC protocol used for mesh traffic encapsulation, use MAC protocol number 0x9AAA, and to match mesh routing traffic, use MAC protocol number 0x9AAB. Example:
 +
interface bridge settings set use-ip-firewall=yes
 +
interface bridge filter add chain=input action=log mac-protocol=0x9aaa
 +
interface bridge filter add chain=input action=log mac-protocol=0x9aab
  
Note that it is perfectly possible to create mixed mesh/bridge setups that will not work (e.g. ''Problematic example 1'' with bridge instead of switch). The recommended fail-safe way that will always work is to create a separate bridge interface per each physical interfaces; then add all these bridge interfaces as mesh ports.
+
Note that it is perfectly possible to create mixed mesh/bridge setups that will not work (e.g. ''Problematic example 1'' with bridge instead of switch). The recommended fail-safe way that will always work is to create a separate bridge interface per each of the physical interfaces; then add all these bridge interfaces as mesh ports.
  
 
<small>
 
<small>
Line 271: Line 472:
 
== Advanced topics ==
 
== Advanced topics ==
  
We all know that it's easy to make problematic layer-2 bridging or routing setups and hard to debug them. (Compared to layer-3 routing setups.) So there are a few bad configuration examples which could create problems for you. Avoid them!
+
We all know that it's easy to make problematic layer-2 bridging or routing setups and it can be hard to debug them. (Compared to layer-3 routing setups.) So here are a few bad configuration examples which could create problems for you. Avoid them!
  
 
=== Problematic example 1: Ethernet switch inside a mesh ===
 
=== Problematic example 1: Ethernet switch inside a mesh ===
Line 277: Line 478:
 
[[Image:mesh_bad_ex1.jpg]]  
 
[[Image:mesh_bad_ex1.jpg]]  
  
''Router A is outside the mesh, all the rest of routers: inside. For routers B, C, D all interfaces are added as mesh ports.''
+
''Router A is outside the mesh, all the rest of the routers are inside. For routers B, C, D all interfaces are added as mesh ports.''
  
 
Router A will not be able to communicate reliably with router C. The problem manifests itself when D is the designated router for Ethernet; if B takes this role, everything is OK. The main cause of the problem is MAC address learning on Ethernet switch.
 
Router A will not be able to communicate reliably with router C. The problem manifests itself when D is the designated router for Ethernet; if B takes this role, everything is OK. The main cause of the problem is MAC address learning on Ethernet switch.
  
Consider what happens when router A wants to send something to C. We suppose router A either knowns or floods data to all interfaces. Either way, data arrives at switch. The switch, not knowing anything about destination's MAC address, forwards to data both to B and D.
+
Consider what happens when router A wants to send something to C. We suppose router A either knowns or floods data to all interfaces. Either way, data arrives at switch. The switch, not knowing anything about destination's MAC address, forwards the data to both B and D.
  
 
What happens now:
 
What happens now:
# B receives the packet on a mesh interface. Since the MAC address is not local for B, and B knows that he is not the designated router for the Ethernet network, he simply ignores the packet.
+
# B receives the packet on a mesh interface. Since the MAC address is not local for B and B knows that he is not the designated router for the Ethernet network, he simply ignores the packet.
# D receives the packet on a mesh interface. Since the MAC address is not local for B, and D is the designated router for the Ethernet network, he initiates path discovery process to C.
+
# D receives the packet on a mesh interface. Since the MAC address is not local for B and D is the designated router for the Ethernet network, he initiates path discovery process to C.
  
After path discovery is completed, D has information that C is reachable over B. Now D encapsulates the packet and forwards back to Ethernet network. The encapsulated packet forwarded by switch, received and forwarded by B, and received by C. So far everything is good.
+
After path discovery is completed, D has information that C is reachable over B. Now D encapsulates the packet and forwards it back to the Ethernet network. The encapsulated packet is forwarded by the switch, received and forwarded by B and received by C. So far everything is good.
  
Now C is likely to respond to the packet. Since B already knows where A is, he will decapsulate and forward the reply packet. But now switch will learn that the MAC address of C is reachable through B! That means, next time when something arrives from A addressed to C, the switch will forward data ''only'' to B. (And B, of course, will silently ignore the packet).
+
Now C is likely to respond to the packet. Since B already knows where A is, he will decapsulate and forward the reply packet. But now the switch will learn that the MAC address of C is reachable through B! That means, next time when something arrives from A addressed to C, the switch will forward data ''only'' to B (and B, of course, will silently ignore the packet)!
  
 
In contrast, if B took up the role of designated router, everything would be OK, because traffic would not have to go through the Ethernet switch twice.
 
In contrast, if B took up the role of designated router, everything would be OK, because traffic would not have to go through the Ethernet switch twice.
  
'''''Troubleshooting''''': either avoid such setup or disable MAC address learning on the switch. Note that on many switches it's not possible.
+
'''''Troubleshooting''''': either avoid such setup or disable MAC address learning on the switch. Note that on many switches that is not possible.
 +
 
 +
Also note that there will be no problem, if either:
 +
* router A supports and is configured to use HWMP+;
 +
* or Ethernet switch is replaced with a router that supports HWMP+ and has Ethernet interfaces added as mesh ports.
  
 
=== Problematic example 2: wireless modes ===
 
=== Problematic example 2: wireless modes ===
  
''Consider this setup (invalid)'':
+
''Consider this (invalid) setup example'':
  
 
[[Image:mesh_bad_ex2.jpg]]  
 
[[Image:mesh_bad_ex2.jpg]]  
  
''Routers A and B are inside the mesh, routers C: outside. For routers A and B all interfaces are added as mesh ports.''
+
''Routers A and B are inside the mesh, router C: outside. For routers A and B all interfaces are added as mesh ports.''
  
It is not possible to bridge wlan1 and wlan2 on router B now. The reason for this is pretty obvious if you understand how WDS works. For WDS communications four address frames are used. This is because for wireless multihop forwarding you need to know both the addresses of intermediate hops, as well as the original sender and final receiver. In contrast, non-WDS 802.11 communication includes only three MAC addresses in a frame. That's why it's not possible to do multihop forwarding in station mode.
+
It is not possible to bridge wlan1 and wlan2 on router B now. The reason for this is pretty obvious if you understand how WDS works. For WDS communications four address frames are used. This is because for wireless multihop forwarding you need to know both the addresses of the intermediate hops, as well as the original sender and final receiver. In contrast, non-WDS 802.11 communication includes only three MAC addresses in a frame. That's why it's not possible to do multihop forwarding in station mode.
  
 
'''''Troubleshooting''''': depends on what you want to achieve:
 
'''''Troubleshooting''''': depends on what you want to achieve:
# If you want to router C as a repeater either for wireless or Ethernet traffic, configure WDS link between router B and router C, and run mesh routing protocol on all nodes.
+
# If you want router C to act as a repeater either for wireless or Ethernet traffic, configure WDS link between router B and router C, and run mesh routing protocol on all nodes.
# In other cases configure wlan2 on router B in AP mode, and wlan on router C in station mode.
+
# In other cases configure wlan2 on router B in AP mode and wlan on router C in station mode.
  
 
</small>
 
</small>
  
==== See also: ====
+
== Further Reading ==
* [http://mum.mikrotik.com/presentations/BR08/Brasil_Mesh_Maia.pdf A presentation about mesh networks and MikroTik (in Portuguese!)]
+
* [http://mum.mikrotik.com/presentations/BR08/Brasil_Mesh_Maia.pdf A presentation about mesh networks and MikroTik ''(in Portuguese)'']
 +
* [http://tiktube.com/?video=lLdI3eplbnlIEHFqLmDyJvLwJlpoDqKH= HWMP+ based MESH networks by Bartlomiej Rodek (Inter Projekt, Poland) at MUM PL 2010''(in English)'']
  
[[Category: Routing]]
+
[[Category:Routing]]
 +
[[Category:Wireless]]
 +
[[Category:Manual]]

Latest revision as of 14:34, 24 October 2018

Version.png

Applies to RouterOS: 3, v4+

Summary

Sub-menu: /interface mesh


HWMP+ is a MikroTik specific layer-2 routing protocol for wireless mesh networks. It is based on Hybrid Wireless Mesh Protocol (HWMP) from IEEE 802.11s draft standard. It can be used instead of (Rapid) Spanning Tree protocols in mesh setups to ensure loop-free optimal routing.

The HWMP+ protocol however is not compatible with HWMP from IEEE 802.11s draft standard.

Note that the distribution system you use for your network need not to be Wireless Distribution System (WDS). HWMP+ mesh routing supports not only WDS interfaces, but also Ethernet interfaces inside the mesh. So you can use simple Ethernet based distribution system, or you can combine both WDS and Ethernet links!

Icon-note.png

Note: Prerequisites for this article: you understand what WDS is and why to use it!
Software versions: 3.28+ (earlier versions are incompatible)


Mesh Properties

Property Description
admin-mac (MAC address; Default: 00:00:00:00:00:00) administratively assigned MAC address, used when auto-mac setting is disabled
arp (disabled | enabled | proxy-arp | reply-only; Default: enabled) Address Resolution Protocol setting
auto-mac (boolean; Default: no) if disabled, then value from admin-mac will be used as the MAC address of the mesh interface; else address of some port will be used if ports are present
hwmp-default-hoplimit (integer: 1..255; Default: ) maximum hop count for generated routing protocol packets; after a HWMP+ packet is forwarded "hoplimit" times, it is dropped
hwmp-prep-lifetime (time; Default: 5m) lifetime for routes created from received PREP or PREQ messages
hwmp-preq-destination-only (boolean; Default: yes) whether only destination can respond to HWMP+ PREQ message
hwmp-preq-reply-and-forward (boolean; Default: yes) whether intermediate nodes should forward HWMP+ PREQ message after responding to it. Useful only when hwmp-preq-destination-only is disabled
hwmp-preq-retries (integer; Default: 2) how many times to retry a route discovery to a specific MAC address before the address is considered unreachable
hwmp-preq-waiting-time (time; Default: 4s) how long to wait for a response to the first PREQ message. Note that for subsequent PREQs the waiting time is increased exponentially
hwmp-rann-interval (time; Default: 10s) how often to send out HWMP+ RANN messages
hwmp-rann-lifetime (time; Default: 1s) lifetime for routes created from received RANN messages
hwmp-rann-propagation-delay (number; Default: 0.5) how long to wait before propagating a RANN message. Value in seconds
mesh-portal (boolean; Default: no) whether this interface is a portal in the mesh network
mtu (number; Default: 1500) maximum transmission unit size
name (string; Default: ) interface name
reoptimize-paths (boolean; Default: no) whether to send out periodic PREQ messages asking for known MAC addresses. Turing on this setting is useful if network topology is changing often. Note that if no reply is received to a reoptimization PREQ, the existing path is kept anyway (until it timeouts itself)


Configure mesh interface ports

Sub-menu: /interface mesh port

Port Properties

Property Description
active-port-type (read-only: wireless | WDS | ethernet-mesh | ethernet-bridge | ethernet-mixed; Default: ) port type and state actually used
hello-interval (time; Default: 10s) maximum interval between sending out HWMP+ Hello messages. Used only for Ethernet type ports
interface (interface name; Default: ) interface name, which is to be included in a mesh
mesh (interface name; Default: ) mesh interface this port belongs to
path-cost (integer: 0..65535; Default: 10) path cost to the interface, used by routing protocol to determine the 'best' path
port-type (WDS | auto | ethernet | wireless; Default: ) port type to use
  • auto - port type is determined automatically based on the underlying interface's type
  • WDS - a Wireless Distribution System interface. Remote MAC address is learnt from wireless connection data
  • ethernet - Remote MAC addresses are learnt either from HWMP+ Hello messages or from source MAC addresses in received or forwarded traffic
  • wireless - Remote MAC addresses are learnt from wireless connection data


Mesh fdb Status

Sub-menu: /interface mesh fdb


Properties:

Property Description
mac-address (MAC address) MAC address corresponding for this FDB entry
seq-number (integer) sequence number used in routing protocol to avoid loops
type (integer) sequence number used in routing protocol to avoid loops
interface (local | outsider | direct | mesh | neighbor | larval | unknown) type of this FDB entry
  • local -- MAC address belongs to the local router itself
  • outsider -- MAC address belongs to a device external to the mesh network
  • direct -- MAC address belongs to a wireless client on an interface that is in the mesh network
  • mesh -- MAC address belongs to a device reachable over the mesh network; it can be either internal or external to the mesh network
  • neighbor -- MAC address belongs to a mesh router that is direct neighbor to this router
  • larval -- MAC address belongs to an unknown device that is reachable over the mesh network
  • unknown -- MAC address belongs to an unknown device
mesh (interface name) the mesh interface this FDB entry belongs to
on-interface (interface name) mesh port used for traffic forwarding, kind of a next-hop value
lifetime (time) time remaining to live if this entry is not used for traffic forwarding
age (time) age of this FDB entry
metric (integer) metric value used by routing protocol to determine the 'best' path

Additional wireless configuration

Use wds-default-cost and wds-cost-range wireless interface parameters for controlling the metric that is used in the routing protocol. The WDS cost will be used as path-cost for ports dynamically added to the mesh interface.

Example

Mesh ex1.jpg

This example uses static WDS links that are dynamically added as mesh ports when they become active. Two different frequencies are used: one for AP interconnections, and one for client connections to APs, so the AP must have at least two wireless interfaces. Of course, the same frequency for all connections also could be used, but that might not work as good because of potential interference issues.

Repeat this configuration on all APs:

/interface mesh add disabled=no
 
/interface mesh port add interface=wlan1 mesh=mesh1
 
/interface mesh port add interface=wlan2 mesh=mesh1
 
# interface used for AP interconnections 
/interface wireless set wlan1 disabled=no ssid=mesh frequency=2437 band=2.4ghz-b/g/n mode=ap-bridge \
  wds-mode=static-mesh wds-default-bridge=mesh1
 
# interface used for client connections
/interface wireless set wlan2 disabled=no ssid=mesh-clients frequency=5180 band=5ghz-a/n/ac mode=ap-bridge 
 
# a static WDS interface for each AP you want to connect to
/interface wireless wds add disabled=no master-interface=wlan1 name=<descriptive name of remote end> \
  wds-address=<MAC address of remote end>

Here WDS interface is added manually, because static WDS mode is used. If you are using wds-mode=dynamic-mesh, all WDS interfaces will be created automatically. The frequency and band parameters are specified here only to produce valid example configuration; mesh protocol operations is by no means limited to, or optimized for, these particular values.

Icon-note.png

Note: You may want to increase disconnect-timeout wireless interface option to make the protocol more stable.


In real world setups you also should take care of securing the wireless connections, using /interface wireless security-profile. For simplicity that configuration is not shown here.

Results on router A (there is one client connected to wlan2):

[admin@A] > /interface mesh print
Flags: X - disabled, R - running
 0  R name="mesh1" mtu=1500 arp=enabled mac-address=00:0C:42:0C:B5:A4 auto-mac=yes
      admin-mac=00:00:00:00:00:00 mesh-portal=no hwmp-default-hoplimit=32
      hwmp-preq-waiting-time=4s hwmp-preq-retries=2 hwmp-preq-destination-only=yes
      hwmp-preq-reply-and-forward=yes hwmp-prep-lifetime=5m hwmp-rann-interval=10s
      hwmp-rann-propagation-delay=1s hwmp-rann-lifetime=22s
 
[admin@A] > /interface mesh port print detail
Flags: X - disabled, I - inactive, D - dynamic
 0    interface=wlan1 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
 1    interface=wlan2 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
 2  D interface=router_B mesh=mesh1 path-cost=105 hello-interval=10s port-type=auto port-type-used=WDS
 3  D interface=router_D mesh=mesh1 path-cost=76 hello-interval=10s port-type=auto port-type-used=WDS

The FDB (Forwarding Database) at the moment contains information only about local MAC addresses, non-mesh nodes reachable through local interface and direct mesh neighbors:

[admin@A] /interface mesh fdb print
Flags: A - active, R - root
   MESH        TYPE     MAC-ADDRESS       ON-INTERFACE       LIFETIME     AGE
A  mesh1       local    00:0C:42:00:00:AA                                 3m17s
A  mesh1       neighbor 00:0C:42:00:00:BB router_B                        1m2s
A  mesh1       neighbor 00:0C:42:00:00:DD router_D                        3m16s
A  mesh1       direct   00:0C:42:0C:7A:2B wlan2                           2m56s
A  mesh1       local    00:0C:42:0C:B5:A4                                 2m56s
 
[admin@A] /interface mesh fdb print detail
Flags: A - active, R - root
 A  mac-address=00:0C:42:00:00:AA type=local age=3m21s mesh=mesh1 metric=0
     seqnum=4294967196
 A  mac-address=00:0C:42:00:00:BB type=neighbor on-interface=router_B age=1m6s
    mesh=mesh1 metric=132 seqnum=4294967196
 A  mac-address=00:0C:42:00:00:DD type=neighbor on-interface=router_D age=3m20s
     mesh=mesh1 metric=79 seqnum=4294967196
 A  mac-address=00:0C:42:0C:7A:2B type=direct on-interface=wlan2 age=3m mesh=mesh1
     metric=10 seqnum=0
 A  mac-address=00:0C:42:0C:B5:A4 type=local age=3m mesh=mesh1 metric=0 seqnum=0

Test if ping works:

[admin@A] > /ping 00:0C:42:00:00:CC
00:0C:42:00:00:CC 64 byte ping time=108 ms
00:0C:42:00:00:CC 64 byte ping time=51 ms
00:0C:42:00:00:CC 64 byte ping time=39 ms
00:0C:42:00:00:CC 64 byte ping time=43 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 39/60.2/108 ms

Router A had to discover path to Router C first, hence the slightly larger time for the first ping. Now the FDB also contains an entry for 00:0C:42:00:00:CC, with type "mesh".

Also test that ARP resolving works and so does IP level ping:

[admin@A] > /ping 10.4.0.3
10.4.0.3 64 byte ping: ttl=64 time=163 ms
10.4.0.3 64 byte ping: ttl=64 time=46 ms
10.4.0.3 64 byte ping: ttl=64 time=48 ms
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 46/85.6/163 ms

Mesh traceroute

There is also mesh traceroute command, that can help you to determine which paths are used for routing.

For example, for this network:

[admin@1] /interface mesh fdb print
Flags: A - active, R - root
   MESH        TYPE     MAC-ADDRESS       ON-INTERFACE       LIFETIME     AGE
A  mesh1       local    00:0C:42:00:00:01                                 7m1s
A  mesh1       mesh     00:0C:42:00:00:02 wds4               17s          4s
A  mesh1       mesh     00:0C:42:00:00:12 wds4               4m58s        1s
A  mesh1       mesh     00:0C:42:00:00:13 wds4               19s          2s
A  mesh1       neighbor 00:0C:42:00:00:16 wds4                            7m1s
A  mesh1       mesh     00:0C:42:00:00:24 wds4               18s          3s

Traceroute to 00:0C:42:00:00:12 shows:

[admin@1] /interface mesh traceroute mesh1 00:0C:42:00:00:12
ADDRESS           TIME         STATUS
00:0C:42:00:00:16 1ms          ttl-exceeded
00:0C:42:00:00:02 2ms          ttl-exceeded
00:0C:42:00:00:24 4ms          ttl-exceeded
00:0C:42:00:00:13 6ms          ttl-exceeded
00:0C:42:00:00:12 6ms          success

Protocol description

Reactive mode

Router A wants to discover path to C
Router C sends unicast response to A

In reactive mode HWMP+ is very much like AODV (Ad-hoc On-demand Distance Vector). All paths are discovered on demand, by flooding Path Request (PREQ) message in the network. The destination node or some router that has a path to the destination will reply with a Path Response (PREP). Note that if the destination address belongs to a client, the AP this client is connected to will serve as a proxy for him (i.e. reply to PREQs on his behalf).

This mode is best suited for mobile networks, and/or when most of the communication happens between intra-mesh nodes.

Proactive mode

The root announces itself by flooding RANN
Internal nodes respond with PREGs

In proactive mode there are some routers configured as portals. In general being a portal means that router has interfaces to some other network,, i.e. it is entry/exit point to the mesh network.

The portals will announce their presence by flooding Root Announcement (RANN) message in the network. Internal nodes will reply with a Path Registration (PREG) message. The result of this process will be routing trees with roots in the portal.

Routes to portals will serve as a kind of default route. If an internal router does not know path to a particular destination, it will forward all data to its closest portal. The portal will then discover path on behalf of the router, if needed. The data afterwards will flow through the portal. This may lead to sub-optimal routing, unless the data is addressed to the portal itself or some external network the portals has interfaces to.

Proactive mode is best suited when most of traffic goes between internal mesh nodes and a few portal nodes.

Topology change detection

Data flow path
After link disappears, error is propagated upstream

HWMP+ uses Path Error (PERR) message to notify that a link has disappeared. The message is propagated to all upstream nodes up to the data source. The source on PERR reception restarts path discovery process.

FAQ

Q. How is this better than RSTP?

A. It gives you optimal routing. RSTP is only for loop prevention.

Q. How the route selection is done?

A. The route with best metric is always selected after the discovery process. There is also a configuration option to periodically reoptimize already known routes.

Route metric is calculated as the sum of individual link metrics.

Link metric is calculated in the same way as for (R)STP protocols:

  • For Ethernet links the metric is configured statically (same as for OSPF, for example).
  • For WDS links the metric is updated dynamically depending on actual link bandwidth, which in turn is influenced by wireless signal strength, and the selected data transfer rate.

Currently the protocol does not take in account the amount of bandwidth being used on a link, but that might be also used in future.

Q. How is this better than OSPF/RIP/layer-3 routing in general?

A. WDS networks usually are bridged, not routed. The ability to self-configure is important for mesh networks; and routing generally requires much more configuration than bridging. Of course, you can always run any L3 routing protocol over a bridged network, but for mesh networks that usually makes little sense.

Icon-note.png

Note: Since optimized layer-2 multicast forwarding is not included in the mesh protocol, it is better to avoid forwarding any multicast traffic (including OSPF) over meshed networks. If you need OSPF, then you have to configure OSPF NBMA neighbors that uses unicast mode instead.


Q. What about performance/CPU requirements?

A. The protocol itself, when properly configured, will take much less resources than OSPF (for example) would. Data forwarding performance on an individual router should be close to that of bridging.

Q. How does it work together with existing mesh setups that are using RSTP?

A. The internal structure of a RSTP network is transparent to the mesh protocol (because mesh hello packets are forwarded inside RSTP network). The mesh will see the path between two entry points in the RSTP network as a single segment. On the other hand, a mesh network is not transparent to the RSTP, since RSTP hello packets are not be forwarded inside the mesh network. (This is the behaviour since v3.26)

Icon-warn.png

Warning: Routing loops are possible, if a mesh network is attached to a RSTP network in two or more points!


Note that if you have a WDS link between two access points, then both ends must have the same configuration (either as ports in a mesh on both ends, or as ports in a bridge interface on both ends).

You can also put a bridge interface as a mesh port (to be able to use bridge firewall, for example).

Q. Can I have multiple entry/exit points to the network?

A. If the entry/exit points are configured as portals (i.e. proactive mode is used), each router inside the mesh network will select its closest portal and forward all data to it. The portal will then discover path on behalf of the router, if needed.

Q. How to control or filter mesh traffic?

A. At the moment the only way is to use bridge firewall. Create a bridge interface, put the WDS interfaces and/or Ethernets in that bridge, and put that bridge in a mesh interface. Then configure bridge firewall rules.

To match MAC protocol used for mesh traffic encapsulation, use MAC protocol number 0x9AAA, and to match mesh routing traffic, use MAC protocol number 0x9AAB. Example:

interface bridge settings set use-ip-firewall=yes
interface bridge filter add chain=input action=log mac-protocol=0x9aaa
interface bridge filter add chain=input action=log mac-protocol=0x9aab

Note that it is perfectly possible to create mixed mesh/bridge setups that will not work (e.g. Problematic example 1 with bridge instead of switch). The recommended fail-safe way that will always work is to create a separate bridge interface per each of the physical interfaces; then add all these bridge interfaces as mesh ports.

Advanced topics

We all know that it's easy to make problematic layer-2 bridging or routing setups and it can be hard to debug them. (Compared to layer-3 routing setups.) So here are a few bad configuration examples which could create problems for you. Avoid them!

Problematic example 1: Ethernet switch inside a mesh

Mesh bad ex1.jpg

Router A is outside the mesh, all the rest of the routers are inside. For routers B, C, D all interfaces are added as mesh ports.

Router A will not be able to communicate reliably with router C. The problem manifests itself when D is the designated router for Ethernet; if B takes this role, everything is OK. The main cause of the problem is MAC address learning on Ethernet switch.

Consider what happens when router A wants to send something to C. We suppose router A either knowns or floods data to all interfaces. Either way, data arrives at switch. The switch, not knowing anything about destination's MAC address, forwards the data to both B and D.

What happens now:

  1. B receives the packet on a mesh interface. Since the MAC address is not local for B and B knows that he is not the designated router for the Ethernet network, he simply ignores the packet.
  2. D receives the packet on a mesh interface. Since the MAC address is not local for B and D is the designated router for the Ethernet network, he initiates path discovery process to C.

After path discovery is completed, D has information that C is reachable over B. Now D encapsulates the packet and forwards it back to the Ethernet network. The encapsulated packet is forwarded by the switch, received and forwarded by B and received by C. So far everything is good.

Now C is likely to respond to the packet. Since B already knows where A is, he will decapsulate and forward the reply packet. But now the switch will learn that the MAC address of C is reachable through B! That means, next time when something arrives from A addressed to C, the switch will forward data only to B (and B, of course, will silently ignore the packet)!

In contrast, if B took up the role of designated router, everything would be OK, because traffic would not have to go through the Ethernet switch twice.

Troubleshooting: either avoid such setup or disable MAC address learning on the switch. Note that on many switches that is not possible.

Also note that there will be no problem, if either:

  • router A supports and is configured to use HWMP+;
  • or Ethernet switch is replaced with a router that supports HWMP+ and has Ethernet interfaces added as mesh ports.

Problematic example 2: wireless modes

Consider this (invalid) setup example:

Mesh bad ex2.jpg

Routers A and B are inside the mesh, router C: outside. For routers A and B all interfaces are added as mesh ports.

It is not possible to bridge wlan1 and wlan2 on router B now. The reason for this is pretty obvious if you understand how WDS works. For WDS communications four address frames are used. This is because for wireless multihop forwarding you need to know both the addresses of the intermediate hops, as well as the original sender and final receiver. In contrast, non-WDS 802.11 communication includes only three MAC addresses in a frame. That's why it's not possible to do multihop forwarding in station mode.

Troubleshooting: depends on what you want to achieve:

  1. If you want router C to act as a repeater either for wireless or Ethernet traffic, configure WDS link between router B and router C, and run mesh routing protocol on all nodes.
  2. In other cases configure wlan2 on router B in AP mode and wlan on router C in station mode.

Further Reading