OpenSolaris

Printable Version Enter a New Search
Bug ID 4785694
Synopsis non-homogeneous IPMP group does not do failback
State 10-Fix Delivered (Fix available in build)
Category:Subcategory network:ipmp
Keywords clearview
Responsible Engineer Peter Memishian
Reported Against 9.0
Duplicate Of
Introduced In solaris_9
Commit to Fix snv_107
Fixed In snv_107
Release Fixed solaris_nevada(snv_107)
Related Bugs 6783149
Submit Date 27-November-2002
Last Update Date 28-January-2009
Description
I had the following IPMP configuration:
qfe1 had v4 instance plumbed with test and failover IP addresses.
qfe2 had v4 and v6 instance plumbed with test and failover IP addresses.
Both were in the same IPMP group.

Now, if I remove the switch connection for qfe1 the failover IP address on qfe1 fails over to qfe2 as expected. But when I replace the qfe1 connection to the switch - I don't see the IP address failback to qfe1. Failback was enabled on the system.

I know that non-homogenous IPMP groups are not supported but if the address fail's over on qfe1 failure, it should fail back on qfe1 repair.
Work Around
N/A
Comments
 xxxxx@xxxxx.com 2003-07-21

I've modified ip_sioctl_move() in usr/src/uts/inet/ip/ip_if.c, to check whether there will be anything to move for each protocol (i.e. IPv4 or IPv6) plumbed on the source interface.  This allows the move to work in situations where the source has more protocols plumbed than the destination: provided the source doesn't have anything to move for the protocol not plumbed on the destination, the move operation for the other protocol is allowed to go ahead.

With the change to ip_sioctl_move, failbacks can be attempted in non-homogenous groups.

 xxxxx@xxxxx.com 2003-08-26

I stopped working on this until Fireengine had been delivered into the gate.  I started making the changes again, but it all looked very messy.  The daemon does failback by failing back from every other interface in the group.  It isn't clear to me what the best thing would be to do if an error occured part way through this process.

I think the current behaviour maybe the best approach; if the administrator wants failback to occur, they need to make their configuration consistient across all interfaces in the group.  I'm not sure large changes are appropriate for what appears to be a minor problem.