[1.9] MAAS can auto-assign a known default gateway for a subnet to a deploying node.

Bug #1690231 reported by David Lawson on 2017-05-11
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mike Pontillo
Mike Pontillo
Mike Pontillo

Bug Description

It doesn't appear that MaaS 1.x has any mechanism that allows a user to reserve IPs in a subnet defined in MaaS. We discovered this after a machine was deployed accidentally with an auto-assigned IP and grabbed the default gateway IP for a subnet. It should be possible to reserve IPs within a subnet and maas should do a ping test on an IP before assigning it to a deploying node.

Related branches

Andres Rodriguez (andreserl) wrote :

Setting this back to invalid provided that it is possible to reserve IP's:


Changed in maas:
status: New → Invalid
status: Invalid → Won't Fix
status: Won't Fix → Invalid
James Troup (elmo) wrote :

So, to be clear, MAAS allocated the IP of the default gateway of the rack controller. You should not have to tell MAAS not to shoot itself in the face.

Changed in maas:
status: Invalid → New
Changed in maas:
importance: Undecided → Critical
milestone: none → 2.1.6
milestone: 2.1.6 → 1.9.6
status: New → Triaged
assignee: nobody → Mike Pontillo (mpontillo)
summary: - MaaS does not allow reserving of IPs in subnets or check whether auto-
- assigned IPs are in use
+ MAAS auto-assigned gateway IP, while not allowing to reserve IP's in
+ subnets.

Wait, if this happened in MAAS 1.9, doesn't that mean that the static range on the cluster interface includes the gateway IP?

Haw Loeung (hloeung) wrote :

We having existing bugs open for the same, or similar - LP: #1569683 and #1600249.

Andres Rodriguez (andreserl) wrote :


Those bugs are not the same. This bug refers to managed subnets auto-assigning the gateway IP for a known subnet.

LP: #1569683 talks about unmanaged subnets, and providing a static IP on an unmanaged subnet.
LP: #1600249 Prevents the user from assigning an IP. Through the comments, this is related to the UI not surfacing an error saying that the IP address is already in use.


The issue seems to be that MAAS is providing the gateway IP as an auto-assigned IP for a subnet that has the gateway IP set. In other words, MAAS is not pre-reserving such IP.

    MAAS did not start pre-reserving IP addresses until MAAS 2.0. MAAS 1.9
expects the static range to be under the complete control of MAAS.

In MAAS 2.0, the concept of a "static range" was removed; without that
explicit knowledge of which IPs were intended for allocation by MAAS, MAAS
learned to cope by excluding "special" addresses such as gateway IPs, DNS
servers, and interfaces configured on the MAAS servers themselves.

There are a couple ways I can think of we could address this in MAAS 1.9:

(1) Validate when saving a cluster interface that the static range doesn't
include the gateway IP.

(2) Change the IP allocation code to mimic the behavior of MAAS 2.x.

Both potential changes might not solve the entire issue, which is that MAAS
does not have complete information about the network. That is, if the user
didn't fill in the default gateway on the cluster and interface definition
page, MAAS 1.x has no idea what address it should avoid.

For the record, support for exclusion of gateway IPs was added in revision 4657 for inclusion in MAAS 2.0, as part of IP range enablement work.

Mike Pontillo (mpontillo) wrote :

I'm proposing a simpler version of (2) which doesn't attempt to backport all the new smarts in MAAS 2.x.

summary: - MAAS auto-assigned gateway IP, while not allowing to reserve IP's in
- subnets.
+ [1.9] MAAS can auto-assign a known default gateway for a subnet to a
+ deploying node.
Paul Gear (paulgear) wrote :

@andresrl, to my knowledge this bug was created as a result of an outage on an unmanaged subnet, and there's nothing in the description which suggests it refers to managed subnets. This leads me to the conclusion that it is the same problem as #1569683.

To me the core issue in both bugs is that MAAS seems to depend on its own configuration to determine which addresses are in use, rather than using the operational state of the network. The latter should be determined through the use of ping and/or the ARP table.

Mike Pontillo (mpontillo) wrote :

@paulgear, MAAS uses the operational state of the network starting in version 2.1, but this bug was filed against MAAS 1.9.

Paul Gear (paulgear) wrote :

@mpontillo, yep; so I guess the question is: does the "simpler version of (2) which doesn't attempt to backport all the new smarts in MAAS 2.x" include the smarts to use ping and/or ARP tables?

Mike Pontillo (mpontillo) wrote :

@paulgear, no, that type of change is out of scope and too risky to add to a maintenance release of MAAS. The change I proposed relies on the subnet's configured gateway IP to be correct.

Changed in maas:
status: Triaged → Fix Committed
milestone: 1.9.6 → none
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers