How IPMP Works
IPMP maintains network availability by attempting to preserve the original number of active and standby interfaces when the group was created.
IPMP failure detection can be link-based or 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 Figure 7–1.
Figure 7–1 IPMP Active–Standby Configuration
The 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: subitops0 and subitops1.
-
The group has one standby interface, also with a flexible link name: subitops2.
-
Probe–based failure detection is used, and thus the active and standby interfaces are configured with test addresses, as follows:
-
subitops0: 192.168.10.30
-
subitops1: 192.168.10.32
-
subitops2: 192.168.10.34
-
Note –
The Active, Offline, Reserve, and Failed areas in the figures indicate only the status of underlying interfaces, and not physical locations. No physical movement of interfaces or addresses nor transfer of IP interfaces occur 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 IPMP configuration in Figure 7–1 can be displayed by using the following ipmpstat command:
# ipmpstat -g GROUP GROUPNAME STATE FDT INTERFACES itops0 itops0 ok 10.00s subitops1 subitops0 (subitops2) |
To display information about the group's underlying interfaces, you would type the following:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE subitops0 yes itops0 ------- up ok ok subitops1 yes itops0 --mb--- up ok ok subitops2 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 subitops0 fails, then subitops2 is deployed to ensure that the group continues to have two active interfaces. The activation of the subitops2 is shown in Figure 7–2.
Figure 7–2 Interface Failure in IPMP
Note –
The one–to–one mapping of data addresses to active interfaces in Figure 7–2 serves only to simplify the illustration. The IP kernel module can assign data addresses randomly without necessarily adhering to a one–to–one relationship between data addresses and interfaces.
The ipmpstat utility displays the information in Figure 7–2 as follows:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE subitops0 no itops0 ------- up failed failed subitops1 yes itops0 --mb--- up ok ok subitops2 yes itops0 -s----- up ok ok |
After subitops0 is repaired, then it reverts to its status as an active interface. In turn, subitops2 is returned to its original standby status.
A different failure scenario is shown in Figure 7–3, where the standby interface subitops2 fails (1), and later, one active interface, subitops1, is switched offline by the administrator (2). The result is that the IPMP group is left with a single functioning interface, subitops0.
Figure 7–3 Standby Interface Failure in IPMP
The ipmpstat utility would display the information illustrated by Figure 7–3 as follows:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE subitops0 yes itops0 ------- up ok ok subitops1 no itops0 --mb-d- up ok offline subitops2 no itops0 is----- up failed failed |
For this particular failure, the recovery after an interface is repaired behaves differently. The restoration 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 Figure 7–4.
Figure 7–4 IPMP Recovery Process
In Figure 7–4, when subitops2 is repaired, it would normally revert to its original status as a standby interface (1). However, the IPMP group still would not reflect the original number of two active interfaces, because subitops1 continues to remain offline (2). Thus, IPMP deploys subitops2 as an active interface instead (3).
The ipmpstat utility would display the post-repair IPMP scenario as follows:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE subitops0 yes itops0 ------- up ok ok subitops1 no itops0 --mb-d- up ok offline subitops2 yes itops0 -s----- up ok ok |
A similar restore sequence 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 subitops0 in Figure 7–2 is configured in FAILBACK=no mode. In that mode, a repaired subitops0 is switched to a reserve status as a standby interface, even though it was originally an active interface. The interface subitops2 would remain active to maintain the IPMP group's original number of two active interfaces. The ipmpstat utility would display the recovery information as follows:
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE subitops0 no itops0 i------ up ok ok subitops1 yes itops0 --mb--- up ok ok subitops2 yes itops0 -s----- up ok ok |
For more information about this type of configuration, see The FAILBACK=no Mode.
- © 2010, Oracle Corporation and/or its affiliates