第 30 章 IPMP 介绍（概述）

IP 网络多路径 (IP network multipathing, IPMP) 为在同一 IP 链路上具有多个接口的系统提供物理接口故障检测和透明网络访问故障转移功能。IPMP 还为具有多个接口的系统提供了包负荷分配。

本章包含以下信息：

• 为什么应该使用 IPMP

• IPMP 的基本要求

• IPMP 寻址

• Oracle Solaris ： IPMP 组件

• IPMP 接口配置

• IPMP 故障检测和恢复功能

• IPMP 和动态重新配置

有关 IPMP 配置任务，请参阅第 31 章。

为什么应该使用 IPMP

IPMP 为具有多个物理接口的系统提供增强的可靠性、可用性和网络性能。有时，连接到该接口的物理接口或网络硬件可能会出现故障或者需要维护。过去，在这种情况下，系统便无法再通过与故障接口关联的任何 IP 地址进行联系。并且，使用这些 IP 地址与系统相连的任何现有连接都将被断开。

通过 IPMP，可以将一个或多个物理接口配置到 IP 多路径组（IPMP 组）中。配置 IPMP 后，系统将自动监视 IPMP 组中的接口是否出现故障。如果组中的接口出现故障或者被移除以进行维护，则 IPMP 自动迁移或故障转移故障接口的 IP 地址。这些地址的接收者是故障接口的 IPMP 组中的工作接口。IPMP 的故障转移功能可以保持连接并防止断开任何现有连接。此外，通过自动在 IPMP 组中的一组接口中分配网络通信流量，IPMP 提高了总体网络性能。此过程称为负荷分配。

Oracle Solaris ： IPMP 组件

Oracle Solaris ： IPMP 涉及以下软件：

• in.mpathd 守护进程（在 in.mpathd(1M) 手册页中进行了完整说明）。

• /etc/default/mpathd 配置文件（也在 in.mpathd(1M) 手册页中进行了说明）。

• ifconfig 用于 IPMP 配置的选项，如 ifconfig(1M) 手册页中所述。

多路径守护进程 in.mpathd

in.mpathd 守护进程检测接口故障，然后实现故障转移和故障恢复的各种过程。在 in.mpathd 检测到故障或修复后，守护进程将发送 ioctl 以执行故障转移或故障恢复。ip 内核模块（用于实现 ioctl）将自动且透明地进行网络访问故障转移。

在同一组网络接口卡上使用 IPMP 时，不要使用 Alternate Pathing。同样，在使用 Alternate Pathing 时，不应使用 IPMP。可以在不同的接口组上同时使用 Alternate Pathing 和 IPMP。有关 Alternate Pathing 的更多信息，请参阅《Sun Enterprise Server Alternate Pathing 2.3.1 User Guide》。

in.mpathd 守护进程通过在属于 IPMP 组的所有接口上发出探测器来检测故障和修复。in.mpathd 守护进程还通过监视组中每个接口上的 RUNNING 标志来检测故障和修复。有关更多信息，请参阅 in.mpathd(1M) 手册页。

不支持 DHCP 管理 IPMP 数据地址。如果尝试对这些地址使用 DHCP，DHCP 最终会放弃对这些地址的控制。请勿对数据地址使用 DHCP。

IPMP 术语和概念

本小节介绍本书 IPMP 章节中涉及的术语和概念。

IP 链路

在 IPMP 术语中，IP 链路是一种通信工具或介质，节点可以通过它在 Internet 协议套件的数据链路层上进行通信。IP 链路的类型可能包括简单以太网、桥接以太网、集线器或异步传输模式 (Asynchronous Transfer Mode, ATM) 网络。IP 链路可以具有一个或多个 IPv4 子网号和（如果适用）一个或多个 IPv6 子网前缀。不能将一个子网号或前缀指定给多个 IP 链路。在 ATM LANE 中，一个 IP 链路便是一个仿真局域网 (local area network, LAN)。对于地址解析协议 (Address Resolution Protocol, ARP)，其作用范围是单个 IP 链路。

其他与 IP 相关的文档（如 RFC 2460，Internet Protocol, Version 6 (IPv6) Specification，使用术语链路而非 IP 链路。第六部分使用术语 IP 链路以避免与 IEEE 802 相混淆。在 IEEE 802 中，链路是指从以太网网络接口卡 (network interface card, NIC) 到以太网交换机的一根线。

