|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Administration: Network Interfaces and Network Virtualization Oracle Solaris 11 Information Library|
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.
Make sure that the prospective targets are available and running. Make a list of their IP addresses.
Ensure that the target interfaces are on the same network as the IPMP group that you are configuring.
The netmask and broadcast address of the target systems must be the same as the addresses in the IPMP group.
The target host must be able to answer ICMP requests from the interface that is using 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 192.168.10.137, which is on the same subnet as the interfaces in IPMP group itops0:
$ route -p add -host 192.168.10.137 192.168.10.137 -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.
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.
# 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.
# svccfg -s svc:/network/ipmp setprop config/transitive-probing=false # svcadm refresh svc:/network/ipmp:default
For more information, see How to Obtain Administrative Rights in Oracle Solaris Administration: Security Services.
Change the default value of one or more of the three parameters.
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.
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.
TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]
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.
# pkill -HUP in.mpathd