"bdachecknet" Does Not Properly Test Failover to the Backup Slave - Instead Raises "1Ping gtw error on host"
(Doc ID 2373880.1)
Last updated on MARCH 23, 2018
Applies to:
Big Data Appliance Integrated Software - Version 4.10.0 to 4.11 [Release 4.10]Linux x86-64
Symptoms
On BDA versions BDA V4.11 and lower, bdachecknet may fail as below even though the cluster and Infiniband are all in a healthy state and bonding failover is working.
host if status actv primary switch gw port ping gw vlan
============================= === ====== ==== ======= ====================== ========= ======= ======
bdanode01 eth8 up no no bdasw-ib3 0A-ETH-1 yes N/A
bdanode01 eth9 up yes yes bdasw-ib2 0A-ETH-1 yes N/A
1Ping gtw error on host bdanode01, interface eth8, switch bdasw-ib3, port 0A-ETH-1
bdachecknet: network checks failed
============================= === ====== ==== ======= ====================== ========= ======= ======
bdanode01 eth8 up no no bdasw-ib3 0A-ETH-1 yes N/A
bdanode01 eth9 up yes yes bdasw-ib2 0A-ETH-1 yes N/A
1Ping gtw error on host bdanode01, interface eth8, switch bdasw-ib3, port 0A-ETH-1
bdachecknet: network checks failed
To test if bonding failover is actually working, follow below steps below. Perform the steps as 'root' user on the BDA server where bdachecknet is reporting "network checks failed". The example below uses bdanode01. And in the example below eth9 is the primary/active slave for bondeth0:
1. Get the output of "bdaibstatus -s" and find the primary/active slave for bondeth0. In the below example eth9 is the primary/active slave for bondeth0.