Deploying nodes in multiple VLANs fails due to RPF filtering

Bug #1665680 reported by Mateusz Pawlowski on 2017-02-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
maas (Ubuntu)

Bug Description

MAAS is unable to deploy nodes in different VLANs even though directory connected to those VLANs.

Steps to reproduce issue:
- Configure multiple VLAN interfaces on the MAAS

root@maas-server:~# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
vlan410 | 410 | ens11
vlan440 | 440 | ens11
vlan450 | 450 | ens11

root@maas-server:~# ip addr

root@maas-server:~# ip route
default via dev vlan450 onlink dev vlan410 proto kernel scope link src dev vlan440 proto kernel scope link src dev vlan450 proto kernel scope link src

- Try to deploy node in VLAN410
- Node will be provided with PXE configuration that configures cloud-config-url to point to main IP address of the MAAS as configured in regiond.conf (maas_url:
- When node boots and cloud-init kicks in it will try to reach seed data at
- Node which is located in VLAN410 will route packets to it's gateway which finally reaches
- At this point Ubuntu 16.04 (which was used in this case) will drop those packets as default RPF setting (strict mode) is not allowing packets to be received on vlan450 if reverse path for source of the packet indicates that packet should arrive on vlan410
- In order to resolve this issue RPF strict mode has to be disabled on the server that is running MAAS
- Another way to resolve this issue is by configuring maas_url to use domain name instead of static IP (maas_url: http://maas-server.local:5240/MAAS) in regiond.conf
- Then configuring multiple A records (one record per IP of the MAAS interface) with same name maas-server.local
- That way PXE will serve configuration with cloud-config-url parameter pointing to domain name instead of static IP
- What will happen when cloud-init kicks in is that it will resolve MAAS address to multiple IP addresses and will iterate over them until it makes successful connection
- However that solution will not scale well if there is a need to configure large number of VLANs
- It would be great if MAAS could dynamically re-configure cloud-config-url with the MAAS IP in the same subnet from switch node requested configuration.

For example : If node in VLAN410 is asking for seed location then MAAS should provide PXE configuration with cloud-config-url pointing to MAAS IP in VLAN410 and not the one statically configured in regiond.conf

Please threat that bug as feature request if you decide to classify it as such.

Mateusz Pawlowski (mateuszz) wrote :
Andres Rodriguez (andreserl) wrote :


What's the output of rackd.conf vs regiond.conf ?

If rackd.conf points to localhost and regiond.conf points to a different IP address, then the metadata url will be the one of regiond.conf. To properly configure this, you need to change rackd.conf to point to an IP address.

That said, the metadata url always has to be an IP that's accessible to the machines so that the machines can always get their metadata. For example, if you pxe boot multiple vlans on the same rack controller (which is typically not reocmmended) the URL of the metadata needs to be one accessible from the various VLANs, and this is because you typically dont have the rack controller in the same VLAN.

Mateusz Pawlowski (mateuszz) wrote :


I have following entries in rackd and regiond.

root@maas-server:~# grep maas_url /etc/maas/*.conf

What would you recommend for multiple VLANs configuration ?

I think having rack controller per VLAN would be quite expensive. Is there any way to launch multiple rackd processes with different maas_url on single host ?

Mike Pontillo (mpontillo) wrote :

I would recommend using loose-mode reverse path filtering on the MAAS server for now.

Strict reverse path filtering seems like it would make a lot of sense for a border router, but little sense for an internal MAAS server.

But I agree that it makes sense to supply a cloud-config-url (and related URLs) using a directly attached subnet if possible. Right now we use the subnet to select a rack controller, and we use the rack controller to select the appropriate rack-facing subnet on the region. But I like the idea of taking a simpler approach and using an on-subnet IP address if possible.

Changed in maas:
status: New → Triaged
importance: Undecided → Wishlist
Changed in maas (Ubuntu):
status: New → Confirmed
Changed in maas (Ubuntu):
assignee: MAAS (maas) → nobody
Changed in maas:
status: Triaged → Confirmed
milestone: none → next
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments