With Cisco switches Dave's response is fantastic (and I'll now be going away and implementing this. So this still leaves the potential for someone to plug a SOHO style WAP/router (or infact anything non-windows) into a wallport and start responding to DHCP requests. Below is the that I had, that produced the nf that didn't have next-server.Am I missing something here? I don't see anything in the linked article that suggests this will cause clients to check the authority of the DHCP server they are talking to (how can they? No IP settings to talk to AD with!). If I get a chance, I will use a VM to verify the update being the cause.Īddendum to answer. I don't generally touch the template files, so it must have been the result of the update. I'm not sure why this caused dhcpd to report the IP to 127.0.1.1, instead of providing no IP. I don't see 127.0.1.1, or the system name, or localhostĭ had been changed to no longer providing the "next-server" option.ĭnf did not state the next server IP. Match if substring (option vendor-class-identifier, 0, 3) = "PXE" Option path-prefix code 210 = text #RFC5071 var/lib/maas/nf looks like this (header comments removed) option arch code 93 = unsigned integer 16 # RFC4578 Using dhcping, I request an IP, and the results have Server identifier: 127.0.1.1, which would seem to indicate that the dhcp is identifying itself 127.0.1.1 I've looked for articles on how to interpret the DHCPREQUEST line to understand the 127.0.1.1, but haven't found anything that addresses the parenthetical part, while the rest seems obvious to me. syslog for mac address shows Oct 27 23:43:47 MaaSServer dhcpd: DHCPDISCOVER from 08:9e:01:bc:eb:e8 via eth0 When I commission a mode I see activity in mass.log, but not clusterd.log. The cluster interface page shows 10.0.1.1 as the server IP. etc/hosts doesn't contain 127.0.1.1 for named server IP 127.0.0.1 localhost Only change I see since it last worked correctly is MaaS updated to 1.9.5+bzr4599-0ubuntu1~14.04.2 (based on file dates of the packages).Īs you might expect, commissioning fails, as does deployment Now the console of a machine attempting to commission shows DCHP IP: 127.0.1.1 and no TFTP address. When I last added machines commissioning worked as it should.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |