This article presents use cases of meaningful data link names.
Introduction to Datalink Interface Naming
The Nemo Unification and Vanity Naming component of project Clearview integrated into OpenSolaris build 83, which (among
other things) enables administrators to give meaningful and stable names to network datalink interfaces.
This document introduces administrators to the concept of datalink interface "vanity naming"
in OpenSolaris.
If the reader is unfamiliar with datalink interfaces and how they fit in
to Solaris networking, this document on network interface administration is recommended reading. It
gives a great overview of the networking administrative objects discussed in this article.
The vanity naming feature provides three main benefits to administrators:
It gives administrators flexibility in how they assign names to network interfaces. This flexibility enables them to assign names that are meaningful to them, for example, assigning a name that is related to the interface's higher-level function like admin0, public3, or data1.
Assigning an administratively chosen and stable name to a network interface isolates the network configuration containing that name from the underlying network topology of the system. The network topology of the system is the hardware and software that comprise the network interface, be it NIC hardware, VLANs, link aggregations, and so on. This isolation enables administrators to make changes to network topology (such as replace a NIC with another NIC of a different chip set, or aggregate existing Ethernet interfaces) without affecting software configuration on the system that contains network interface names.
This isolation of configuration from network topology makes it possible to migrate software configuration from one system to another when that configuration contains references to network interface names. Because the interface names are not tied to the underlying network topology of the systems, migrating the configuration does not require the two systems to have identical network topology.
The primary command-line tool for network administration at the datalink layer is dladm(1M).
This command enables the administrator to view, create, delete, or modify datalink
interfaces or administrative objects that are associated with datalinks interfaces. The command
now has the ability to rename datalink interfaces, which is the focus of
this article.
The basic usage of dladm is dladm subcommand, where subcommand is an action that
allows the administrator to operate on a datalink object. Some of the subcommands
used in this article are:
show-link: Display all or specified datalinks.
show-phys: Display all or specified physical datalinks.
rename-link: Rename a datalink.
create-aggr: Create a link aggregation from a set of Ethernet datalinks.
create-vlan: Create a VLAN datalink over another datalink.
show-vlan: Show all or specified VLAN datalinks.
As a basic example, to rename an existing datalink, one would type
dladm rename-link old-namenew-name, as follows:
# dladm show-link
LINK CLASS MTU STATE OVER
ce0 phys 1500 up --
# dladm rename-link ce0 net0
# dladm show-link
LINK CLASS MTU STATE OVER
net0 phys 1500 up --
Note that while link names are flexible, they must adhere to DLPI
device naming rules defined in the NOTES section of dlpi(7P). Also note that dladm(1M)
operations are persistent (changes survive across reboots) unless the -t command-line flag is used
to indicate that an operation is temporary and should not survive a
reboot. The examples in this article show persistent operations.
Because the preceding datalink is a physical datalink (as denoted by a class
of phys), the show-phys subcommand can be used to show additional information:
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
net0 Ethernet up 100 full ce0
The rest of this article focuses on concrete examples to showcase the benefits
of giving meaningful names to datalink interfaces.
Example 1: Using dladm(1M) for Lab Router Configuration
This example demonstrates how the dladm command can used to configure a system
that is part of a more complex network topology.
The system in this example has four Ethernet NICs and needs to
be the router for eight separate lab subnets. The aggregate bandwidth of four
gigabit pipes is sufficient for all of the lab subnets combined. With a
system having only so many slots, adding four more NICs is not a
scalable approach, and therefore not worthwhile. Instead, a more scalable, cost-effective approach is to
create a single link aggregation (802.3ad) including all four Ethernet links, and then
to create individual tagged VLAN interfaces (one for each subnet) on top of
this aggregation.
Here is the initial list of datalinks on the system:
# dladm show-link
LINK CLASS MTU STATE OVER
nge0 phys 1500 up --
nge1 phys 1500 up --
e1000g0 phys 1500 up --
e1000g1 phys 1500 up --
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
nge0 Ethernet up 1000Mb full nge0
nge1 Ethernet up 1000Mb full nge1
e1000g0 Ethernet up 1000Mb full e1000g0
e1000g1 Ethernet up 1000Mb full e1000g1
The first step is to rename these physical datalinks to decouple their names
from the hardware underneath. The benefit of renaming these datalinks is that if
a NIC is ever replaced with another NIC of a different chip
set, the configuration that is associated with these links won't need to be
adjusted. Before datalinks are renamed, IP interfaces on each of these links must
be unplumbed (for example, by issuing the appropriate ifconfig intf unplumb commands). Then, dladm is used
to rename the datalinks, as follows:
# dladm rename-link nge0 net0
# dladm rename-link nge1 net1
# dladm rename-link e1000g0 net2
# dladm rename-link e1000g1 net3
LINK CLASS MTU STATE OVER
net0 phys 1500 up --
net1 phys 1500 up --
net2 phys 1500 up --
net3 phys 1500 up --
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
net0 Ethernet up 1000Mb full nge0
net1 Ethernet up 1000Mb full nge1
net2 Ethernet up 1000Mb full e1000g0
net3 Ethernet up 1000Mb full e1000g1
A link aggregation can then be created by using these four Ethernet links,
giving the aggregation a meaningful name of default0:
The default0 link name was chosen for this aggregation link because this link
is the main untagged subnet for the lab network, and the network to
which the default route will point. Now the set of links looks like
the following:
# dladm show-link
LINK CLASS MTU STATE OVER
net0 phys 1500 up --
net1 phys 1500 up --
net2 phys 1500 up --
net3 phys 1500 up --
default0 aggr 1500 up net0 net1 net2 net3
Note that the show-aggr subcommand can also be used to show details that
are specific to link aggregations.
The next step is to create the VLAN links on top of
this aggregation. The lab subnets have a color-coded naming scheme, which is used
when the VLAN links are named. This scheme is convenient when diagnosing network
problems with particular systems, as the DNS naming could use a parallel scheme.
For example, if a system's hostname is blue-98, one would know to do network
snooping on the "blue" link. The VLAN links are created by using the
following commands:
Note that persistent system and application configuration must be inspected and potentially modified
to ensure that the new set of datalinks are being referred to, rather
than the original set of four Ethernet datalinks (nge0, nge1, e1000g0, and
e1000g1 in this example).
Example 2: Replacing a NIC
For this example, consider a system that has a small number of
network interfaces and that provides various network services. Assume that the system has two
interfaces, bge0 and bge1, and that when the system was installed, the interfaces
were named mgmt0 and public0. The mgmt0 interface is a back-end management interface.
The public0 interface is an Internet-facing public interface.
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
mgmt0 Ethernet up 1000 full bge0
public0 Ethernet up 1000 full bge1
This system's network and application configuration contains network interface names in potentially many
places, such as the following:
IP interface configuration files such as /etc/hostname.public0 and /etc/hostname.mgmt0.
IP filter configuration. IP filter rules in ipf.conf can contain rules like block in log quick on public0 from 10.0.0.0/8 to any. Many such rules containing network interface names might exist.
Persistent static routes such as a route installed by running the route -p add default 11.12.13.14 -ifp public0 command.
Dynamic routing information, such as the following in.routed configuration in /etc/gateways to participate in RIPv2 on a specific interface: if=public0 ripv2
If the system is part of a cluster, the cluster configuration would certainly contain network interface information.
Countless applications that might be configured to use network interfaces.
Assume that something has gone wrong with the bge1 hardware, and it needs
to be replaced. A spare NIC to replace it is available but
it is not of the same chip set. The system is DR (Dynamic
Reconfiguration) capable, and the hardware can be replaced dynamically in the following way:
# cfgadm -c disconnect PCI8
At this point, bge1 is physically removed and replaced with the other NIC
in the same PCI slot. Then, the following command is run:
# cfgadm -c configure PCI8
The new NIC's driver registers the datalink as e1000g0. This link must now
be renamed public0, as this is the name that network configuration refers to
on this system:
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
mgmt0 Ethernet up 0 full bge0
e1000g0 Ethernet up 1000 full e1000g0
# dladm rename-link e1000g0 public0
# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
mgmt0 Ethernet up 1000 full bge0
public0 Ethernet up 1000 full e1000g0
This single rename-link operation eliminated the need to reconfigure all of the network-aware
services and applications, taking much risk out of the hardware replacement. If Dynamic
Reconfiguration isn't supported by the hardware, the same benefits can be achieved by
shutting down the system, replacing the hardware, booting the system, and then renaming the
newly installed datalink as shown in this example (without the cfgadm steps).
Example 3: Zone Migration
Zone migration enables administrators to transport an installed non-global zone from one system
to another. During zone migration, an entire zone's file system and configuration are
preserved and re-applied to another system by using the zoneadm(1M) detach and attach subcommands. In
this example, an exclusive IP instance zone running a mail server is
deployed on a system (labeled system1). The administrators of the system have decided to
purchase newer, more powerful, hardware to run their services. Migrating the existing zone
to the new system (labeled system2) will be required to provide minimal
downtime to customers.
It is not always possible to ensure complete hardware compatibility from an older
system to a new one. In this example, the old system has
a quad-port Ethernet card that uses the qfe driver, and the new system
has two nge cards and two e1000g cards.
Assume that the exclusive IP instance of the non-global zone is using the
qfe2 datalink, and that this datalink has not been renamed. Migrating the zone
as required would be very difficult, as the name of the network interface
is embedded in the zone configuration and in the zone's file system (in
networking and application configuration files within the zone), and the target system doesn't
have a qfe2 datalink. The zone would either have to be reinstalled on
the new system, or existing configuration files including the zone configuration itself in
zonecfg would need to be inspected and modified. Either way, network services and
applications would need to be reconfigured, along with the zone itself. This process
could be time consuming and error prone.
Now assume that the administrator gave a meaningful name to the datalinks on
the original system prior to installing the zone. Because qfe2's purpose was to
be the exclusive interface for mail services in the zone, it was named
email0. Also, the zone was created and configured to use this datalink for
its exclusive IP instance, as follows:
system1# dladm rename-link qfe2 email0
system1# zonecfg -z emailzone
emailzone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:emailzone> create
zonecfg:emailzone> set ip-type=exclusive
zonecfg:emailzone> add net
zonecfg:emailzone:net> set physical=email0
zonecfg:emailzone:net> end
zonecfg:emailzone>
... (other zonecfg configuration)
zonecfg:emailzone> verify
zonecfg:emailzone> commit
zonecfg:emailzone> exit
The zone is installed and booted. The mail server has been configured to
use the email0 interface, as well as other network services such as routing
protocols, IP filter rules, and so on. The new system has been purchased
and brought online, and is running the same version of the operating system
as the old system (as is required by zone migration; see zoneadm(1M)
for details). In preparation for migrating the zone data, the administrator has chosen
to use the nge1 datalink for the new zone, and names it appropriately:
system2# dladm rename-link nge1 email0
There is now a datalink on the new system named email0 which will
be referred to by the zone configuration to be migrated. The zone
can now be migrated safely from system1 to system2, as follows:
system1# zoneadm -z emailzone detach
(copy the zone's filesystem from system1 to system2)
system2# zonecfg -z emailzone
emailzone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:emailzone> create -a /export/zones/emailzone
zonecfg:emailzone> commit
zonecfg:emailzone> exit
system2# zoneadm -z emailzone attach
This example shows that by proactively giving a meaningful name to a datalink
interface, a zone from one system with one set of network interfaces can
be seamlessly migrated to another system with a completely different set of network
interfaces.
Conclusion
The goal of network interface vanity naming is to enable administrators to disassociate
their network configuration from the specifics of the hardware underneath, and to protect
this configuration from the inherent variability of hardware topology.
The examples in this article demonstrate that giving meaningful and stable names to
network interfaces lowers the administrative overhead associated with making changes to networking hardware
or topology.
Discuss and comment on this resource in the BigAdmin Wiki
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
Print-friendly Version
