Closed numericillustration closed 2 years ago
OK, to summarize this:
dhcp_server
and allow_dhcp_spoofing
, will implicitly behave as if allow_ip_spoofing
is also enabled (i.e., the ip-nospoof
protection is dropped).dhcp_server
is applied to a running zone, ip-nospoof
is automatically removed.allow_ip_spoofing
is applied to a running zone, ip-nospoof
is not automatically removed. This is the behavior that is incorrect.allow_ip_spoofing
is not an explicitly set property in the zone XML file.
In the zone state change handling the instance nic flags
dhcp_server
andallow_dhcp_spoofing
are treated the same way https://github.com/TritonDataCenter/illumos-joyent/blob/master/usr/src/lib/brand/jcommon/statechange#L398-L436 in that when either is set in the instance, neither of the the protection properties dhcp-nospoof ip-nospoof will be applied to the instance's link.But in the vmadm code for managing these same settings at https://github.com/TritonDataCenter/smartos-live/blob/master/src/vm/node_modules/VM.js#L15392-L15403 there is a difference such that if one sets
allow_dhcp_spoofing
via vmapi, only the dhcp-nospoof protection will be dropped from the link while the instance is running.Once it is restarted both protections will not have been applied.
test 1: add
allow_dhcp_spoofing
to a new instance via vmapiNew instance created via triton cli:
instance nic info via vmadm on the CN
link protection props
instance info in vmapi:
nic in napi:
add the
allow_dhcp_spoofing
via vmapi:link props change to
vmadm logs show:
stop start and check link props again:
test 2: add
dhcp_server
to a nic via vmadmcreate instance via triton cli
examine the nics on the CN
update the instance nic with
dhcp_server
param