Remove interface from list of standby interfaces

[Richard I Curtis]

I have a cluster, which was not build by myself, so I dont know the history, but in short, I need to tell serviceguard not to use lan3 as the failover interface..

What is the correct procedue to reconfigure it so lan3 is not in the list of potential failover interfaces? I need to use lan3 elsewhere, and even if I didnt, this setup will never work as lan3 is not in the same vlan or anything as lan1 so there is no link layer connectivity

An extract from cmviewcl:
NODE_NAME node_1
NETWORK_INTERFACE lan1
HEARTBEAT_IP 10.0.0.1
NETWORK_INTERFACE lan0
HEARTBEAT_IP 192.168.2.1
NETWORK_INTERFACE lan3
FIRST_CLUSTER_LOCK_PV /dev/dsk/c5t4d0
# List of serial device file names
# For example:
# SERIAL_DEVICE_FILE /dev/tty0p0

# Primary Network Interfaces on Bridged Net 2: lan1.
# Possible standby Network Interfaces on Bridged Net 2: lan3.
# Primary Network Interfaces on Bridged Net 1: lan0.
# Wa ã are no standby network interfaces on bridged net 1.

[Ivan Krastev]

What is your SG version - older from 11.18 doesnt support changing the network interfaces without cluster downtime.

regards,
ivan

[melvyn burnard]

you will have to halt the cluster, use cmquerycl to verify that lan3 does not show up as a apossible Stndby, then use cmapplyconf to apply the chaneg to the binary

Before doing that, you may just want to check what is actually in the binary, use cmviewconf and look to see if lan 3 does indeed show up on the same bridged net as a working lan

[Richard I Curtis]

Apologies for the stupid questions - I've not had any serviceguard training yet...

If I do a cmquerycl on the running cluster I get:

host_a # lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/1/2/0 0x0014C2102249 0 UP lan0 snap0 1 ETHER Yes 119
0/2/1/0 0x0012799EDA02 1 UP lan1 snap1 2 ETHER Yes 119
0/2/1/1 0x0012799EDA03 2 UP lan2 snap2 3 ETHER Yes 119
0/6/1/0 0x0012799ED912 3 UP lan3 snap3 4 ETHER Yes 119
host_a # cmquerycl -c clus01 -l net

Node Names: host_a
host_b

Bridged networks (local node information only - full probing was not performed):

2 lan1 (host_a)
lan3 (host_a)
lan1 (host_b)
lan3 (host_b)
1 lan0 (host_a)
lan0 (host_b)

IP subnets:

IPv4:

10.x.x.x lan1 (host_a)
lan1 (host_b)

192.168.2.0 lan0 (host_a)
lan0 (host_b)


host_a # linkloop -i 1 0x0012799ED912
Link connectivity to LAN station: 0x0012799ED912

frames sent : 1
frames received correctly : 0

It is still showing lan3 as being a failover interface but link layer connectivity fails... where am I going wrong ?

[Duncan Edmonstone]

Richard,

You do realise that without lan3 you'll have no failover network in your cluster yes? That means you have single points of failure...

linkloop isn't absolutely reliable - it doesn't do quite what Serviceguard does at the link level. I'd repeat your cmquerycl with full network probing:

cmquerycl -w full -c clus01 -l net

HTH

Duncan

[Richard I Curtis]

I have done the query again with full scanning, and get the same results..lan3 still shows as being in the same bridged network if I do a cviewconf and still shows up in the cmquerycl when I do a full scan

I realise that without a failover interface I have a single point of failure, but at this time, I dont have enough available interfaces to have a spare configured... I need to use lan3 for something else so that is a risk I will have to take until I can add more cards..

[melvyn burnard]

well it sems that the cluster still thinks lan3 is physically connected.
I think this could be because you are interrogating teh existing binary file


I would rather try using:
cmquerycl -v -C testascii -n node1 -n node2

And then see what the resultant ascii file shows in it's comments below each host info section.

If it still shows lan3 as a possible standby interface, then there is a physical connection somewhere. The simple answer here would then be to physically pull the cables out of both lan3 ports on the servers, then re-apply the cluster binary, and verify with cmviewconf etc.
Then plug the cables back in

[Richard I Curtis]

I think I am getting somewhere now.. after running:
cmquerycl -v -C testascii -n node1 -n node2

as advised, the resultant testascii file does not contain any mention of lan3 which is what I am hoping to achieve... it does however contain a load of other entries relating to some vlans that I dont want the cluster to be worrying about... am I right in thinking that all I need to do is run the above command, remove the lines relating to the vlans (ie, the NETWORK_INTERFACE lan5005, and the associated STATIONARY_IP entries), then run cmcheckconf followed by cmapplyconf ?

If that is the correct process, as I am making changes to the lan settup within the cluster, do I have to do this when the cluster is down ?

Thanks in advance!

[Duncan Edmonstone]

Thanks for correcting me there Melvyn - I always seem to forget that cmquerycl uses the existing ascii file unless you're creating a new one...

Duncan

[melvyn burnard · Accepted solution]

You should be able to remove those entries for vlans you do not wish to have in, and then check and apply the configuration.
You will have to do this with the cluster halted, unless you are running version 11.18 of SG, in which case you may be able to make these changes on line (cannot remember all of the stuff we changed in 11.18)

[Richard I Curtis]

Thanks both. I wont be making this change for a week or so, but from your help, I am confident I know what to do :)

Just need to get some proper SG training now !