[2.2.0] MAAS hands out a broken (lxdbr0) SNTP server IP address
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
New
|
Undecided
|
Unassigned | ||
Bug Description
I noticed that several devices on my network were unable to sync time. It turned out that MAAS was giving them 10.0.3.1 as an address. That turned out to be because a rack controller had a lxdbr0 with that IP address, and for some reason that interface/address had been selected.
I would expect:
* MAAS would only auto-select interfaces which other MAAS services can route to
- i.e. we test which MAAS controller interfaces can be seen by other MAAS services
* MAAS will enable manual control of the "service interfaces"
- i.e. rack /region controller interfaces can be service-providing or not
- the admin can designate an interface as "service providing"
- those interfaces are used appropriately, i.e. local-to-the-vlan for rack controllers
| Mike Pontillo (mpontillo) wrote | #1 |
I agree "manual control of service interfaces" would very nice to have, but the scope of that is too large for a bug fix.
As for the symptom being seen here, we recently fixed bug #1695083 (for inclusion in MAAS 2.2.1), which should provide better behavior for NTP server selection. Previously, MAAS might have choose any address on the box as the NTP endpoint. With that fix, the pool of possible NTP server addresses is limited to "managed interfaces" (IP addresses on rack interfaces with DHCP enabled). So it should solve the problem you're seeing, unless you also have MAAS DHCP managing lxdbr0 (in which case, roll the dice).
Bug #1695937 captures the additional concern that you might have two mutually unreachable VLANs on a rack controller. But that fix has a larger scope, so was not included in the fix for bug #1695083.