System Administration Guide: Network Interfaces and Network Virtualization

Network Interface Administration in the Solaris Operating System

This chapter introduces network administration in the Solaris OS. It describes interrelationships that underlie interfaces, data links over which the interfaces are configured, and network devices. Support for flexible names for data links is also discussed at length.

Overview of the Networking Stack

Network interfaces provide the connection between the system and the network. These interfaces are configured over data links, which in turn correspond to instances of hardware devices in the system. Network hardware devices are also called network interface cards (NICs) or network adapters. NICs can be built in and already present in the system when the system is purchased. However, you can also purchase separate NICs to add to the system. Certain NICs have only a single interface that resides on the card. Many other brands of NICs have multiple interfaces that you can configure to perform network operations.

In the current model of the network stack, interfaces and links on the software layer build on the devices in the hardware layer. More specifically, a hardware device instance in the hardware layer has a corresponding link on the data-link layer and a configured interface on the interface layer. This one-to-one relationship among the network device, its data link, and the IP interface is illustrated in the figure that follows.

Note –

For a fuller explanation of the TCP/IP stack, see Chapter 1, Solaris TCP/IP Protocol Suite (Overview), in System Administration Guide: IP Services.

Figure P–1 Network Stack Showing Network Devices, Links, and Interfaces

One-to-one relationship between hardware devices, links,
and IP interfaces.

The figure shows two NICs on the hardware layer: ce with a single device instance ce0, and qfe with multiple device instances, qfe0 to qfe3. The devices qfe0 through qfe2 are not used. Devices ce0 and qfe3 are used and have corresponding links ce0 and qfe3 on the data-link layer. In the figure, the IP interfaces are likewise named after their respective underlying hardware, ce0 and qfe3. These interfaces can be configured with IPv4 or IPv6 addresses to host both types of network traffic. Note also the presence of the loopback interface lo0 on the interface layer. This interface is used to test, for example, that the IP stack is functioning properly.

Different administrative commands are used at each layer of the stack. For example, hardware devices that are installed on the system are listed by the dladm show-dev command. Information about links on the data-link layer is displayed by the dladm show-link command. The ifconfig command shows the IP interface configuration on the interface layer.

In this model, a one-to-one relationship exists that binds the device, the data link, and the interface. This relationship means that network configuration is dependent on hardware configuration and network topology. Interfaces must be reconfigured if changes are implemented in the hardware layer, such as replacing the NIC or changing the network topology.

The Solaris OS introduces a new implementation of the network stack in which the basic relationship between the hardware, data link, and interface layers remains. However, the software layer is decoupled from the hardware layer. With this separation, network configuration on the software level is no longer bound to the chipset or the network topology in the hardware layer. The new implementation makes network administration more flexible in the following two ways:

The network configuration is insulated from any changes that might occur in the hardware layer. Link and interface configurations are preserved even if the underlying hardware is removed. These same configurations can then be reapplied to any replacement NIC, provided that the two NICs are of the same type.
The separation of the network configuration from the network hardware configuration also allows the use of customized link names in the data-link layer. This feature is further explained in the following section.

Assigning Names to Data Links

From an administrative perspective, a network interface has a link name. The data link represents a data-link object in the second layer of the Open Systems Interconnection (OSI) model. The physical link is directly associated with a device and possesses a device name. The device name is essentially the device instance name, and is composed of the driver name and the device instance number.

Driver names can be ce, hme, bge, e1000g, among many other driver names. The variable instance-number can have a value from zero to n, depending on how many interfaces of that driver type are installed on the system.

For example, consider a 100BASE-TX Fast Ethernet card, which is often used as the primary NIC on both host systems and server systems. Some typical driver names for this NIC are eri, qfe, and hme. When used as the primary NIC, the Fast Ethernet interface has a device name such as eri0 or qfe0.

Only one interface can be configured on NICs such as eri and hme. However, many brands of NICs can have multiple interfaces. For example, the Sun Quad FastEthernet^TM (qfe) card has four interfaces, qfe0 through qfe3. See Figure P–1.

