JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Managing Oracle Solaris 11.1 Network Performance     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Introduction to Network Performance Management

2.  Using Link Aggregations

3.  Working With VLANs

4.  Administering Bridged Networks (Tasks)

5.  Introduction to IPMP

IPMP in Oracle Solaris

Benefits of Using IPMP

Rules for Using IPMP

IPMP Components

Types of IPMP Interface Configurations

How IPMP Works

IPMP Addressing

Data Addresses

Test Addresses

Failure Detection in IPMP

Probe-Based Failure Detection

Probe-Based Failure Detection Using Test Addresses

Probe-Based Failure Detection Without Using Test Addresses

Group Failure

Link-Based Failure Detection

Failure Detection and the Anonymous Group Feature

Detecting Physical Interface Repairs

FAILBACK=no Mode

IPMP and Dynamic Reconfiguration

6.  Administering IPMP (Tasks)

7.  Exchanging Network Connectivity Information With LLDP

8.  Working With Data Center Bridging Features in Oracle Solaris

9.  Edge Virtual Bridging in Oracle Solaris

10.  Integrated Load Balancer (Overview)

11.  Configuring Integrated Load Balancer

12.  Managing Integrated Load Balancer

13.  Virtual Router Redundancy Protocol (Overview)

A.  Link Aggregation Types: Feature Comparison

B.  Link Aggregations and IPMP: Feature Comparison

Index

IPMP and Dynamic Reconfiguration

The dynamic reconfiguration (DR) feature of Oracle Solaris enables you to reconfigure system hardware, such as interfaces, while the system is running. DR can be used only on systems that support this feature. On systems that support DR, 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. For example, you can attach, plumb, and then add new interfaces to existing IPMP groups. After these interfaces have been configured, they are immediately available for use by IPMP.

All requests to detach NICs are first checked to ensure that connectivity can be preserved. For example, 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 the cfgadm command, as explained in the cfgadm(1M) man page.

If the checks are successful, the in.mpathd 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 is displayed. Otherwise, the detach request completes successfully. You can remove the component from the system. No existing connections are disrupted.


Note - When replacing NICs, make sure that the cards are of the same type, such as Ethernet. After the NIC is replaced, then the persistent IP interface configurations are applied to that NIC.