Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Network Interfaces and Network Virtualization Oracle Solaris 11 Express 11/10 |
2. NWAM Configuration and Administration (Overview)
3. NWAM Profile Configuration (Tasks)
4. NWAM Profile Administration (Tasks)
5. About the NWAM Graphical User Interface
Part II Administering Single Interfaces
6. Overview of the Networking Stack
Working With Flexible Link Names
Replacing Hardware-Based Link Names
Caution About Changing Link Names
7. Datalink Configuration and Administration
8. Configuring an IP Interface
9. Configuring Wireless Interface Communications on Oracle Solaris
Part III Administering Interface Groups
11. Administering Link Aggregations
Part IV Network Virtualization and Resource Management
15. Introducing Network Virtualization and Resource Control (Overview)
16. Planning for Network Virtualization and Resource Control
17. Configuring Virtual Networks (Tasks)
18. Using Link Protection in Virtualized Environments
19. Managing Network Resources
Network interfaces provide the connection between the system and the network. These interfaces are configured over datalinks, 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 datalink layer and a configured interface on the interface layer. This one-to-one relationship among the network device, its datalink, and the IP interface is illustrated in the figure that follows.
Note - For a fuller explanation of the TCP/IP stack, see Chapter 1, Oracle Solaris TCP/IP Protocol Suite (Overview), in System Administration Guide: IP Services.
Figure 6-1 Network Stack Showing Network Devices, Links, and 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 datalink 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 datalink layer is displayed by the dladm show-link command. The ipadm show-if command or the ifconfig -a command shows the IP interface configuration on the interface layer.
In this model, a one-to-one relationship exists that binds the device, the datalink, 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.
Oracle Solaris introduces a new implementation of the network stack in which the basic relationship between the hardware, datalink, 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 datalink layer. This feature is further explained in the following section.
From an administrative perspective, a network interface has a link name. The datalink represents a datalink 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 nge, nxge, 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 Gigabit 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 bge and e1000g. When used as the primary NIC, the Gigabit Ethernet interface has a device name such as bge or e1000g.
With the separation of the network configuration between the software layer and the hardware layer, you can now use flexible names for datalinks. The device instance name continues to be based on the underlying hardware and cannot be changed. However, the datalink 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 6-2, the following table illustrates the new correspondence between the hardware (NIC), the device instance, the link name, and the interface over the link.
|
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.
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 6-2 Types of Link Configurations in the Network Stack
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 datalink 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 datalink layer, these interfaces, like the links, can also be assigned customized names. For more information about IPMP groups, see Chapter 13, 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.
The following figure shows a bridge configuration. Two interfaces, net0 and videoagg0, are configured as a bridge, bridge0. Packets that are received on one are forwarded to the other. After bridge configuration, both interfaces can still be used to configure VLANs and IP interfaces.
Figure 6-3 Bridges in the Network Stack