If you're like me and working with zones on your laptop and/or desktop, you probably only have one network interface card to work with. Therefore, the zones I've created share the single network interface with the global zone (ip-type=shared).

Behind the scenes, OpenSolaris creates a logical interface for the zone to use. The logical interface appears in ifconfig as your physical interface with an instance number. For example:

bleonard@opensolaris:~$ ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	inet 127.0.0.1 netmask ff000000 
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	zone myzone
	inet 127.0.0.1 netmask ff000000 
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
	inet 10.0.1.10 netmask ffffff00 broadcast 10.0.1.255
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
	zone myzone
	inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255

You can see both the loopback (loO) and physical (e1000g0) have an instance (lo0:1 and e1000g0:1) that was created for the zone myzone. These logical interfaces only exist when the zone is running. If you halt the zone, they disappear.

From inside the zone, I only see the logical interfaces:

root@myzone:~# ifconfig -au4
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255

However, I have no control over them. For example, if I try to bring down e1000g0:1:

root@myzone:~# pfexec ifconfig e1000g0:1 inet down
ifconfig: setifflags: SIOCSLIFFLAGS: e1000g0:1: permission denied 

The global zone is responsible for managing the local zone's network configuration.

Crossbow

Project Crossbow brings virtualization to the network. For example, I can create a virtual network interface card (vnic) that has all the properties of a physical nic.

bleonard@opensolaris:~$ pfexec dladm create-vnic -l e1000g0 myzone0
pfexec dladm create-vnic -l e1000g0 myzone0

bleonard@opensolaris:~$ dladm show-link 
LINK        CLASS    MTU    STATE    OVER
e1000g0     phys     1500   up       --
iwh0        phys     1500   down     --
vboxnet0    phys     1500   unknown  --
myzone0     vnic     1500   up       e1000g0

Now it's as if my laptop has 2 physical network interface cards. Using this "new" card, I can create a zone with an exclusive IP stack. My zone config would look something like follows:

bleonard@opensolaris:~$ cat myzone.config
create
set zonepath=/zones/myzone
set ip-type=exclusive	
add net
set physical=myzone0
end

Note there's now longer an IP address associated with the zone configuration. With a dedicated IP stack the zone will be able to manage its own IP.

Create the zone:

pfexec zonecfg -z myzone -f myzone.config

Install the zone:

bleonard@opensolaris:~$ pfexec zoneadm -z myzone install
A ZFS file system has been created for this zone.
   Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/).
       Image: Preparing at /zones/myzone/root.
       Cache: Using /var/pkg/download.  
Sanity Check: Looking for 'entire' incorporation.
  Installing: Core System (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  20/20   3021/3021   42.55/42.55 

PHASE                                        ACTIONS
Install Phase                              5747/5747 
  Installing: Additional Packages (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  37/37   5598/5598   32.52/32.52 

PHASE                                        ACTIONS
Install Phase                              7332/7332 

        Note: Man pages can be obtained by installing SUNWman
 Postinstall: Copying SMF seed repository ... done.
 Postinstall: Applying workarounds.
        Done: Installation completed in 148.737 seconds.

  Next Steps: Boot the zone, then log into the zone console
             (zlogin -C) to complete the configuration process 

Create a configuration file for the zone. Note, here we can define the zone's IP configuration (or we could do it later):

bleonard@opensolaris:~$ cat sysidcfg
system_locale=C
terminal=xterms
network_interface=myzone0 {
	hostname=myzone
	ip_address=10.0.1.25
        default_route=NONE
	netmask=255.255.255.0
 	protocol_ipv6=no}
security_policy=none
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=fto/dU8MKwQRI

Ready the zone (this mounts its file system):

pfexec zoneadm -z myzone ready

Copy the sysidcfg file to the zone:

pfexec cp sysidcfg /zones/myzone/root/etc/.

Log into zone:

bleonard@opensolaris:~$ pfexec zlogin -C myzone
[Connected to zone 'myzone' console]

Open a 2nd terminal and boot the zone:

pfexec zoneadm -z myzone boot

Back in the first terminal you can watch the zone boot and configure itself. Note the message about myzone0 being an invalid network interface. This appears to be benign as a few lines down we see myzone0 getting configured.

bleonard@opensolaris:~$ pfexec zlogin -C myzone
[Connected to zone 'myzone' console]

[NOTICE: Zone booting up]


SunOS Release 5.11 Version snv_111b 64-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: myzone
Loading smf(5) service descriptions: 69/69
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
 network_interface=myzone0 {
myzone0 is not a valid network interface  line 3 position 19
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
Configuring network interface addresses: myzone0.

myzone console login: 

If you used the root_password setting from above, you can log in as root/abc123:

myzone console login: root
Password: 
Jul 14 10:55:32 myzone login: ROOT LOGIN /dev/console
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
root@myzone:~# 

As with shared IP, you can see the interface using ifconfig:

root@myzone:~# ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
myzone0: flags=1000863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255
        ether 2:8:20:59:0:b5 

However, now you can also manage it. For example:

root@myzone:~# ifconfig myzone0 down
root@myzone:~# ifconfig -au4
lo0: flags=2001000849<⁞UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 

And back in the global zone, there's no more logical interfaces cluttering up the ifconfig output:

bleonard@opensolaris:~$ ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,⁞RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	inet 127.0.0.1 netmask ff000000 
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
	inet 10.0.1.10 netmask ffffff00 broadcast 10.0.1.255

In addtion to this, virtual nics provide a whole bunch of control over the data passing through the network interface. For a brief introduction to that see Fun with Crossbow.