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


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


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


IPMP in Oracle Solaris

In Oracle Solaris, IPMP contains the following features:

Benefits of Using IPMP

Different factors can cause an interface to become unusable, such as an interface failure or interfaces being taken offline for maintenance. Without IPMP, the system can no longer be contacted by using any of the IP addresses that are associated with that unusable interface. Additionally, existing connections that use those IP addresses are disrupted.

With IPMP, multiple IP interfaces can be configured into an IPMP group. The group functions like an IP interface with data addresses to send or receive network traffic. If an underlying interface in the group fails, the data addresses are redistributed among the remaining underlying active interfaces in the group. Thus, the group maintains network connectivity despite an interface failure. With IPMP, network connectivity is always available, provided that a minimum of one interface is usable for the group.

IPMP improves overall network performance by automatically spreading out outbound network traffic across the set of interfaces in the IPMP group. This process is called outbound load spreading. The system also indirectly controls inbound load spreading by performing source address selection for packets whose IP source address was not specified by the application. However, if an application has explicitly chosen an IP source address, then the system does not vary that source address.

Note - Link aggregations perform similar functions as IPMP to improve network performance and availability. For a comparison of these two technologies, see Appendix B, Link Aggregations and IPMP: Feature Comparison.

Rules for Using IPMP

The configuration of an IPMP group is determined by your system configuration.

When using IPMP, observe the following rules:

For example, suppose that a system with three interfaces is connected to two separate LANs. Two IP interfaces connect to one LAN while a single IP interface connects to the other LAN. In this case, the two IP interfaces connecting to the first LAN must be configured as an IPMP group, as required by the first rule. In compliance with the second rule, the single IP interface that connects to the second LAN cannot become a member of that IPMP group. No IPMP configuration is required for the single IP interface. However, you can configure the single interface into an IPMP group to monitor the interface's availability. The single-interface IPMP configuration is discussed further in Types of IPMP Interface Configurations.

Consider another case where the link to the first LAN consists of three IP interfaces while the other link consists of two interfaces. This setup requires the configuration of two IPMP groups: a three-interface group that connects to the first LAN, and a two-interface group that connects to the second LAN.

IPMP Components

The following are the IPMP software components:

Types of IPMP Interface Configurations

An IPMP configuration typically consists of two or more physical interfaces on the same system that are attached to the same LAN. These interfaces can belong to an IPMP group in either of the following configurations:

A single interface can also be configured in its own IPMP group. The single-interface IPMP group has the same behavior as an IPMP group with multiple interfaces. However, this IPMP configuration does not provide high availability for network traffic. If the underlying interface fails, then the system loses all capability to send or receive traffic. The purpose of configuring a single-interface IPMP group is to monitor the availability of the interface by using failure detection. By configuring a test address on the interface, the multipathing daemon can track the interface by using probe-based failure detection.

Typically, a single-interface IPMP group configuration is used with other technologies that have broader failover capabilities, such as the Oracle Solaris Cluster software. The system can continue to monitor the status of the underlying interface, but the Oracle Solaris Cluster software provides the functionality to ensure availability of the network when a failure occurs. For more information about the Oracle Solaris Cluster software, see Oracle Solaris Cluster Concepts Guide.

An IPMP group without underlying interfaces can also exist, such as a group whose underlying interfaces have been removed. The IPMP group is not destroyed, but the group cannot be used to send and receive traffic. As underlying interfaces are brought online for the group, then the data addresses of the IPMP interface are allocated to these interfaces, and the system resumes hosting network traffic.

How IPMP Works

IPMP maintains network availability by attempting to preserve the same number of active and standby interfaces that was originally configured when the IPMP group was created.

IPMP failure detection can be link-based, probe-based, or both to determine the availability of a specific underlying IP interface in the group. If IPMP determines that an underlying interface has failed, then that interface is flagged as failed and is no longer usable. The data IP address that was associated with the failed interface is then redistributed to another functioning interface in the group. If available, a standby interface is also deployed to maintain the original number of active interfaces.

Consider a three-interface IPMP group itops0 with an active-standby configuration, as illustrated in the following figure..

