1in.mpathd(1M)           System Administration Commands           in.mpathd(1M)
2
3
4

NAME

6       in.mpathd - IP multipathing daemon
7

SYNOPSIS

9       /usr/lib/inet/in.mpathd
10
11

DESCRIPTION

13       The  in.mpathd  daemon  performs  failure  and  repair detection for IP
14       interfaces that have been placed into an IPMP group (or optionally, for
15       all  IP interfaces on the system). It also controls which IP interfaces
16       in an IPMP group are "active" (being used by  the  system  to  send  or
17       receive IP data traffic) in a manner that is consistent with the admin‐
18       istrator's configured policy.
19
20
21       The in.mpathd daemon can detect IP interface failure and repair through
22       two  methods:  by monitoring the IFF_RUNNING flag for each IP interface
23       (link-based failure detection),  and  by  sending  and  receiving  ICMP
24       probes on each IP interface (probe-based failure detection). Link-based
25       failure detection is instantaneous and is always enabled (provided  the
26       network  driver  supports  the  feature); probe-based failure detection
27       must be enabled through the configuration of one or more test addresses
28       (described  below),  but tests the entire IP interface send and receive
29       path. The ipmpstat(1M) utility can  be  used  to  check  which  failure
30       detection methods are enabled.
31
32
33       If only link-based failure detection is enabled, then the health of the
34       interface is determined solely from the state of the IFF_RUNNING  flag.
35       Otherwise,  the  interface  is  considered  failed if either of the two
36       methods indicate a failure, and repaired once both methods indicate the
37       failure  has  been  corrected. Not all interfaces in a group need to be
38       configured with the same failure detection methods.
39
40
41       As mentioned above, to perform probe-based failure detection  in.mpathd
42       requires a test address on each IP interface for the purpose of sending
43       and receiving probes. Each  address  must  be  marked  NOFAILOVER  (see
44       ifconfig(1M))  and  in.mpathd will be limited to probing targets on the
45       same subnet. Each address may be configured statically or  acquired  by
46       means  of  DHCP.  To find targets, in.mpathd first consults the routing
47       table for routes on the same subnet, and uses the  specified  next-hop.
48       If no routes match, it sends all-hosts ICMP probes and selects a subset
49       of the systems that respond. Thus, for probe-based failure detection to
50       operate,  there  must  be  at  least  one  neighbor on each subnet that
51       responds to ICMP echo request probes. The ipmpstat(1M) utility  can  be
52       used  to display both the current probe target information and the sta‐
53       tus of sent probes.
54
55
56       Both IPv4 and IPv6 are supported. If an IP  interface  is  plumbed  for
57       IPv4  and  an IPv4 test address is configured then in.mpathd will start
58       sending ICMPv4 probes over that  IP  interface.  Similarly,  if  an  IP
59       interface  is  plumbed for IPv6 and an IPv6 test address is configured,
60       then in.mpathd will start sending ICMPv6 probes over that IP interface.
61       However,  note  that in.mpathd will ignore IPv6 test addresses that are
62       not link-local. If both IPv4 and IPv6 are plumbed, it is sufficient  to
63       configure  only one of the two, that is, either an IPv4 test address or
64       an IPv6 test address. If both IPv4 and IPv6 test addresses are  config‐
65       ured, in.mpathd probes using both ICMPv4 and ICMPv6.
66
67
68       As  mentioned  above, in.mpathd also controls which IP interfaces in an
69       IPMP group are "active" (used by the system to send and receive IP data
70       traffic).  Specifically, in.mpathd tracks the administrative configura‐
71       tion of each IPMP group and attempts to keep the number  of  active  IP
72       interfaces in each group consistent with that configuration. Therefore,
73       if an active IP interface fails, in.mpathd will  activate  an  INACTIVE
74       interface  in  the  group, provided one exists (it will prefer INACTIVE
75       interfaces that are also marked STANDBY). Likewise, if an IP  interface
76       repairs and the resulting repair leaves the IPMP group with more active
77       interfaces than the administrative configuration  specifies,  in.mpathd
78       will  deactivate one of the interfaces (preferably one marked STANDBY),
79       except when the FAILBACK variable is used, as described below.  Similar
80       adjustments will be made by in.mpathd when offlining IP interfaces (for
81       instance, in response to if_mpadm(1M)).
82
83
84       The   in.mpathd   daemon   accesses   three    variable    values    in
85       /etc/default/mpathd:  FAILURE_DETECTION_TIME, FAILBACK and TRACK_INTER‐
86       FACES_ONLY_WITH_GROUPS.
87
88
89       The FAILURE_DETECTION_TIME variable specifies the  probe-based  failure
90       detection  time. The shorter the failure detection time, the more probe
91       traffic. The default value of  FAILURE_DETECTION_TIME  is  10  seconds.
92       This  means  that  IP  interface  failure will be detected by in.mpathd
93       within 10 seconds. The IP interface repair  detection  time  is  always
94       twice  the  value  of  FAILURE_DETECTION_TIME.  Note  that failures and
95       repairs detected by link-based failure detection are acted  on  immedi‐
96       ately,  though  in.mpathd  may ignore link state changes if it suspects
97       that the link state is flapping due to defective hardware; see DIAGNOS‐
98       TICS.
99
100
101       By  default, in.mpathd limits failure and repair detection to IP inter‐
102       faces that are configured as  part  of  a  named  IPMP  group.  Setting
103       TRACK_INTERFACES_ONLY_WITH_GROUPS  to  no  enables  failure  and repair
104       detection on all IP interfaces, even if they are not part  of  a  named
105       IPMP group. IP interfaces that are tracked but not part of a named IPMP
106       group are considered to be part of the "anonymous" IPMP group. In addi‐
107       tion  to  having  no  name,  this  IPMP group is special in that its IP
108       interfaces are not equivalent and thus cannot take over for one another
109       in  the  event  of an IP interface failure. That is, the anonymous IPMP
110       group can only be used for failure and repair detection,  and  provides
111       no high-availability or load-spreading.
112
113
114       As  described  above,  when  in.mpathd detects that an IP interface has
115       repaired, it activates it so that it will again be  used  to  send  and
116       receive IP data traffic. However, if FAILBACK is set to no, then the IP
117       interface will only be activated if no other active  IP  interfaces  in
118       the  group remain. However, the interface may subsequently be activated
119       if another IP interface in the group fails.
120

