Section 6.7. Networking


6.7. Networking

Consider a server that contains several zones as a result of a server consolidation program. Externally over the network, it will appear to be a multihomed server that has inherited all the IP addresses of the original servers. However, internally it will look quite different from a traditional multihomed server. The IP stack must partition the networking between the zones in much the same way it would have been partitioned between separate servers. While the original servers could potentially all communicate with each other over the network, they could also all run the same services such as sendmail(1M), apache(1M), etc. The same features are provided by zonesthe zones can all communicate with one another just as though they were still linked by a network, but they also all have separate bindings such they can all run their own server daemons, and these can be the same as those running in another zone listening on the same port numbers without any conflict. The IP stack resolves these conflicts by considering the IP addresses for which incoming connections are destined; the addresses identify the original server and now the zone the connection is considered to be in.

6.7.1. Partitioning

The IP stack in a system supporting zones implements the separation of network traffic between zones. Each logical interface on the system belongs to a specific zone (the global zone by default). Likewise, each stream or connection belongs to the zone of the process that opened it.

Bindings (connections) between upper-layer streams and logical interfaces are restricted such that a stream can establish bindings only to logical interfaces in the same zone. Likewise, packets from a logical interface can only be passed to upper-layer streams in the same zone as the logical interface. Applications that bind to INADDR_ANY for receiving IP traffic are silently restricted to receiving traffic from the same zone. Each zone conceptually has a separate set of binds (mainly used for listens), so that each zone can be running the same application listening on the same port number without binds failing because the address is already in use. Thus, each zone can, for example, run its own inetd(1M) with a full configuration file, sendmail(1M), apache(1M), and the like.

Each zone conceptually has its own loopback interface, and bindings to the loop-back address are kept partitioned within a zone. An exception is the case in which a stream in one zone attempts to access the IP address of an interface in another zonesuch bindings are established through the pseudo loopback interface, as is currently the case in Solaris systems before zone support. Since there is currently no mechanism to prevent such cross-zone bindings, existing Solaris firewalling products will not be able to filter or otherwise act on cross-zone traffic, because it is handled entirely within IP and is not visible to any underlying firewalling products. In the future as part of another project, an option might be provided to prevent such cross-zone bindings.

Sending and receiving broadcast and multicast packets is supported in all zones. Interzone broadcast and multicast is implemented by replication of outgoing and incoming packets as necessary so that each zone that should receive a broadcast packet or has joined a particular multicast group receives the appropriate data.

Zones (other than the global zone) get restricted access to the network. The standard TCP/UDP transport interfaces are available, but some lower-level interfaces are not. These restrictions are in place to ensure that a zone cannot gain uncontrolled access to the network, such that it might be able to behave in undesirable ways (for example, masquerade as a different zone, interfere with the network structure or operation, or obtain from the network some data that does not relate to itself).

The if_tcp(7P) SIOCTMYADDR ioctl tests whether a specified address belongs to this node. The uses of this ioctl identified so far require a "node" to be interpreted as a zone.

6.7.2. Interfaces

Each zone that requires network connectivity has one or more dedicated IP addresses. These addresses are associated with logical network interfaces that can be placed in a zone by ifconfig(1M) using a new zone argument. Zone interfaces configured by zonecfg(1M) are automatically plumbed and placed in the zone when it is booted, although ifconfig(1M) can add or remove logical interfaces once the zone is running. A new if_tcp(7P) ioctl is provided to place a logical interface into a zone, SIOCSLIFZONE (along with the corresponding SIOCGLIFZONE to read back the value). Interfaces can only be configured from within the global zone; zone administrators are not permitted to change the configuration of their network interfaces.

Within a local zone, only that zone's interfaces are visible to ifconfig(1M). In the global zone, ifconfig(1M) can be run with a new -Z flag, which restricts the command to global zone interfaces, but by default, all interfaces are shown, and those not in the global zone are indicated. The example below shows interfaces in all zones. The existing if_tcp(7p) ioctls, SIOCGLIFCONF and SIOCGLIFNUM, return interfaces only in the caller's zone (for both global and local zones). The struct lifconf used by SIOCGLIFCONF and the struct lifnum used by SIOCGLIFNUM include a new flag, LIFC_ALLZONES, which requests that interfaces in all zones be returned in the response. This flag is ignored if the requester is not in the global zone.

global# ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1         inet 127.0.0.1 netmask ff000000 lo0:1: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1         zone my-zone         inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         inet 129.146.126.89 netmask ffffff00 broadcast 129.146.126.255         ether 8:0:20:b9:37:ff hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         zone my-zone         inet 129.146.126.203 netmask ffffff00 broadcast 129.146.126.255 global#  ifconfig -aZ lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1         inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         inet 129.146.126.89 netmask ffffff00 broadcast 129.146.126.255         ether 8:0:20:b9:37:ff global# zlogin my-zone ifconfig -a lo0:1: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1         inet 127.0.0.1 netmask ff000000 hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         inet 129.146.126.203 netmask ffffff00 broadcast 129.146.126.255 