物理接口

物理接口提供系统与 IP 链路的连接。此连接通常实现为设备驱动程序和 NIC。如果系统具有连接到同一链路的多个接口，则可以将 IPMP 配置为在其中某个接口出现故障时执行故障转移。有关物理接口的更多信息，请参阅IPMP 接口配置。

网络接口卡

网络接口卡是一个可以内置到系统中的网络适配器。NIC 也可以是一个单独的卡，以用作从系统到 IP 链路的接口。一些 NIC 可以具有多个物理接口。例如，qfe NIC 可以具有四个接口：qfe0 到 qfe3。

IPMP 组

IP 多路径组（IPMP 组）由同一系统中使用同一 IPMP 组名称配置的一个或多个物理接口组成。IPMP 组中的所有接口都必须连接到同一 IP 链路。同一（非空）字符串 IPMP 组名称用于标识组中的所有接口。只要 NIC 属于同一类型，就可以将不同速度 NIC 中的接口放置在同一 IPMP 组中。例如，可以在同一组中配置 100 MB 以太网 NIC 的接口和 1 GB 以太网 NIC 的接口。再假定您有两个 100 MB 的以太网 NIC。可以将其中一个接口配置为 10 MB，并且仍将这两个接口放置在同一 IPMP 组中。

不能将介质类型不同的两个接口放置到一个 IPMP 组中。例如，不能将 ATM 接口与以太网接口放置在同一组中。

故障检测和故障转移

故障检测是检测一个接口或从接口到 Internet 层设备的路径何时不再工作的过程。IPMP 为系统提供检测接口何时出现故障的功能。IPMP 检测以下类型的通信故障：

• 接口的传输或接收路径出现故障。

• 接口到 IP 链路的连接已关闭。

• 交换机上的端口不传输或接收包。

• IPMP 组中的物理接口在系统引导时不存在。

检测到故障后，IPMP 开始进行故障转移。故障转移是将网络访问从出现故障的接口切换到同一组中正常工作的物理接口的自动过程。网络访问除包括 IPv6 单点传送和多点传送通信外，还包括 IPv4 单点传送、多点传送和广播通信。仅当在 IPMP 组中配置了多个接口时，才可以发生故障转移。故障转移过程可确保对网络的不间断访问。

修复检测和故障恢复

修复检测是检测 NIC 或从 NIC 到某个 Internet 层设备的路径在出现故障后何时开始正常工作的过程。在检测到已修复的 NIC 后，IPMP 执行故障恢复（将网络访问切换回已修复接口的过程）。修复检测假定已启用故障恢复。有关更多信息，请参见检测物理接口修复。

目标系统

基于探测器的故障检测使用目标系统确定接口的状态。每个目标系统都必须连接到与 IPMP 组成员相同的 IP 链路。本地系统上的 in.mpathd 守护进程将 ICMP 探测器消息发送到每个目标系统。探测器消息有助于确定 IPMP 组中每个接口的运行状况。

有关在基于探测器的故障检测中使用目标系统的更多信息，请参阅基于探测器的故障检测。

外发负荷分配

在配置 IPMP 后，可以在多个 NIC 中分配外发网络包，而不会影响包的排序。此过程称为负荷分配。通过负荷分配可以达到较高的吞吐量。仅当网络通信流向使用多个连接的多个目标时，才会发生负荷分配。

动态重新配置

动态重新配置 (Dynamic reconfiguration, DR) 是指在系统运行时重新配置系统而对现有操作影响很小或者没有影响的能力。并非所有 Sun 平台都支持 DR。有些 Sun 平台可能仅支持某些类型硬件的 DR。在支持 NIC 的 DR 的平台上，可以使用 IPMP 透明地故障转移网络访问，从而为系统提供不间断的网络访问。

有关 IPMP 如何支持 DR 的更多信息，请参阅IPMP 和动态重新配置。

IPMP 的基本要求

IPMP 内置于 Oracle Solaris ： 中，无需任何特殊硬件。Oracle Solaris ： 支持的任何接口都可以与 IPMP 一起使用。但是，IPMP 对网络配置和拓扑有以下要求：

