Maas and juju subnets

juju
1

Hey,

I have maas deployed with 3 fabrics one of theses is a bond of two NIC, the other two a regular interfaces and also have a VLAN on them.

The Problem i am having now is that, one interface is connected to network where also ipv6 is enabled, so on one fabric i have looks like this

test 	untagged 	No DHCP 	ipv4 	      6%    test
		            No DHCP 	ipv6 	      100% 	test
	    2 (guest) 	No DHCP 	ipv4          100% 	guest-test

Now i want to deploy some machines on the test space, the baremetal machines and the lxd containers both getting the ipv4 and ipv6 addresses.

But when i am having something like

bindings:
  public: test

I am running into the problem that the charms i deploy there are usually configured with the ipv6 address as their public binding, so for example my keystone public api endpoint is using the ipv6 address instead of the ipv4 address, also vault only seem to be using the ipv6 address when providing certificates.

Is there any option to force using the ipv4 instead of the ipv6 address, like for example so?

bindings:
  public: test:2(provider-id)

Is there any better why to do so ? Or do I have to remove the subnet inside maas alltogether ?

2

IIRC, spaces in MAAS are a Layer 2 (VLAN) concept, so the space “test” is assigned to the ipv6 subnet and ipv4 subnet because they are both part of the untagged VLAN on that fabric.

I might suggest checking MAAS subnet editor to see if you can change the space assignment for the ipv6 subnet to unassigned or a third space.

Juju considers spaces as a layer 3 (IP) concept. You can see this with the command juju spaces which will show both the ipv4 and ipv6 subnets as part of the “test” space.

The juju charms typically utilize some framework function which calls “network-get” which provides all IPs on the host (or is filtered based on a relation or binding to limit IPs which are enumerated). This network-get function then typically is parsed by the charm developer to return the first of the addresses enumerated by the network-get command.

A related bug discussing this issue in the past can be found here. Bug #1574844 “juju2 gives ipv6 address for one lxd, rabbit doesn...” : Bugs : rabbitmq-server package : Juju Charms Collection

I think the two questions to answer to determine path to take are:

  1. Do you require MAAS to configure the static IPv6 addresses on the servers you’re deploying?
  2. Do you intend to have any services consumed via IPv6 within/across juju models?

If the answer to both of those questions is No, the best course of action would be to remove the IPv6 subnet definition from MAAS and re-sync the juju spaces from MAAS and re-deploy your model.

If you need MAAS to provide static IPv6 addresses to the deployed units, see if there’s a way to remove the space configuration from the IPv6 subnet definition either within the UI or via the MAAS CLI.

As I’m not sure this is actually possible, the next option would be to manually use the juju commands:

juju add-space test-ipv6
juju move-to-space test-ipv6 <IPv6 CIDR>

This would have to be a manually updated configuration each time after you sync spaces with MAAS if you ever add subnets/spaces or deploy new models/controllers.

You could then specify test space or test-ipv6 space in your bundles depending on the address CIDR/IP protocol you wanted to relate on/announce for each binding.

1 Like
3

Thanks for your anwser,

both subnets are on the same interfaces and they should both be untagged vlan its an allready implemented subnet with an external DHCP server.

Moving the subnet with juju to another space is not possible because they are provider managnet.

I think i will just ignore the the ipv6 then.

Thanks for your help

4

The problem still persists, even after deleting the ipv6 subnet inside maas and juju subnets not showing the ipv6 subnet, the charms still getting ipv6 addresses.

So it seems like, that if I have an interface which has a plugged in network cable or is part of a network which uses ipv4 and ipv6 than juju seems to notice that and still provide ipv6 on that interface, even if I deleted it in maas

Don’t know if this should be the case.

Edit: Even after I created a new fabric (even if thats unlogical to put the ipv6 net on another fabric, because they are on the same interface) and giving that subnet a new space, like so

test 	    untagged 	No DHCP 	ipv4 	      6%    test
	        2 (guest) 	No DHCP 	ipv4          100% 	guest-test
test -v6	untagged 	No DHCP 	ipv6	      6%    test-v6

they are still getting the ipv6 addresse, but i expected that because on the test fabric runs both ipv6 and ipv4.

5

What does juju spaces show?

I might suggest filing a bug against the specific charm announcing the IPv6 address if juju spaces looks accurate.