On 12/05/10 12:56 PM, Sebastien Roy wrote:
...
Typical zone deployments that exist today use shared-IP zones to run
applications and services like Apache or Weblogic in the contained
environment provided by the shared-IP zone. In these use-cases, the
Administrator in the global zone has full control over the networking
resources used by the non-global zone. In the common case, networking
is simply configured by specifying the IP interface, IP addresses and,
optionally, the default routers from zonecfg(1m). The configuration
resources thus supplied are then applied for the non-global zone when
it is booted, and the non-global zone itself may not modify any of
these configuration parameters.
However, there is no such simple configuration mechanism for the
simple networking use-case in place for exclusive IP zones, which must
be configured through sysidcfg, ifconfig, and an assortment of other
methods, all of which are not controllable from the global zone, and
may not be managed through zonecfg(1m).
The addition of many new virtualization and resource management
features to Solaris (PSARC 2006/357, PSARC 2005/132 and associated
cases) makes Exclusive-IP zones a cleaner and more powerful Zone model
than shared-IP zones. Thus, bridging any gaps in the configuration
methods for the simple use cases between shared- and exlusive-IP zones
is important to ease the transition of shared-IP customer
configurations to exclusive-IP.
...
When the global-zone specifies the 'address' for an interface via
zonecfg(1m), the non-global zone may not use any other addresses for
the specified IP Version on that interface. The address information
provided via zonecfg(1m) will be used to set up Layer-3 protection
[PSARC/2009/436] for the non-global zone during zone-boot to filter
out all other addresses for the selected interface. For instance,
when zonecfg(1m) has been used in the global-zone to set one or more
IPv4 addresses on an interface, an attempt to set an IPv4 address on
the interface that is outside the globally defined set will encounter
the EPERM failure. Thus ifconfig(1m), ipadm(1m), and associated
ioctls will receive this error if they are used within the non-global
zone to set addresses that are not in the set that is permitted from
the global-zone, and attempts by the non-global zone to turn on
forwarding on the interface will also encounter EPERM. Note that IPv4
and IPv6 are considered as independent resources, so that
specification of an IPv4 address via zonecfg(1m) does not place any
constraints on permissible IPv6 addresses, and vice-versa.
Attempts to boot a zone that has already been configured for IP, or
has previously customized values for Layer-3 protection
[PSARC/2009/436] will fail.
Implementation Overview:
------------------------
A brief overview of the implementation is provided here. Note that all
interfaces between zoneadmd(1m) and the kernel/zonecfg(1m), are
Private interfaces, subject to change in the future.
When the non-global zone is booted, zoneadmd(1m) will store the
information specified by the 'address' and 'defrouter' properties as
nvlists in the kernel following a mechanism similar to that in use
today for other zonecfg(1m) resources such as the "physical"
datalink. At the same time, the zone boot process will also ensure
'ip-nospoof' protection for the datalink with the specified addresses
used as input to the 'allowed-ips' property. The stored nvlist
information for 'address' and 'defrouter' will be retrieved and
re-applied in the non-global zone by the daemon associated with the
ip-interface-management service before any other IP configuration is
applied.
What is done to ensure the alignment of "allowed-ips" and the
addresses configured?
If I change the "allowed-ips" directly with dladm after a zone
has booted, will there be any warning?
If I want to change the IP address of a network interface in a
zone that is so restricted, what is the correct procedure?
At the top, it states that if the global zone configures the address
for a network interface then the local zone is not permitted to
change it. Why should that have anything to do with forwarding?
Is the right approach being taken here? This would appear to
be a security issue (revoking the right of a zone to make a change
to its network configuration) but yet the implementation of the
support for this does not make use of any security fundamentals.
Why not?
At the bottom of this document, the man page update mentions
that this feature is incompatible with enabling forwarding. Why?
Shouldn't we be engineering Solaris to make features compatible
with each other rather than incompatible?
The GLDv3 layer communicates the set of "allowed-ips" to the IP layer
through DLPI notifications. The notification sent is a DL_NOTIFY_IND
message of (Project Private) type DL_NOTE_ALLOWED_IPS, sent to the IP
clients that have registered for this notification. The payload of
the DL_NOTE_ALLOWED_IPS message is the mac_protect_t data-structure
introduced by PSARC 2009/436. Receipt of this notification enables
the IP layer to track the current set of permitted IP addresses per
interface, so that the IP layer can return informative error
diagnostics if an attempt is made to enable forwarding or set
addresses on the interface that are outside the permitted set.
I'm uncomfortable with this because it increases the complexity
of the interaction with GLD and IP for questionable gain. My
view of this is that it is an attempt to make up for the lack
of proper architecture whereby networking resources for a zone
are supplied, set and applied.
The title of this case is "layer-3 net properties for exclusive-IP
zones" but there's nothing in the design being put forward that looks
anything like an attempt to solve this problem in a generic fashion
aside from the common repository for configuration data being the
zone configuration file. Two different properties, the IP address
and the default router, are applied to the zone in a very different
way. The danger I see here is that there is no pattern to follow for
future properties and that it is hard to recognise which one of the
two being used here would be used for others.
If, for example, I wanted to extend this work to supply other layer-3
network properties, how would I do that? Implement a new mechanism
for each one? Does that really scale?
My concern here is that given a problem that would have future benefit
from real architecture being developed, the solution that we're being
given is a few hacks to solve specific problems.
DHCP:
It is assumed that when IP resources for an IP interface have been
set up in the global-zone using zonecfg(1m), then that interface
has been marked for static IP configuration only, and attempts to
send out outgoing DHCP DISCOVER packets will be dropped in
GLDv3. Thus attempts to start DHCP on these interfaces in the
non-global zone will time out.
If we can present error messages for ifconfig/ipadm when
it attempts to change the IP address, why can't we present
an error message when someone tries to use DHCP on the
network interface?
Darren
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
