Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Network Interfaces and Network Virtualization Oracle Solaris 11 Information Library |
1. Overview of the Networking Stack
Network Configuration in This Oracle Solaris Release
The Network Stack in Oracle Solaris
Network Devices and Datalink Names
Administration of Other Link Types
3. NWAM Configuration and Administration (Overview)
4. NWAM Profile Configuration (Tasks)
5. NWAM Profile Administration (Tasks)
6. About the NWAM Graphical User Interface
Part II Datalink and Interface Configuration
7. Using Datalink and Interface Configuration Commands on Profiles
8. Datalink Configuration and Administration
9. Configuring an IP Interface
10. Configuring Wireless Interface Communications on Oracle Solaris
12. Administering Link Aggregations
Comparing IPMP and Link Aggregation
Using Flexible Link Names on IPMP Configuration
IPMP Components in Oracle Solaris
Types of IPMP Interface Configurations
Failure and Repair Detection in IPMP
Types of Failure Detection in IPMP
Failure Detection and the Anonymous Group Feature
Detecting Physical Interface Repairs
IPMP and Dynamic Reconfiguration
16. Exchanging Network Connectivity Information With LLDP
Part III Network Virtualization and Resource Management
17. Introducing Network Virtualization and Resource Control (Overview)
18. Planning for Network Virtualization and Resource Control
19. Configuring Virtual Networks (Tasks)
20. Using Link Protection in Virtualized Environments
21. Managing Network Resources
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 are the conventional IPv4 and IPv6 addresses that are assigned to an IP interface dynamically at boot time by the DHCP server, or manually by using the ipadm command. Data addresses are assigned to the IPMP interface. The standard IPv4 packet traffic and, if applicable, IPv6 packet traffic are considered data traffic. Data traffic flow use the data addresses that are hosted on the IPMP interface and flow through the active interfaces of that group.
Test Addresses are IPMP-specific addresses that are used by the in.mpathd daemon to perform probe-based failure and repair detection. Test addresses can also be assigned dynamically by the DHCP server, or manually by using the ipadm command. While data addresses are assigned to the IPMP interface, only test addresses are assigned to the underlying interfaces of the group. For an underlying interface on a dual-stack network, you can configure an IPv4 test address or an IPv6 test address or both. When an underlying interface fails, the interface's test address continues to be used by the in.mpathd daemon for probe-based failure detection to check for the interface's subsequent repair.
Note - You need to configure test addresses only if you specifically want to use probe-based failure detection. Otherwise, you can enable transitive probing to detect failure without using test addresses. For more information about probe-based failure detection with or without using test addresses, refer to Probe-Based Failure Detection.
In previous IPMP implementations, test addresses needed to be marked as DEPRECATED to avoid being used by applications especially during interface failures. In the current implementation, test addresses reside in the underlying interfaces. Thus, these addresses can no longer be accidentally used by applications that are unaware of IPMP. However, to ensure that these addresses will not be considered as a possible source for data packets, the system automatically marks any addresses with the NOFAILOVER flag as also DEPRECATED.
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 network with addresses on the appropriate RFC 1918 subnet. The in.mpathd daemon can then successfully exchange probes with target systems. For more information about RFC 1918 private addresses, refer to RFC 1918, Address Allocation for Private Internets.
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 ipadm.
For more information on link-local addresses, refer to Link-Local Unicast Address in System Administration Guide: IP Services.
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.