Deploying nodes in multiple VLANs fails due to RPF filtering

[Teluka]

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
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan410 | 410 | ens11
vlan440 | 440 | ens11
vlan450 | 450 | ens11

root@maas-server:~# ip addr
[output_attached]

root@maas-server:~# ip route
default via 192.168.50.1 dev vlan450 onlink
10.0.10.0/23 dev vlan410 proto kernel scope link src 10.0.10.250
192.168.40.0/24 dev vlan440 proto kernel scope link src 192.168.40.250
192.168.50.0/24 dev vlan450 proto kernel scope link src 192.168.50.250

- 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: http://192.168.50.250:5240/MAAS)
- When node boots and cloud-init kicks in it will try to reach seed data at 192.168.50.250
- Node which is located in VLAN410 will route packets to it's gateway which finally reaches 192.168.50.250
- 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.

[Andres Rodriguez (andreserl)]

@Mateusz

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.

[Teluka (mateusz-p)]

@Andreas

I have following entries in rackd and regiond.

root@maas-server:~# grep maas_url /etc/maas/*.conf
/etc/maas/rackd.conf:maas_url: http://192.168.50.250:5240/MAAS
/etc/maas/regiond.conf:maas_url: http://192.168.50.250:5240/MAAS

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)]

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.

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team