Sun Microsystems SOLARIS 10 - Manual (Page 48)

Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.1.7. Network concepts
4.1.7.1. Introduction into networks and zones
[dd] A network address is not mandatory when configuring a zone. However, services within a zone
can only be reached from the outside through the network. Therefore at least one network address
per zone is typically required (configurable with zonecfg).
A zone's network address can be placed as a virtual interface in any physical interface (shared IP
instance) or directly in a physical interface assigned exclusively to the zone (exclusive IP
instance). The different types of IP instances are explained in (
4.1.7.4 Exclusive IP instance ) .
For shared IP instances, routes for the local zone networks can be entered in the zone configuration.
This ensures that when the zone is booted, the corresponding routing entry exists in the global zone.
The IP stack of the global zone contains and manages all routes of the shared IP instance. Exclusive
IP instances manage their own routing tables and are assigned to exactly one zone.
4.1.7.2. Network address management for zones
[ug] DHCP is not possible for addresses of zones with shared IP instances since DHCP is based on
the HW address of the network interface (MAC). Zones use a virtual address on a shared network
interface: therefore, they have the same MAC address as the interface in the global zone. The
management of network addresses for zones must therefore take place in a different manner.
Basically, the following types of management are possible:
• Manual list-keeping.
When configuring the zone, the IP address must therefore be tagged in the list.
• Predefining the IP addresses with the zone name in name service.
When configuring the zone, a script can thus automatically detect the IP address of the zone if
the IP name can be computed from the zone name (Cookbook).
• If many zones are to be set up on a system, it is advisable to allocate an entire range of IP
addresses in advance where the network address is equal to the intended zone name. This
ensures definite allocation.
• Integration into the IP naming system of the target environment,
f.e. integration into the organizational processes of the company's IP allocation.
4.1.7.3. Shared IP instance and routing between zones
[dd] Each zone has at least one IP address of its own and its own TCP and UDP port numbers.
Applications that are used in zones attach themselves to the IP addresses visible in the zone and
also use them as sender addresses. This allows logical network separation between the zones.
If zones are located in different logical subnets as a result of corresponding address allocation, and if
it is necessary that the zone communicates with other networks, separate routes must exist for each
zone. These are placed in the global zone by means of zone configuration since the routing table is
located in the TCP/IP stack which is shared among all zones (shared IP instance). If such a
route is set up for a zone, inter-zone communication (local zone to local zone) takes place directly via
the shared IP instance. If this inter-zone communication is to be prevented, so-called reject routes
must be used that prevent any communication between two IP addresses of a single IP instance.
Another way to inhibit communication between shared-IP zones is by configuration of the IP Stack
with ndd:
ndd -set /dev/ip ip_restrict_interzone_loopback 1
This can also be set into /etc/system to make it permanently.
If targeted communication between two local zones is required but if it should be conducted e.g. via
an external router, load balancer or firewall, NAT-capable routers must be used. Corresponding
setups are discussed in section
5 . Cookbooks .
41