Normally:
- subnet 1 is in fabric 0, which is the admin network for machines connected to
rackd-1
- subnet 63 is in fabric 55, which is the admin network for machines connected to
rackd-2
DHCP serves IPs on both subnets.
Last week, DHCP was not working in subnet 63. That is, there were no entries in rackd-2's dhcpd.conf for that subnet, and the machine’s interface on that subnet was missing from dhcpd-interfaces. We found that subnet 63 was configured to be in fabric 0. To fix it, we set the subnet back to the correct fabric and everything started working again.
We didn’t check the matching files in rackd-1, so we don’t know whether they were temporarily changed. We do know that DHCP continued to work fine in subnet 1.
Is there any way of finding out how that setting was changed? We are fairly confident that no admins would have taken the 6 steps required to configure it incorrectly.
Hey there!
At risk of asking for something you’ve already tried, have you had a peek at the log files around the time in question?
(If not, we have a short list of common log locations depending on install method)
In short, nothing interesting in any of those logs, or syslog. During the issue we found that bind was failing to start on that rackd host, complaining of a missing file. I fixed that with
touch /etc/bind/maas/keys.conf.maas
systemctl restart maas-rackd.service
Bind was then happy, but it didn’t fix the fabric issue.
Huh, glad that issue was fixed at least.
What MAAS version are you running, and how have you been configuring these networks?
Actually, could I ask you create a bug report on https://bugs.launchpad.net/maas describing your issue with the logs linked? That would be a super helpful step to diagnosing the issue
We’re running 3.3.3 with .debs, regiond + 2x rackd. We need to update to 3.3.4 to get rid of annoying Address already in use messages.
We just created fabrics and networks with the GUI, quite a while back now.
Yes, will do. I took a snapshot of the logs last night so they won’t get rotated away.