FILES

122       /etc/default/mpathd    Contains default values used  by  the  in.mpathd
123                              daemon.
124
125

ATTRIBUTES

127       See attributes(5) for descriptions of the following attributes:
128
129
130
131
132       ┌─────────────────────────────┬─────────────────────────────┐
133       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
134       ├─────────────────────────────┼─────────────────────────────┤
135       │Availability                 │SUNWcsr                      │
136       └─────────────────────────────┴─────────────────────────────┘
137

SEE ALSO

139       if_mpadm(1M),   ifconfig(1M),  ipmpstat(1M),  attributes(5),  icmp(7P),
140       icmp6(7P),
141
142
143       System Administration Guide: IP Services
144

DIAGNOSTICS

146       IP interface interface_name has a hardware address which is not  unique
147       in group group_name; offlining
148           Description:
149
150
151           For  probe-based  failure detection, load-spreading, and other code
152           IPMP features to work properly, each IP interface in an IPMP  group
153           must  have  a  unique  hardware address. If this requirement is not
154           met, in.mpathd will automatically offline all but  one  of  the  IP
155           interfaces with duplicate hardware addresses.
156
157
158
159       IP  interface interface_name now has a unique hardware address in group
160       group_name; onlining
161           Description:
162
163
164           The previously-detected duplicate hardware address is  now  unique,
165           and therefore in.mpathd has brought interface_name back online.
166
167
168
169       Test  address  address  is  not  unique in group; disabling probe-based
170       failure detection on interface_name
171           Description:
172
173
174           For in.mpathd to perform probe-based failure detection,  each  test
175           address in the group must be unique.
176
177
178
179       No test address configured on interface interface_name disabling probe-
180       based failure detection on it
181           Description:
182
183
184           For in.mpathd to perform probe-based failure  detection  on  an  IP
185           interface,  it  must be configured with a test address: IPv4, IPv6,
186           or both.
187
188
189
190       IP interface_name in group group_name  is  not  plumbed  for  IPv[4|6],
191       affecting IPv[4|6] connectivity
192           Description:
193
194
195           All  IP  interfaces  in  a multipathing group must be homogeneously
196           plumbed. For example, if one IP interface is plumbed for IPv4, then
197           all  IP  interfaces  in the group must be plumbed for IPv4, or IPv4
198           packets will not be able to be  reliably  sent  and  received.  The
199           STREAMS modules pushed on all IP interfaces must also be identical.
200
201
202
203       The  link  has  come up on interface_name more than 2 times in the last
204       minute; disabling repair until it stabilizes.
205           Description:
206
207
208           To limit the impact of interfaces with intermittent hardware  (such
209           as a bad cable), in.mpathd will not consider an IP interface with a
210           frequently changing link state as repaired  until  the  link  state
211           stabilizes.
212
213
214
215       Invalid failure detection time of time, assuming default 10000 ms
216           Description:
217
218
219           An  invalid value was encountered for FAILURE_DETECTION_TIME in the
220           /etc/default/mpathd file.
221
222
223
224       Too small failure detection time of time, assuming minimum of 100 ms
225           Description:
226
227
228           The minimum value that can be specified for  FAILURE_DETECTION_TIME
229           is currently 100 milliseconds.
230
231
232
233       Invalid value for FAILBACK value
234           Description:
235
236
237           Valid values for the boolean variable FAILBACK are yes or no.
238
239
240
241       Invalid value for TRACK_INTERFACES_ONLY_WITH_GROUPS value
242           Description:
243
244
245           Valid    values    for    the    boolean    variable   TRACK_INTER‐
246           FACES_ONLY_WITH_GROUPS are yes or no.
247
248
249
250       Cannot meet requested failure detection time of  time  ms  on  (inet[6]
251       interface_name) new failure detection time for group group_name is time
252       ms
253           Description:
254
255
256           The round trip time for ICMP probes is  higher  than  necessary  to
257           maintain  the current failure detection time. The network is proba‐
258           bly congested or the probe targets are loaded. in.mpathd  automati‐
259           cally  increases  the  failure  detection  time  to whatever it can
260           achieve under these conditions.
261
262
263
264       Improved failure detection time time ms on (inet[6] interface_name) for
265       group group_name
266           Description:
267
268
269           The round trip time for ICMP probes has now decreased and in.mpathd
270           has lowered the failure detection time correspondingly.
271
272
273
274       IP interface failure detected on interface_name
275           Description:
276
277
278           in.mpathd has detected a failure on interface_name, and has set the
279           IFF_FAILED  flag  on  interface_name,  ensuring that it will not be
280           used for IP data traffic.
281
282
283
284       IP interface repair detected on interface_name
285           Description:
286
287
288           in.mpathd has detected a repair on interface_name, and has  cleared
289           the IFF_FAILED flag. Depending on the administrative configuration,
290           the interface_name may again be used for IP data traffic.
291
292
293
294       All IP interfaces in group group are now unusable
295           Description:
296
297
298           in.mpathd has determined that none of the IP  interfaces  in  group
299           can  be used for IP data traffic, breaking network connectivity for
300           the group.
301
302
303
304       At least 1 IP interface (interface_name) in group group is now usable
305           Description:
306
307
308           in.mpathd has determined that at least one of the IP interfaces  in
309           group can again be used for IP data traffic, restoring network con‐
310           nectivity for the group.
311
312
313
314       The link has gone down on interface_name
315           Description:
316
317
318           in.mpathd has detected that the IFF_RUNNING flag for interface_name
319           has been cleared, indicating that the link has gone down.
320
321
322
323       The link has come up on interface_name
324           Description:
325
326
327           in.mpathd has detected that the IFF_RUNNING flag for interface_name
328           has been set, indicating that the link has come up.
329
330
331
332
333SunOS 5.11                        13 May 2009                    in.mpathd(1M)
Impressum