Lan Failback from Standby not working

[Maggie Wilson_1]

Can anyone help? A student on my course has told me of a situation whereby having switched a failed lan over to the standby, it will not switch back to Primary once the lan cable is reinserted.

I cant determine any more information from him at this point - sorry.

In fact it might be useful to be able to prevent this failback until further tests are carried out on the Primary.

Regards
Maggie Wilson

[Juergen Tappe]

The easiest reason that the package is not configured to fail back automaticly (the default value I beliefe).

Ther should be an option in the package config file like "AUTO_FAIL_BACK=..." or something similar.

(Have no access to a cluster system right now while Im sitting out of office currently)

[Maggie Wilson_1]

Thanks for the reply but this doesnt answer the question. The package is certainly configured to failover to the standby (which it has done). The problem is simply that once the Primary is back on line, it doesnt failback to that card.

Regards
Maggie

[Juergen Tappe]

Might be I still misunderstand, but as far as I remember Fail-Over and Fail-Back are configured seperatly.
So : Is it configured to Fail-Back as well?

[Maggie Wilson_1]

Hi

Failover and failback relate to packages failing over to alternate nodes or failing back to primary nodes - nothing to do with lan failover/failback.

Regards
Maggie

[A. Clay Stephenson]

This is normal. When the node is restarted, it will attempt to first use the primary LAN; the good news is that MC/SG does recogize that the primary lan has been restored to health and it, in effect, becomes an available "STANDBY" interface so that if the currently active standby interface fails the primary can be used.

Not switching back automatically to the primary is really a good thing as it avoids the loss of packets during the switchover and thus minimizes the impact upon the clients.

I assume that you are not using APA.

[melvyn burnard]

Not to be rude, but I think you are all missing the point here.
The issue is a cluster is running, with packages, and there is a primary lan with it's configured standby lan.
When the primary lan fails (cable is pulled) it does a local lan failover to the standby, as expected.
What is then supposed to happen is that when the cable is reinserted( lan recovers) it is NOT recovering, and the switch back to the primary lan of the IP addresses is not occurring.

What is mising here is:
Version of OS, version of SG, patching levels, information in the syslogs, what type of lan is the primary and standby, when the primary is reinsertd, can a linkloop be performed from that NIC to other NIC's in the bridged net, etc.

I suspect this student may already have a call open with eth UK Response Centre

[Maggie Wilson_1]

there is no APA in use.

Just to clarify; the package has not failed over to any alternate nodes, but simply that the lan failover is tested by pulling the primary lan - it behaves corrrectly in that the standby is now configured. When the primary lan is re-connected, SG should fail the lan back again to the primary which is not happening. Of course this may be deemed desireable in some circumstances but I do not believe that this is the default behaviour and certainly any time I perform the same test, the standby ALWAYS fails back to the primary. I simply wondered if there was a configurable parameter somewhere which prevents the failing back to the primary from the standby which would account for this 'strange' behaviour.

[Maggie Wilson_1]

Hi Melvyn, You said what I wanted to say! I'll check with the guy if there is an outstanding call and if there isnt I think I will suggest he opens one. I really just wanted to check if I had missed some parameter somewhere before I asked him to open the call. Sounds like I havent missed anything.

Hope you are well.

Regards
Maggie

[Stephen Doud · Accepted solution]

Just a brief perusal of our database yielded this:
11.00 Cumulative ARPA transport patch:
PHNE_29473 (originally fixed in PHNE_17662)
For 100BT btlan6 interfaces, disconnecting and reconnecting the lan card results in the card state being marked UP. This causes ServiceGuard lan switchback to fail with EBUSY.

-sd-

[Maggie Wilson_1]

Hi Stephen,

Thanks very much for your reply - looks like that patch may solve their problems. The student has now left the course (I told him to put in a call for his problem as per Melvyn's response), so I guess he might already know of the existence of this patch.

Many thanks
Maggie