Skip Navigation Links | |
Exit Print View | |
Managing Oracle Solaris 11.1 Network Performance Oracle Solaris 11.1 Information Library |
1. Introduction to Network Performance Management
4. Administering Bridged Networks (Tasks)
Probe-Based Failure Detection Using Test Addresses
Probe-Based Failure Detection Without Using Test Addresses
Failure Detection and the Anonymous Group Feature
Detecting Physical Interface Repairs
IPMP and Dynamic Reconfiguration
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
In Oracle Solaris, IPMP contains the following features:
IPMP enables you to configure multiple IP interfaces into a single group called an IPMP group. As a whole, the IPMP group with its multiple underlying IP interfaces is represented as a single IPMP interface. This interface is treated just like any other interface on the IP layer of the network stack. All IP administrative tasks, routing tables, Address Resolution Protocol (ARP) tables, firewall rules, and other IP-related procedures work with an IPMP group by referring to the IPMP interface.
The system handles the distribution of data addresses among underlying active interfaces. When the IPMP group is created, data addresses belong to the IPMP interface as an address pool. The kernel then automatically and randomly binds the data addresses to the underlying active interfaces of the group.
The ipmpstat tool is the principal tool to obtain information about IPMP groups. This command provides information about all aspects of the IPMP configuration, such as the underlying IP interfaces of the group, test and data addresses, types of failure detection being used, and which interfaces have failed. The ipmpstat functions, the options you can use, and the output each option generates are all described in Monitoring IPMP Information.
The IPMP interface can be assigned a customized name to identify the IPMP group more easily. See Configuring IPMP Groups.
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.
The configuration of an IPMP group is determined by your system configuration.
When using IPMP, observe the following rules:
Multiple IP interfaces on the same LAN must be configured into an IPMP group. LAN broadly refers to a variety of local network configurations including VLANs and both wired and wireless local networks whose nodes belong to the same link-layer broadcast domain.
Note - Multiple IPMP groups on the same link layer (L2) broadcast domain are unsupported. A L2 broadcast domain typically maps to a specific subnet. Therefore, you must configure only one IPMP group per subnet.
Underlying IP interfaces of an IPMP group must not span different LANs.
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.
The following are the IPMP software components:
Multipathing daemon, in.mpathd - Detects interface failures and repairs. The daemon performs both link-based failure detection and probe-based failure detection if test addresses are configured for the underlying interfaces. Depending on the type of failure detection method that is used, the daemon sets or clears the appropriate flags on the interface to indicate whether the interface failed or has been repaired. As an option, the daemon can also be configured to monitor the availability of all interfaces, including interfaces that are not configured to belong to an IPMP group. For a description of failure detection, see Failure Detection in IPMP.
The in.mpathd daemon also controls the designation of active interfaces in the IPMP group. The daemon attempts to maintain the same number of active interfaces that was originally configured when the IPMP group was created. Thus, in.mpathd activates or deactivates underlying interfaces as needed to be consistent with the administrator's configured policy. For more information about how the in.mpathd daemon manages the activation of underlying interfaces, refer to How IPMP Works. For more information about the daemon, refer to the in.mpathd(1M) man page.
IP kernel module - Manages outbound load spreading by distributing the set of available IP data addresses in the IPMP group across the set of available underlying IP interfaces in the group. The module also performs source address selection to manage inbound load spreading. Both roles of the module improve network traffic performance.
IPMP configuration file (/etc/default/mpathd) - Defines the daemon's behavior.
You customize the file to set the following parameters:
The target interfaces to probe when running probe-based failure detection
The time duration to probe a target to detect failure
The status with which to flag a failed interface after that interface is repaired
The scope of IP interfaces to monitor, whether to also include IP interfaces in the system that are not configured to belong to IPMP groups
For procedures to modify the configuration file, refer to How to Configure the Behavior of the IPMP Daemon.
ipmpstat command - Provides different types of information about the status of IPMP as a whole. The tool also displays other information about the underlying IP interfaces for each IPMP group, as well as data and test addresses that have been configured for the group. For more information about this command, see Monitoring IPMP Information and the ipmpstat(1M) man page.
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:
Active-active configuration – An IPMP group in which all underlying interfaces are active. An active interface is an IP interface that is currently available for use by the IPMP group.
Note - By default, an underlying interface becomes active when you configure the interface to become part of an IPMP group.
Active-standby configuration – An IPMP group in which at least one interface is administratively configured as a standby interface. Although idle, the standby interface is monitored by the multipathing daemon to track the interface's availability, depending on how the interface is configured. If link-failure notification is supported by the interface, link-based failure detection is used. If the interface is configured with a test address, probe-based failure detection is also used. If an active interface fails, the standby interface is automatically deployed as needed. You can configure as many standby interfaces as you want for an IPMP group.
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.
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
The IPMP group itops0 is configured as follows:
Two data addresses are assigned to the group: 192.168.10.10 and 192.168.10.15.
Two underlying interfaces are configured as active interfaces and are assigned flexible link names: net0 and net1.
The group has one standby interface, also with a flexible link name: net2.
Probe-based failure detection is used, and thus the active and standby interfaces are configured with test addresses, as follows:
net0: 192.168.10.30
net1: 192.168.10.32
net2: 192.168.10.34
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 GROUP GROUPNAME STATE FDT INTERFACES itops0 itops0 ok 10.00s net1 net0 (net2)
To display information about the group's underlying interfaces, you would type the following:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE 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
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 INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE 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
The ipmpstat command displays the information in Figure 5-3 as follows:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE 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
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 INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE 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 INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE 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.