hey erik,
some questions after reading the interface document.  (and i apologize in
advance if some of the questions seem silly because i'm not a networking

- what will happen in zonecfg if the administrator sets
  ip-type=exclusive and then also configures networking parameters
  (address and netmask) for an interface?

- how about the opposite scenario.  a user configures a zone with
  without and an exclusive ip instance and sets up a bunch of network
  configuration inside that zone that would normally only apply to a
  zone with an exclusive ip instance.  then the user boots the zone.
  does this result in any errors during boot?

- you mention that no GLD or layer 2 changes will be supported inside
  zones.  your example then mentions aggregations.  i'm rusty on
  remembering all the layers so i'll just ask, are vlans and ip
  tunnels supported?

- if an a zone is configured with an exclusive stack, will the
  /dev (and eventually /dev/net) devices associated with that stack
  also be automatically imported into that zone?  if so, then how does
  this interact with non-native zones?  (linux won't be expecting
  /dev/bge0 in it's namespace.  linux uses network devices like

- wrt to brandz, supporting an exclusive ip instance in an an lx
  branded zone will require the implementation of network configuration
  interfaces within the lx brand.  it will probably involve translating
  a bunch of ioctls and socket operations.  also, looking at a centos
  machine i see that it uses iptables instead of ipfilters.  so all
  the iptables configuration system calls would need to be translated
  into their corresponding ipfilters commands.

  will this project do this work?  if not it seems that users should be
  unable to create such a configuration in zonecfg.

- have you considered providing a way to configure an ip instance
  assigned to a zone from the global zone?

  this would help with the situation above where the lx branded zone
  can't configure itself.

  another reason that i ask this is because currently you plan to make
  SMF startup scripts detect if a zone has an exclusive configuration
  or not.  this becomes more complicated when it comes to modifying
  linux startup scripts.  currently we disable most of them.  if we
  take the same approach for non-native zones then we'll have to stop
  disabling the script and patch them to be stacked instances aware
  as well?

- you mention that this will help us get NAT support for zones, then
  you also mention vSwitch.  so i'm a little confused.  after ip
  instances goes back will we be able to use the global zone as a NAT
  for local zones or not?  (rfe 6338667)  if so, could you provide an
  example configuration to illustrate how this might be setup using
  ip instances?  if not, could you explain a little more what additional
  functionality is still required?

- will dladm show-* subcommands work in a zone?  will they display the
  interfaces associated with exclusive ip instances assigned to that

- clearview will allow interfaces to be renamed via dladm, so once an
  interface has been assigned exclusively to a zone will zone
  administrators be able to rename it via dladm?


On Tue, Oct 10, 2006 at 02:23:35PM -0700, Erik Nordmark wrote:
> -------- Original Message --------
> Subject: Reminder: Design review of IP Instances part of Crossbow]
> Date: Tue, 10 Oct 2006 14:21:59 -0700
> From: Erik Nordmark <[EMAIL PROTECTED]>
> The deadline for design review comments is October 20th.
>    Erik
> -------- Original Message --------
> Subject: [crossbow-discuss] Design review of IP Instances part of Crossbow
> Date: Mon, 18 Sep 2006 16:53:02 -0700
> From: Erik Nordmark <[EMAIL PROTECTED]>
> CC: networking-discuss@opensolaris.org,
> "zones-discuss@opensolaris.org" <zones-discuss@opensolaris.org>
> The IP instances (formerly known as "Stack Instances") piece of crossbow
> is now ready for design review comments.
> 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
>       si-design - the design of the code changes. Assumes the reader
>       has read si-interfaces already!
> These documents are available at
> http://www.opensolaris.org/os/project/crossbow/Docs/pdf_filename_si-interfaces.pdf
> and
> http://www.opensolaris.org/os/project/crossbow/Docs/si-design.pdf
> Please send any comments to [EMAIL PROTECTED]
> Note that the design described in these documents differs slightly from
> the bits that can be downloaded from opensolaris.org (e.g., "stacktype"
> vs. "ip-type", and no IP addresses for the "net" resource in zonecfg).
> Those changes will be available in the next version of bits we make
> available on opensolaris.org.
>    Erik
> _______________________________________________
> crossbow-discuss mailing list
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
zones-discuss mailing list

Reply via email to