Figure 5-1 IPMP Active-Standby Configuration

image:An active-standby configuration of itops0

The IPMP group itops0 is configured as follows:

Note - The Active, Offline, Standby, and Failed areas in Figure 5-1, Figure 5-2, Figure 5-3, and Figure 5-4 indicate only the status of underlying interfaces, and not physical locations. No physical movement of interfaces or addresses, or any transfer of IP interfaces, occurs within this IPMP implementation. The areas only serve to show how an underlying interface changes status as a result of either failure or repair.

You can use the ipmpstat command with different options to display specific types of information about existing IPMP groups. For additional examples, see Monitoring IPMP Information.

The following ipmpstat command displays information about the IPMP configuration in Figure 5-1:

# ipmpstat -g
itops0    itops0        ok        10.00s     net1 net0 (net2)

To display information about the group's underlying interfaces, you would type the following:

# ipmpstat -i
net0        yes        itops0    -------    up          ok        ok
net1        yes        itops0    --mb---    up          ok        ok
net2        no         itops0    is-----    up          ok        ok

IPMP maintains network availability by managing the underlying interfaces to preserve the original number of active interfaces. Thus, if net0 fails, then net2 is deployed to ensure that the IPMP group continues to have two active interfaces. The activation of the net2 is shown in the following figure.

Figure 5-2 Interface Failure in IPMP

image:Failure of an active interface in the IPMP group

Note - The one to one mapping of data addresses to active interfaces in Figure 5-2 serves only to simplify the illustration. The IP kernel module can randomly assign data addresses without necessarily adhering to a one to one relationship between data addresses and interfaces.

The ipmpstat command displays the information in Figure 5-2 as follows:

# ipmpstat -i
net0        no         itops0    -------    up          failed    failed
net1        yes        itops0    --mb---    up          ok        ok
net2        yes        itops0    -s-----    up          ok        ok

After net0 is repaired, it reverts to its status as an active interface. In turn, net2 is returned to its original standby status.

A different failure scenario is shown in Figure 5-3, where the standby interface net2 fails (1). Later, one active interface, net1, is taken offline by the administrator (2). The result is that the IPMP group is left with a single functioning interface, net0.

Figure 5-3 Standby Interface Failure in IPMP

image:Failure of a standby interface in the IPMP group

The ipmpstat command displays the information in Figure 5-3 as follows:

# ipmpstat -i
net0        yes        itops0    -------     up          ok        ok
net1        no         itops0    --mb-d-     up          ok        offline
net2        no         itops0    is-----     up          failed    failed

For this particular failure, the recovery after an interface is repaired operates differently. The recovery process depends on the IPMP group's original number of active interfaces compared with the configuration after the repair. The recovery process is represented graphically in the following figure:

Figure 5-4 IPMP Recovery Process

image:IPMP Recovery Process

In Figure 5-4, when net2 is repaired, it would normally revert to its original status as a standby interface (1). However, the IPMP group would still not reflect the original number of two active interfaces because net1 continues to remain offline (2). Thus, IPMP instead deploys net2 as an active interface (3).

The ipmpstat command displays the post-repair IPMP scenario as follows:

# ipmpstat -i
net0        yes        itops0    -------     up          ok        ok
net1        no         itops0    --mb-d-     up          ok        offline
net2        yes        itops0    -s-----     up          ok        ok

A similar recovery process occurs if the failure involves an active interface that is also configured in FAILBACK=no mode, where a failed active interface does not automatically revert to active status upon repair. Suppose that net0 in Figure 5-2 is configured in FAILBACK=no mode. In that mode, a repaired net0 is becomes a standby interface, even though it was originally an active interface. The interface net2 remains active to maintain the IPMP group's original number of two active interfaces.

The ipmpstat command displays the recovery information as follows:

# ipmpstat -i
net0        no         itops0    i------    up          ok        ok
net1        yes        itops0    --mb---    up          ok        ok
net2        yes        itops0    -s-----    up          ok        ok

For more information about this type of configuration, see FAILBACK=no Mode.