Operating System - HP-UX
1820879 Members
3904 Online
109628 Solutions
New Discussion юеВ

service guard standby interface

 
avik
Valued Contributor

service guard standby interface

I have a two node cluster with 2 SX-1000 interface and a 1GB utb interace. utb interface is used as the heardbeat NIC and one of the SX-1000 NIC is used for the public network. The second SX-1000 interface was left to be configured by the MCSG for the standby.

the standby interface information is not listed in the configuration file generated by the service guard. the interface in both the machines are connected and in the same subnet. I am able to ping to these interface when I configure them. any idea whts the problem ?
6 REPLIES 6
Uday_S_Ankolekar
Honored Contributor

Re: service guard standby interface

Please send the output of lanscan and netstat -in command

Also run cmscancl for a detailed analysis

Goodluck,

-USA..
Good Luck..
Matti_Kurkela
Honored Contributor

Re: service guard standby interface

In my experience, to use an interface as a standby interface for ServiceGuard, it must be *plumbed but otherwise unconfigured*.

If "ifconfig " says "No such interface, the interface is not plumbed. You can plumb it manually with "ifconfig plumb".

ServiceGuard uses the "linkloop" command (or a similar internal function) to detect the possible standby interfaces. An interface will respond to "linkloop" even if it does not have an IP address, because linkloop works with MAC addresses.

To get the system start-up scripts to put the interface to the plumbed-but-unconfigured state automatically, add something like this to /etc/rc.config.d/netconf:

INTERFACE_NAME[0]=├в lan0├в
DHCP_ENABLE[0]=├в 0├в

These two lines (instead of six as normal) are enough to make the startup scripts plumb the interface. Since there is no IP address specified and DHCP is disabled, the interface is left in plumbed-but-unconfigured state, suitable for ServiceGuard.
MK
John Bigg
Esteemed Contributor

Re: service guard standby interface

Stanby lans should *not* be plumbed so please ensure they are not plumbed. Serviceguard plumbs interfaces which are configured when it is started. Plumbing them will guarenteee Serviceguard cannot use them.

Serviceguard does use link level polling to determine connectivity. It does not use linkloop which uses special test packets but uses real link level traffic to test for real connectivity. It is possible that if you have a firewall that linkloop can show connectivity when this has been disabled for the Serviceguard packets although this is very unlikely.

I would suggest use of linkloop to verify that the unconfigured lan card you want to use as a standby does have link level connectivity to the primary card. If this does not help you determine the problem then I suspect your best course of action is to contact HP support since the next step would be to turn up logging and have this interpreted to determine why the standby lan card does not show up.

Have you tried simply adding the standby lan card into you cluster ascii file manually and running cmcheckconf to see if this generates any errors? This may also help determine the cause of the problem.
Thomas J. Harrold
Trusted Contributor

Re: service guard standby interface

I've noticed (confirmed with HP) that it IS possible to have a standby LAN act as standby for TWO networks. (say private, and public).

It can, of course, only be standby for one network at a time. I found this when someone inadvertently configured both heartbeat and production networks on the same physical switches, without using VLANs.

To answer your questions, I agree with the previous post: use linkloop to test connectivity. If that works, manually enter the information into your cluster ascii file, and run a cmcheckconf.


-tjh
I learn something new everyday. (usually because I break something new everyday)
Matti_Kurkela
Honored Contributor

Re: service guard standby interface

Sorry, my mistake - and John, you're right.

We do manual "linkloop" testing before starting up the cluster configuration, to check the network for any problems. Going back to my notes, it seems that manual plumbing is necessary for this testing phase only.

Hmm, seems I haven't been configuring any new ServiceGuard installations lately. I must be getting a little rusty :-)
MK
Stephen Doud
Honored Contributor

Re: service guard standby interface

I had a running 11.16 cluster.
The cluster.ascii file showed this:

NODE_NAME bunker
NETWORK_INTERFACE lan2
HEARTBEAT_IP 16.113.145.24
NETWORK_INTERFACE lan0
FIRST_CLUSTER_LOCK_PV /dev/dsk/c0t2d0
# List of serial device file names
# For example:
# SERIAL_DEVICE_FILE /dev/tty0p0

# Primary Network Interfaces on Bridged Net 1: lan2.
# Possible standby Network Interfaces on Bridged Net 1: lan0.


I halted the cluster and then did this on node bunker:
# cmdeleteconf -f
Checking current status
Completed the cluster deletion.
# ifconfig lan0 unplumb
unplumb operation for lan0 was unsuccessful

I performed a cmquerycl to create a newcluster.ascii file - and lan0 was still listed as a standby LAN.

I then plumbed the potential standby LAN:
# ifconfig lan0 plumb
and re-did the cmquerycl and lan0 still appeared in the resulting output file.

I suggest using lanscan to get the info required for the linkloop command:

# linkloop -i
This command validates basic inter-NIC link-level traffic capability, necessary for Serviceguard to consider DLPI traffic and validate the linkage by listing a NIC as a standby LAN.

Example:
# lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
8/4/2/0 0x0060B0A60528 1 UP lan1 snap1 1 ETHER Yes 119
10/12/6 0x0060B08362C7 2 UP lan2 snap2 2 ETHER Yes 119
8/4/1/0 0x0060B0A60527 0 UP lan0 snap0 3 ETHER Yes 119
bunker# linkloop -i 0 0x0060B08362C7
Link connectivity to LAN station: 0x0060B08362C7
-- OK