JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Network Interfaces and Network Virtualization     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

1.  Overview of the Networking Stack

Network Configuration in This Oracle Solaris Release

The Network Stack in Oracle Solaris

Network Devices and Datalink Names

Administration of Other Link Types

Part I Network Auto-Magic

2.  Introduction to NWAM

3.  NWAM Configuration and Administration (Overview)

4.  NWAM Profile Configuration (Tasks)

5.  NWAM Profile Administration (Tasks)

6.  About the NWAM Graphical User Interface

Part II Datalink and Interface Configuration

7.  Using Datalink and Interface Configuration Commands on Profiles

8.  Datalink Configuration and Administration

9.  Configuring an IP Interface

10.  Configuring Wireless Interface Communications on Oracle Solaris

11.  Administering Bridges

12.  Administering Link Aggregations

13.  Administering VLANs

14.  Introducing IPMP

What's New With IPMP

Deploying IPMP

Why You Should Use IPMP

When You Must Use IPMP

Comparing IPMP and Link Aggregation

Using Flexible Link Names on IPMP Configuration

How IPMP Works

IPMP Components in Oracle Solaris

Types of IPMP Interface Configurations

IPMP Addressing

IPv4 Test Addresses

IPv6 Test Addresses

Failure and Repair Detection in IPMP

Types of Failure Detection in IPMP

Probe-Based Failure Detection

Link-Based Failure Detection

Failure Detection and the Anonymous Group Feature

Detecting Physical Interface Repairs

The FAILBACK=no Mode

IPMP and Dynamic Reconfiguration

Attaching New NICs

Detaching NICs

Replacing NICs

IPMP Terminology and Concepts

15.  Administering IPMP

16.  Exchanging Network Connectivity Information With LLDP

Part III Network Virtualization and Resource Management

17.  Introducing Network Virtualization and Resource Control (Overview)

18.  Planning for Network Virtualization and Resource Control

19.  Configuring Virtual Networks (Tasks)

20.  Using Link Protection in Virtualized Environments

21.  Managing Network Resources

22.  Monitoring Network Traffic and Resource Usage

Glossary

Index

IPMP and Dynamic Reconfiguration

Dynamic reconfiguration (DR) feature allows you to reconfigure system hardware, such as interfaces, while the system is running. DR can be used only on systems that support this feature.

You typically use the cfgadm command to perform DR operations. However, some platforms provide other methods. Make sure to consult your platform's documentation for details to perform DR. For systems that use Oracle Solaris, you can find specific documentation about DR in the resources that are listed in Table 14-1. Current information about DR is also available at http://www.oracle.com/technetwork/indexes/documentation/index.html and can be obtained by searching for the topic “dynamic reconfiguration.”

Table 14-1 Documentation Resources for Dynamic Reconfiguration

Description
For Information
Detailed information on the cfgadm command
cfgadm(1M) man page
Specific information about DR in the Oracle Solaris Cluster environment
Specific information about DR in the Sun Servers from Oracle
See documentation that came with your specific server
Introductory information about DR and the cfgadm command
Tasks for administering IPMP groups on a system that supports DR

The sections that follow explain how DR interoperates with IPMP.

On a system that supports DR of NICs, IPMP can be used to preserve connectivity and prevent disruption of existing connections. IPMP is integrated into the Reconfiguration Coordination Manager (RCM) framework. Thus, you can safely attach, detach, or reattach NICs and RCM manages the dynamic reconfiguration of system components.

Attaching New NICs

With DR support, you can attach, plumb, and then add new interfaces to existing IPMP groups. Or, if appropriate, you can configure the newly added interfaces into their own IPMP group. For procedures to configure IPMP groups, refer to Configuring IPMP Groups. After these interfaces have been configured, they are immediately available for use by IPMP. However, to benefit from the advantages of using customized link names, you must assign generic link names to replace the interface's hardware-based link names. Then you create corresponding configuration files by using the generic name that you just assigned. For procedures to configure a singe interface by using customized link names, refer to How to Configure an IP Interface. After you assign a generic link name to interface, make sure that you always refer to the generic name when you perform any additional configuration on the interface such as using the interface for IPMP.

Detaching NICs

All requests to detach system components that contain NICs are first checked to ensure that connectivity can be preserved. For instance, by default you cannot detach a NIC that is not in an IPMP group. You also cannot detach a NIC that contains the only functioning interfaces in an IPMP group. However, if you must remove the system component, you can override this behavior by using the -f option of cfgadm, as explained in the cfgadm(1M) man page.

If the checks are successful, the daemon sets the OFFLINE flag for the interface. All test addresses on the interfaces are unconfigured. Then, the NIC is unplumbed from the system. If any of these steps fail, or if the DR of other hardware on the same system component fails, then the previous configuration is restored to its original state. A status message about this event will be displayed. Otherwise, the detach request completes successfully. You can remove the component from the system. No existing connections are disrupted.

Replacing NICs

When an underlying interface of an IPMP group fails, a typical solution would be to replace the failed interface by attaching a new NIC. RCM records the configuration information associated with any NIC that is detached from a running system. If you replace a failed NIC with an identical NIC, then RCM automatically configures the interface according to the persistent configurations that had been previously defined by using the ipadm command.

For example, suppose you replace a failed bge0 interface with another bge0 interface. The failed bge0's configuration settings that were defined by using the ipadm command are persistent settings. After you attach the replacement bge NIC, RCM plumbs and then configures the bge0 interface according to these persistent settings. Thus the interface is properly configured with the test address and is added to the IPMP group.

You can replace a failed NIC with a different NIC, provided that both are the same type, such as Ethernet. In this case, RCM plumbs the new interface after it is attached. If you did not use customized link names when you first configured your interfaces, then you will have to configure the new NIC before you can add the interface to the IPMP group.

However, if you used customized link names, the additional configuration steps are unnecessary. By reassigning the failed interface's link name to the new interface, then the new interface acquires the configuration specified in the removed interface's persistent settings. RCM then configures the interface according to those settings. For procedures to recover your IPMP configuration by using DR when an interface fails, refer to Recovering an IPMP Configuration With Dynamic Reconfiguration.