|Priority:||5 - Low|
|Created by:||Brian Bennett|
|Reported by:||Brian Bennett|
|Assigned to:||Brian Bennett|
There are two mechanisms to enable dhcp service
Both remove the dhcp-nospoof protection from the vnic. Only dhcp_server removes the ip-nospoof protection.
In illumos-joyent, these are handled identically in the zone boot scripts. I.e., they both remove both dhcp-nospoof and ip-nospoof. Consequently, setting dhcp_server will make a zone work immediately, while allow_dhcp_spoofing requires a reboot, or also explicitly setting allow_ip_spoofing.
To correct this, vmadm needs to handle allow_dhcp_spoofing the same way dhcp_server is handled.
Further complicating matters, Triton (i.e., napi) has no concept of dhcp_server. It’s not reported as properties in nic objects, and it cannot be set because it’s not considered a valid property. Despite this, sdc-headnode creates the dhcpd zone with dhcp_server and not allow_dhcp_spoofing. This makes dhcpd seem as if it just magically works, because the dhcp_server property can’t be seen on the nic object in napi or via adminui. Instead of adding support for dhcp_server to Triton, we should just consider dhcp_server as deprecated.
The reporter was able to test the fix for me.
After creating the instance, before adding
[root@JC827359 (iad001) ~]$ dladm show-linkprop -p protection -z 5b97d2ff-7417-4088-9eb9-d8ea8d5a2429 net0 LINK PROPERTY PERM VALUE DEFAULT POSSIBLE net0 protection rw mac-nospoof, -- mac-nospoof, restricted, restricted, ip-nospoof, ip-nospoof, dhcp-nospoof dhcp-nospoof
allow_dhcp_spoofing, without rebooting the zone:
[root@JC827359 (iad001) ~]$ dladm show-linkprop -p protection -z 5b97d2ff-7417-4088-9eb9-d8ea8d5a2429 net0 LINK PROPERTY PERM VALUE DEFAULT POSSIBLE net0 protection rw mac-nospoof, -- mac-nospoof, restricted restricted, ip-nospoof, dhcp-nospoof