Here are my belated comments on the IP Instances design.

And here are my belated responses. But we've already acted on the comments that affect the design and code, and I'll make sure the Zones documentation covers the other documentation items.

There are two documents which describe the design
    si-interfaces - a high-level design focusing on the problem the
    project solves, and what the user-visible changes are

A general comment that in both documents page numbers seem to be

Good point.

But I suspect the remaining shelf-life of the design document is very
limited. I'll definitely take your comments on missing pieces in the
documents as strong hints that we should ensure that the zones book be
clear on these points.

Figures 1 and 2 - I think the pictures are a little misleading the
second picture displays an example of two applications (web servers?)
both binding to INADDR_ANY on port 80.  Of course, that's also a very
viable example for the current zones model.  Perhaps a better example
might be one of those applications designated as "Internet facing" and
another might be "Intranet-facing" or "Internal".

Figure 1 shows how zones can be used today.
Figure 2 shows what customers want from IP-level isolation between VLANs (and the white space between the two instances of IP is critical).
Clearly zones today doesn't provide that isolation.
Even if we ignore that (a bit foolish it might be), in figure two the two different zones use different IP subnets and as a side effect they need to use different (default or otherwise) routes. AFAIK we don't actually claim to support different routes for different zones.
Do you still think this is misleading?

Page 6, Section 4 - I'm not sure if this is the proper place for a
discussion on security or if it warrants a separate section, but I
think the document should discuss the security implications of a zone
using a shared stack versus an exclusive stack.  For example, I think
including the table you had sent in private email some time ago which
documented the various attack vectors and how each type of zone
addresses the type of attack would be helpful in understanding the

We'll put this in the zones book. We need to describe the tradeoffs between using shared-IP and exclusive-IP zones there, and the network security differences is one part of that.

Page 6, Section 5 - In the second paragraph, you mention there are no
planned layer two changes.  Does that mean for the initial design that
there will be no filtering done at that layer?  Again, perhaps this
merits discussion in a separate "Security" section but it's important
to understand what sorts of capabilities a privileged user in an
exclusive stack zone has versus one in a zone using the shared stack.

Correct. I'll make sure the zones book covers this topic.

Page 7, Section 6 - In #4, leveraging zonename(1) in this way does seem
strange.  I know we discussed at one time a command to retrieve and
interpret the values of ZONE_ATTR_* kernel attributes although in this
particular case, it seems the only one that makes sense from inside the
zone itself is whether this zone is tied to an exclusive stack.

We've discussed this in a separate email thread.
As your college indicated given that this is a private interface it isn't a big deal. If some new general command for getting ZONE_ATTR_* is created we can just switch to using that instead. (The only place which calls zonename -t is in smf_include.sh thus it would be easy to change when that day comes.)

What about using /sbin/netstrategy and smf_netstrategy() in
/lib/svc/share/smf_include.sh for this purpose?

Overloading them would probably be a mistake. We also have Xen adding its own mechanisms to net-physical. Once we get a perspective across all of the virtualization technologies then we can try to refactor how we do configuration.

Page 7, Section 7 - Given the recent discussion with a customer, would
it make sense to make it clear here that there is a *single* shared IP
and the project does not allow for "islands" of shared IP instances?

Will do in the zones book.

Page 8, Section 9 - When does the enforcement of only allowing a
"physical" property for exclusive IP zones?  Does it occur when one
tries to complete the addition of a "net" resource by specifying "end"
subcommand?  Or does it occur when "verify" is performed on the whole
configuration (either the explicit command or the implicit verification
that takes place prior to commit?)

The latter. (It is done is the verify command in zonecfg.)

In the example given for the shared IP zone, I would specify add the
/24 prefix length to the address parameter (it's not required but
definitely encourage it) and also the missing "end" subcommand.

In the example given for the exclusive IP zone, there is also a missing
"end" subcommand.

I'll make sure the examples in the zones book are correct on these points.

Page 9, Section 10 - BrandZ added their BRAND column after the existing
PATH column but you're introducing it before.  It seems the "IP TYPE"
should follow both PATH and BRAND.  Also, updating the output for first
two "list" examples to account for the merge with BrandZ would be

IP (a short form of IP TYPE) is at the end of the line.

In the third example, the command listed is "list -i" but earlier "-l"
is defined for this purpose.


With respect to "list -l", I'm not sure if this really belongs in
zoneadm(1M) or somewhere else.  In some ways, I'd rather see it as a
new option to dladm(1M) instead.

We concluded with PSARC that adding support for this to dladm (as a property) makes more sense.
Thus there is no more zoneadm list -l.

Will the list of link names printed be the ones actually registered
with the kernel though zone_add_ifname() or the subset of those link
names actually plumbed by the zone with the exclusive stack?  I assume
the former but please verify that.

Even with dladm this doesn't change. It is the list that has been granted to the zone, whether or not the zone is using them.

In this respect, it seems that "list -l" is printing one of that
several pieces of zone runtime state which we don't currently print
through zoneadm(1M) or any other command.  The zones team has discussed
in the past introducing a more general "zoneadm status" or "zoneadm
info" facility but that's not yet designed.  Another alternative is to
begin supporting a "list -o <format>" in zoneadm(1M) and allow the link
names to be a supported type there.

This comment might be important for the future direction. What I got from PSARC was the strong opinion that such observation would be done with sub-system specific commands. Thus mount(1m) should be used to observe that is mounted in a zone, pool* to observe what the running pool configuration is for a zone, etc.

