Solaris 10 IPMP - failback=no


Login or Register for Dates, Times and to Reply

 
Thread Tools Search this Thread
# 1  
Solaris 10 IPMP - failback=no

Hi all,

Just a few questions ->

Is an "OFFLINE" interface going back to "ONLINE" consider as a failback by IPMP ?

I have "FAILBACK=no" in my /etc/default/mpathd; however when i do the following
(igb0 and igb7 are in the same ipmp link based group)

Quote:
if_mpadm -d igb7
-- see ip on igb7 failover to igb0

if_mpadm -r igb7
-- see ip for igb7 (currently on igb0) failback to igb7
q1) why does "if_mpadm -r igb7" cause the ip of igb7 (on igb0) to failback to igb7 when i have "FAILBACK=no" ?

==================

q2) is there any difference between the following IPMP linked base (active, active) setup

a) active, active (1 active ip only, 0.0.0.0 on the other interface)
e.g. hostname.igb0 ( hosta group group1 up )
hostname.igb7 ( group group1 up )

b) active, active (2 active ips , 1 on each interface)
e.g. hostname.igb0 ( hosta group group1 up )
hostname.igb7 ( hostb group group1 up )

Smilie

Regards,
Noob

Last edited by javanoob; 07-25-2016 at 08:34 AM..
Login or Register for Dates, Times and to Reply

Previous Thread | Next Thread
Thread Tools Search this Thread
Search this Thread:
Advanced Search

10 More Discussions You Might Find Interesting

1. Solaris

New to Solaris IPMP (conversion from Linux)

Hi all, I been reading examples of how to setup IPMP and how it differs from Etherchannel. However, i am still unsure of how it really works and i hope gurus here can shed some light on the questions I have below while i will lab it up for my own test -> q1) for IPMP, there is no such thing... (23 Replies)
Discussion started by: javanoob
23 Replies

2. Solaris

IPMP over aggregate in Solaris 11

hi all, i start with solaris 11 and i am disapointed by the change on ip managing. i want to set a ipmp over tow aggregate but i dont find any doc and i am lost with the new commande switch1 net0 aggregate1 | net1 aggregate1 |-----| |... (1 Reply)
Discussion started by: sylvain
1 Replies

3. Solaris

Solaris 10 branded zone with IPMP

All. I am trying to create a 10 branded zone on a Sol 11.1 T5. The Global is using IPMP...so aggregating is out of the question. Has anyone successfully created a branded zone with IPMP? If they have can you please show me the steps you took to get this to run. Thanks (4 Replies)
Discussion started by: aeroforce
4 Replies

4. Solaris

Link Based IPMP on Shared IP Solaris Zone

Hi, This may have already been raised previously so sorry for the duplication. What I want to achieve is have a physical server using link based IPMP setup in the global zone (not problem doing that) and then create a zone set as Shared-IP so when the servers NIC has an issue the IP will... (0 Replies)
Discussion started by: giles.cardew
0 Replies

5. Solaris

Solaris IPMP

Can any one please explain me the concept behind IPMP in solaris clustering.Basic explanation would be really appreciated... Thanks in Advance vks (2 Replies)
Discussion started by: vks47
2 Replies

6. Solaris

how to configure IPMP in solaris 9

Hi friends , can anyone provide me the complete steps to configure IPMP in solaris 9 or 10 provided i have two NIC card ? regards jagan (4 Replies)
Discussion started by: jaganblore
4 Replies

7. Solaris

IPMP config

Hi All, I have unplumbed one interface. after that ifconfig -a shows that lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 ... (7 Replies)
Discussion started by: jegaraman
7 Replies

8. Solaris

Ipmp

Hi All, Kindly help me in configuring IPMP or guid me to some link, tried goggling however no luck. Thanks in anticipation (1 Reply)
Discussion started by: kumarmani
1 Replies

9. Solaris

Does Veritas Cluster work with IPMP on Solaris 10?

Does Veritas Cluster work with IPMP on Solaris 10? If anyone has set it up do you have a doc or tips? I have heard several different statements ranging from , not working at all to Yes it works! Great How? * Test and Base IPs???? * configure the MultiNICB agent ? I can give details... (1 Reply)
Discussion started by: dfezz1
1 Replies

10. Solaris

Solaris IP Multipathing (IPMP) Help

