I have Dell servers with 4 NICs. Current network setup:
NIC 1 & 2 – Connected to switch-ext, VLAN 100 (172.28.0.0/16). This is the external network with DHCP and a gateway. MAAS can’t manage this subnet. It’s named External fabric in MAAS.
NIC 3 – Connected to switch-pxe, VLAN 120 (192.168.0.0/24). This subnet is managed by MAAS, providing DHCP. It’s not routed to other VLANS. In MAAS it is named PXE fabric.
NIC 4 – Connected to switch-mgmt, VLAN 1 (10.12.0.0/16). Used for management and reaching IPMI interface of the servers. MAAS should not manage this. Labelled as MGMT fabric in MAAS.
All VLANS are untagged.
I want to deploy OpenStack using Juju, but I’m unsure if the network and fabric layout is correct. Only the External fabric has internet access, so when Juju deploys applications, machines, and containers, they can’t reach the internet to fetch packages. Obviously becuase the PXE fabric doesn’t have a gateway.
I’m confused because it doesn’t seem right to place Juju-deployed workloads on the External fabric, even though it’s the only one with a gateway.
Question: How should I configure subnets and fabrics so Juju-deployed machines and containers have internet access? I feel like I’m missing a core concept.
Any advice from someone with experience would be appreciated. AI has been of no use 
Cheers.
hey, @masih-shek,
i moved your post to the “Users” category because more gurus will see it there. i’ll also bring it to the attention of someone who might be able to help.
1 Like
Hi @masih-shek
Before moving to Juju plus OpenStack deployment on top of MAAS, let’s try to fix the internet access issue. Have you considered using a static route to your switch-pxe subnet to point to switch-ext?
You could do this with the following command:
# assuming that 172.28.0.1 is the gateway of switch-ext
maas $profile static-routes create \
source=192.168.0.0/24 \
destination=172.28.0.0/16 \
gateway_ip=172.28.0.1
Hi @skatsaounis,
I didn’t consider implementing a static route. The switch-ext and switch-pxe are not physically connected and don’t have a route to each other. I thought adding a static route requires the physical switches to be connected.
I see. Please take a look at this enlightening Discourse post to introduce yourself to the concept of Juju spaces, how they are mapped with MAAS spaces, and how they can be declared to interface bindings.
Assuming that you have figured out the desired network topology for your OpenStack, you have to:
- infra-wise: connect your machines appropriately
- enlist your machines in MAAS
- (optional) pre-configure your MAAS machines with any extra network/storage configuration
- declare your MAAS spaces by adding the relevant subnets to them (i.e.,
172.28.0.0/16 goes to space external, 192.168.0.0/24 goes to space pxe, etc.). Also include any subnets you have declared in any VLAN. In general this is the time when you are declaring your soon-to-be-created OpenStack networking.
- Ensure that your spaces are loaded in Juju, and if not, re-load them - link.
- Ask Juju to deploy OpenStack charms, relate them, and provide bindings for both sides of the relation.
Juju will make sure that:
- It will place application units only on machines that their networking includes all the spaces defined in the application bindings of the units’ applications.
- It will create containers for containerized application units only on machines with networking that includes all the application bindings of the units’ applications.
- It will make sure that application units that are integrated with bindings will use only their addresses that corresponds to subnets that are part of the spaces of the bindings. This one is taken care by the charm implementation logic though, not directly by Juju.
I cannot advise you on the networking side of things, so this is yours to investigate. But with the mechanism described above, you can make sure that Juju understands your intentions for the networking and tries to deploy OpenStack in the way you are expecting it to do. As for package download during deployment, you can also consider setting MAAS as a proxy, which is the default configuration - link.