To efficiently remove all the logical interfaces associated with a particular non-global zone, a new ioctl, SIOCREMZONEIFS, will be introduced for use when shutting down such a zone.

6.7.3. IPv6

As with IPv4, the use of IPv6 within a zone can be supported by logical interfaces placed in the zone. IPv6, however, does include a number of unique features (such as address autoconfiguration), that require special consideration when they are configured for use with zones. These features are discussed below.

At the time of this writing, you can use IPv6 within non-global zones only by manually configuring addresses and assigning them to zones, using zonecfg(1M) or ifconfig(1M). Support for address autoconfiguration and default address selection will be part of future Solaris releases.

6.7.3.1. Address Autoconfiguration

Unlike IPv4 in which where the global administrator assigns addresses to a zone, the use of the address autoconfiguration feature of IPv6 provides a useful mechanism to generate unique addresses for the zone. Since typically the system's IEEE 802 48-bit MAC address is used to generate unique addresses for the global zone, a different mechanism is required for each of the local zones so that each has a unique EUI-64 interface identifier as described in RFC 2373. The existing IPv6 address token mechanism is extended to permit multiple tokens to be assigned to a physical interface, each tied to an associated zone (in the existing system, only a single token is permitted for a physical interface), and a per-zone token can be one of the properties that can be set for a network resource that has been assigned to a zone. When in.ndpd(1M) (which runs within the global zone) performs address autoconfiguration, it can use the list of tokens assigned to a physical interface and the prefixes being advertised on that interface to plumb logical interfaces and assign them to their respective zones. It may also be possible to automate the generation of the interface identifier by combining part of the system's MAC address with the zoneid itself.

6.7.3.2. Address Selection

The IPv6 Default Address Selection facility introduced a mechanism for a global administrator to select which source and destination IPv6 addresses should be used when sending datagrams in the case for which multiple addresses are available.

6.7.4. IPsec

IPsec configuration applies systemwide, but zone-specific configuration can be created by specifying a zone's IP address as the laddr field in a ruleset. Tunnels, just like physical interfaces, can be placed into non-global zones by means of logical interfaces and used with IPsec. Multiple logical interfaces are required with the 0th logical interface in the global zone, and further logical interfaces are required in those zones that need access to the tunnel. Appropriate IPsec configuration can block traffic to or from the global zone's logical interface through its IP address, where access from the global zone needs to be explicitly excluded.

IPsec operation between zones is the same as that currently operated over the loopback interfacesome performance gains are made here on the basis that the traffic is not exposed on any external interfaces.

IPsec can be configured only from the global zone.

6.7.5. Raw IP Socket Access

General raw IP socket access is not available in a non-global zone. Such access gives a privileged user in the zone the uncontrolled ability to fabricate and receive packets contrary to the network partitioning between zones.

One special case of raw socket access is supported for the ICMP protocol since this is required by the ping(1M) command. However, the IPPROTO_IP-level option IP_HDRINCL option is not allowed. To this end, a new privilege, PRIV_NET_ICMPACCESS, is introduced and granted to all zones by default. The device policy now allows processes with this privilege to open /dev/icmp, /dev/icmp6, /dev/ rawip, and /dev/rawip6 read-write and read-only.

The /dev/ip device node is not provided within a zone because of the difficulty of ensuring that it could not be used to circumvent the Raw IP Socket Access restrictions. Some applications use /dev/ip to access network statistics, but this can be done with /dev/arp and those applications will be modified appropriately.

6.7.6. DLPI Access

DLPI access provides the raw interface to the network drivers on Solaris.

6.7.7. Routing

Routing remains a systemwide feature, just as it is today on Solaris systems before zone support. Since routing changes affect the whole system, routing changes are allowed only from the global zone. Views of the routing table from within zones are restricted to routes relevant to that zone.

6.7.8. TCP Connection Teardown

The ioctl TCP_IOC_ABORT_CONN can abort existing TCP connections and unconnected TCP endpoints without waiting for a timeout. It is used by the Sun Cluster and Netra High Availability (HA) Suite products to allow quick failover of IP addresses from one node to another. The tcp_ic_abort_conn_t structure has been extended to include a zone ID, allowing all connections associated with a given zone to be terminated; this is used internally as part of zone shutdown. You can preserve the previous behavior by setting the zone ID field (ac_zoneid) to ALL_ZONES.




SolarisT Internals. Solaris 10 and OpenSolaris Kernel Architecture
Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture (2nd Edition)
ISBN: 0131482092
EAN: 2147483647
Year: 2004
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net