SUBNET 10.x.x.x not part of the cluster, line 270

[boomer_2]

Hi guys,
i have created an new package and when i ran cmapplyconf to apply the package conf then i got the follwng error :
Begin package verification...
SUBNET 10.1.4.0 not part of the cluster, line 270
Specify a SUBNET that is part of the cluster.

cmapplyconf: Error found in package file: /etc/cmcluster/gbcg_test/gbcg_test.conf.


while i have checked that my subnet is right for all the current remaining packages they r same as of given to this package...what should be done now ?

Thanx in advance

[Ivan Krastev · Accepted solution]

See this doc from kb - http://www5.itrc.hp.com/service/cki/search.do?category=c0&prevQueryString=%22not+part+of+the+cluster%22&searchLevel=newsearch&mode=id&searchString=KBRC00016030&searchCrit=allwords&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&dateRange=all&search.x=20&search.y=11

Document ID: KBRC00016030

regards,
ivan

[boomer_2]

Hi Ivan,
i couldn't find the doc at the given link//plzz suggest what is to be done...

[Dennis Handly]

>I couldn't find the doc at the given link//plzz suggest what is to be done

I couldn't either, it went to Europe. I assume you must search the Technical Knowledge Base for KBRC00016030.
(You will have to have a support contract.)

[boomer_2]

So Denis,
then what is to be done for this error kindly suggest a soln for my problem...

[Dennis Handly]

>then what is to be done for this error kindly suggest a soln for my problem.

I said I can't see that document from the ITRC. Did you try searching for it? Do you have a support contract?

Some of the info in the document says:
The cause of the cmcheckconf failure is two fold:
1- A LAN's IP/Subnet has been changed but not found in the current cluster
binary file.
2- The cmcheckconf will fail if a IP/Subnet is different AND if the cluster is
running.

[melvyn burnard]

verify the subnet mask and network address of the subnet you wish to add the package to, for example use netstat -in to verify teh subnet.
If there is a difference, you need to correct this
Also verify in your cluster tyhe subnets in use, do a cmviewconf and check the subnets in use in teh cluster binary

[boomer_2]

Hi guys,
Actually we had shifted the cluster setup from 10.1.1.0 n/w to 10.1.4.0 accordingly i had made changes in cluster conf and control file,but still it takes as 10.1.1.0..b'coz after giving 10.1.1.0 instaead of current 10.1.4.0 my package successfully ran...

now it is successfully running on 10.1.1.0 ...how should i change it to 10.1.4.0 subnet....???

thanx...

[melvyn burnard]

you have to reapply your cluster using cmapplyconf with the CORRECT values for your subnets etc.
see another thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1108247

[boomer_2]

hi Melvyn,
actually my cluster is running fine ..but when i try to ping the package ip 10.1.4.207 when the package is up i m not able to ping it..and also thro' sam i saw that for the original package i have lan0:1 and the package ip..but its not present for the second test package that i have added in it....so now what should i do ???

[melvyn burnard]

well I would suggest you now revisit ALL of your networking configuration, an dthen verify what is in teh cluster binary using cmviewconf, and also look at your packages.
Make any changes required and then reapply the binary with cmapplyconf

[boomer_2]

hi melvyn,
Can i run cmscancl on the running cluster to check the current subnet..is it safe....

[Ivan Krastev]

Yes you can use cmscancl on running cluster. For setting up cmscancl and troubleshooting see this - http://docs.hp.com/en/B3936-90105/ch08s07.html

regards,
ivan

[Johnny Damtoft]

If you check that all your network interface cards are on the correct lan/vlan - use the commands:

# lanscan -v
# netstat -rn

After checking that the hardware is in place, you need to start checking your subnets.

Your network configuration:
/etc/rc.config.d/netconf needs to match your IPs and subnets. You also need to check your routes and default route.

When all of this is done, your should have enough information to setup your cluster package, with the empty/available NIC Card for your cluster IP.

Let's know how it goes.. :)

--Johnny

[boomer_2]

Hi johnny,
Here's the o/p ...

# lanscan -v
-------------------------------------------------------------------------------
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/1/2/0 0x0015600495BA 0 UP lan0 snap0 1 ETHER Yes 119

Extended Station LLC Encapsulation
Address Methods
0x0015600495BA IEEE HPEXTIEEE SNAP ETHER NOVELL