If we follow that advice going forward, then zoneadm status/info would just be for purely zones specific information i.e. information maintained by the zones subsystem and no other place.

Page 9, Section 11 - As I mentioned earlier, zonename(1) seems the
wrong interface for obtaining this information.  What about using
/sbin/netstrategy and smf_netstrategy()?

See above.

Page 9, Section 12 - There should be some discussion of the packaging
changes somewhere in one or both of the documents.  In the particular
case of IP Filter, is the proposal to move all of the contents of
SUNWipfr into a non-hollow package?

Packaging changes are important, but not central to the design.

After the pfhooks putback SUNWipfr no longer contain kernel components, so for Nevada are just changing that (as well as SUNWcnetr) to no longer be HOLLOW. (Packaging for S10 updates warrants a separate thread.)

Page 15, Section 14 - This is more of a code review question but are
the additional privileges being granted to an exclusive stack zone
being hard-coded in either libzonecfg or zoneadmd(1M) or are you
extending the XML uses for each brand?

Hard coded. There is nothing brand specific about what privileges would be granted. The devices are brand specific, so for that we have extended the brand XML syntax.

Page 16, Section 15 - Is the additional configuration that is being
introduced part of this case or a future case?  If the latter, how will
this project and TX interact?

For updated discussion of TX see section 19 in the PSARC commitment materials (also available at http://www.opensolaris.org/os/project/crossbow/Docs/si-interfaces.pdf )

Page 16, Section 17 - Could you provide a bit more detail on each of
these interfaces?  In particular, does zone_get_ifnum() return the
number of link names registered via zone_add_ifname()?  Is the second
parameter of zone_get_iflist() a single string containing the link
names registered in a concatenated form?

Best done by reviewing the code.
But the answers are
        No, it is an array of chat[LIFNAMSIZ].

And as Jerry pointed out in his code review, we can drop the ifnum function since the iflist function returns the number of entries already.

More generally, can zone_getattr() be used in place of these
zone_get_if*() functions?

Not easily.
If we just look at the "get" part, there isn't support in zone_getattr to handle an array of structured elements of unknown size - all existing attributes are either fixed size or have a fixed upper bound. Thus one would have to add a way to determine the size of the attribute. And since one also wants to handle the size changing between the "get size of X" and "get X", one might need to have "get X" be able to return the current size (as we do in zone_get_iflist()).

If we were to solve this, then the next question would be why not to use zone_setattr() for setting it. That one would be even more problematic. In order to support dladm's model of zone as a property of a datalink name, we need to be able to do add/remove and not just a replacement of the whole list. (One can in theory use get+set plus some new zone_attr_lock/unlock to implement atomic add/remove, but now we seem to adding way too much complexity.)

For those reasons it doesn't seem worth-while to try to force-fit this into zone_getattr/setattr.

Should these functions be dealing with "link names" rather than
"interfaces" to avoid confusion with the interfaces that ifconfig(1M)
deals with?

Good point.
We've renamed them to have "datalink" in their names.
Jerry also pointed out that we should be more careful about terminology like "ifname" and "interface name" in the code, so we have done that as well. (Basically the general concept which corresponds to physical=bge0 is something we call "network interface (name)". Those could be for shared-, or exclusive-IP zones. But when it comes to adding a datalink name for an exclusive IP zone we call the zone_add_datalink() syscall.)

    si-design - the design of the code changes. Assumes the reader
    has read si-interfaces already!

Pages 14, Section 7.1 - More of a code review comment but please update
truss(1) to account for the additional argument to zone_create().

Good point (and done).

Pages 14-15, Section 7.2 - As mentioned above, could you please provide
some more details on these new system calls?  Can zone_getattr() be
used instead of the proposed zone_get_if*() functions?

See above.

Also, could you list the changes to the proposed zone_t structure?

OK. FWIW it is
+       /*
+        * zone_iflist is protected by zone_lock
+        */
+       struct ifnamelist *zone_iflist;
+       netstack_t      *zone_netstack;

With regard to the third bullet, please see my concerns above about the
introduction of "list -l".  I think this should be part of a general
zone status/health facility or perhaps something that dladm(1M) can
print about the link names and how their assignment zone-wise.

See above.
With respect to the fourth bullet, can the global zone plumb an
interface which has been "assigned" to an exclusive IP zone but not yet
plumbed by that zone?

The "used" is a typo. The semantics are "assigned".

Page 15, Section 7.3 - As I asked about in the earlier document, is
"zonecfg verify" the only place where address property verification is
done or is it also done at end of adding or changing a "net" resource?

See above. I'll update the design document.

And as I asked earlier, are the additional privileges and devices being
hard-coded intop libzonecfg or zoneadm(1M) or are you extending the XML
uses for each brand?

Page 16, Section 9 - Providing the table of attack vectors here along
with some discussion would be very helpful.

Will do that in an appropriate form in the zones book.


One additional comment I meant to include is that I think it would be
useful to add a paragraph on what is possible today with the current
stack in terms of sharing a link versus what will be possible with IP
instances (using separate physical NICs or VLANs) versus what will be
possible once VNIC support is introduced.  Once VNICs are available,
there will be a lot more flexibility but until then, the use of IP
instances will be limited by the physical hardware or the use of

Will do that in an appropriate form in the zones book.

zones-discuss mailing list

Reply via email to