With the separation of the network configuration between the software layer and the hardware layer, you can now use flexible names for data links . The device instance name continues to be based on the underlying hardware and cannot be changed. However, the data link name is no longer similarly bound. Thus, you can change the device instance's link name to a name that is more meaningful in your network setup. You assign a customized name to the link, and then perform network configuration and maintenance tasks by referring to the assigned link name instead of the hardware-based name.

Using the information in Figure P–2, the following table illustrates the new correspondence between the hardware (NIC), the device instance, the link name, and the interface over the link.

Hardware (NIC)	Device Instance	Link's Assigned Name	IP Interface
`ce`	`ce0`	`subitops0`	`subitops0`
`qfe`	`qfe3`	`subitops1`	`subitops1`

As the table indicates, the ce0 device instance's link is assigned the name subitops0, while the link for the qfe3 instance is assigned the name subitops1. Such names allow you to readily identify links and their functions on the system. In this example, the links have been designated to service IT Operations.

Administration of Other Link Types

The separation between network configuration and network hardware configuration introduces the same flexibility to other types of link configurations. For example, virtual local area networks (VLANs), link aggregations, and IP tunnels can be assigned administratively-chosen names and then configured by referring to those names. Other related tasks, such as performing dynamic reconfiguration (DR) to replace hardware devices, are also easier to perform because no further network reconfiguration is required, provided that the network configuration was not deleted.

The following figure shows the interrelationship among devices, link types, and their corresponding interfaces.

Figure P–2 Types of Link Configurations in the Network Stack

Panoramic view of devices, and different link configurations

The figure also provides a sample of how administratively chosen names can be used in the network setup;

The device instances ce0 and qfe3 are designated to service traffic for IT Operations, and hence given the link names subitops0 and subitops1. The customized names facilitate the identification of the roles of these links.
VLANs are configured on the subitops0 link. These VLANs, in turn, are also assigned customized names, such as sales1 and sales2. The VLAN sales2's IP interface is plumbed and operational.
The device instances qfe0 and qfe2 are used to service video traffic. Accordingly, the corresponding links in the data-link layer are assigned the names subvideo0 and subvideo1. These two links are aggregated to host video feed. The link aggregation possesses its own customized name as well, video0.
Two interfaces (subitops0 and subitops1) with different underlying hardware (ce and qfe) are grouped together as an IPMP group (itops0) to host email traffic.

Note –
Although IPMP interfaces are not links on the data-link layer, these interfaces, like the links, can also be assigned customized names. For more information about IPMP groups, see Chapter 7, Introducing IPMP.
Two interfaces have no underlying devices: the tunnel vpn1, which is configured for VPN connections and lo0 for IP loopback operations.

All of the link and interface configurations in this figure are independent of the configurations in the underlying hardware. For example, if the qfe card is replaced, the video0 interface configuration for video traffic remains and can later be applied to a replacement NIC.

Considerations for Working With Link Names

After you install the Solaris OS, your system's network links retain their original hardware-based names, such as bge0 or ce0. However, in the new network implementation, these link names are no longer bound to their associated hardware. You can replace the link names with names that are more meaningful within the context of your network environment. Interface configurations are then performed by using the link names.

Before you change link names, note the following important considerations.

Replacing Hardware-Based Link Names

If your system's links have hardware-based names, rename these links with at least neutral names. If you retain the hardware-based names of the links, confusion might arise in later situations where these physical devices are removed or replaced.

For example, you retain the link name bge0 that is associated with the device bge0. All link configurations are performed by referring to the link name. Later, you might replace the NIC bge with the NIC ce. To reapply the former device's link configuration to the new NIC ce0, you would need to reassign the link name bge0 to ce0. The combination of a hardware-based link name bge0 with a different associated NIC ce0 can cause confusion. By using names that are not hardware-based, you can better distinguish the links from the associated devices.

Caution About Changing Link Names