Driver Specific Information
iether
-------------------------------------------------------------------------------
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/1/2/1 0x0015600495BB 1 UP lan1 snap1 2 ETHER Yes 119

Extended Station LLC Encapsulation
Address Methods
0x0015600495BB IEEE HPEXTIEEE SNAP ETHER NOVELL

Driver Specific Information
iether
-------------------------------------------------------------------------------
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/5/1/0 0x001321EA58EF 2 UP lan2 snap2 3 ETHER Yes 119

Extended Station LLC Encapsulation
Address Methods
0x001321EA58EF IEEE HPEXTIEEE SNAP ETHER NOVELL

Driver Specific Information
igelan
-------------------------------------------------------------------------------
# netstat -rn
IPv4 Routing tables:
Destination Gateway Flags Refs Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 lo0 4136
10.1.4.23 10.1.4.23 UH 0 lan0:1 4136
10.1.4.22 10.1.4.22 UH 0 lan0:2 4136
10.1.4.18 10.1.4.18 UH 0 lan0 4136
192.168.0.61 192.168.0.61 UH 0 lan2 4136
192.168.0.0 192.168.0.61 U 2 lan2 1500
10.1.4.0 10.1.4.18 U 4 lan0 1500
10.1.4.0 10.1.4.22 U 4 lan0:2 1500
10.1.4.0 10.1.4.23 U 4 lan0:1 1500
127.0.0.0 127.0.0.1 U 0 lo0 0
default 10.1.4.1 UG 0 lan0 0

IPv6 Routing tables:
Destination/Prefix Gateway Flags Refs Interface Pmtu
::1/128 ::1 UH 0 lo0 4136

/etc/rc.config.d/netconf file attached herewith...

[Johnny Damtoft]

So, it is correct that you want to use lan1 as the NIC for the cluster package?

If so, you need the NIC to be "online" and have it ready for the cluster config to use.

Check with
# ifconfig lan1

If the output is:
ifconfig: no such interface

Then you need to plumb the NIC.
# ifconfig lan1 plumb
lan1: flags=1843

Which NIC are you using for heartbeat?

--Johnny

[Johnny Damtoft]

Normally you don't need to execute the ifconfig lan1 plumb.

When MCSG setup the package including cluster IP for a specific NIC, the server does the plumb stuff it self.

Can you send me the cntl and conf files for MCSG?


--Johnny

[boomer_2]

hi johnny,
# ifconfig lan1
lan1: flags=842
inet 0.0.0.0 netmask 0
lan1: flags=4800840
inet6 :: prefix 0
============================================
Control and conf attached herewith....

Conf file pasted here::
# **********************************************************************
# ****** HIGH AVAILABILITY PACKAGE CONFIGURATION FILE (template) *******
# **********************************************************************
# ******* Note: This file MUST be edited before it can be used. ********
# * For complete details about package parameters and how to set them, *
# * consult the Serviceguard Extension for RAC manuals.
# **********************************************************************

# Enter a name for this package. This name will be used to identify the
# package when viewing or manipulating it. It must be different from
# the other configured package names.

PACKAGE_NAME gbcg_test

# Enter the package type for this package. PACKAGE_TYPE indicates
# whether this package is to run as a FAILOVER, MULTI_NODE, or
# SYSTEM_MULTI_NODE package.
#
# FAILOVER package runs on one node at a time and if a failure
# occurs it can switch to an alternate node.
#
# MULTI_NODE package runs on multiple nodes at the same time and
# can be independently started and halted on
# individual nodes. Failures of package components such
# as services, EMS resources or subnets, will cause
# the package to be halted only on the node on which the
# failure occurred. Relocatable IP addresses cannot be
# assigned to MULTI_NODE packages.
#
# SYSTEM_MULTI_NODE
# package runs on all cluster nodes at the same time.
# It can not be started and halted on individual nodes.
# Both NODE_FAIL_FAST_ENABLED and AUTO_RUN must be set
# to YES for this type of package. All SERVICES must
# have SERVICE_FAIL_FAST_ENABLED set to YES.
#
# NOTE: Packages which have a PACKAGE_TYPE of MULTI_NODE and
# SYSTEM_MULTI_NODE are not failover packages and are only
# supported for use by applications provided by Hewlett-Packard.
#
# Since MULTI_NODE and SYSTEM_MULTI_NODE packages can run on more
# than one node at a time and do not failover in the event of a
# package failure, the following parameters cannot be
# specified when configuring packages of these types:
#
# FAILOVER_POLICY
# FAILBACK_POLICY
#
# Since an IP address can not be assigned to more than node at a
# time, relocatable IP addresses can not be assigned in the
# package control script for MULTI_NODE packages. If volume
# groups are used in a MULTI_NODE package, they must be
# activated in a shared mode and data integrity is left to the
# application. Shared access requires a shared volume manager.
#
# Examples : PACKAGE_TYPE FAILOVER (default)
# PACKAGE_TYPE MULTI_NODE
# PACKAGE_TYPE SYSTEM_MULTI_NODE
#
#

