JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: IP Services     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


Part I Introducing System Administration: IP Services

1.  Oracle Solaris TCP/IP Protocol Suite (Overview)

Part II TCP/IP Administration

2.  Planning Your TCP/IP Network (Tasks)

3.  Introducing IPv6 (Overview)

4.  Planning an IPv6 Network (Tasks)

5.  Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

6.  Administering Network Interfaces (Tasks)

7.  Configuring an IPv6 Network (Tasks)

8.  Administering a TCP/IP Network (Tasks)

9.  Troubleshooting Network Problems (Tasks)

10.  TCP/IP and IPv4 in Depth (Reference)

11.  IPv6 in Depth (Reference)


12.  About DHCP (Overview)

13.  Planning for DHCP Service (Tasks)

14.  Configuring the DHCP Service (Tasks)

15.  Administering DHCP (Tasks)

16.  Configuring and Administering the DHCP Client

17.  Troubleshooting DHCP (Reference)

18.  DHCP Commands and Files (Reference)

Part IV IP Security

19.  IP Security Architecture (Overview)

20.  Configuring IPsec (Tasks)

21.  IP Security Architecture (Reference)

22.  Internet Key Exchange (Overview)

23.  Configuring IKE (Tasks)

24.  Internet Key Exchange (Reference)

25.  IP Filter in Oracle Solaris (Overview)

26.  IP Filter (Tasks)


27.  Introducing IPMP (Overview)

Why You Should Use IPMP

Oracle Solaris IPMP Components

Multipathing Daemon, in.mpathd

IPMP Terminology and Concepts

IP Link

Physical Interface

Network Interface Card

IPMP Group

Failure Detection and Failover

Repair Detection and Failback

Target Systems

Outbound Load Spreading

Dynamic Reconfiguration

Basic Requirements of IPMP

IPMP Addressing

Data Addresses

Test Addresses

IPv4 Test Addresses

IPv6 Test Addresses

Preventing Applications From Using Test Addresses

IPMP Interface Configurations

Standby Interfaces in an IPMP Group

Common IPMP Interface Configurations

Checking the Status of an Interface

IPMP Failure Detection and Recovery Features

Link-Based Failure Detection

Probe-Based Failure Detection

Group Failures

Detecting Physical Interface Repairs

What Happens During Interface Failover

IPMP and Dynamic Reconfiguration

Attaching NICs

Detaching NICs

Reattaching NICs

NICs That Were Missing at System Boot

28.  Administering IPMP (Tasks)

Part VI IP Quality of Service (IPQoS)

29.  Introducing IPQoS (Overview)

30.  Planning for an IPQoS-Enabled Network (Tasks)

31.  Creating the IPQoS Configuration File (Tasks)

32.  Starting and Maintaining IPQoS (Tasks)

33.  Using Flow Accounting and Statistics Gathering (Tasks)

34.  IPQoS in Detail (Reference)



IPMP Addressing

You can configure IPMP failure detection on both IPv4 networks and dual-stack, IPv4 and IPv6 networks. Interfaces that are configured with IPMP support two types of addresses: data addresses and test addresses.

Data Addresses

Data addresses are the conventional IPv4 and IPv6 addresses that are assigned to an interface of a NIC at boot time or manually, through the ifconfig command. The standard IPv4 and, if applicable, IPv6 packet traffic through an interface is considered to be data traffic.

Test Addresses

Test addresses are IPMP-specific addresses that are used by the in.mpathd daemon. For an interface to use probe-based failure and repair detection, that interface must be configured with at least one test address.

Note - You need to configure test addresses only if you want to use probe-based failure detection.

The in.mpathd daemon uses test addresses to exchange ICMP probes, also called probe traffic, with other targets on the IP link. Probe traffic helps to determine the status of the interface and its NIC, including whether an interface has failed. The probes verify that the send and receive path to the interface is working correctly.

Each interface can be configured with an IP test address. For an interface on a dual-stack network, you can configure an IPv4 test address, an IPv6 test address, or both IPv4 and IPv6 test addresses.

After an interface fails, the test addresses remain on the failed interface so that in.mpathd can continue to send probes to check for subsequent repair. You must specifically configure test addresses so that applications do not accidentally use them. For more information, refer to Preventing Applications From Using Test Addresses.

For more information on probe-based failure detection, refer to Probe-Based Failure Detection.

IPv4 Test Addresses

In general, you can use any IPv4 address on your subnet as a test address. IPv4 test addresses do not need to be routeable. Because IPv4 addresses are a limited resource for many sites, you might want to use non-routeable RFC 1918 private addresses as test addresses. Note that the in.mpathd daemon exchanges only ICMP probes with other hosts on the same subnet as the test address. If you do use RFC 1918-style test addresses, be sure to configure other systems, preferably routers, on the IP link with addresses on the appropriate RFC 1918 subnet. The in.mpathd daemon can then successfully exchange probes with target systems.

The IPMP examples use RFC 1918 addresses from the 192.168.0/24 network as IPv4 test addresses. For more information about RFC 1918 private addresses, refer to RFC 1918, Address Allocation for Private Internets.

To configure IPv4 test addresses, refer to the task How to Configure an IPMP Group With Multiple Interfaces.

IPv6 Test Addresses

The only valid IPv6 test address is the link-local address of a physical interface. You do not need a separate IPv6 address to serve as an IPMP test address. The IPv6 link-local address is based on the Media Access Control (MAC ) address of the interface. Link-local addresses are automatically configured when the interface becomes IPv6-enabled at boot time or when the interface is manually configured through ifconfig.

To identify the link-local address of an interface, run the ifconfig interface command on an IPv6-enabled node. Check the output for the address that begins with the prefix fe80, the link-local prefix. The NOFAILOVER flag in the following ifconfig output indicates that the link-local address fe80::a00:20ff:feb9:17fa/10 of the hme0 interface is used as the test address.

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

For more information on link-local addresses, refer to Link-Local Unicast Address.

When an IPMP group has both IPv4 and IPv6 plumbed on all the group's interfaces, you do not need to configure separate IPv4 test addresses. The in.mpathd daemon can use the IPv6 link-local addresses as test addresses.

To create an IPv6 test address, refer to the task How to Configure an IPMP Group With Multiple Interfaces.

Preventing Applications From Using Test Addresses

After you have configured a test address, you need to ensure that this address is not used by applications. Otherwise, if the interface fails, the application is no longer reachable because test addresses do not fail over during the failover operation. To ensure that IP does not choose the test address for normal applications, mark the test address as deprecated.

IPv4 does not use a deprecated address as a source address for any communication, unless an application explicitly binds to the address. The in.mpathd daemon explicitly binds to such an address in order to send and receive probe traffic. However, if an application does not explicitly bind to an address and the only address that is marked as UP on the interface is also marked as deprecated, then as a last resort that address is used as a source address.

Note - In cases of failover and failback, while the Duplicate Address Detection is still running, applications might receive packets that use deprecated addresses as source addresses. This behavior is expected. Typically, after DAD has completed, then deprecated addresses will no longer be processed by applications. However, a rare exception might be observed with TCP packets. After a TCP connection has chosen a particular source address, the use of that address cannot be changed over the duration of that connection. That duration can extend over a long period of time. In such edge cases, the possibilities exists that applications might still continue to use deprecated addresses even after DAD completes.

Because IPv6 link-local addresses are usually not present in a name service, DNS and NIS applications do not use link-local addresses for communication. Consequently, you must not mark IPv6 link-local addresses as deprecated.

IPv4 test addresses should not be placed in the DNS and NIS name service tables. In IPv6, link-local addresses are not normally placed in the name service tables.