Closed bahamas10 closed 2 years ago
The brand framework supports both persistent and on-demand VNICs, so if you create a VNIC without specifying the global-nic
property, it will persist over a zone reboot. That's the current workaround for doing something like this, create the VNIC manually, add it to the zone without specifying global-nic
, and then set the properties you want. One thing to bear in mind is that if you configure an allowed-address
attribute, zoneadmd
will automatically set protection
to ip-nospoof
and configure allowed-ips
on zone boot, unless you have manually set either of those properties on the link.
Can you expand a bit on what you're trying to achieve here? We could add more properties to the network resource in the zone configuration, we just have to manage the interaction with allowed-ips
.
@citrus-it Thanks for the reply - that's good to know about the persistent VNICs.
My current goal is to move my dhcp
zone (dhcp server for my home network) over from SmartOS to OmniOS. When I originally spun up my new DHCP server on my OmniOS test server I noticed that none of the DHCP responses were going out. The zone was getting the requests from clients, and offering IPs back, but nothing was actually leaving the zone.
At the request of @papertigers I ran the D script from this comment (https://github.com/joyent/smartos-live/issues/567#issuecomment-187462068). Running that while an incoming DHCP request was received by the zone I saw:
dave - GZ:test-gz sunos ~ $ sudo ./test.d
dtrace: script './test.d' matched 6 probes
CPU ID FUNCTION:NAME
0 41603 intercept_dhcpv4_outbound:return intercept_dhcpv4_outbound returned 0
0 41681 ipnospoof_check:return ipnospoof_check returned 22
0 16331 mac_protect_check_one:ip-nospoof-fail
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
0: ff ff ff ff ff ff 02 08 20 c8 fa 2a 08 00 ........ ..*..
^C
I then compared the protection properties on my links (my DHCP server lives on 4 vlans so it has 4 VNICs) from SmartOS to OmniOS.
On SmartOS:
root - datadyne sunos ~ # dladm show-linkprop -z b72627b5-5eca-eb70-875d-dddeb85eaf68 -p protection
LINK PROPERTY PERM VALUE DEFAULT POSSIBLE
net0 protection rw mac-nospoof, -- mac-nospoof,
restricted restricted,
ip-nospoof,
dhcp-nospoof
net1 protection rw mac-nospoof, -- mac-nospoof,
restricted restricted,
ip-nospoof,
dhcp-nospoof
net2 protection rw mac-nospoof, -- mac-nospoof,
restricted restricted,
ip-nospoof,
dhcp-nospoof
net3 protection rw mac-nospoof, -- mac-nospoof,
restricted restricted,
ip-nospoof,
dhcp-nospoof
On OmniOS:
dave - GZ:test-gz sunos ~ $ dladm show-linkprop -p protection
LINK PROPERTY PERM VALUE DEFAULT POSSIBLE
... snipped ...
dhcp0 protection rw ip-nospoof -- mac-nospoof,
restricted,
ip-nospoof,
dhcp-nospoof
dhcp1 protection rw ip-nospoof -- mac-nospoof,
restricted,
ip-nospoof,
dhcp-nospoof
dhcp2 protection rw ip-nospoof -- mac-nospoof,
restricted,
ip-nospoof,
dhcp-nospoof
dhcp3 protection rw ip-nospoof -- mac-nospoof,
restricted,
ip-nospoof,
dhcp-nospoof
Because of the ip-nospoof-fail
from the D script output, and ip-nospoof
being enabled on OmniOS and not SmartOS for the zone, I disabled all protections on the interfaces in the DHCP zone. This allowed the DHCP server to work as expected.
So there are a couple things going on here:
It appears that my zone on SmartOS when configured with "allow_dhcp_spoofing":true
disables ip-nospoof
. I was surprised by this behavior personally - I'm not immediately sure why a DHCP server packet would require spoofing an IP address. However, this could just be my ignorance about how DHCP's server work showing.
My first thought was to have zadm
be able to set (or reset) link properties, but after more thought I realize the persistence of those would be more the responsibility of the brand scripts and how they tie in with what zadm
does during creation.
This is all a long winded way to ask:
zadm
create VNICs with ip-nospoof disabled, or should I create these outside of zadm
and just assign them to the zone?ip-nospoof
right to be breaking my dhcp server? it's possible I'm using some dhcp extensions I'm unaware of.dladm
supports -z
on SmartOS and I've gotten used to it. Is there any chance this can be pulled into OmniOS (https://github.com/joyent/illumos-joyent/commit/fa9b9945bd7803ffdb04bcd69a2c04e14ca852fc) :) I realize this probably isn't the best place to ask this.zadm
does not set any link protection properties when creating vnics; as andy mentioned it's the allowed-address
zone net attribute that sets ip-nospoof
. You can either create a vnic manually or let zadm create it, but don't specify neither global-nic
nor allowed-address
(you can use the over
attribute in the zone net config to tell zadm which link to use for the vnic to create if it does not exist, yet).
We'll discuss it in the team how to make setting vnic link protection properties easier.
Ok, great thank you for the reply @hadfl . I was able to create the VNICs manually and just give them to the zone with no protections (and no allowed-address
) properties. I then was able to use ipadm
in the zone to give them the right addresses and this gives me the result I want.
I made this GitHub issue to mostly ask is this something that zadm
can/could support (if it's feasible). In the SmartOS world configuring the JSON manifest was enough to make the VNICs in a way that I never had to manually intervene with. I don't mind having to create the VNICs with dladm
and then use ipadm
in the zone - I just wanted to know if this was possible with zadm
before I reached for my manual solution.
PS: Thank you both for the quick replies - you've both eased a lot of the learning curve I had coming from the SmartOS world!
[edit] for anyone coming here from google, here is how I accomplished this:
In the global zone I created the VNICs with the vlan IDs in the global zone over my physical NIC (e1000g0
, found via dladm show-phys
):
dladm create-vnic -l e1000g0 newdhcp0
dladm create-vnic -l e1000g0 -v 3 newdhcp1
dladm create-vnic -l e1000g0 -v 4 newdhcp2
dladm create-vnic -l e1000g0 -v 5 newdhcp3
Then, I modified the zadm
manifest for my zone to look like:
$ zadm show dhcp
... snipped ...
[[net]]
physical="newdhcp0"
[[net]]
physical="newdhcp1"
[[net]]
physical="newdhcp2"
[[net]]
physical="newdhcp3"
After booting the zone I zlogin'd in and set up the interfaces with their correct IPs via ipadm
:
ipadm create-addr -T static -a 10.0.1.4/24 newdhcp0/v4
ipadm create-addr -T static -a 10.0.2.4/24 newdhcp1/v4
ipadm create-addr -T static -a 10.0.3.4/24 newdhcp2/v4
ipadm create-addr -T static -a 10.0.4.4/24 newdhcp3/v4
route add default 10.0.1.1
echo 10.0.1.1 > /etc/defaultrouter
With all of that the interfaces should be setup and ready to server DHCP traffic, and survives reboots.
I just wanted to know if this was possible with
zadm
before I reached for my manual solution.
We could certainly enhance zadm
to deal with link protection properties; however, to fully support it even for "transient" vnics we'll have to imlement it at the zone brand level.
This all makes sense - I'll close this issue for now
Hello, is it possible to specify linkprops (like protection) with
zadm
when creating an interface? Right now I can achieve what I want by runningdladm
commands after booting the zone, but I know these won't persist by default over a zone (or gz) reboot.The default when I create a zone with
zadm
:Is this something that
zadm
supports? or should I create the interface outside ofzadm
and usezadm
to just give my preconfigured network interface to the zone?