PACKAGE_TYPE FAILOVER


# Enter the failover policy for this package. This policy will be used
# to select an adoptive node whenever the package needs to be started.
# The default policy unless otherwise specified is CONFIGURED_NODE.
# This policy will select nodes in priority order from the list of
# NODE_NAME entries specified below.
#
# The alternative policy is MIN_PACKAGE_NODE. This policy will select
# the node, from the list of NODE_NAME entries below, which is
# running the least number of packages at the time this package needs
# to start.

FAILOVER_POLICY CONFIGURED_NODE


# Enter the failback policy for this package. This policy will be used
# to determine what action to take when a package is not running on
# its primary node and its primary node is capable of running the
# package. The default policy unless otherwise specified is MANUAL.
# The MANUAL policy means no attempt will be made to move the package
# back to its primary node when it is running on an adoptive node.
#
# The alternative policy is AUTOMATIC. This policy will attempt to
# move the package back to its primary node whenever the primary node
# is capable of running the package.

FAILBACK_POLICY MANUAL


# Enter the names of the nodes configured for this package. Repeat
# this line as necessary for additional adoptive nodes.
#
# NOTE: The order is relevant.
# Put the second Adoptive Node after the first one.
#
# Example : NODE_NAME original_node
# NODE_NAME adoptive_node
#
# If all nodes in the cluster are to be specified and order is not
# important, "NODE_NAME *" may be specified.
#
# Example : NODE_NAME *

NODE_NAME cedge2



# Enter the value for AUTO_RUN. Possible values are YES and NO.
# The default for AUTO_RUN is YES. When the cluster is started the
# package will be automatically started. In the event of a failure the
# package will be started on an adoptive node. Adjust as necessary.
#
# AUTO_RUN replaces obsolete PKG_SWITCHING_ENABLED.

AUTO_RUN YES


# Enter the value for LOCAL_LAN_FAILOVER_ALLOWED.
# Possible values are YES and NO.
# The default for LOCAL_LAN_FAILOVER_ALLOWED is YES. In the event of a
# failure, this permits the cluster software to switch LANs locally
# (transfer to a standby LAN card). Adjust as necessary.
#
# LOCAL_LAN_FAILOVER_ALLOWED replaces obsolete NET_SWITCHING_ENABLED.

LOCAL_LAN_FAILOVER_ALLOWED YES


# Enter the value for NODE_FAIL_FAST_ENABLED.
# Possible values are YES and NO.
# The default for NODE_FAIL_FAST_ENABLED is NO. If set to YES,
# in the event of a failure, the cluster software will halt the node
# on which the package is running. All SYSTEM_MULTI_NODE packages must have
# NODE_FAIL_FAST_ENABLED set to YES. Adjust as necessary.

NODE_FAIL_FAST_ENABLED NO


# Enter the complete path for the run and halt scripts. In most cases
# the run script and halt script specified here will be the same script,
# the package control script generated by the cmmakepkg command. This
# control script handles the run(ning) and halt(ing) of the package.
#
# Enter the timeout, specified in seconds, for the run and halt scripts.
# If the script has not completed by the specified timeout value,
# it will be terminated. The default for each script timeout is
# NO_TIMEOUT. Adjust the timeouts as necessary to permit full
# execution of each script.
#
# Note: The HALT_SCRIPT_TIMEOUT should be greater than the sum of
# all SERVICE_HALT_TIMEOUT values specified for all services.
#
# The file where the output of the scripts is logged can be specified
# via the SCRIPT_LOG_FILE parameter. If not set, script output is sent
# to a file named by appending '.log' to the script path.
#
#SCRIPT_LOG_FILE