Hello All, I work for a Health care company at a local trauma hospital. I maintain a Picture Archiving and Communication System (PAC's). Basically, any medical images (X-Ray, CT, MRI, Mammo, etc) are stored digitally on the servers for viewing and dictation from diagnostic stations. I took over... (10 Replies)
Discussion started by: mainegeek
10 Replies
in.mpathd(1M)						  System Administration Commands					     in.mpathd(1M)

NAME
in.mpathd - IP multipathing daemon SYNOPSIS
/usr/lib/inet/in.mpathd DESCRIPTION
The in.mpathd daemon performs failure and repair detection for IP interfaces that have been placed into an IPMP group (or optionally, for all IP interfaces on the system). It also controls which IP interfaces in an IPMP group are "active" (being used by the system to send or receive IP data traffic) in a manner that is consistent with the administrator's configured policy. The in.mpathd daemon can detect IP interface failure and repair through two methods: by monitoring the IFF_RUNNING flag for each IP inter- face (link-based failure detection), and by sending and receiving ICMP probes on each IP interface (probe-based failure detection). Link- based failure detection is instantaneous and is always enabled (provided the network driver supports the feature); probe-based failure detection must be enabled through the configuration of one or more test addresses (described below), but tests the entire IP interface send and receive path. The ipmpstat(1M) utility can be used to check which failure detection methods are enabled. If only link-based failure detection is enabled, then the health of the interface is determined solely from the state of the IFF_RUNNING flag. Otherwise, the interface is considered failed if either of the two methods indicate a failure, and repaired once both methods indi- cate the failure has been corrected. Not all interfaces in a group need to be configured with the same failure detection methods. As mentioned above, to perform probe-based failure detection in.mpathd requires a test address on each IP interface for the purpose of sending and receiving probes. Each address must be marked NOFAILOVER (see ifconfig(1M)) and in.mpathd will be limited to probing targets on the same subnet. Each address may be configured statically or acquired by means of DHCP. To find targets, in.mpathd first consults the routing table for routes on the same subnet, and uses the specified next-hop. If no routes match, it sends all-hosts ICMP probes and selects a subset of the systems that respond. Thus, for probe-based failure detection to operate, there must be at least one neighbor on each subnet that responds to ICMP echo request probes. The ipmpstat(1M) utility can be used to display both the current probe target infor- mation and the status of sent probes. Both IPv4 and IPv6 are supported. If an IP interface is plumbed for IPv4 and an IPv4 test address is configured then in.mpathd will start sending ICMPv4 probes over that IP interface. Similarly, if an IP interface is plumbed for IPv6 and an IPv6 test address is configured, then in.mpathd will start sending ICMPv6 probes over that IP interface. However, note that in.mpathd will ignore IPv6 test addresses that are not link-local. If both IPv4 and IPv6 are plumbed, it is sufficient to configure only one of the two, that is, either an IPv4 test address or an IPv6 test address. If both IPv4 and IPv6 test addresses are configured, in.mpathd probes using both ICMPv4 and ICMPv6. As mentioned above, in.mpathd also controls which IP interfaces in an IPMP group are "active" (used by the system to send and receive IP data traffic). Specifically, in.mpathd tracks the administrative configuration of each IPMP group and attempts to keep the number of active IP interfaces in each group consistent with that configuration. Therefore, if an active IP interface fails, in.mpathd will activate an INACTIVE interface in the group, provided one exists (it will prefer INACTIVE interfaces that are also marked STANDBY). Likewise, if an IP interface repairs and the resulting repair leaves the IPMP group with more active interfaces than the administrative configuration speci- fies, in.mpathd will deactivate one of the interfaces (preferably one marked STANDBY), except when the FAILBACK variable is used, as described below. Similar adjustments will be made by in.mpathd when offlining IP interfaces (for instance, in response to if_mpadm(1M)). The in.mpathd daemon accesses three variable values in /etc/default/mpathd: FAILURE_DETECTION_TIME, FAILBACK and TRACK_INTER- FACES_ONLY_WITH_GROUPS. The FAILURE_DETECTION_TIME variable specifies the probe-based failure detection time. The shorter the failure detection time, the more probe traffic. The default value of FAILURE_DETECTION_TIME is 10 seconds. This means that IP interface failure will be detected by in.mpathd within 10 seconds. The IP interface repair detection time is always twice the value of FAILURE_DETECTION_TIME. Note that failures and repairs detected by link-based failure detection are acted on immediately, though in.mpathd may ignore link state changes if it sus- pects that the link state is flapping due to defective hardware; see DIAGNOSTICS. By default, in.mpathd limits failure and repair detection to IP interfaces that are configured as part of a named IPMP group. Setting TRACK_INTERFACES_ONLY_WITH_GROUPS to no enables failure and repair detection on all IP interfaces, even if they are not part of a named IPMP group. IP interfaces that are tracked but not part of a named IPMP group are considered to be part of the "anonymous" IPMP group. In addition to having no name, this IPMP group is special in that its IP interfaces are not equivalent and thus cannot take over for one another in the event of an IP interface failure. That is, the anonymous IPMP group can only be used for failure and repair detection, and provides no high-availability or load-spreading. As described above, when in.mpathd detects that an IP interface has repaired, it activates it so that it will again be used to send and receive IP data traffic. However, if FAILBACK is set to no, then the IP interface will only be activated if no other active IP interfaces in the group remain. However, the interface may subsequently be activated if another IP interface in the group fails. FILES
/etc/default/mpathd Contains default values used by the in.mpathd daemon. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Availability |SUNWcsr | +-----------------------------+-----------------------------+ SEE ALSO
if_mpadm(1M), ifconfig(1M), ipmpstat(1M), attributes(5), icmp(7P), icmp6(7P), System Administration Guide: IP Services DIAGNOSTICS
IP interface interface_name has a hardware address which is not unique in group group_name; offlining Description: For probe-based failure detection, load-spreading, and other code IPMP features to work properly, each IP interface in an IPMP group must have a unique hardware address. If this requirement is not met, in.mpathd will automatically offline all but one of the IP inter- faces with duplicate hardware addresses. IP interface interface_name now has a unique hardware address in group group_name; onlining Description: The previously-detected duplicate hardware address is now unique, and therefore in.mpathd has brought interface_name back online. Test address address is not unique in group; disabling probe-based failure detection on interface_name Description: For in.mpathd to perform probe-based failure detection, each test address in the group must be unique. No test address configured on interface interface_name disabling probe-based failure detection on it Description: For in.mpathd to perform probe-based failure detection on an IP interface, it must be configured with a test address: IPv4, IPv6, or both. IP interface_name in group group_name is not plumbed for IPv[4|6], affecting IPv[4|6] connectivity Description: All IP interfaces in a multipathing group must be homogeneously plumbed. For example, if one IP interface is plumbed for IPv4, then all IP interfaces in the group must be plumbed for IPv4, or IPv4 packets will not be able to be reliably sent and received. The STREAMS modules pushed on all IP interfaces must also be identical. The link has come up on interface_name more than 2 times in the last minute; disabling repair until it stabilizes. Description: To limit the impact of interfaces with intermittent hardware (such as a bad cable), in.mpathd will not consider an IP interface with a frequently changing link state as repaired until the link state stabilizes. Invalid failure detection time of time, assuming default 10000 ms Description: An invalid value was encountered for FAILURE_DETECTION_TIME in the /etc/default/mpathd file. Too small failure detection time of time, assuming minimum of 100 ms Description: The minimum value that can be specified for FAILURE_DETECTION_TIME is currently 100 milliseconds. Invalid value for FAILBACK value Description: Valid values for the boolean variable FAILBACK are yes or no. Invalid value for TRACK_INTERFACES_ONLY_WITH_GROUPS value Description: Valid values for the boolean variable TRACK_INTERFACES_ONLY_WITH_GROUPS are yes or no. Cannot meet requested failure detection time of time ms on (inet[6] interface_name) new failure detection time for group group_name is time ms Description: The round trip time for ICMP probes is higher than necessary to maintain the current failure detection time. The network is probably congested or the probe targets are loaded. in.mpathd automatically increases the failure detection time to whatever it can achieve under these conditions. Improved failure detection time time ms on (inet[6] interface_name) for group group_name Description: The round trip time for ICMP probes has now decreased and in.mpathd has lowered the failure detection time correspondingly. IP interface failure detected on interface_name Description: in.mpathd has detected a failure on interface_name, and has set the IFF_FAILED flag on interface_name, ensuring that it will not be used for IP data traffic. IP interface repair detected on interface_name Description: in.mpathd has detected a repair on interface_name, and has cleared the IFF_FAILED flag. Depending on the administrative configuration, the interface_name may again be used for IP data traffic. The link has gone down on interface_name Description: in.mpathd has detected that the IFF_RUNNING flag for interface_name has been cleared, indicating that the link has gone down. The link has come up on interface_name Description: in.mpathd has detected that the IFF_RUNNING flag for interface_name has been set, indicating that the link has come up. SunOS 5.11 20 Jan 2009 in.mpathd(1M)

Featured Tech Videos