MAAS

Subnet update allows incorrect information

Bug #1901719 reported by Paul Jonason
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Triaged
Medium
Unassigned
MAAS 3.5.0

Bug Description

When trying to create a new subnet (cidr=10.86.112.0/26), we used an existing subnet name by accident, getting an existing subnet id (for cidr=10.86.112.64/26) rather than creating a new one. The end result was that the MAAS API updated the existing subnet with incorrect information - it moved it to a different VLAN in a different fabric, allowed IP ranges out of bounds of the subnet, and reported a /26 subnet as having 126 subnet address when it really only should have 62.

Our code for subnet update/creation takes a subnet name and GETs a subnet id for the name. If an ID is returned, update the subnet with that ID with the given values, otherwise, create a new subnet with the given values. Similar for all other network components, actually.

maas-dhcpd failed on the config update, however, so it caught the issue.

MAAS version: 2.6.2 (7841-ga10625be3-0ubuntu1~18.04.1)

There are not a lot of helpful log entries, but
regiond.log
-----------
2020-10-22 13:17:49 maasserver.dhcp: [info] Successfully configured DHCPv4 on rack controller 'mrklx1005 (ff88am)'.
2020-10-22 13:17:49 maasserver.dhcp: [info] Successfully configured DHCPv6 on rack controller 'mrklx1005 (ff88am)'.
2020-10-22 13:17:59 maasserver.region_controller: [info] Reloaded DNS configuration; subnet 10.86.112.64/26 changed to 10.86.112.0/26

maas-dhcp
---------
Oct 22 13:18:25 mrklx1005 systemd[1]: Stopping MAAS instance of ISC DHCP server for IPv4...
Oct 22 13:18:25 mrklx1005 systemd[1]: Stopped MAAS instance of ISC DHCP server for IPv4.
Oct 22 13:18:25 mrklx1005 systemd[1]: Starting MAAS instance of ISC DHCP server for IPv4...
Oct 22 13:18:25 mrklx1005 systemd[1]: Started MAAS instance of ISC DHCP server for IPv4.
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: bad range, address 10.86.112.111 not in subnet 10.86.112.0 netmask 255.255.255.192
Oct 22 13:18:25 mrklx1005 dhcpd[30524]:
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: If you think you have received this message due to a bug rather
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: than a configuration issue please read the section on submitting
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: bugs on either our web page at www.isc.org or in the README file
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: before submitting a bug. These pages explain the proper
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: process and the information we find helpful for debugging..
Oct 22 13:18:25 mrklx1005 dhcpd[30524]:
Oct 22 13:18:25 mrklx1005 dhcpd[30524]: exiting.
Oct 22 13:18:25 mrklx1005 systemd[1]: maas-dhcpd.service: Main process exited, code=exited, status=1/FAILURE
Oct 22 13:18:25 mrklx1005 systemd[1]: maas-dhcpd.service: Failed with result 'exit-code'.

Revision history for this message
Paul Jonason (pjonason) wrote :
Revision history for this message
Paul Jonason (pjonason) wrote :

More effect seen from this today: Filtering machines by the new fabric (where the new subnet belongs) returns all the machines in the old fabric (which holds the mistakenly updated subnet), as well.

Revision history for this message
Alberto Donato (ack) wrote :

Could you please add more details about

1) what was the subnet(s) state before you made changes
2) what are the exact changes you made
3) what was the subnet(s) state after the changes

Changed in maas:
status: New → Incomplete
Revision history for this message
Paul Jonason (pjonason) wrote :

Sure,

1) Subnet F3CR6SWT Vlan601 (id=429) state prior to change:
cidr: 10.86.112.64/26
gateway: 10.86.112.65
in vlan: 601 (id=5452)
in fabric: AV25 (id=403)
with reserved iprange 10.86.112.65-10.86.112.67
and dynamic iprange 10.86.112.112-10.86.112.126
displayed subnet address available: 62

2) Changes made:
subnet_args = { 'name'=>'F3CR6SWT Vlan601', 'cidr'=>'10.86.112.0/26', 'gateway_ip'=>'10.86.112.1', 'vlan'=>5492 }
send PUT to '/MAAS/api/2.0/subnets/429/' with subnet_args

res_args = { 'type'=>'reserved', 'start_ip'=>'10.86.112.1', 'end_ip'=>10.86.112.3', 'subnet'=>429 }
send POST to '/MAAS/api/2.0/ipranges/' with res_args

dyn_args = { 'type'=>'reserved', 'start_ip'=>'10.86.112.48', 'end_ip'=>10.86.112.62', 'subnet'=>429 }
send POST to '/MAAS/api/2.0/ipranges/' with dyn_args

3) Subnet F3CR6SWT Vlan601 (id=429) state after change:
cidr: 10.86.112.0/26
gateway: 10.86.112.1
in vlan: 601 (id=5492)
in fabric: AV13 (id=438)
with reserved ipranges 10.86.112.65-10.86.112.67 and 10.86.112.1-10.86.112.3
and dynamic ipranges 10.86.112.112-10.86.112.126 and 10.86.112.48-10.86.112.62
displayed subnet address available: 126

**Our intention was to send a POST to '/MAAS/api/2.0/subnets/' with subnet_args rather than the PUT to '/MAAS/api/2.0/subnets/429', but we forgot to update the subnet name in the call. That's our bug to fix.

However, the original ipranges in the subnet are now illegal as a result of the cidr change, and the subnet address calculation is incorrect. I would expect an error from MAAS in these cases. Perhaps validate existing gateway and ipranges in a subnet on a cidr change?

Alberto Donato (ack)
Changed in maas:
milestone: none → 2.9.x
status: Incomplete → Triaged
importance: Undecided → High
Adam Collard (adam-collard)
Changed in maas:
milestone: 2.9.2 → 2.9.x
Mauricio Faria de Oliveira (mfo)
Changed in maas:
milestone: 2.9.x → none
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

MAAS should validate subnet parameter changes to prevent similar issues.

Changed in maas:
importance: High → Medium
milestone: none → 3.5.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.