RUN_SCRIPT /etc/cmcluster/gbcg_test/gbcg_test.cntl
RUN_SCRIPT_TIMEOUT NO_TIMEOUT
HALT_SCRIPT /etc/cmcluster/gbcg_test/gbcg_test.cntl
HALT_SCRIPT_TIMEOUT NO_TIMEOUT


# Enter the names of the storage groups configured for this package.
# Repeat this line as necessary for additional storage groups.
#
# Storage groups are only used with CVM disk groups. Neither
# VxVM disk groups or LVM volume groups should be listed here.
# By specifying a CVM disk group with the STORAGE_GROUP keyword
# this package will not run until the CVM system multi node package is
# running and thus the CVM shared disk groups are ready for
# activation.
#
# NOTE: Should only be used by applications provided by
# Hewlett-Packard.
#
# Example : STORAGE_GROUP dg01
# STORAGE_GROUP dg02
# STORAGE_GROUP dg03
# STORAGE_GROUP dg04
#


# Enter the names of the dependency condition for this package.
# Dependencies are used to describe the relationship between packages
# To define a dependency, all three attributes are required.
#
# DEPENDENCY_NAME must have a unique identifier for the dependency.
#
# DEPENDENCY_CONDITION
# This is an expression describing what must be true for
# the dependency to be satisfied.
#
# The syntax is: = UP , where
# is the name of a multi-node or system multi-node package.
#
# DEPENDENCY_LOCATION
# This describes where the condition must be satisfied.
# The only possible value for this attribute is SAME_NODE
#
# NOTE:
# Dependencies can only be defined for packages within a CFS cluster. These are
# automatically setup in the SYSTEM-MULTI-NODE and MULTI-NODE packages created for
# disk groups and mount points. Customers configure dependencies for FAILOVER type
# packages only; and the dependency would be on a MULTI-NODE mount point (MP) package.
#
# Example :
# DEPENDENCY_NAME SG-CFS-MP-1
# DEPENDENCY_CONDITION SG-CFS-MP-1=UP
# DEPENDENCY_LOCATION SAME_NODE
#
#DEPENDENCY_NAME
#DEPENDENCY_CONDITION
#DEPENDENCY_LOCATION SAME_NODE
#


# Enter the SERVICE_NAME, the SERVICE_FAIL_FAST_ENABLED and the
# SERVICE_HALT_TIMEOUT values for this package. Repeat these
# three lines as necessary for additional service names. All
# service names MUST correspond to the SERVICE_NAME[] entries in
# the package control script.
#
# The value for SERVICE_FAIL_FAST_ENABLED can be either YES or
# NO. If set to YES, in the event of a service failure, the
# cluster software will halt the node on which the service is
# running. If SERVICE_FAIL_FAST_ENABLED is not specified, the
# default will be NO.
#
# SERVICE_HALT_TIMEOUT is represented as a number of seconds.
# This timeout is used to determine the length of time (in
# seconds) the cluster software will wait for the service to
# halt before a SIGKILL signal is sent to force the termination
# of the service. In the event of a service halt, the cluster
# software will first send a SIGTERM signal to terminate the
# service. If the service does not halt, after waiting for the
# specified SERVICE_HALT_TIMEOUT, the cluster software will send
# out the SIGKILL signal to the service to force its termination.
# This timeout value should be large enough to allow all cleanup
# processes associated with the service to complete. If the
# SERVICE_HALT_TIMEOUT is not specified, a zero timeout will be
# assumed, meaning the cluster software will not wait at all
# before sending the SIGKILL signal to halt the service.
#
# Example: SERVICE_NAME DB_SERVICE
# SERVICE_FAIL_FAST_ENABLED NO
# SERVICE_HALT_TIMEOUT 300
#
# To configure a service, uncomment the following lines and
# fill in the values for all of the keywords.
#
#SERVICE_NAME
#SERVICE_FAIL_FAST_ENABLED
#SERVICE_HALT_TIMEOUT


# Enter the network subnet name that is to be monitored for this package.
# Repeat this line as necessary for additional subnet names. If any of
# the subnets defined goes down, the package will be switched to another
# node that is configured for this package and has all the defined subnets
# available.
# The subnet names could be IPv4 or IPv6. The network subnet
# names that are to be monitored for this package could be a mix
# of IPv4 or IPv6 subnet names

#SUBNET
SUBNET 10.1.1.0

