This contribution aims at collecting tips to fix the MAAS supervision of a cluster of four Raspberry Pi 4 addressed in IPv6.

Consider four Raspberry Pi 4 (RPi4) with PoE hats joined in a cluster. An unmanaged NetGear switch (300 series) provides them networking and power. This switch is connected to a laptop through a cross-over Ethernet cable and USB Apple Ethernet adapter. Please refer to the ASCII sketch below.

The plan is to pilot this cluster with Canonical MAAS (Metal-as-a-Service) running in a VirtualBox virtual machine, in order to exploit the cluster resources from Canonical Juju. The direct manual set-up of the cluster in Juju failed, because the cluster lacks a controller. Hence the choice for MAAS.

Within the VM, ICMPv6 Router Advertisements are sent from the USB Ethernet adapter to the cluster. The four RPi4s automatically address themselves within the fd00::/8 prefix announced. From within the VM, everything is fine from a networking point of view: the VM can ping6 the RPi4s at their fd00::/8 addresses, the RPi4s are listed in its Neighbour table.

However, the situation looks different from MAAS dashboard. MAAS acknowledges the presence of its own interface in the fd00::/8 prefix, but does not notice the RPi4s. Scanning the subnet is not possible because MAAS limits automatic scanning to IPv4 subnets.

Commissionning the RPi4s as "Machines" by listing them with their MAC addresses fails as well. This failure might be explained by the fact that the RPi4s are not ready for netboot yet. However, one would expect the IPv6 addresses of the RPi4s appear in the list of IPv6 addresses in use in the fd00::/8 subnet. Unfortunately, they don't.

In a nutshell, it looks like the cluster is duly reachable from the VM running MAAS, but not from MAAS itself.

Would you have any hint how to solve this? Thx, LS

                                                   |  ----------------  |
 --------    ----------                            | | MAAS Dashboard | |
| RPi4_1 |--|          |                           |  ----------------  | 
 --------   | NetGear  |                           |       |            |
 --------   |  5-Port  |                           |       |
| RPi4_2 |--|   PoE    |                           |       |            |
 --------   | Gigabit  |                           |   ------------     |
 --------   | Ethernet |                           |  |    |    VM |    |
| RPi4_3 |--|  Switch  |  fd00::/8   -----------   |  |   ------   |    |
 --------   |  GS305P  |------------| Apple USB |--|--|--| MAAS |  |    |
 --------   |          |            |  adapter  |  |  |   ------   |    |
| RPi4_4 |--|          |             -----------   |   ------------     |
 --------    ----------                             --------------------

Seems a rather very strange problem. My 2 eurocents : are you sure the MAAS is not playing around with a MAC address (i.e. a new random calculated MAC) ? Because I've experienced a lot of limitations with virtualization platforms that are NOT allowing the VM to receive any non virtually-assigned MAC (except for broadcast). I've seen this problem with playing around with VRRP between two pfSense virtual machines that are running CARP for failover of the routing address, and resolve the IPv4 address to the specific mac-prefix of the VRRP protocol. Regards, Didier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.