Replacing hardware-based link names is recommended. However, you must plan carefully before you rename links. Prior to the installation of the Solaris release, your system might already have other configurations that are associated with the NIC's hardware-based name. Changing the device's link name does not automatically propagate the new name to all associated configurations. The following examples illustrate the risks when you change link names:

You create a VLAN link, bge1000, over the link bge0. If you rename bge0 to net0, this step applies only to the link bge0. If you attempt to plumb net1000, the operation fails because the VLAN link continues to exist as bge1000. If you then unplumb and replumb bge1000, replumbing fails because bge0 no longer exists after being renamed net0.
Some rules in a Solaris IP Filter configuration apply to specific links. When you change a link's name, the filter rules continue to refer to the link's original name. Consequently, these rules no longer behave as expected after you rename the link. You need to adjust the filter rules to apply to the link by using the new link name.

Thus, as a general rule, do not rename data links randomly. When renaming data links, ensure that all of the link's associated configurations continue to apply after the link name is changed. Some of the configurations that might be affected by renaming links are as follows:

Solaris IP Filter rules
All IP configurations that are specified in configuration files such as /etc/dhcp.* or /etc/hostname[6].*
Zones
autopush configuration

Note –
No changes are required in the autopush configuration when you rename links. However, you must be aware of how the configuration would work with the per-link autopush property after the link has been renamed. For more information, see How to Set STREAMS Modules on Data Links.

When to Rename Links

The following describe circumstances when renaming links can be usefully applied:

To identify an available link by another name. For example, a link bge0 is renamed to net0. In this situation, all link configuration of bge0 becomes based on net0. Note that renaming the link is allowed only if the original link, bge0 in this example, is not in use.
To transfer a configuration of a removed physical link to a nonexistent link. The second link is nonexistent because the replacement hardware is not yet connected to the system. For example, support0 is the link name of the device instance bge0. The NIC bge is removed to be replaced by the NIC ce. Even before you install the NIC ce on the system, you can already issue the command to rename the data link ce0 to support0. After you connect the NIC, ce0 inherits all the configuration that was formerly based on bge0.
To transfer an inactive link configuration of a removed NIC to a connected replacement link. This case is similar to the preceding case except that the replacement NIC is connected first before the inactive link is renamed. Thus, the replacement device ce is first connected, and then renamed support0.

Rules for Valid Link Names

When you assign link names, observe the following rules:

Link names consist of a string and a physical point of attachment (PPA) number.
The name must abide by the following constraints:
- Names consist of between 3 to 8 characters. However, names can have a maximum of 16 characters.
- Valid characters for names are alphanumeric (a-z, 0–9) and the underscore ('_').
  
  Caution –
  Do not use upper case letters on link names.
Each data link must have only one link name at one time.
Each data link must have a unique link name within the system.

Note –

As an added restriction, you cannot use lo0 as a flexible link name. This name is reserved to identify the IP loopback interface.

The function of the link within your network setup can be a useful reference when you assign link names. For example, netmgt0 can be a link that is dedicated to network management. Upstream2 can be the link that connects to the ISP. As a general rule to avoid confusion, do not assign names of known devices to your links.

Link Names and the `dladm` Command

Subcommands of the dladm command have either been created or modified to work with link names. For more detailed information about dladm subcommands, refer to the dladm(1M) man page.

show-phys: Displays the device names and the physical attributes of each device. This subcommand displays the equivalent information as the show-dev subcommand. However, to leverage the use of link names, use the show-phys subcommand instead of the show-dev subcommand.
rename-link: Assigns a new link name to replace an existing link name.
show-link: Displays information about available data links in the system.
create-vlan: Configures a VLAN in the network.
show-vlan: Lists existing VLANs in the network.
delete-vlan: Removes an unused VLAN. A VLAN that is being used cannot be deleted.
delete-phys: Removes all link configurations that are associated with a removed NIC. This operation allows the link name to be used with another data-link with new link configurations.

Changes were also implemented on current dladm subcommands to enable the following operations to work with link names:

Creating link aggregations.
Administering autopush link properties.