[1.9] wrong subnet in DHCP answer when multiple networks are present
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
High
|
Blake Rouse | ||
1.9 |
Fix Released
|
High
|
Trent Lloyd | ||
isc-dhcp (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
So I have 3 interfaces with 3, non-overlapping subnets defined in my maas cluster controller.
The idea would be that there is a provisioning network (10.6.0.0/16) to do the actual provisioning and once the node gets deployed it is using a different network (because the provisioning network is only 1x1Gbit while the production network is bonded (LACP) 10Gbit).
However, when I boot up a fresh, new node to add to MAAS, it gets the following DHCP reply:
ip=10.6.
So instead of picking up the /16 subnet correctly for the 10.6.239.3 IP, it picks up the /24 from the network where it gets it's default gateway from.
Is this a bug or my understanding of how MAAS should behave when there are multiple networks flawed?
Here is my /var/lib/
subnet 9.4.113.0 netmask 255.255.255.0 {
if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
} elsif option arch = 00:07 {
filename "bootx64.efi";
} elsif option arch = 00:0B {
filename "grubaa64.efi";
} elsif option arch = 00:0C {
filename "bootppc64.bin";
} else {
filename "pxelinux.0";
}
interface "eth0";
option subnet-mask 255.255.255.0;
option broadcast-address 9.4.113.255;
option domain-name-servers 9.4.113.251;
option domain-name "i.zc2.ibm.com";
option routers 9.4.113.254;
option ntp-servers ntp.ubuntu.com;
range dynamic-bootp 9.4.113.150 9.4.113.190;
class "PXE" {
match if substring (option vendor-
}
}
subnet 10.6.0.0 netmask 255.255.0.0 {
if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
} elsif option arch = 00:07 {
filename "bootx64.efi";
} elsif option arch = 00:0B {
filename "grubaa64.efi";
} elsif option arch = 00:0C {
filename "bootppc64.bin";
} else {
filename "pxelinux.0";
}
interface "eth1";
option subnet-mask 255.255.0.0;
option broadcast-address 10.6.255.255;
option domain-name-servers 9.4.113.251;
option domain-name "i.zc2.ibm.com";
option ntp-servers ntp.ubuntu.com;
range dynamic-bootp 10.6.239.0 10.6.239.239;
class "PXE" {
match if substring (option vendor-
}
}
Here is "subnets read":
[
{
"name": "9.4.113.0/24",
"space": "space-0",
"vlan": {
"name": "untagged",
"vid": 0,
"id": 0
},
"cidr": "9.4.113.0/24",
"id": 1,
},
{
"name": "10.7.0.0/16",
"space": "space-0",
"vlan": {
"name": "untagged",
"vid": 0,
"id": 5001
},
"cidr": "10.7.0.0/16",
"id": 2,
},
{
"name": "10.6.0.0/16",
"space": "space-0",
"vlan": {
"name": "untagged",
"vid": 0,
"id": 5002
},
"cidr": "10.6.0.0/16",
"id": 3,
}
]
Running 1.9.0~rc2+
Related branches
- Blake Rouse (community): Approve
-
Diff: 50 lines (+11/-7)2 files modifiedetc/maas/templates/dhcp/dhcpd.conf.template (+8/-6)
etc/maas/templates/dhcp/dhcpd6.conf.template (+3/-1)
- Blake Rouse (community): Approve
-
Diff: 32 lines (+9/-6)1 file modifiedsrc/provisioningserver/templates/dhcp/dhcpd.conf.template (+9/-6)
Changed in maas: | |
importance: | Medium → Critical |
milestone: | none → 2.0.0 |
Changed in maas: | |
status: | Triaged → In Progress |
importance: | Critical → High |
assignee: | nobody → Blake Rouse (blake-rouse) |
summary: |
- wrong subnet in DHCP answer when multiple networks are present + [1.9] wrong subnet in DHCP answer when multiple networks are present |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Thanks for taking the time to report a bug in MAAS.
Can you give us more information on this line in your bug report:
ip=10.6. 239.3:10. 6.250.250: 9.4.113. 254:255. 255.255. 0
Is this from a packet capture? (if so, on which interface?) I'm trying to figure out what this means. In it you have:
10.6.239.3 <-- seems to be an IP address within "range dynamic-bootp 10.6.239.0 10.6.239.239"
10.6.250.250 <-- seems to be another IP address within your /16
9.4.113.254 <-- router
255.255.255.0 <-- /24
It's interesting that dhcpd would behave in this way; it seems to be picking up the "option routers" from a subnet it didn't select. It looks like this may be a dhcpd bug...