X

Solaris News, Views, and Real-World Experiences from the Field

Configuring multiple IP interfaces in a System Configuration Profile

Scott Dickson
Enterprise Systems Architect

Here's something that I missed when it came out in a Solaris 11 update and just found this week.  You can configure multiple network interfaces in the System Configuration profile for either an AI installed system or for a zone.

I always thought that when I used an AI system configuration profile to configure network interfaces, I was limited to configuring only the first address, but that's not the case.  You can actually configure multiple interfaces in the profile.  The big benefit to this is you may be able to avoid having to have a finish script or any sort of after-installation mechanism just to configure network interfaces.  Of course, you have to know the names of the network interfaces.  For the built-in interfaces, this is easy.  For additional interfaces on NIC cards, it may not be quite as simple.  For zones, since you can define the names of every interface, it is always seasy.

The Old Way - Single Interface Configuration

You have always been able to use sysconfig to create a system configuration profile that provided the identity to an OS instance being installed: hostname, IP addresses, terminal type, locale, timezone, etc.  Often, you might use sysconfig just once and then edit the XML for each subsequent installation, using installadm criteria to select which profile you might want to use.  You could also make use (when using the Automated Installer - AI) to use macros to generalize the configuration and use the values passed through the boot process.

So, the section of the system configuration profile to configure both IPv4 and IPv6 addresses on net0 would look like this: (I have left out the service_bundle section at the top and bottom of the XML and am just showing the particular services used for network configuration).

  <service version="1" type="service" name="system/identity">
    <instance enabled="true" name="node">
      <property_group type="application" name="config">
        <propval type="astring" name="nodename" value="{{AI_HOSTNAME}}"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="network/install">
    <instance enabled="true" name="default">
      <property_group type="application" name="install_ipv6_interface">
        <propval type="astring" name="stateful" value="yes"/>
        <propval type="astring" name="address_type" value="addrconf"/>
        <propval type="astring" name="name" value="net0/v6"/>
        <propval type="astring" name="stateless" value="yes"/>
      </property_group>
      <property_group type="application" name="install_ipv4_interface">
        <propval type="net_address_v4" name="static_address" value="{{AI_IPV4}}/{{AI_IPV4_PREFIXLEN}}"/>
        <propval type="astring" name="name" value="{{AI_NETLINK_VANITY}}/v4"/>
        <propval type="astring" name="address_type" value="static"/>
        <propval type="net_address_v4" name="default_route" value="{{AI_ROUTER}}"/>
      </property_group>
    </instance>
  </service>

You can see the way that the {{AI_HOSTNAME}} macro is used to set the nodename of the server in the system/identity service, as well as the various pieces of the IPv4 address in the network/install service.  Take a look at the Solaris installation manual in the section called Using System Configuration Profile Templates.

The key parts of this profile are the two property groups for install_ipv4_interface and install_ipv6_interface.  In each property group, you can assign the properties with the necessary values to configure the network.  If you choose not to have an IPv6 interface, just eliminate this property group in the profile and it will not be configured (except for the loopback, which requires an IPv6 address).   With these property groups, you can configure any single interface - one for IPv6 and one for IPv4 - but you can't just replicate these property groups to configure additional interfaces.

The New Way - Multiple Interface Configuration

As it turns out, you actually can configure multiple interfaces within the SC profile.  You just need additional property groups for each interface you choose to configure.  In Solaris 11, SMF was significantly extended.  One of the extensions allowed for new property groups and properties to be defined in a profile dynamically.  Previously, they were all statically defined in the service manifest.

Now, in addition to the install_ipv6_interface and install_ipv4_interface property groups, you can add additional property groups.  Each one has to be of type ipv6_interface or ipv4_interface and can be named with any valid property group name.  Each of these property groups uses the same set of properties as their corresponding pre-defined group.  This means that property groups of type ipv4_interface use the same properties as the install_ipv4_interface property group, and likewise for IPv6.

  <service version="1" type="service" name="network/install">
    <instance enabled="true" name="default">
      <property_group type="application" name="install_ipv6_interface">
        <propval type="astring" name="stateful" value="yes"/>
        <propval type="astring" name="address_type" value="addrconf"/>
        <propval type="astring" name="name" value="net0/v6"/>
        <propval type="astring" name="stateless" value="yes"/>
      </property_group>
      <property_group type="ipv6_interface" name="install_ipv6_addr">
        <propval type="net_address_v6" name="static_address" value="2620:0160:daef:0001::11/64"/>
        <propval type="astring" name="name" value="net0/v6static"/>
        <propval type="astring" name="address_type" value="static"/>
        <propval type="net_address_v6" name="default_route" value="2620:0160:daef:0001::1/64"/>
      </property_group>
      <property_group type="application" name="install_ipv4_interface">
        <propval type="net_address_v4" name="static_address" value="10.80.162.150/24"/>
        <propval type="astring" name="name" value="net0/v4"/>
        <propval type="astring" name="address_type" value="static"/>
        <propval type="net_address_v4" name="default_route" value="10.80.162.1"/>
      </property_group>
      <property_group type="ipv4_interface" name="install_ipv4_net1">
        <propval type="net_address_v4" name="static_address" value="10.80.163.150/24"/>
        <propval type="astring" name="name" value="net1/v4"/>
        <propval type="astring" name="address_type" value="static"/>
      </property_group>
    </instance>
  </service>

In the above example, we use this capability in two different ways.  First, we assign an IPv4 address to both net0 and net1, using the same address on two different subnets.  This is probably the most common use case.  So long as you know the name of the interface where you want to assign an address, you can configure several network interfaces this way at system configuration time.  This removes the need to have a first-boot service and package just to
configure the network, or to use Puppet or some other after-installation
tool to manage the configuration.

Notice, that we did not use the AI macros in this example.  First, there are no macros that would help define the second interface.  Second, in a case where you are configuring multiple interfaces, chances are that you will need much more precise control than the AI macros provide - different subnets, specific interfaces, etc.  This means that you will be more likely either to use installadm criteria to select a particular profile for a host or to use a derived manifest to create the manifest and profile at install-time.

For the IPv6 interface, we want to assign a global scope static address.  There has to be a link-local scope address in place before a global scope address can be assigned.  As it turns out, ipadm does not create the link-local address when you create a static address.  So, we have to use addrconf since it creates the link-local address on the interface.  Then, we can define a second address that is the global scope static address that we really wanted.

So, you can see, that this small feature really does help and makes it a lot easier to create both VMs and bare-metal systems configured just the way you need right from their initial installation.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.