1. Overview & Component Interaction

1.1 Introduction

Network Profiles, the primary component of the Network Auto-Magic project, are a way to simplify network configuration management. The profiles implementation consists of a number of entities that cooperate to effect network configuration in as automated a manner as possible.

There are two primary profile types: the Network Configuration Profile (NCP), which specifies the configuration of individual network interfaces; and the Location, which specifies system-wide network configuration.

1.1.1 Network Configuration Profile (NCP)

The NCP specifies how to configure the various network interfaces; this includes information such as which interfaces should be brought up, and under which conditions that should happen; how to obtain IP address(es) for the interface(s); etc.

As it specifies individual network components, the NCP is made up of individual Network Configuration Units (NCUs). There are two types of NCUs: link and interface. Link NCUs are layer two entities such as physical devices, aggregations, vlans, or tunnels. Interface NCUs are layer three entities; specifically, IP interfaces. Interface NCUs may be basic IP interfaces (IP plumbed on a link; one or more IPv4 and/or IPv6 addresses may be assigned to the interface) or IPMP group interfaces. In Phase 1, only physical and tunnel link NCUs and basic IP interface NCUs will be supported.

Also in Phase 1, only one user-created NCP is supported; configuration of additional (inactive) NCPs is not allowed. However there will be a second NCP which is used by the NWAM service when running in automatic mode. This automatic NCP will be maintained by the NWAM service and will not be user-modifiable.

1.1.2 Location

• conditions under which the profile should be activated
• which name service(s) to use
• a domain name
• a set of IP Filter rules
• IPsec policy
• smf(5) services and properties

Only one Location may be active at any given time.

For future extensibility, it will be possible for SMF services to identify properties that should be included in an NWAM Location; those properties will then be automatically included when viewing/configuring a Location via the libnwam interface.

1.2 Component Overview

• The profile repository. This is where the configuration program stores its data, which will also be read by the profile daemon.
• The profile repository API (libnwam and netcfgd).
  • The libnwam library will provide an interface to the profile repository, allowing consumers to read and modify profiles for:
    • Links
    • IP interfaces
    • Locations (system-wide network configuration)
    • External Network Modifiers (ENMs)
  • The library will interact with the repository indirectly, via a door interface to netcfgd. netcfgd will act as a gateway to the repository, ensuring that access to the repository is only available to users with appropriate authorizations.
  • The library will also interact with the profile daemon, allowing consumers to trigger profile actions and request notification of profile-related events.
• The profile configuration programs (a.k.a. the UI).
  • There will be both CLI and GUI versions, which will perform similar if not identical tasks.
  • They will interact with the repository and the profile daemon via the libnwam interface.
  • The following tasks will be supported:
    • creating, modifying and deleting profiles
    • activating one or more profiles
    • querying information about profiles
  • The GUI will also have a component which displays current status.
• The profile daemon. This is the entity that arbitrates between the desired network configuration (e.g. I want my wired link to be brought up) and the reality (the network cable was just unplugged) to effect as complete a configuration as is possible under present conditions.
  • This reads configuration data from the repository.
  • It collects and processes external events related to links and interfaces. Some examples of external events:
    • A hotpluggable NIC is inserted/removed
    • A network cable is plugged in/unplugged
  • It dispatches events to entities that have registered interest via the libnwam interface.
  • It manages network objects, which include:
    • Links
    • IP interfaces
    • Locations
    • ENMs
    Management of these objects involves applying network configuration depending on
    • The active links and interfaces
    • Characteristics of the connected networks
    • Contingencies and dependencies built in to the active profiles
    • External events received
• The SMF network services. These are already part of Solaris, but will be modified to some extent. The daemon will restart / refresh some of these services as needed.

1.2.1 Interactions

• At any given time, one NCP and one Location are "active".
• At boot, the profile daemon consults the repository for the current active NCP, proceeds until one or more IP addresses have been configured, checks the conditions of the Locations, activates the one specified by the policy engine, and configures the network(s) accordingly.
• As events occur which may trigger a change in the network configuration, the event handler detects these and the daemon consults the active profiles and may reconfigure the network(s) accordingly. Note that some of these events may indicate that the conditions have changed.
• A change in conditions may trigger a change in the Location, which may in turn affect the network configuration.
• If a user modifies a profile, the configuration program updates the repository and notifies the daemon. If the current active profile is modified, then the daemon will reconfigure the network(s) accordingly.
• Likewise, if a user activates a new profile (NCP or Location), then the configuration program updates the repository and notifies the daemon, which will then reconfigure the network(s) accordingly. Note that a user can always manually activate a profile (NCP or Location), regardless of conditions. Also note that users who desire total control will be able to specify conditions such that a different profile is never activated automatically.

1.2.2 Examples

• There will be an out-of-the box Location for "no network" which specifies files for everything in /etc/nsswitch.conf, disables services which make no sense in a stand-alone setting, etc. Then at boot, the profile daemon would consult the conditions, note that there was no networking, then automatically select that Location.
• A user at Sun might specify a "SWAN" Location:
  • conditions of the form "apply when a network with IP addresses in the range 129.144.0.0/12 is detected"
  • a property to use name server X
  • a property to use files/dns/nis or files/nis in /etc/nsswitch.conf
  • a property to use NIS server Y
  • enable the SMF service nis/client
  • etc.
• A user might specify an NCP of the form "connect link ath0 to whatever WLAN, then use DHCP to get an IP address", then a related Location whose conditions activate it contingent on ath0 being connected to ESSID X and BSSID Y, then have a user "hook" to punchin, which creates an IPsec tunnel, thus triggering a condition check, which ultimately leads to the "SWAN" Location being activated.

1.3 Phase 0 vs. Phase 0.5 (Picea) vs. Phase 1

To understand the limitations of NWAM phase 0, it is important to first understand the target audience: laptop users. The intent in delivering a less-than-complete solution was to provide sensible default autoconfiguration for laptop users, with the following constraints:

• Prefer plugged-in wired interfaces to wireless.
• One interface active at a time. As a consequence of this and the above constraint, if a wired interface is plugged in, NWAM switches to it.
• Simple, unstable configuration to override defaults. By default, nwamd creates the /etc/nwam/llp file, which lists the IP interfaces, with wired interfaces ordered before wireless (indicating preference). In addition, interfaces were assigned the default address acquisition method: DHCP. Users could override these defaults by reordering interfaces, or specifying a static IP address in /etc/nwam/llp .
• No support for more complex link or interface types (VLANs, aggregations, tunnels, IPMP groups).
• Simple profile mechanism. Users could supply a check-conditions script, which could analyze the network configuration, and specify an upper layer profile script to run when certain conditions are met.
• No support for hotplug/DR events
• Simplified GUI interaction via zenity(1M).

Phase 0.5 introduced updates to the netstatus panel applet it make it more NWAM-friendly, as well as a basic GUI in the nwam-manager tool to improve observability and user interaction. The bulk of the phase 0 constraints remained, however; and while these constraints fit with the average laptop user's needs, NWAM Profiles need to be enhanced in a number of dimensions to scale to more a broader set of users. The first of these enhancements constitute Phase 1 of the project; the primary new features include:

• UI (both GUI and CLI) to create/modify profiles and policy.
• Better observability via GUI and CLI.
• More flexible network interface configuration: more than one interface may be active at a time; interfaces and links may have dependencies on other interfaces and links.
• Support for IP Tunnels.
• More robust profile mechanism.
• Detection of hotplug events.

Revision History