# The keywords RESOURCE_NAME, RESOURCE_POLLING_INTERVAL,
# RESOURCE_START, and RESOURCE_UP_VALUE are used to specify Package
# Resource Dependencies. To define a package Resource Dependency, a
# RESOURCE_NAME line with a fully qualified resource path name, and
# one or more RESOURCE_UP_VALUE lines are required. The
# RESOURCE_POLLING_INTERVAL and the RESOURCE_START are optional.
#
# The RESOURCE_POLLING_INTERVAL indicates how often, in seconds, the
# resource is to be monitored. It will be defaulted to 60 seconds if
# RESOURCE_POLLING_INTERVAL is not specified.
#
# The RESOURCE_START option can be set to either AUTOMATIC or DEFERRED.
# The default setting for RESOURCE_START is AUTOMATIC. If AUTOMATIC
# is specified, Serviceguard will start up resource monitoring for
# these AUTOMATIC resources automatically when the node starts up.
# If DEFERRED is selected, Serviceguard will not attempt to start
# resource monitoring for these resources during node start up. User
# should specify all the DEFERRED resources in the package run script
# so that these DEFERRED resources will be started up from the package
# run script during package run time.
#
# RESOURCE_UP_VALUE requires an operator and a value. This defines
# the resource 'UP' condition. The operators are =, !=, >, <, >=,
# and <=, depending on the type of value. Values can be string or
# numeric. If the type is string, then only = and != are valid
# operators. If the string contains whitespace, it must be enclosed
# in quotes. String values are case sensitive. For example,
#
# Resource is up when its value is
# --------------------------------
# RESOURCE_UP_VALUE = UP "UP"
# RESOURCE_UP_VALUE != DOWN Any value except "DOWN"
# RESOURCE_UP_VALUE = "On Course" "On Course"
#
# If the type is numeric, then it can specify a threshold, or a range to
# define a resource up condition. If it is a threshold, then any operator
# may be used. If a range is to be specified, then only > or >= may be used
# for the first operator, and only < or <= may be used for the second operator.
# For example,
# Resource is up when its value is
# --------------------------------
# RESOURCE_UP_VALUE = 5 5 (threshold)
# RESOURCE_UP_VALUE > 5.1 greater than 5.1 (threshold)
# RESOURCE_UP_VALUE > -5 and < 10 between -5 and 10 (range)
#
# Note that "and" is required between the lower limit and upper limit
# when specifying a range. The upper limit must be greater than the lower
# limit. If RESOURCE_UP_VALUE is repeated within a RESOURCE_NAME block, then
# they are inclusively OR'd together. Package Resource Dependencies may be
# defined by repeating the entire RESOURCE_NAME block.
#
# Example : RESOURCE_NAME /net/interfaces/lan/status/lan0
# RESOURCE_POLLING_INTERVAL 120
# RESOURCE_START AUTOMATIC
# RESOURCE_UP_VALUE = RUNNING
# RESOURCE_UP_VALUE = ONLINE
#
# Means that the value of resource /net/interfaces/lan/status/lan0
# will be checked every 120 seconds, and is considered to
# be 'up' when its value is "RUNNING" or "ONLINE".
#
# Uncomment the following lines to specify Package Resource Dependencies.
#
#RESOURCE_NAME
#RESOURCE_POLLING_INTERVAL
#RESOURCE_START
#RESOURCE_UP_VALUE [and ]

# Access Control Policy Parameters.
#
# Three entries set the access control policy for the package:
# First line must be USER_NAME, second USER_HOST, and third USER_ROLE.
# Enter a value after each.
#
# 1. USER_NAME can either be ANY_USER, or a maximum of
# 8 login names from the /etc/passwd file on user host.
# 2. USER_HOST is where the user can issue Serviceguard commands.
# If using Serviceguard Manager, it is the COM server.
# Choose one of these three values: ANY_SERVICEGUARD_NODE, or
# (any) CLUSTER_MEMBER_NODE, or a specific node. For node,
# use the official hostname from domain name server, and not
# an IP addresses or fully qualified name.
# 3. USER_ROLE must be PACKAGE_ADMIN. This role grants permission
# to MONITOR, plus for administrative commands for the package.
#
# These policies do not effect root users. Access Policies here
# should not conflict with policies defined in the cluster configuration file.
#
# Example: to configure a role for user john from node noir to
# administer the package, enter:
# USER_NAME john
# USER_HOST noir
# USER_ROLE PACKAGE_ADMIN

[Johnny Damtoft]

Hi again,

Under the subnet section you are missing something.

