Safe to disable autoneg for failover NIC online?

[Ralph Grothe]

Hi,

while revising the mode settings of cluster node NICs and their corrosponding link partners (i.e. switch ports), I discovered that on one box I forgot to fill array elements for the failover NIC of HP_BTLAN_* arrays in the /etc/rc.config.d/hpbtlanconf file.
Thus the failover NIC got initialized with standard autoneg enabled, which shouldn't be the case, at last reboot.
Since it is only the failover NIC while the primary NIC on this node is set up correctly, I thought I could fix it in a wink by issueing

# /usr/sbin/lanadmin -X 100FD 7

N.B. primary is lan2 and failover is lan7

[root@jupiter:/etc/cmcluster]
# cmviewconf|grep -e Node\ name: -e \ ppa:
Node name: jupiter
ppa: 2
ppa: 7
Node name: neptun
ppa: 0
ppa: 7
Node name: saturn
ppa: 2
ppa: 7

[root@jupiter:/etc/cmcluster]
# lanadmin -x 2
Current Speed = 100 Full-Duplex Auto-Negotiation-OFF

[root@jupiter:/etc/cmcluster]
# lanadmin -x 7
Current Speed = 100 Full-Duplex Auto-Negotiation-ON

[root@jupiter:/etc/cmcluster]
# netstat -in|grep lan7
lan7* 1500 none none 34 12844


But I hesitate to issue the command (I already fixed the setting in the hpbtlanconf file for next reboot), because I can under no circumstance afford the risk of the node or any packages falling down if one must not do this with a running node.

Is it safe to fix it right now, or should I wait until I can cmhaltnode?

Rgds.
Ralph

[Mark Grant]

I have done this a few times with no problem at all.

However, if "under no circumstances can you afford the risk" then in my view it isn't worth doing it now.

To sum up. It's no problem but don't do it :)

[Pete Randall]

Ralph,

In your situation, I'd have to agree with Mark: it's safe to do it but I'd wait anyway, "just in case"! Do you have anything to gain by doing it now? Anything to lose?

Wait.


Pete

[Ralph Grothe]

Mark, Pete,

you both are right.
At the moment there would be no gain since the NIC isn't in use now anyway.
So it's safer to wait for the fix.
I only had the very unpleasent situation that owe to a mode mismatch between failover NIC and switch, and above all a duplicate IP in disguise, the failover of lan2 to lan7 didn't work when it was expected to.
I couldn't even send frames on link layer between NICs, so that the linkloop command that now is returning with OK failed

[root@jupiter:/etc/cmcluster]
# linkloop -i 2 $(lanadmin -a 7|cut -d= -f2)|tail -1
-- OK

while the NIC's LED of port 7 pretended it got a link.
I had trouble explaining the users why the failover mechanism didn't work.
So I still have some concerns if it will work now, although several tests with pulling cables showed that the failover NIC took over the IPs without the node TOCing to leave the cluster.

[Sridhar Bhaskarla]

Hi Ralph,

It is safe to reset the standby lancard. If it is not working now, then there is a risk than not doing it.

I had my network people work on the standby switch where it didn't affect a thing.

How about the status of the lancard w.r.t serviceguard? 'cmviewcl -v -l node'. Does it show the standby lan as up or down?. The answer is dependent on it as down state can cause your packages to failover if there is a failure on your primary interface.

-Sri