| Skip Navigation Links | |
| Exit Print View | |
|
System Administration Guide: IP Services Oracle Solaris 10 8/11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
System Administration Guide: IP Services Oracle Solaris 10 8/11 Information Library |
Part I Introducing System Administration: IP Services
1. Oracle Solaris TCP/IP Protocol Suite (Overview)
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)
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)
19. IP Security Architecture (Overview)
21. IP Security Architecture (Reference)
22. Internet Key Exchange (Overview)
24. Internet Key Exchange (Reference)
25. IP Filter in Oracle Solaris (Overview)
28. Administering Mobile IP (Tasks)
29. Mobile IP Files and Commands (Reference)
30. Introducing IPMP (Overview)
Oracle Solaris IPMP Components
Multipathing Daemon, in.mpathd
Failure Detection and Failover
Standby Interfaces in an IPMP Group
Common IPMP Interface Configurations
Checking the Status of an Interface
IPMP Failure Detection and Recovery Features
Detecting Physical Interface Repairs
What Happens During Interface Failover
IPMP and Dynamic Reconfiguration
NICs That Were Missing at System Boot
31. Administering IPMP (Tasks)
Part VII IP Quality of Service (IPQoS)
32. Introducing IPQoS (Overview)
33. Planning for an IPQoS-Enabled Network (Tasks)
34. Creating the IPQoS Configuration File (Tasks)
35. Starting and Maintaining IPQoS (Tasks)
36. Using Flow Accounting and Statistics Gathering (Tasks)
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 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 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.
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.
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.
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.
|