#SUBNET
SUBNET 10.1.1.0

It needs to be:
#SUBNET
SUBNET 10.1.4.0
SUBNET 192.168.0.0


In your netconf file, you need to make sure that you are using /23 (255.255.254.0) af your subnet.

INTERFACE_NAME[0]=lan0
IP_ADDRESS[0]=10.1.4.18
SUBNET_MASK[0]=255.255.254.0
BROADCAST_ADDRESS[0]=10.1.5.255

Make sure that you have the correct SUBNET/IPs in the /etc/hosts file as well.

Let me know, how it goes.


--Johnny

[Johnny Damtoft]

In your cntl file, you need to set FS_TYPE when mounting a mountpoint.
Not that it wont work, but you need to give your system all the information that it needs.

LV[0]=/dev/vg_gbcb/lvol1;FS[0]=/gbcb_test;FS_MOUNT_OPT[0]="-o largefiles"; FS_UMOUNT_OPT[0]="";FS_FSCK_OPT[0]=""; FS_TYPE[0]=""

change it to:
LV[0]=/dev/vg_gbcb/lvol1;FS[0]=/gbcb_test;FS_MOUNT_OPT[0]="-o largefiles"; FS_UMOUNT_OPT[0]="";FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"


Furthermore, you have this in your cntl file:

IP[0]=10.1.4.207
SUBNET[0]=10.1.4.0
IP[0]=
SUBNET[0]=10.1.4.0

This might give a bit of a problem... You need to remove the second entry of both IP and SUBNET.


--Johnny

[boomer_2]

Hi johny,
After putting 10.1.4.0 as subnet i get the same error as i was getting earlier originally..........subnet not part of cluster...so what do i do now.........?
Let me tell u johnny this cluster setup was shhifted from 10.1.1.0 setup to 10.1.4.0 now...

and when i did stress tests i.e. removing both lan cables from my server to test my cluster failover i was successful..but while switching from lan0 to lan1 there again the subnet shown was 10.1.1.0..???

Is is hardcoded somewhere in cluster config files where i need to change...plzz let me know...

[Johnny Damtoft]

If your still having problems, send me the cluster.ascii (cluster config file) located at: /etc/cmcluster/cluster.ascii

--Johnny

[boomer_2]

hi johnny,
cluster config file attached herewith.........

[Johnny Damtoft]

A few questions:

Have you change the IPs in the cluster config?

Has the cluster config been "applyed"? (if so, how?)

What is the heartbeat network and ips?

What are you using the IP Aliases for on lan0, and how are they configured/setup?

One rule with MC/SG is listed here:
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could
# be either HEARTBEAT_IP or STATIONARY_IP.


--Johnny

[boomer_2]

Have you change the IPs in the cluster config? YEs

Has the cluster config been "applyed"? (if so, how?)
cmapplyconf -C cedge.config -P mcgb_bancs.conf -P mcgb_bancs_live.ascii -P gbcb_test.conf

What is the heartbeat network and ips?
since its a cross cable we have given class c ip 192.168.0.61 and 192.168.0.62

What are you using the IP Aliases for on lan0, and how are they configured/setup?
What do u mean by IP aliases .?.we have package ip as 10.1.4.22,10.1.4.23 and 2 node ip's as 10.1.4.18 & 10.1.4.19..

o/p from sam attached herewith ...
â Network Interface Cards 0 of 8 selectedâ
â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â
â Card Interface Hardware Internet â
â Type Name Path Status Address â
â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â
â â 1000Base-T lan0:1 0/1/2/0 Enabled 10.1.4.207 ^ â
â â 1000Base-T lan0:2 0/1/2/0 Disabled 10.1.4.207 â
â â 1000Base-T lan0 0/1/2/0 Enabled 10.1.4.19 â
â â 1000Base-T lan0 0/1/2/0 IPV6 Not Configured :: â
â â 1000Base-T lan1 0/1/2/1 Not Configured 0.0.0.0 â
â â 1000Base-T lan1 0/1/2/1 IPV6 Not Configured :: â
â â 1000Base-T lan2 0/5/1/0 Enabled 192.168.0.62 â
â â 1000Base-T lan2 0/5/1/0 IPV6 Not Configured :: â
â â v â
â <â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â â >â â


One rule with MC/SG is listed here:
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could
# be either HEARTBEAT_IP or STATIONARY_IP.


--Johnny