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.
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.
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
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.
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.