Network Beaconing in MAAS

You might be aware that MAAS sends out multicast beacons on the network in order to infer truths about the underlying networking topology it’s running on. This post explains what beaconing in MAAS is all about.


In the past, if MAAS didn’t have a way to correlate a newly-seen interface with an existing VLAN or subnet, MAAS (knowing nothing about the actual topology) would create a fabric for each new physical interface seen on a rack controller. In MAAS 2.3, beaconing is now performed prior to final interface registration. This means that new network interfaces (even unconfigured interfaces) redundantly connected, or connected to known networks in MAAS, will be associated with the proper VLAN and fabric out-of-the-box.

How it Works

The beaconing protocol in MAAS is based on multicast UDP packets, sourced from port 5240. (The same port MAAS uses for its web interface.) Beaconing supports both IPv4 and IPv6; packets will be sent out using whatever protocol is available on each interface. The receive path operates independently, and can recognize beacons even on unconfigured interfaces (as long as the link is up).

MAAS receives beacon packets using a mechanism similar to network discovery, in that packets are received at a very low level and deeply inspected, so that any additional relevant information (such as 802.1q VLAN IDs) can be obtained. In this way, the beacon receive path is able to process beacons on networks (or VLANs) that may not even be configured, or may not even be configured with an IP address yet.

Beacons are encrypted using a key derivation algorithm based on the existing MAAS shared secret, to ensure that beacons are only valid within the same MAAS region, and cannot be easily spoofed. In addition, beacons are only valid for two minutes, which limits the ability to use them in a replay attack.

Ideas for the Future

With basic beaconing in place for the MAAS 2.3.0 release, we have some exciting ideas about how we might use the beaconing protocol might be used to further improve the MAAS user experience, including:

  • Rack registration improvements. Currently, registering a new controller in MAAS involves manually typing in a URL. This step could be eliminated, since beaconing could be used to quickly identify a MAAS server on the network, and validate that the supplied shared secret is correct.
  • Beaconing on commissioning nodes. This would allow MAAS to more accurately determine the network topology of newly-commissioned machines.
  • Local network MTU discovery. Unlike path MTU discovery (which determines how large a packet can be as it travels across a routed network), it can be more difficult to diagnose MTU issues on a local link. Beaconing packets could be used to ensure that MTU settings on the network are appropriate to allow packets of the desired size to be used.
  • Deep discovery and validation of VLAN access, by generating raw beacon packets using various VLAN IDs.