IP Instances are separate views of the IP stack, so that visibility
and control is limited to the entity (zone) that the instance is
assigned to. By default, all of Solaris has one view of IP, and
therefor central visibility and control. With zones, the ability to
view and control is limited by privileges, and all zones' network
traffic decisions are made with a global view by the kernel. When IP
instances are used, the view is limited to that information that
applies to the instance, not the full kernel. So routing decisions, for
example, are made based on the information only in this instance, and
does not use any of the additional information that other instances on
the same kernel may have. Similarly, control is delegated to this
instance, so that a non-global zone can set network parameters such as
routes, ndd(1m) values, IP address(es). Snooping of the interface(s) in
the IP Instance is also possible. There is no visibility into any of
the other IP Instances that may be sharing this Solaris instance and
kernel.
Another feature with IP Instances is that traffic between zones
must pass the whole path down the stack to the underlying NIC. This is
the result of the zone's IP not knowing where the destination address
is, and it must thus be put on the wire. If the zone is using a VNIC,
whether the traffic stays within the system or exists on a physical
netowrk interface depends on whether the destination also using a VNIC
sharing the same physical NIC. If a NIC is shared for VNICs, traffic
directly between the VNICs will be switched by the VNICs' virtual
switch to the destination VNIC, and it will not leave the system.
IP Instances are in Solaris Nevada build 57 and later.
IP Instances are in Solaris 10 8/07 released on 4 September 2007.
Only NICs supported by the Generic LAN Driver version 3 (GLDv3) are
supported with IP Instances. The way to determine if a NIC is GLDv3,
run the dladm(1m) command with the 'show-link' subcommand and look for
links that are not of type 'legacy'.
The is one exception. The ce interfaces can also be used now. See Which NICs are known to work with IP Instances? for details, such as Nevada build and Solaris 10 patches required.
This is how non-GLDv3 interfaces will look.
# dladm show-link
eri0 type: legacy mtu: 1500 device: eri0
qfe0 type: legacy mtu: 1500 device: qfe0
qfe1 type: legacy mtu: 1500 device: qfe1
qfe2 type: legacy mtu: 1500 device: qfe2
qfe3 type: legacy mtu: 1500 device: qfe3
And how GLDv3 interfaces look.
# dladm show-link
bge0 type: non-vlan mtu: 1500 device: bge0
bge1 type: non-vlan mtu: 1500 device: bge1
bge1001 type: vlan 1 mtu: 1500 device: bge1
bge2001 type: vlan 2 mtu: 1500 device: bge1
bge2 type: non-vlan mtu: 1500 device: bge2
bge3 type: non-vlan mtu: 1500 device: bge3
aggr1 type: non-vlan mtu: 1500 aggregation: key 1
- Which NICs are known to work with IP Instances?
- afe (Nevada build 73 and later)
- bge
- ce (Nevada build 80 and later, Solaris 10 with IP Instance patches*)
- dfme (Nevada build 73 and later)
- e1000g
- eri (Nevada build 73 and later)
- hme (Nevada build 73 and later)
- iprb (Nevada build 73 and later)
- ixgb
- mxfe (Nevada build 73 and later)
- nge
- nxge
- qfe (Nevada build 73 and later)
- rge
- rtls (Nevada build 73 and later)
- xge
- ath (Nevada only)
- 118777-12 and 137042-01 (SPARC)
- 118778-11 and 137043-01 (i386, x86, x64)
* NOTE: The ce NIC is not a GLDv3 device, but has been made to work with IP Instances. The Solaris 10 patches required are:
- Which NICs don't work with IP Instances?
- ce (Nevada build 79 and earlier, and Solaris 10)
- dnet
- elx
- fjgi
- ge
- ipge
- ixge
- spwr
- Sun PCI-Express Dual Gigabit Ethernet UTP X7280A-2
- Sun PCI-Express Dual Gigabit Ethernet MMF X7281A-2
* NOTE: The e1000g driver replaces ipge in Solaris 10 11/06 and later for these NICS:
However, a shim is planned as part of Nemu Unification within
Project Clearview that will allow those interfaces to be used together
with IP Instances. (The list is based on most of the NICs for which
drivers are included in Solaris.)
There are two Change Requests to enable IP Instances with the ce driver. See What's Up ce-Doc?
for some details. These fixes have been put into OpenSolaris and are
available in Nevada build 80 and later, and available for Solaris 10
with patches
Yes.
The maximum number of IP Instances is the same as the maximum number of non-global zones, which currently is 8191 (8K – 1).
A non-global zone can have only one IP Instance. By default, a zone
is in the global instance sharing IP with the global zone and all other
zones without an exclusive IP Instance. When a zone is configured to
have an exclusive IP Instance, its view of IP is now isolated from the
rest of the system.
No.
Commands at the IP level such as ifconfig(1m) will only
work with the interfaces in the IP Instance from which the command is
run. In the global zone, they will only be able to see those interfaces
not set as exclusive to a non-global zone.
The snoop(1m) command is able to be used from the
global zone even if that interface has been given to a non-global zone
with an IP Instance configured. If snoop is run in the global zone and
in the zone that has exclusive access to the interface, they will see
the same data.
The dladm(1m) command is used from the global zone to manage all devices, links, aggregations, VLANs, and VNICs.
Using the dladm(1m) command, a privileged user in the
global zone can see and control the physical interfaces (NICs, link
aggregations (aggr), VLANs, and VNICs).
All interfaces assigned to a non-global zone can be identified by running 'ifconfig -a plumb', followed by 'ifconfig -a'.
non-global zone# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
non-global zone# ifconfig -a plumb
non-global zone# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge1: flags=201000842<BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask 0
ether 0:3:ba:e3:42:8c
non-global zone#If you have, for example, an nge interface, one method is to create the file /etc/hostname.nge0 in the non-global zone.
non-global zone# echo "192.168.1.11/24" > /etc/hostname.nge0
non-globalzone# init 6
...
non-global zone# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
nge0: flags=1000843"<"UP,BROADCAST,RUNNING,MULTICAST,IPv4">" mtu 1500 index 2
inet 192.168.1.11 netmask ffffff00 broadcast 10.1.14.255
ether 0:17:31:46:d8:eb
non-global zone# Generally, you will set up the /etc/hosts file, /etc/defaultrouter
if using static routes, /etc/netmasks, /etc/resolv.conf, and the like,
as with any stand-alone system. With a shared IP Instance, much of this
was managed by the adminstrator(s) in the global zone.
- What services can now run in a zone that could not before?
- DHCP client
- DHCP server
- Routing daemon
- IPsec
- IPfilter
- IP Multipathing (IPMP)
- ndd commands
- ifconfig (with set or modify capabilities)
After configuring and installing the zone, copy or create an /etc/sysidcfg file. For example,
global-zone# cat /myzones/dhcpzone/root/etc/sysidcfg
system_locale=C
terminal=xterm
network_interface=primary {
dhcp
protocol_ipv6=no
}
security_policy=NONE
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=""
global-zone# zlogin dhcpzone ifconfig -a
lo0: flags=2001000849"<"UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL">" mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge2: flags=201004843"<"UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4,CoS">" mtu 1500 index 2
inet 10.1.14.161 netmask ffffffc0 broadcast 10.1.14.191
ether 0:3:ba:e3:42:8d
global-zone#
A non-global zone can still be an NFS client (not of the global zone
on the same system), but can not be an NFS server. The in-ability of a
non-global zone to be an NFS server is not related to networking, but
rather to file system and virtual memory interaction.
You can not load private kernel modules in a non-global zone, even
if you have your own instance. Also, IPfilter rulesets are controlled
from the global zone at this time. A linux branded zone does not work
with IP Instances at this time.