Disabling failback on NIC Bonding

[Mick Ryan]

Hi All

I'm running SLES10.0 and have NIC bonding configured using eth0 and eth1 which is all working fine. However, my question relates to NIC failover.

I have eth0 defined as the primary and when eth0 gets disconnected, the service fails over to eth1. When service is restored, it fails back to eth0.

What I'd like, is for the service to stay on eth1 (or whatever the slave is), until I decide to fail it back.

Is this possible? I've been thinking about options like creating a script to look out for a failover message and updating the /sys/class/net/bond0/bonding/primary file, but it'd be a lot nicer and simpler if there was some kind of variable I could set (or not set).

Cheers

Mick

[Ivan Ferreira]

Try without specifying the "primary" option.

[Matti_Kurkela]

...and the "primary" option Ivan refers to should be wherever the "bonding" kernel module gets its options.

I don't have a SLES10 machine at hand at the moment, so I cannot check how its startup scripts handle the bonded NICs. But I'd start by checking the /etc/modprobe.conf file and/or /etc/modprobe.d directory.

MK

[Mick Ryan]

Thanks, guys. I thought about the primary option, but I wonder how the system decides which is the "correct" interface. In my bond setup, I reference the slaves as eth0/1 which are in turn defined in udev as their respective pci devices, so I'd imagine this would work for me.

Cheers

Mick

[Mick Ryan]

My solution to the problem of confirming the interface after network startup, was to add a POST_UP_SCRIPT to the ifcfg-bond0 file. In the script, I use this command to force the bond onto eth0
ifenslave -c bond0 eth0

Cheers

Mick

[rick jones]

Out of mostly idle curiousity, why do you want to disable the failback?

[Mick Ryan]

We had a problem with a Foundry switch that took a port down then brought it back up (as far as the O/S was concerned). However, the port wasn't fully enabled and the upshot was it took the server off the air even though the server still had a valid network port available.

This solution would allow us to control which port is live while still maintaining resilience.

[rick jones]

Ah, so it is to be a workaround/kludge (depending on the point of view :) to some bad switch behaviour. Thanks for satisfying my curiousity.

I trust that Foundry is/was able to address the problem in the switch?

[Mick Ryan]

Yes they were and everything is fine. However, the feeling is that this control would be preferable to automated failovers.

Cheers

Mick