• IPMP 组中的所有接口都必须具有唯一的 MAC 地址。

  请注意，在缺省情况下，基于 SPARC 的系统上的网络接口都共享单个 MAC 地址。因此，必须显式更改缺省值，才能在基于 SPARC 的系统上使用 IPMP。有关更多信息，请参阅如何规划 IPMP 组。

• IPMP 组中的所有接口都必须具有相同的介质类型。有关更多信息，请参阅IPMP 组。

• IPMP 组中的所有接口都必须位于同一 IP 链路上。有关更多信息，请参阅IPMP 组。

  ---

  注 –

  不支持同一个链路层（L2 或第二层）广播域上存在多个 IPMP 组。L2 广播域通常对应于特定子网。因此对于每个子网，只能配置一个 IPMP 组。

  ---

• 根据故障检测要求，可能需要使用特定类型的网络接口，或者在每个网络接口上配置其他 IP 地址。请参阅基于链路的故障检测和基于探测器的故障检测。

IPMP 寻址

可以在 IPv4 网络以及双栈、IPv4 和 IPv6 网络中配置 IPMP 故障检测。使用 IPMP 配置的接口支持以下两种类型的地址： 数据地址和测试地址。

数据地址

数据地址是在引导时指定给或通过 ifconfig 命令手动指定给 NIC 的接口的常规 IPv4 和 IPv6 地址。通过接口的标准 IPv4 和（如果适用）IPv6 包流量被视为数据通信。

测试地址

测试地址是由 in.mpathd 守护进程使用的特定于 IPMP 的地址。对于要使用基于探测器的故障和修复检测的接口，至少必须为其配置一个测试地址。

仅当希望使用基于探测器的故障检测时，才需要配置测试地址。

in.mpathd 守护进程使用测试地址与 IP 链路上的其他目标交换 ICMP 探测器（也称为探测器通信）。探测器通信有助于确定接口及其 NIC 的状态，其中包括接口是否已出现故障。探测器检验接口的发送和接收路径是否正常工作。

可以使用 IP 测试地址配置每个接口。对于双栈网络中的接口，可以配置 IPv4 测试地址或/和IPv6 测试地址。

在接口出现故障后，测试地址将一直保留在故障接口上，以便 in.mpathd 可以继续发送探测器以检查后续修复。必须专门配置测试地址，以便应用程序不会意外地使用它们。有关更多信息，请参阅防止应用程序使用测试地址。

有关基于探测器的故障检测的更多信息，请参阅基于探测器的故障检测。

IPv4 测试地址

通常，可以将子网中的任何 IPv4 地址用作测试地址。IPv4 测试地址无需是可路由的。由于 IPv4 地址是许多站点的有限资源，因此您可能希望将不可路由的 RFC 1918 专用地址用作测试地址。请注意，in.mpathd 守护进程与测试地址在同一子网中的其他主机仅交换 ICMP 探测器。如果使用 RFC 1918 样式的测试地址，请确保使用适当的 RFC 1918 子网中的地址配置 IP 链路上的其他系统（首选路由器）。然后 in.mpathd 守护进程便可以成功地与目标系统交换探测器。

IPMP 示例将来自 192.168.0/24 网络的 RFC 1918 地址用作 IPv4 测试地址。有关 RFC 1918 专用地址的更多信息，请参阅RFC 1918, Address Allocation for Private Internets。

有关如何配置 IPv4 测试地址，请参阅如何配置具有多个接口的 IPMP 组。

IPv6 测试地址

唯一的有效 IPv6 测试地址是物理接口的链路本地地址。无需将单独的 IPv6 地址用作 IPMP 测试地址。IPv6 链路本地地址基于接口的介质访问控制 (Media Access Control, MAC) 地址。当引导时接口变成启用了 IPv6 的接口或通过 ifconfig 手动配置接口时，将自动配置链路本地地址。

要确定接口的链路本地地址，请在启用了 IPv6 的节点上运行 ifconfig interface 命令。检查输出中是否包含以前缀 fe80（链路本地前缀）开头的地址。以下 ifconfig 输出中的 NOFAILOVER 标志指示，hme0 接口的链路本地地址 fe80::a00:20ff:feb9:17fa/10 被用作测试地址。

hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:17fa/10 

有关链路本地地址的更多信息，请参阅链路本地单点传送地址。

如果在 IPMP 组的所有接口上同时检测了 IPv4 和 IPv6，则无需配置单独的 IPv4 测试地址。in.mpathd 守护进程可以将 IPv6 链路本地地址用作测试地址。

要创建 IPv6 测试地址，请参阅如何配置具有多个接口的 IPMP 组任务。

防止应用程序使用测试地址

配置测试地址后，需要确保应用程序未使用此地址。否则，如果接口出现故障，则无法再访问应用程序，因为在故障转移操作期间测试地址并不故障转移。要确保 IP 不选择将测试地址用于常规应用程序，请将测试地址标记为 deprecated。

除非应用程序显式绑定到过时的地址，否则 IPv4 不会将该地址用作源地址进行任何通信。in.mpathd 守护进程显式绑定到此类地址，以便发送和接收探测器通信。

因为 IPv6 链路本地地址通常不存在于名称服务中，所以 DNS 和 NIS 应用程序不使用链路本地地址进行通信。因此，不能将 IPv6 链路本地地址标记为 deprecated。

不应将 IPv4 测试地址放置在 DNS 和 NIS 名称服务表中。在 IPv6 中，通常不将链路本地地址放置在名称服务表中。

IPMP 接口配置

IPMP 配置通常由同一系统上连接到同一 IP 链路的两个或更多物理接口组成。这些物理接口可能在同一 NIC 上，也可能不在同一 NIC 上。这些接口被配置为同一 IPMP 组的成员。如果系统在第二个 IP 链路上具有其他接口，则必须将这些接口配置为另一个 IPMP 组。

单个接口可以在自己的 IPMP 组中进行配置。单接口 IPMP 组的行为与具有多个接口的 IPMP 组相同。但是，对于只有一个接口的 IPMP 组，不能进行故障转移和故障恢复。

也可通过与配置 IP 接口之外的组相同的步骤在 IPMP 组内配置 VLAN。有关过程，请参见配置 IPMP 组。在IPMP 的基本要求中列出的同一要求适用于将 VLAN 配置到 IPMP 组。

当将 VLAN 配置为 IPMP 组时，用于命名 VLAN 的约定可能导致错误。有关 VLAN 名称的更多详细信息，请参见《系统管理指南：IP 服务》中VLAN 标记和物理连接点。考虑四种 VLAN 示例，bge1000、bge1001、bge2000 和 bge2001。IPMP 实现需要这些 VLAN 按如下方式进行分组：bge1000 和 bge1001 属于同一 VLAN 1 中的一个组，而 bge2000 和 bge2001 属于同一 VLAN 2 中的另一个组。由于 VLAN 的名称，很容易发生诸如将属于不同链路的 VLAN 混入一个 IPMP 组的错误，例如，bge1000 和 bge2000。

IPMP 组中的待机接口

除非 IPMP 组中的某个其他接口出现故障，否则不会使用该组中的待机接口进行数据通信。在出现故障时，故障接口上的数据地址将迁移到待机接口。然后，会像对待其他活动接口一样对待待机接口，直到修复故障接口为止。一些故障转移可能不选择待机接口。相反，这些故障转移可能选择比待机接口具有更少配置为 UP 的数据地址的活动接口。

在待机接口上应仅配置测试地址。IPMP 不允许将数据地址添加到通过 ifconfig 命令配置为 standby 的接口。创建此类型配置的任何尝试都将失败。同样，如果将已具有数据地址的接口配置为 standby，则这些地址将自动地故障转移到 IPMP 组中的其他接口。由于存在这些限制，因此在将接口设置为 standby 之前，必须使用 ifconfig 命令将所有测试地址标记为 -deprecated 和 failover。有关如何配置待机接口，请参阅如何为 IPMP 组配置待机接口。

常见的 IPMP 接口配置

如IPMP 寻址所述，IPMP 组中的接口根据接口配置处理有规律的数据通信和探测器通信。使用 ifconfig 命令的 IPMP 选项可以创建配置。

活动接口是既传输数据通信又传输探测器通信的物理接口。通过执行如何配置具有多个接口的 IPMP 组或如何配置单接口 IPMP 组中所述的任务，可以将接口配置为“活动”。

