multiple subnets dhcp shared-network does not work with dhcp-relay

Bug #1640298 reported by Andrei Bacos
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
MAAS
New
Undecided
Unassigned

Bug Description

We have one /24 subnet per rack each on a different vlan and use dhcp-relay on the core switch to give each server an appropriate ip (we do not have a MAAS rack controller per rack)

The subnets are defined in MAAS under untagged vlan, when dhcpd.conf gets rendered all these subnets are in a single shared-network which breaks dhcp-relay (ip assignment is done from the first subnet until depleted no mather which server/rack sends the request)

To fix this issue we just edited maas dhcpd template and commented the shared-network line:

55c55
< #shared-network {{shared_network["name"]}} {
---
> shared-network {{shared_network["name"]}} {
94c94
< #}
---
> }

ii maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

Revision history for this message
Patrick De La Rosa (thatfatguypat) wrote :

This is marked as a duplicate, and that duplicate issue is marked as fixed. The fix for the Duplicate is in 2.2.0 which is what I've explored. It requires that we implement MAAS DHCP relay which requires VLAN tagging per rack (per /26 subnet in my case), and also limits DHCP Relay from one source VLAN to one destination Fabric + VLAN.

The difference here is the desire to use a single VLAN with several subnets, but with some control
as to which subnet (within the same VLAN) a DHCP lease is granted from based off of the network segment the request originates. The way suggested in this bug report is by not joining the subnets in dhcpd.conf as a shared-network based off of their VLAN.

While a VLAN can consist of multiple subnets, there may be reasons to logically seperate those subnets (such as logically seperating server racks by subnet). The fix from bug #1254807 in version 2.2.0 does now allow for a DHCP Relay from fabric-0,VLAN1,192.168.1.0/26 -> fabric-0,VLAN1,192.168.1.64/26 while also taking dhcp requests for fabric-0,VLAN1,192.168.1.0/26 -> fabric-0,VLAN1,192.168.1.128/26 and fabric-0,VLAN1,192.168.1.0/26 -> fabric-0,VLAN1,192.168.1.192/26

Revision history for this message
Andrei Bacos (andreibacos) wrote :

The request was to allow serving multiple VLANS using one network interface on the maas server and DHCP relay, same as the other ticket.

"The difference here is the desire to use a single VLAN with several subnets"
From a network perspective we use one subnet per VLAN. In MAAS gui, we actually used the same vlan/fabric for everything because we could no enable DHCP on any other vlan (dhcp server dropdown was empty), that's why i changed the dhcpd.conf template. There was a bug fix for this iirc.

Glad to see this issue has been resolved.
Thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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