MC/Service Guard Upgrade Issues (Lan Cards)

[Justin Willoughby]

I am upgrading MC/Service Guard and the convert command is giving me issues, I am upgrading to 11.14. convert says one of the NICs does not exists but it does and I can configure it manually. Anyone seen this error before and what to do about it? I have placed a call to HP but I figured I would see if any of you had any idea what might be going on! Thanks,

# convert -f /etc/cmcluster/cmclconfig
NOTE: Executing the conversion tool.
NOTE: MC/ServiceGuard binary config file is an older version,
. needs to update to the latest version of SG 11.08.
* Configuration file $SGCONF/cmclconfig from caiback has old 10.10
configuration information. The configuration file must be
converted before it can be used on the local node.
* Configuration file /etc/cmcluster/cmclconfig from caiback has
old 10.10 configuration information. The configuration file must
be converted before it can be used on the local node.
ERROR: Network interface at '10/4/4.1' was a standby lan. It either
no longer exists on the current system, or is not physically
connected to a primary lan.
ERROR: Unable to convert lan interface data.

[Martin Johnson]

Does "lanscan" show the card as UP and Supported?

What does "ioscan -fnC lan" show? Should be CLAIMED.


HTH
Marty

[Justin Willoughby]

Yes it is ok, I an manaully configure it with ifconfig.

Here is the lanscan output:

Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
10/4/4.1 0x080009D4598A 3 UP lan3 snap3 1 ETHER Yes 119
10/4/8.1 0x080009B104C3 0 UP lan0 snap0 2 ETHER Yes 119
10/4/16 0x080009D9D0B2 2 UP lan2 snap2 3 ETHER Yes 119
10/12/6 0x080009E33A27 1 UP lan1 snap1 4 ETHER Yes 119

- Justin

[Justin Willoughby]

I am still working though this issue.

The guy from HP thinks this happens because I am doing a cold install instead a in-place. He thinks the issue is that the NM ID of the NICs changed. Any one ever change the NM ID of NICs in HP/UX? The guy from HP is going to try and see if it's possible.

- Justin

[Justin Willoughby]

It seems my problem was that the primary and fail-over network cards could not talk to themselves via the network. I could configure both with an IP address and connect to either from my workstation but they could not talk to each other. The guy from HP said they should be able to. He said at one point they likely could. This was verified by the linkloop command.

To get past this I simply used a cross-over network cable to connected the primary and fail-over network cards (lan3 and lan2) and then the MC/SG binary was upgraded without a problem with the convert command (the linkloop command also worked fine). After I upgraded the binary I reconnected Lan3 and Lan2 as they were before.

Very strange problem.

[Justin Willoughby]

I was testing the lan card fail-over and I was able to get the backup lan card to fail-over when I unplugged the main lan card, however it did not work trying to go back to the main network card. What I did was unplug the main lan cable and it failed-over to the backup, then I plugged in the main lan cable and unplugged the backup. Is it suppose to work this way?

Thanks,

- Justin

[Christopher McCray_1]

Hello

When testing LAN failover capability to the backup LAN, if you unplug the primary data cable, the backup LAN should immediately (<= 2sec.) . MCSG knows that this is only a backup LAN and for the LAN config to failback, you should only have to plug the cable back in to the primary LAN card and that interface should be reconfigured.

I guess the major question is, do you still have a problem? If so, what are your rmaining issues?

Could you please post your cluster.ascii file for us to look at?

Standing by

Chris

[Justin Willoughby]

So far, my only real issue is the fail-over. I did not setup this system so I am just trying to figure out the way it was setup. Now that I have upgraded the O.S. and MC/SG I wanted to test that it works the way it is suppose to.

Here is part of my ascii file (if more is needed let me know):

NODE_NAME caiback
NETWORK_INTERFACE lan3
NETWORK_INTERFACE lan0
NETWORK_INTERFACE lan2
HEARTBEAT_IP 192.168.224.55
NETWORK_INTERFACE lan1
HEARTBEAT_IP 192.168.1.9

When I upgraded the MC/SG config binary it noticed lan0 was not being used and removed it. So the output from cmviewcl -v from the upgraded node shows the following:

NODE STATUS STATE
caiback up running

Network_Parameters:
INTERFACE STATUS PATH NAME
PRIMARY up 10/4/16 lan2
STANDBY up 10/4/4.1 lan3
PRIMARY up 10/12/6 lan1

I will test it again but it looks like when I plugged the main lan card back in it stayed using the backup lan card. I unplugged the backup lan card and it did not fail-back to the main card. I will wait a while longer this time after I plug in the main lan card and before I unplug the backup lan card.

- Justin

[Stephen Doud]

Hello Justin,

We rarely see problems with the "convert" command. As such, I suspect the source of the trouble may be due to a change in a network-related configuration that is not reflected in the old cluster binary file. For instance, perhaps there is a duplicate MAC address (verify w/ lanscan), or temporary communication issue with the LAN in question.
The messages from the convert command indicate that it thinks the LAN at '10/4/4.1' no longer exists or is not connected. It may be getting it's information from a inaccurate cmclconfig file.

-s.

[Justin Willoughby]

Stephen,

The first part of my problem has been fixed. I had to use a cross-over cable between lan3 and lan2 for the convert to work. linkloop failed otherwise.

Now I am trying to verify the lan card fail-over. I can fail-over to the backup lan card but not from the backup lan card to the primary lan card.

- Justin

[Christopher McCray_1]

The failover/failback should be almost instantaneous, this is linked to the

NETWORK_POLLING_INTERVAL 2000000

parameter in your cluster.ascii file. as you can see here, it is set to 2 seconds, where it is checking for lost connections, etc. By unplugging lan2, in 2 seconds or less, the cluster should detect that lan2 has lost connectivity for some reason and will deconfigure it and configure lan3. By plugging in lan2 again (do not unplug lan3 -- not necessary), the cluster will detect that the node's primary lan is bac online and will(should) move back, again, in the same timeframe.

Have you ran the cmscancl command yet and looked at the lan config portion?

Hope this helps

Chris