以下是两种常见的 IPMP 配置类型：

活动-活动配置

一个双接口 IPMP 组，其中的两个接口都为“活动”，即它们始终可能既传输探测器通信又传输数据通信。

活动-待机配置

一个双接口 IPMP 组，其中一个接口被配置为“待机”。

检查接口的状态

通过发出 ifconfig interface 命令，可以检查接口的状态。有关 ifconfig 状态报告的一般信息，请参阅如何获取有关特定接口的信息。

例如，可以使用 ifconfig 命令获取待机接口的状态。当待机接口未承载任何数据地址时，该接口具有指示其状态的 INACTIVE 标志。可以在 ifconfig 输出中该接口的状态行中看到此标志。

IPMP 故障检测和恢复功能

in.mpathd 守护进程处理以下类型的故障检测：

• 基于链路的故障检测（如果 NIC 驱动程序支持该故障检测）

• 基于探测器的故障检测（配置测试地址时）

• 检测引导时缺少的接口

in.mpathd(1M) 手册页对 in.mpathd 守护进程如何处理接口故障的检测进行了完整说明。

基于链路的故障检测

如果接口支持基于链路的故障检测，应始终启用该类故障检测。在 Oracle Solaris ： 的当前发行版中支持以下 Sun 网络驱动程序：

• hme

• eri

• ce

• ge

• bge

• qfe

• dmfe

• e1000g

• ixgb

• nge

• nxge

• rge

• xge

要确定第三方接口是否支持基于链路的故障检测，请参阅制造商文档。

这些网络接口驱动程序会监视接口的链路状态，并在链路状态更改时通知联网子系统。收到更改通知后，联网子系统会根据需要设置或清除该接口的 RUNNING 标志。守护进程在检测到接口的 RUNNING 标志已被清除时，会立即使该接口失效。

基于探测器的故障检测

in.mpathd 守护进程会对 IPMP 组中具有测试地址的每个接口执行基于探测器的故障检测。基于探测器的故障检测涉及使用测试地址发送和接收 ICMP 探测器消息。这些消息通过接口发送到同一 IP 链路上的一个或多个目标系统。有关测试地址的介绍，请参阅测试地址。有关配置测试地址的信息，请参阅如何配置具有多个接口的 IPMP 组。

in.mpathd 守护进程确定要动态探测的目标系统。会自动将连接到 IP 链路的路由器选为探测目标。如果在链路上不存在路由器，则 in.mpathd 会将探测器发送到链路上的相邻主机。发送到所有主机多点传送地址（在 IPv4 中为 224.0.0.1，在 IPv6 中为 ff02::1）的多点传送包可确定要用作目标系统的主机。对回显包作出响应的前几个主机将被选作探测目标。如果 in.mpathd 找不到响应 ICMP 回显包的路由器或主机，则 in.mpathd 无法检测基于探测器的故障。

可以使用主机路由显式配置要由 in.mpathd 使用的目标系统的列表。有关说明，请参阅配置目标系统。

为确保 IPMP 组中的每个接口都正常工作，in.mpathd 将通过 IPMP 组中的所有接口分别探测所有目标。如果对五个连续的探测器未做出任何响应，则 in.mpathd 认为接口已出现故障。探测速率取决于故障检测时间 (failure detection time, FDT)。故障检测时间的缺省值是 10 秒。不过，可以在 /etc/default/mpathd 文件中调整故障检测时间。有关说明，请转至如何配置 /etc/default/mpathd 文件。

对于 10 秒的修复检测时间，探测速率约为每两秒发送一个探测器。最短的修复检测时间是故障检测时间的两倍，缺省情况下为 20 秒，因为必须收到对 10 个连续探测器的回复。故障检测时间和修复检测时间仅适用于基于探测器的故障检测。

由 VLAN 组成的 IPMP 组，基于链路的故障检测通过物理链路实现，因此影响该链路上的所有 VLAN。基于探测器的故障检测通过 VLAN 链路执行。例如，同时在一个组内配置bge0/bge1 和 bge1000/bge1001。如果已拔出 bge0 的电缆，那么基于链路的故障检测将立即报告 bge0 和 bge1000 都好像已发生故障。但是，如果 bge0 上的所有探测器目标变得不可访问，将仅报告 bge0 发生故障，因为 bge1000 在其自己的 VLAN 上有其自己的探测器目标。

