This chapter contains tasks and information about network interfaces:
The information in this chapter describes interface configuration starting with the Solaris 10 1/06 release. If you are using the original release of Solaris 10, 3/05, refer to Administering Interfaces in Solaris 10 3/05. For a complete listing of new Oracle Solaris features and a description of Oracle Solaris releases, refer to Oracle Solaris 10 9/10 What’s New.
In Solaris 10 1/06, the following new features were introduced:
The new dladm command for viewing interface status is introduced in How to Configure a Physical Interface After System Installation.
VLAN support has extended to GLDv3 interfaces, as explained in Administering Virtual Local Area Networks.
Link aggregation support is introduced in Overview of Link Aggregations.
In Solaris 10 7/07, the /etc/inet/ipnodes becomes obsolete. Use /etc/inet/ipnodes only for earlier Solaris 10 releases, as explained in the individual procedures.
The following table lists different tasks for configuring network interfaces, including special configurations such as VLANs and link aggregations. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.
Task |
Description |
For Instructions |
---|---|---|
Check the status of interfaces on a system. |
List all interfaces on the system and check which interfaces are already plumbed. | |
Add a single interface after system installation. |
Change a system to a multihomed host or router by configuring another interface. |
How to Configure a Physical Interface After System Installation |
SPARC: Check that the MAC address of an interface is unique. |
Ensure that the interface is configured with its factory-installed MAC address, rather than the system MAC address (SPARC only). |
SPARC: How to Ensure That the MAC Address of an Interface Is Unique |
Plan for a virtual local area network (VLAN). |
Perform required planning tasks prior to creating a VLAN. | |
Configure a VLAN. |
Create and modify VLANs on your network. | |
Plan for aggregations. |
Design your aggregation and perform required planning tasks prior to configuring aggregations. | |
Configure an aggregation. |
Perform various tasks related to link aggregations. | |
Plan for and configure an IPMP group. |
Configure failover and failback for interfaces that are members of an IPMP group. |
After Oracle Solaris installation, you might configure or administer interfaces on a system for the following purposes:
To upgrade the system to become a multihomed host. For more information, refer to Configuring Multihomed Hosts.
To change a host to a router. For instructions on configuring routers, refer to Configuring an IPv4 Router.
To configure interfaces as part of a VLAN. For more information, refer to Administering Virtual Local Area Networks.
To configure interfaces as members of an aggregation. For more information, refer to Overview of Link Aggregations.
To add an interface to an IPMP group. For instructions on configuring an IPMP group, refer to Configuring IPMP Groups
This section contains information about configuring individual network interfaces , starting with the Solaris 10 1/06 release. Refer to the following sections for information about configuring interfaces into one of the following groupings:
For configuring interfaces into a VLAN, refer to Administering Virtual Local Area Networks.
For configuring interfaces into an aggregation, refer to Overview of Link Aggregations.
For configuring interfaces as members of IPMP groups, refer to Configuring IPMP Groups.
Starting with Solaris 10 1/06, this procedure explains how to determine which interfaces are currently available on a system and their status. This procedure also shows which interfaces are currently plumbed. If you are using the earlier Solaris 10 3/05, refer to How to Get Information About a Specific Interface.
On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine which interfaces are currently installed on your system.
# dladm show-link |
This step uses the dladm command, which is explained in detail in the dladm(1M) man page. This command reports on all the interface drivers that it finds, regardless of whether the interfaces are currently configured.
Determine which interfaces on the system are currently plumbed.
# ifconfig -a |
The ifconfig command has many additional functions, including plumbing an interface. For more information, refer to the ifconfig(1M) man page.
The next example shows the status display of the dladm command.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 |
The output of dladm show-link indicates that four interface drivers are available for the local host. Both the ce and the bge interfaces can be configured for VLANs. However, only the GLDV3 interfaces with a type of non-VLAN can be used for link aggregations.
The next example shows the status display of the ifconfig -a command.
# ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 3 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e bge0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>mtu 1500 index 2 inet 10.8.57.39 netmask ffffff00 broadcast 10.8.57.255 ether 0:3:ba:29:fc:cc |
The output of the ifconfig -a command displays statistics for only two interfaces, ce0 and bge0. This output shows that only ce0 and bge0 have been plumbed and are ready for use by network traffic. These interfaces can be used in a VLAN. Because bge0 has been plumbed, you can no longer use this interface in an aggregation.
Use the next procedure for configuring interfaces. If you are using the Solaris 10 3/05 release, use the procedure How to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY.
Determine the IPv4 addresses that you want to use for the additional interfaces.
Ensure that the physical interface to be configured has been physically installed onto the system. For information about installing separately purchased NIC hardware, refer to the manufacturer's instructions that accompany the NIC.
If you have just installed the interface, perform a reconfiguration boot before proceeding with the next task.
On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine which interfaces are currently installed on the system.
# dladm show-link |
Configure and plumb each interface.
# ifconfig interface plumb up |
For example, for qfe0 you would type:
# ifconfig qfe0 plumb up |
Interfaces that are explicitly configured with the ifconfig command do not persist across a reboot.
Assign an IPv4 address and netmask to the interface.
# ifconfig interface IPv4-address netmask+netmask |
For example, for qfe0 you would type:
# ifconfig qfe0 192.168.84.3 netmask + 255.255.255.0 |
You can specify an IPv4 address in either traditional IPv4 notation or CIDR notation.
Verify that the newly configured interfaces are plumbed and configured, or “UP.”
# ifconfig -a |
Check the status line for each interface that is displayed. Ensure that the output contains an UP flag on the status line, for example:
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 |
(Optional) To make the interface configuration persist across reboots, perform the following steps:
Create an /etc/hostname.interface file for each interface to be configured.
For example, to add a qfe0 interface, you would create the following file:
# vi /etc/hostname.qfe0 |
If you create alternate hostname files for the same interface, the alternate files must also follow the naming format hostname.[0–9]*, such as hostname.qfe0.a123. Names such as hostname.qfe0.bak or hostname.qfe0.old are invalid and will be ignored by scripts during system boot.
Note, too, that a given interface must have only one corresponding hostname file. If you create an alternate hostname file for an interface with a valid filename, such as /etc/hostname.qfe and /etc/hostname.qfe.a123, the boot scripts will attempt to configure by referencing the contents of both hostname files and would therefore generate errors. To prevent these errors, provide an invalid file name to the hostname file that you do not want to use in a given configuration.
Edit the /etc/hostname.interface file.
At a minimum, add the IPv4 address of the interface to the file. You can use traditional IPv4 notation or CIDR notation to specify the IP address of the interface. You can also add a netmask and other configuration information to the file.
To add an IPv6 address to an interface, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers
For Solaris 10 11/06 and earlier releases of Oracle Solaris 10, add entries for the new interfaces into the /etc/inet/ipnodes file.
Add entries for the new interfaces into the /etc/inet/hosts file.
Perform a reconfiguration boot.
# reboot -- -r |
Verify that the interface you created in the /etc/hostname.interface file has been configured.
# ifconfig -a |
For examples, refer to Example 6–2.
The example shows how to configure the interfaces qfe0 and qfe1 to a host. These interfaces remain persistent across reboots.
# dladm show-link eri0 type: legacy mtu: 1500 device: eri0 qfe0 type: legacy mtu: 1500 device: qfe0 qfe1 type: legacy mtu: 1500 device: qfe1 qfe2 type: legacy mtu: 1500 device: qfe2 qfe3 type: legacy mtu: 1500 device: qfe3 bge0 type: non-vlan mtu: 1500 device: bge0 # vi /etc/hostname.qfe0 192.168.84.3 netmask 255.255.255.0 # vi /etc/hostname.qfe1 192.168.84.72 netmask 255.255.255.0 # vi /etc/inet/hosts # Internet host table # 127.0.0.1 localhost 10.0.0.14 myhost 192.168.84.3 interface-2 192.168.84.72 interface-3 For Solaris 10 11/06 and earlier releases:# vi /etc/inet/ipnodes 10.0.0.14 myhost 192.168.84.3 interface-2 192.168.84.72 interface-3 |
At this point, you would reboot the system.
# reboot -- -r |
After the system boots, you would then verify the interface configuration.
ifconfig -a # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 qfe0:flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.3 netmask ffffff00 broadcast 192.255.255.255 ether 8:0:20:c8:f4:1d qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4 inet 192.168.84.72 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c8:f4:1e |
To configure an IPv6 address onto an interface, refer to How to Enable an IPv6 Interface for the Current Session.
To set up failover detection and failback for interfaces by using IP Network Multipathing (IPMP), refer to Chapter 31, Administering IPMP (Tasks).
Use this procedure for removing a physical interface. If you are using the earlier Solaris 10 3/05, refer to How to Remove a Physical Interface in Solaris 10 3/05 ONLY.
On the system with the interface to be removed, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Remove the physical interface.
# ifconfig interface down unplumb |
For example, to remove the interface qfe1, you would type:
# ifconfig qfe1 down unplumb |
Use this procedure for configuring MAC addresses.
Some applications require every interface on a host to have a unique MAC addresses. However, every SPARC based system has a system-wide MAC address, which by default is used by all interfaces. Here are two situations where you might want to configure the factory-installed MAC addresses for the interfaces on a SPARC system.
For link aggregations, you should use the factory-set MAC addresses of the interfaces in the aggregation configuration.
For IPMP groups, each interface in the group must have a unique MAC address. These interfaces must use their factory-installed MAC addresses.
The EEPROM parameter local-mac-address? determines whether all interfaces on a SPARC system use the system-wide MAC address or their unique MAC address. The next procedure shows how to use the eeprom command to check the current value of local-mac-address? and change it, if necessary.
On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine whether all interfaces on the system currently use the system-wide MAC address.
# eeprom local-mac-address? local-mac-address?=false |
In the example, the response to the eeprom command, local-mac-address?=false, indicates that all interfaces do use the system-wide MAC address. The value of local-mac-address?=false must be changed to local-mac-address?=true before the interfaces can become members of an IPMP group. You should also change local-mac-address?=false to local-mac-address?=true for aggregations.
If necessary, change the value of local-mac-address? as follows:
# eeprom local-mac-address?=true |
When you reboot the system, the interfaces with factory-installed MAC addresses now use these factory settings, rather than the system-wide MAC address. Interfaces without factory-set MAC addresses continue to use the system-wide MAC address.
Check the MAC addresses of all the interfaces on the system.
Look for cases where multiple interfaces have the same MAC address. In this example, all interfaces use the system-wide MAC address 8:0:20:0:0:1.
ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 ce0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.114 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 ce1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 |
Continue to the next step only if more than one network interface still has the same MAC address. Otherwise, go on to the final step.
If necessary, manually configure the remaining interfaces so that all interfaces have unique MAC address.
Specify a unique MAC address in the /etc/hostname.interface file for the particular interface.
In the example in Step 4, you would need to configure ce0 and ce1 with locally administered MAC addresses. For example, to reconfigure ce1 with the locally administered MAC address 06:05:04:03:02, you would add the following line to /etc/hostname.ce1:
ether 06:05:04:03:02 |
To prevent any risk of manually configured MAC addresses conflicting with other MAC addresses on your network, you must always configure locally administered MAC addresses, as defined by the IEEE 802.3 standard.
You also can use the ifconfig ether command to configure an interface's MAC address for the current session. However, any changes made directly with ifconfig are not preserved across reboots. Refer to the ifconfig(1M) man page for details.
Reboot the system.
Network interfaces provide the connection between a system and a network. An Oracle Solaris-based system can have two types of interfaces, physical and logical. Physical interfaces consist of a software driver and a connector into which you connect network media, such as an Ethernet cable. Physical interfaces can be grouped for administrative or availability purposes. Logical interfaces are configured onto existing physical interfaces, usually for adding addresses and creating tunnel endpoints on the physical interfaces.
Logical network interfaces are described in the tasks where they are used: IPv6 tasks, IPMP tasks, DHCP tasks, and others.
Most computer systems have at least one physical interface that is built-in by the manufacturer on the main system board. Some systems can also have more than one built-in interface.
In addition to built-in interfaces, you can add separately purchased interfaces to a system. A separately purchased interface is known as a network interface card (NIC). You physically install a NIC according to the manufacturer's instructions.
NICs are also referred to as network adapters.
During system installation, the Oracle Solaris installation program detects any interfaces that are physically installed and displays each interface's name. You must configure at least one interface from the list of interfaces. The first interface to be configured during installation becomes the primary network interface. The IP address of the primary network interface is associated with the configured host name of the system, which is stored in the /etc/nodename file. However, you can configure any additional interfaces during installation or later.
Each physical interface is identified by a unique device name. Device names have the following syntax:
<driver-name><instance-number> |
Driver names on Oracle Solaris systems could include ce, hme, bge, e1000g and 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 interface, which is often used as the primary network interface on both host systems and server systems. Some typical driver names for this interface are eri, qfe, and hme. When used as the primary network interface, the Fast Ethernet interface has a device name such as eri0 or qfe0.
NICs such as eri and hme have only one interface. However, many brands of NICs have multiple interfaces. For example, the Quad Fast Ethernet (qfe) card has four interfaces, qfe0 through qfe3.
An interface must be plumbed before it can pass traffic between the system and the network. The plumbing process involves associating an interface with a device name. Then, streams are set up so that the interface can be used by the IP protocol. Both physical interfaces and logical interfaces must be plumbed. Interfaces are plumbed either as part of the boot sequence or explicitly, with the appropriate syntax of the ifconfig command.
When you configure an interface during installation, the interface is automatically plumbed. If you decide during installation not to configure the additional interfaces on the system, those interfaces are not plumbed.
Starting with the Solaris 10 1/06 release, Oracle Solaris supports the following two types of interfaces:
Legacy interfaces – These interfaces are DLPI interfaces and GLDv2 interfaces. Some legacy interface types are eri, qfe, and ce. When you check interface status with the dladm show-link command, these interfaces are reported as “legacy.”
Non-VLAN interfaces – These interfaces are GLDv3 interfaces.
Currently GLDv3 is supported on the following interface types: bge, xge, and e1000g.
If you are using the earlier Solaris 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.
A virtual local area network (VLAN) is a subdivision of a local area network at the datalink layer of the TCP/IP protocol stack. You can create VLANs for local area networks that use switch technology. By assigning groups of users to VLANs, you can improve network administration and security for the entire local network. You can also assign interfaces on the same system to different VLANs.
Consider dividing your local network into VLANs if you need to do the following:
Create a logical division of workgroups.
For example, suppose all hosts on a floor of a building are connected on one switched-based local network. You could create a separate VLAN for each workgroup on the floor.
Enforce differing security policies for the workgroups.
For example, the security needs of a Finance department and an Information Technologies department are quite different. If systems for both departments share the same local network, you could create a separate VLAN for each department. Then, you could enforce the appropriate security policy on a per-VLAN basis.
Split workgroups into manageable broadcast domains.
The use of VLANs reduces the size of broadcast domains and improves network efficiency.
Switched LAN technology enables you to organize the systems on a local network into VLANs. Before you can divide a local network into VLANs, you must obtain switches that support VLAN technology. You can configure all ports on a switch to serve a single VLAN or multiple VLANs, depending on the VLAN topology design. Each switch manufacturer has different procedures for configuring the ports of a switch.
The following figure shows a local area network that has the subnet address 192.168.84.0. This LAN is subdivided into three VLANs, Red, Yellow, and Blue.
Connectivity on LAN 192.168.84.0 is handled by Switches 1 and 2. The Red VLAN contains systems in the Accounting workgroup. The Human Resources workgroup's systems are on the Yellow VLAN. Systems of the Information Technologies workgroup are assigned to the Blue VLAN.
Each VLAN in a local area network is identified by a VLAN tag, or VLAN ID (VID). The VID is assigned during VLAN configuration. The VID is a 12-bit identifier between 1 and 4094 that provides a unique identity for each VLAN. In Figure 6–1, the Red VLAN has the VID 789, the Yellow VLAN has the VID 456, and the Blue VLAN has the VID 123.
When you configure switches to support VLANs, you need to assign a VID to each port. The VID on the port must be the same as the VID assigned to the interface that connects to the port, as shown in the following figure.
Figure 6–2 shows multiple hosts that are connected to different VLANs. Two hosts belong to the same VLAN. In this figure, the primary network interfaces of the three hosts connect to Switch 1. Host A is a member of the Blue VLAN. Therefore, Host A's interface is configured with the VID 123. This interface connects to Port 1 on Switch 1, which is then configured with the VID 123. Host B is a member of the Yellow VLAN with the VID 456. Host B's interface connects to Port 5 on Switch 1, which is configured with the VID 456. Finally, Host C's interface connects to Port 9 on Switch 1. The Blue VLAN is configured with the VID 123.
The figure also shows that a single host can also belong to more than one VLAN. For example, Host A has two VLANs configured over the host's interface. The second VLAN is configured with the VID 456 and is connected to Port 3 which is also configured with the VID 456. Thus, Host A is a member of both the Blue VLAN and the Yellow VLAN.
During VLAN configuration, you have to specify the physical point of attachment, or PPA, of the VLAN. You obtain the PPA value by using this formula:
driver-name + VID * 1000 + device-instance |
Note that the device-instance number must be less than 1000.
For example, you would create the following PPA for a ce1 interface to be configured as part of VLAN 456:
ce + 456 * 1000 + 1= ce456001 |
Use the following procedure to plan for VLANs on your network.
Examine the local network topology and determine where subdivision into VLANs is appropriate.
For a basic example of such a topology, refer to Figure 6–1.
Create a numbering scheme for the VIDs, and assign a VID to each VLAN.
A VLAN numbering scheme might already exist on the network. If so, you must create VIDs within the existing VLAN numbering scheme.
On each system, determine which interfaces will be members of a particular VLAN.
Determine which interfaces are configured on a system.
# dladm show-link |
Identify which VID will be associated with each datalink on the system.
Create PPAs for each interface to be configured with a VLAN.
All interfaces on a system do not necessarily have to be configured on the same VLAN.
Check the connections of the interfaces to the network's switches.
Note the VID of each interface and the switch port where each interface is connected.
Configure each port of the switch with the same VID as the interface to which it is connected.
Refer to the switch manufacturer's documentation for configuration instructions.
If you are using the earlier Solaris 10 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.
Oracle Solaris now supports VLANs on the following interface types:
ce
bge
xge
e1000g
Of the legacy interface types, only the ce interface can become a member of a VLAN. You can configure interfaces of different types in the same VLAN.
You can configure multiple VLANs into an IPMP group. For more information about IPMP groups, see IPMP Interface Configurations.
If you are using Solaris 10 3/05, use the procedure How To Configure Static VLANs in Solaris 10 3/05 ONLY.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine the types of interfaces in use on your system.
# dladm show-link |
The output shows the available interface types:
ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 |
Configure an interface as part of a VLAN.
# ifconfig interface-PPA plumb IP-address up |
For example, you would use the following command to configure the interface ce1 with a new IP address 10.0.0.2 into a VLAN with the VID 123:
# ifconfig ce123001 plumb 10.0.0.2 up |
You can assign IPv4 and IPv6 addresses to VLANs just as you do to other interfaces.
(Optional) To make the VLAN settings persist across reboots, create a hostname.interface-PPA file for each interface that is configured as part of a VLAN.
# cat hostname.interface-PPA IPv4-address |
On the switch, set VLAN tagging and VLAN ports to correspond with the VLANs that you have set up on the system.
This example shows how to configure devices bge1 and bge2 into a VLAN with the VID 123.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 # ifconfig bge123001 plumb 10.0.0.1 up # ifconfig bge123002 plumb 10.0.0.2 up # cat hostname.bge123001 10.0.0.1 # cat hostname.bge123002 10.0.0.2 # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge123001: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2 inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255 ether 0:3:ba:7:84:5e bge123002:flags=201000803 <UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 10.0.0.2 netmask ff000000 broadcast 10.255.255.255 ether 0:3:ba:7:84:5e ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e # dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 bge123001 type: vlan 123 mtu: 1500 device: bge1 bge123002 type: vlan 123 mtu: 1500 device: bge2 |
The original Oracle Solaris 10 release and earlier versions of Oracle Solaris do not support Link Aggregations. To create link aggregations for these earlier Oracle Solaris releases, use Sun Trunking, as described in the Sun Trunking 1.3 Installation and Users Guide.
Oracle Solaris supports the organization of network interfaces into link aggregations. A link aggregation consists of several interfaces on a system that are configured together as a single, logical unit. Link aggregation, also referred to as trunking, is defined in the IEEE 802.3ad Link Aggregation Standard.
The IEEE 802.3ad Link Aggregation Standard provides a method to combine the capacity of multiple full-duplex Ethernet links into a single logical link. This link aggregation group is then treated as though it were, in fact, a single link.
The following are features of link aggregations:
Increased bandwidth – The capacity of multiple links is combined into one logical link.
Automatic failover/failback – Traffic from a failed link is failed over to working links in the aggregation.
Load balancing – Both inbound and outbound traffic is distributed according to user selected load-balancing policies, such as source and destination MAC or IP addresses.
Support for redundancy – Two systems can be configured with parallel aggregations.
Improved administration – All interfaces are administered as a single unit.
Less drain on the network address pool – The entire aggregation can be assigned one IP address.
The basic link aggregation topology involves a single aggregation that contains a set of physical interfaces. You might use the basic link aggregation in the following situations:
For systems that run an application with distributed heavy traffic, you can dedicate an aggregation to that application's traffic.
For sites with limited IP address space that nevertheless require large amounts of bandwidth, you need only one IP address for a large aggregation of interfaces.
For sites that need to hide the existence of internal interfaces, the IP address of the aggregation hides its interfaces from external applications.
Figure 6–3 shows an aggregation for a server that hosts a popular web site. The site requires increased bandwidth for query traffic between Internet customers and the site's database server. For security purposes, the existence of the individual interfaces on the server must be hidden from external applications. The solution is the aggregation aggr1 with the IP address 192.168.50.32. This aggregation consists of three interfaces,bge0 through bge2. These interfaces are dedicated to sending out traffic in response to customer queries. The outgoing address on packet traffic from all the interfaces is the IP address of aggr1, 192.168.50.32.
Figure 6–4 depicts a local network with two systems, and each system has an aggregation configured. The two systems are connected by a switch. If you need to run an aggregation through a switch, that switch must support aggregation technology. This type of configuration is particularly useful for high availability and redundant systems.
In the figure, System A has an aggregation that consists of two interfaces, bge0 and bge1. These interfaces are connected to the switch through aggregated ports. System B has an aggregation of four interfaces, e1000g0 through e1000g3. These interfaces are also connected to aggregated ports on the switch.
The back-to-back link aggregation topology involves two separate systems that are cabled directly to each other, as shown in the following figure. The systems run parallel aggregations.
In this figure, device bge0 on System A is directly linked to bge0 on System B, and so on. In this way, Systems A and B can support redundancy and high availability, as well as high-speed communications between both systems. Each system also has interface ce0 configured for traffic flow within the local network.
The most common application for back-to-back link aggregations is mirrored database servers. Both servers need to be updated together and therefore require significant bandwidth, high-speed traffic flow, and reliability. The most common use of back-to-back link aggregations is in data centers.
If you plan to use a link aggregation, consider defining a policy for outgoing traffic. This policy can specify how you want packets to be distributed across the available links of an aggregation, thus establishing load balancing. The following are the possible layer specifiers and their significance for the aggregation policy:
L2 – Determines the outgoing link by hashing the MAC (L2) header of each packet
L3 – Determines the outgoing link by hashing the IP (L3) header of each packet
L4 – Determines the outgoing link by hashing the TCP, UDP, or other ULP (L4) header of each packet
Any combination of these policies is also valid. The default policy is L4. For more information, refer to the dladm(1M) man page.
If your aggregation topology involves connection through a switch, you must note whether the switch supports the link aggregation control protocol (LACP). If the switch supports LACP, you must configure LACP for the switch and the aggregation. However, you can define one of the following modes in which LACP is to operate:
Off mode – The default mode for aggregations. LACP packets, which are called LACPDUs are not generated.
Active mode – The system generates LACPDUs at regular intervals, which you can specify.
Passive mode – The system generates an LACPDU only when it receives an LACPDU from the switch. When both the aggregation and the switch are configured in passive mode, they cannot exchange LACPDUs.
See the dladm(1M) man page and the switch manufacturer's documentation for syntax information.
Your link aggregation configuration is bound by the following requirements:
You must use the dladm command to configure aggregations.
An interface that has been plumbed cannot become a member of an aggregation.
All interfaces in the aggregation must run at the same speed and in full-duplex mode.
You must set the value for MAC addresses to “true” in the EEPROM parameter local-mac-address? For instructions, refer to How to Ensure That the MAC Address of an Interface Is Unique.
Link aggregation only works on full-duplex, point-to-point links that operate at identical speeds. Make sure that the interfaces in your aggregation conform to this requirement.
If you are using a switch in your aggregation topology, make sure that you have done the following on the switch:
Configured the ports to be used as an aggregation
If the switch supports LACP, configured LACP in either active mode or passive mode
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine which interfaces are currently installed on your system.
# dladm show-link |
Determine which interfaces have been plumbed.
# ifconfig -a |
# dladm create-aggr -d interface -d interface [...]key |
Represents the device name of the interface to become part of the aggregation.
Is the number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.
For example:
# dladm create-aggr -d bge0 -d bge1 1 |
Configure and plumb the newly created aggregation.
# ifconfig aggrkey plumb IP-address up |
For example:
# ifconfig aggr1 plumb 192.168.84.14 up |
Check the status of the aggregation you just created.
# dladm show-aggr |
You receive the following output:
key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby |
The output shows that an aggregation with the key of 1 and a policy of L4 was created.
(Optional) Make the IP configuration of the link aggregation persist across reboots.
For link aggregations with IPv4 addresses, create an /etc/hostname.aggrkey file. For IPv6–based link aggregations, create an /etc/hostname6.aggrkey file.
Enter the IPv4 or IPv6 address of the link aggregation into the file.
For example, you would create the following file for the aggregation that is created in this procedure:
# vi /etc/hostname.aggr1 192.168.84.14 |
Perform a reconfiguration boot.
# reboot -- -r |
Verify that the link aggregation configuration you entered in the /etc/hostname.aggrkey file has been configured.
# ifconfig -a . . aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.14 netmask ff000000 broadcast 192.255.255. |
This example shows the commands that are used to create a link aggregation with two devices, bge0 and bge1, and the resulting output.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e # dladm create-aggr -d bge0 -d bge1 1 # ifconfig aggr1 plumb 192.168.84.14 up # dladm show-aggr key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.255 ether 0:3:ba:7:84:5e |
Note that the two interfaces that were used for the aggregation were not previously plumbed by ifconfig.
This procedure shows how to make the following changes to an aggregation definition:
Modifying the policy for the aggregation
Changing the mode for the aggregation
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Modify the aggregation to change the policy.
# dladm modify-aggr -Ppolicy key |
Represents one or more of the policies L2, L3, and L4, as explained in Policies and Load Balancing.
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.
If LACP is running on the switch to which the devices in the aggregation are attached, modify the aggregation to support LACP.
If the switch runs LACP in passive mode, be sure to configure active mode for your aggregation.
# dladm modify-aggr -l LACP mode -t timer-value key |
Indicates the LACP mode in which the aggregation is to run. The values are active, passive, and off.
Indicates the LACP timer value, either short or long.
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.
This example shows how to modify the policy of aggregation aggr1 to L2 and then turn on active LACP mode.
# dladm modify-aggr -P L2 1 # dladm modify-aggr -l active -t short 1 # dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby |
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Remove an interface from the aggregation.
# dladm remove-aggr -d interface |
This example shows how to remove the interfaces of the aggregation aggr1.
# dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # dladm remove-aggr -d bge1 1 # dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached |
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Delete the aggregation.
# dladm delete-aggr key |
Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.
This example shows how to remove the aggregation aggr1.
# dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state # dladm delete-aggr -d 1 |
In the same manner as configuring VLANs over an interface, you can also create VLANs on a link aggregation. VLANs are described in Administering Virtual Local Area Networks. This section combines configuring VLANs and link aggregations.
Configure the link aggregation first with a valid IP address. Note the value of the aggregation's key which you will need when you create the VLANs over the aggregation. To create link aggregations, refer to How to Create a Link Aggregation.
If a link aggregation has already been previously created, obtain that aggregation's key.
# dladm show-aggr |
Create the VLANs over the link aggregation.
# ifconfig aggrVIDkey plumb |
where
The ID of the VLAN
The key of the link aggregation over which the VLAN is created. The key must be in a 3–digit format. For example, if the aggregation's key is 1, then the key number that is included in the name of the VLAN is 001.
Repeat Step 2 to create other VLANs over the aggregation.
Configure the VLANs with valid IP addresses.
To create persistent VLAN configurations, add the IP address information to the corresponding /etc/hostname.VLAN configuration files.
In this example, two VLANs are configured on a link aggregation. The output of the dladm show-aggr command indicates that the link aggregation's key is 1. The VLANs are assigned VIDs 193 and 194, respectively.
# dladm show-aggr key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # ifconfig aggr193001 plumb # ifconfig aggr193001 192.168.10.5/24 up # ifconfig aggr194001 plumb # ifconfig aggr194001 192.168.10.25/24 up # vi /etc/hostname.aggr193001 192.168.10.5/24 # vi /etc/hostname.aggr194001 192.168.10.25/24 |