JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Network Interfaces and Network Virtualization     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


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

Part I Network Auto-Magic

2.  Introduction to NWAM

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

11.  Administering Bridges

12.  Administering Link Aggregations

13.  Administering VLANs

14.  Introducing IPMP

15.  Administering IPMP

IPMP Administration Task Maps

IPMP Group Creation and Configuration (Task Map)

IPMP Group Maintenance (Task Map)

Probe-Based Failure Detection Configuration (Task Map)

IPMP Group Monitoring (Task Map)

Configuring IPMP Groups

How to Plan an IPMP Group

How to Configure an IPMP Group by Using DHCP

How to Manually Configure an Active-Active IPMP Group

How to Manually Configure an Active-Standby IPMP Group

Maintaining IPMP Groups

How to Add an Interface to an IPMP Group

How to Remove an Interface From an IPMP Group

How to Add or Remove IP Addresses

How to Move an Interface From One IPMP Group to Another Group

How to Delete an IPMP Group

Configuring for Probe-Based Failure Detection

How to Manually Specify Target Systems for Probe-Based Failure Detection

How to Select Which Failure Detection Method to Use

How to Configure the Behavior of the IPMP Daemon

Recovering an IPMP Configuration With Dynamic Reconfiguration

How to Replace a Physical Card That Has Failed

Monitoring IPMP Information

How to Obtain IPMP Group Information

How to Obtain IPMP Data Address Information

How to Obtain Information About Underlying IP Interfaces of a Group

How to Obtain IPMP Probe Target Information

How to Observe IPMP Probes

How to Customize the Output of the ipmpstat Command in a Script

How to Generate Machine Parseable Output of the ipmpstat Command

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

22.  Monitoring Network Traffic and Resource Usage



Configuring for Probe-Based Failure Detection

Probe-based failure detection involves the use of target systems, as explained in Probe-Based Failure Detection. In identifying targets for probe-based failure detection, the in.mpathd daemon operates in two modes: router target mode or multicast target mode. In the router target mode, the multipathing daemon probes targets that are defined in the routing table. If no targets are defined, then the daemon operates in multicast target mode, where multicast packets are sent out to probe neighbor hosts on the LAN.

Preferably, you should set up host targets for the in.mpathd daemon to probe. For some IPMP groups, the default router is sufficient as a target. However, for some IPMP groups, you might want to configure specific targets for probe-based failure detection. To specify the targets, set up host routes in the routing table as probe targets. Any host routes that are configured in the routing table are listed before the default router. IPMP uses the explicitly defined host routes for target selection. Thus, you should set up host routes to configure specific probe targets rather than use the default router.

To set up host routes in the routing table, you use the route command. You can use the -p option with this command to add persistent routes. For example, route -p add adds a route which will remain in the routing table even after you reboot the system. The -p option thus allows you to add persistent routes without needing any special scripts to recreate these routes every system startup. To optimally use probe-based failure detection, make sure that you set up multiple targets to receive probes.

The sample procedure that follows shows the exact syntax to add persistent routes to targets for probe-based failure detection. For more information about the options for the route command, refer to the route(1M) man page.

Consider the following criteria when evaluating which hosts on your network might make good targets.

How to Manually Specify Target Systems for Probe-Based Failure Detection

  1. Log in with your user account to the system where you are configuring probe-based failure detection.
  2. Add a route to a particular host to be used as a target in probe-based failure detection.
    $ route -p add -host destination-IP gateway-IP -static

    where destination-IP and gateway-IP are IPv4 addresses of the host to be used as a target. For example, you would type the following to specify the target system, which is on the same subnet as the interfaces in IPMP group itops0:

    $ route -p add -host -static

    This new route will be automatically configured every time the system is restarted. If you want to define only a temporary route to a target system for probe-based failure detection, then do not use the -p option.

  3. Add routes to additional hosts on the network to be used as target systems.

How to Select Which Failure Detection Method to Use

By default, probe-based failure detection can only be performed by using test addresses. If the NIC driver supports it, link-based failure detection is also enabled automatically.

You cannot disable link-based failure detection if this method is supported by the NIC driver. However, you can select which type of probe-based failure detection to implement.

  1. To use only transitive probing, perform the following steps:
    1. Use the appropriate SMF commands to switch on the IPMP property transitive-probing.
      # svccfg -s svc:/network/ipmp setprop config/transitive-probing=true
      # svcadm refresh svc:/network/ipmp:default

      For more information about setting this property, see the in.mpathd(1M) man page.

    2. Remove any existing test addresses that have been configured for the IPMP group.
  2. To use only test addresses to probe for failure, perform the following steps:
    1. If necessary, turn off transitive probing.
      # svccfg -s svc:/network/ipmp setprop config/transitive-probing=false
      # svcadm refresh svc:/network/ipmp:default
    2. Assign test addresses to the underlying interfaces of the IPMP group.

How to Configure the Behavior of the IPMP Daemon

Use the IPMP configuration file /etc/default/mpathd to configure the following system-wide parameters for IPMP groups.

  1. Become an administrator.

    For more information, see How to Obtain Administrative Rights in Oracle Solaris Administration: Security Services.

  2. Edit the /etc/default/mpathd file.

    Change the default value of one or more of the three parameters.

    1. Type the new value for the FAILURE_DETECTION_TIME parameter.

      where n is the amount of time in seconds for ICMP probes to detect whether an interface failure has occurred. The default is 10 seconds.

    2. Type the new value for the FAILBACK parameter.
      FAILBACK=[yes | no]
      • yes– The yes value is the default for the failback behavior of IPMP. When the repair of a failed interface is detected, network access fails back to the repaired interface, as described in Detecting Physical Interface Repairs.

      • no – The no value indicates that data traffic does not move back to a repaired interface. When a failed interfaces is detected as repaired, the INACTIVE flag is set for that interface. This flag indicates that the interface is currently not to be used for data traffic. The interface can still be used for probe traffic.

        For example, the IPMP group ipmp0 consists of two interfaces, net0 and net1. In the /etc/default/mpathd file, the FAILBACK=no parameter is set. If net0 fails, then it is flagged as FAILED and becomes unusable. After repair, the interface is flagged as INACTIVE and remains unusable because of the FAILBACK=no setting.

        If net1 fails and only net0 is in the INACTIVE state, then net0's INACTIVE flag is cleared and the interface becomes usable. If the IPMP group has other interfaces that are also in the INACTIVE state, then any one of these INACTIVE interfaces, and not necessarily net0, can be cleared and become usable when net1 fails.

    3. Type the new value for the TRACK_INTERFACES_ONLY_WITH_GROUPS parameter.

      Note - For information about this parameter and the anonymous group feature, see Failure Detection and the Anonymous Group Feature.

      • yes– The yes value is the default for the behavior of IPMP. This parameter causes IPMP to ignore network interfaces that are not configured into an IPMP group.

      • no – The no value sets failure and repair detection for all network interfaces, regardless of whether they are configured into an IPMP group. However, when a failure or repair is detected on an interface that is not configured into an IPMP group, no action is triggered in IPMP to maintain the networking functions of that interface. Therefore, theno value is only useful for reporting failures and does not directly improve network availability.

  3. Restart the in.mpathd daemon.
    # pkill -HUP in.mpathd