组故障

当 IPMP 组中的所有接口看起来同时出现故障时，就会出现组故障。对于组故障，in.mpathd 守护进程不执行故障转移。此外，当所有目标系统同时出现故障时，也不会执行故障转移。在这种情况下，in.mpathd 会清除其当前所有的目标系统并搜索新的目标系统。

检测物理接口修复

要使 in.mpathd 守护进程将某个接口视为要进行修复，必须为该接口设置 RUNNING 标志。如果使用基于探测器的故障检测，in.mpathd 守护进程必须先从接口收到对 10 个连续探测器包的响应，才会将该接口视为已修复。接口被视为已修复时，故障转移到其他接口的任何地址都将故障恢复到已修复的接口。如果接口在出现故障之前被配置为“活动”，则在修复之后该接口可以恢复发送和接收通信。

接口故障转移期间发生的情况

以下两个示例说明了一种典型配置，以及该配置在接口出现故障时如何自动更改。当 hme0 接口出现故障时，请注意所有数据地址都将从 hme0 移动到 hme1。

示例 30–1 接口出现故障之前的接口配置

hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> 
     mtu 1500 index 2
     inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme0:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.21 netmask ffffff00 broadcast 192.168.85.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
8     inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.22 netmask ffffff00 broadcast 192.168.85.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:19fa/10
     groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:1bfc/10
     groupname test

示例 30–2 接口出现故障之后的接口配置

hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4,
      NOFAILOVER,FAILED> mtu 0 index 2
      inet 0.0.0.0 netmask 0 
      groupname test
hme0:1: flags=19040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER,FAILED> mtu 1500 index 2 
      inet 192.168.85.21 netmask ffffff00 broadcast 10.0.0.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
      groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER> mtu 1500 
      index 2 inet 192.168.85.22 netmask ffffff00 broadcast 10.0.0.255
hme1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
      inet 192.168.85.19 netmask ffffff00 broadcast 192.168.18.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER,FAILED> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:19fa/10 
      groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:1bfc/10 
      groupname test

可以看到，在 hme0 上设置了 FAILED 标志，以指示此接口已出现故障。还可以看到，创建了 hme1:2，而 hme1:2 最初是 hme0。然后，地址 192.168.85.19 变成可通过 hme1 进行访问。

与 192.168.85.19 关联的多点传送成员仍可以接收包，但是它们现在通过 hme1 接收包。当进行地址 192.168.85.19 从 hme0 到 hme1 的故障转移时，在 hme0 上创建了伪地址 0.0.0.0。由于创建了伪地址，因此仍可以访问 hme0。如果没有 hme0，hme0:1 便无法存在。在执行后续的故障恢复时，将删除伪地址。

同样，进行了 IPv6 地址从 hme0 到 hme1 的故障转移。在 IPv6 中，多点传送成员与接口索引关联。多点传送成员也从 hme0 故障转移到 hme1。而且还移动了 in.ndpd 配置的所有地址。示例中未说明此操作。

in.mpathd 守护进程继续通过故障接口 hme0 进行探测。守护进程在 20 秒的缺省修复检测时间内收到 10 个连续回复后，确定该接口已修复。由于在 hme0 上也设置了 RUNNING 标志，因此守护进程调用故障恢复。在故障恢复后，将恢复原始配置。

有关故障和修复期间在控制台上记录的所有错误消息的说明，请参见 in.mpathd(1M) 手册页。

IPMP 和动态重新配置

使用动态重新配置 (dynamic reconfiguration, DR) 功能，可以在系统运行的同时重新配置系统硬件（如接口）。本节介绍 DR 如何与 IPMP 交互操作。

在支持 NIC 的 DR 的系统上，可以使用 IPMP 保持连通性和防止断开现有的连接。在支持 DR 并使用 IPMP 的系统上，可以安全地连接、拆离或重新连接 NIC。这是因为 IPMP 已集成到重新配置调整管理器 (Reconfiguration Coordination Manager, RCM) 框架中。RCM 用于管理系统组件的动态重新配置。

