[2.2] DHCP ntp-server setting can be misconfigured with an IP of a different fabric/vlan
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Fix Released
|
Critical
|
Mike Pontillo | ||
| 2.2 |
Fix Released
|
Critical
|
Mike Pontillo | ||
Bug Description
The MAAS rack discovered a new interface bridge (lxdbr0). After the discovery of such bridge, MAAS created a new Fabric/VLAN/Subnet (e.g. fabric-
That said, I was providing DHCP from fabric-3/untagged which has two subnets 10.90.90.0/24 and 192.168.100.0/24.
After restarting the rack controller, the "ntp-servers" configuration in DHCP was updated pointing to the IP address of the lxdbr0. You can see this as:
shared-network vlan-5002 {
subnet 10.90.90.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 10.90.90.255;
option domain-name-servers 10.90.90.1;
option domain-name "maas";
option routers 10.90.90.254;
option ntp-servers 10.10.10.1;
}
subnet 192.168.100.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.100.255;
option domain-name-servers 10.90.90.1;
option domain-name "maas";
option ntp-servers 10.10.10.1;
}
}
To revert it back, two things were tried:
Removing 'lxdbr0'
1. Remove 'lxdbr0'
2. restart maas-rackd
3. ntp-servers option was updated accordingly.
Changing newly created VLAN to a different L2 space
1. Added a new L2 space (test).
2. Moved fabric-5/untagged to 'test' space.
3. restarted maas-rackd.
This updated the configuration of dhcpd to have the correct NTP server.
That said, what seems to be happening:
1. MAAS using the IP of a different subnet (in a different fabric/vlan) for NTP because it is in the same space.
2. Trigger that would have updated the config automatically in the event of a space change.
3. Removing an interface should trigger an update as well.
Related branches
- Blake Rouse (community): Approve
-
Diff: 85 lines (+51/-7)2 files modifiedsrc/maasserver/dhcp.py (+24/-7)
src/maasserver/tests/test_dhcp.py (+27/-0)
- Mike Pontillo (community): Approve
-
Diff: 111 lines (+64/-9)3 files modifieddocs/changelog.rst (+13/-2)
src/maasserver/dhcp.py (+24/-7)
src/maasserver/tests/test_dhcp.py (+27/-0)
| description: | updated |
| Changed in maas: | |
| milestone: | none → 2.2.1 |
| importance: | Undecided → Critical |
| status: | New → Triaged |
| milestone: | 2.2.1 → 2.3.0 |
| BenLake (me-benlake) wrote | #1 |
| Andres Rodriguez (andreserl) wrote | #2 |
| summary: |
- [2.2] NTP misconfigured after the Rack discovered a new 'lxdbr0' - interface + [2.2] DHCP ntp-server setting can be misconfigured with an IP of a + different fabric/vlan |
| Mike Pontillo (mpontillo) wrote | #3 |
| Changed in maas: | |
| status: | Triaged → Fix Committed |
| Mike Pontillo (mpontillo) wrote | #4 |
| Mike Pontillo (mpontillo) wrote | #5 |
| Changed in maas: | |
| assignee: | nobody → Mike Pontillo (mpontillo) |
| Changed in maas: | |
| milestone: | 2.3.0 → 2.3.0alpha1 |
| Changed in maas: | |
| status: | Fix Committed → Fix Released |
I think this happened to me as well, but I'm not as clear on the timing of the new fabric coming up and when NTP server IPs on deployment changed. Also, the NTP server IP chosen was not that of the new fabric; so my issue may not be quite the same as the OPs. However, the IP chosen, whenever it was chosen, was non-functional. I have no way to specify which fabric/
In any case, I don't really care for most of the behind-the-scenes automagical discovery. Anything that is changing a config should be confirmed (even if it is a yet-to-be config). So having processes discover things is handy, but nothing should take effect until confirmed (my $0.02).