通常使用 cfgadm 命令执行 DR 操作。但是，一些平台可提供其他方法。有关详细信息，请参阅平台文档。可以从以下资源中找到有关 DR 的特定文档。

连接 NIC

可以随时使用 ifconfig 命令将接口添加到 IPMP 组，如如何配置具有多个接口的 IPMP 组所述。因此，可以检测在系统引导后连接的系统组件上的任何接口并将其添加到现有的 IPMP 组。或者，如果适当，可以将新添加的接口配置到其 IPMP 组中。

这些接口和其上配置的数据地址可供 IPMP 组立即使用。但是，为了使系统在重新引导后自动配置和使用这些接口，必须为每个新接口创建 /etc/hostname.interface 文件。有关说明，请参阅如何在安装系统后配置物理接口。

如果在连接接口时 /etc/hostname.interface 文件已存在，则 RCM 将根据此文件的内容自动配置接口。这样，该接口接收的配置与系统引导后其将接收的配置相同。

拆离 NIC

首先检查拆离包含 NIC 的系统组件的所有请求以确保可以保持连通性。例如，缺省情况下，无法拆离不在 IPMP 组中的 NIC。也无法拆离包含 IPMP 组中仅有的工作接口的 NIC。但是，如果必须移除系统组件，则可以使用 cfgadm 的 -f 选项覆盖此行为，如 cfgadm(1M) 手册页中所述。

如果检查成功，则与已拆离的 NIC 关联的数据地址将故障转移到同一组中的工作 NIC，如同被拆离的 NIC 出现了故障。拆离 NIC 时，会取消 NIC 接口上配置的所有测试地址。然后，从系统中取消检测 NIC。如果其中的任一步骤失败，或者同一系统组件上其他硬件的 DR 失败，则会将先前的配置恢复到其原始状态。您应接收到有关此事件的状态消息。否则，拆离请求成功完成。可以从系统中移除组件。未断开任何现有连接。

重新连接 NIC

RCM 记录与从正在运行的系统拆离的任何 NIC 关联的配置信息。因此，RCM 会像连接新的 NIC 一样，重新连接以前拆离的 NIC。即，RCM 仅执行检测。

但是，重新连接的 NIC 通常具有现有的 /etc/hostname.interface 文件。在这种情况下，RCM 会根据现有 /etc/hostname.interface 文件的内容自动配置接口。此外，RCM 会通知 in.mpathd 守护进程最初在重新连接的接口上承载的每个数据地址。因此，在重新连接的接口正常工作后，其所有数据地址都将故障恢复到重新连接的接口，如同已修复该接口。

如果重新连接的 NIC 没有 /etc/hostname.interface 文件，则没有可用的配置信息。RCM 没有有关如何配置接口的信息。此情况的一个结果是，不会故障恢复以前故障转移到其他接口的地址。

系统引导时缺少的 NIC

系统引导时不存在的 NIC 是特殊的故障检测实例。在引导时，启动脚本会跟踪所有具有无法检测的 /etc/hostname.interface 文件的接口。在这类接口的 /etc/hostname.interface 文件中的所有数据地址将自动驻留在 IPMP 组中的替换接口上。

在此类事件中，会收到与以下内容类似的错误消息：

moving addresses from failed IPv4 interfaces: hme0 (moved to hme1)
moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)

如果不存在备用接口，则收到与以下内容类似的错误消息：

moving addresses from failed IPv4 interfaces: hme0 (couldn't move; 
   no alternative interface) 
 moving addresses from failed IPv6 interfaces: hme0 (couldn't move; 
   no alternative interface) 

在此故障检测实例中，只有在缺少的接口的 /etc/hostname.interface 文件中显式指定的数据地址才会移动到备用接口。不会获取或移动通常通过其他方法（如通过 RARP 或 DHCP）获取的任何地址。

如果使用 DR 重新连接与在系统引导时缺少的接口同名的另一接口，则 RCM 将自动检测该接口。然后，RCM 根据接口的 /etc/hostname.interface 文件内容配置接口。最后，RCM 故障恢复所有数据地址，如同已修复接口。因此，最终的网络配置与在该接口存在的情况下引导系统时进行的配置完全相同。