Technical Considerations for a Serviceguard Cluster that Spans Multiple IP Subnets, July 2009
12
/etc/rc.config.d/netconf as shown in the excerpt. Note that the static routing configuration in
this example is applicable to HP-UX only. Static routing setup may be different in Linux.
In this correct configuration, heartbeat packets from subnet 5.1.2.0 to subnet 5.2.2.0 are routed
through lan2 and its own router gateway (R2) 5.1.2.254. On node C, heartbeat packets from subnet
5.2.2.0 to subnet 5.1.2.0 are routed through lan2 and its own router gateway (R2) 5.2.2.254.
Table 3 – Configuration file showing correct configuration of heartbeat routing
Configuration file: /etc/rc.config.d/netconf
Node A Node C
IP_ADDRESS[0]=5.1.1.1
SUBNET_MASK[0]=255.255.255.0
INTERFACE_NAME[0]=lan1
BROADCAST_ADDRESS[0]=5.1.1.255
INTERFACE_STATE[0]=up
#
ROUTE_DESTINATION[0]="net 5.2.1.0"
ROUTE_MASK[0]="255.255.255.0"
ROUTE_GATEWAY[0]="5.1.1.254"
ROUTE_COUNT[0]="1"
ROUTE_ARGS[0]=""
IP_ADDRESS[1]=5.1.2.0
SUBNET_MASK[1]=255.255.255.0
INTERFACE_NAME[1]=lan2
BROADCAST_ADDRESS[1]=5.1.2.255
INTERFACE_STATE[1]=up
#
ROUTE_DESTINATION[1]="net 5.2.2.0"
ROUTE_MASK[1]="255.255.255.0"
ROUTE_GATEWAY[0]="5.1.2.254"
ROUTE_COUNT[1]="1“
ROUTE_ARGS[1]=""
IP_ADDRESS[0]=5.2.1.1
SUBNET_MASK[0]=255.255.255.0
INTERFACE_NAME[0]=lan1
BROADCAST_ADDRESS[0]=5.2.1.255
INTERFACE_STATE[0]=up
#
ROUTE_DESTINATION[0]="net 5.1.1.0"
ROUTE_MASK[0]="255.255.255.0"
ROUTE_GATEWAY[0]="5.2.1.254"
ROUTE_COUNT[0]="1"
ROUTE_ARGS[0]=""
IP_ADDRESS[1]=5.2.2.1
SUBNET_MASK[1]=255.255.255.0
INTERFACE_NAME[1]=lan2
BROADCAST_ADDRESS[1]=5.2.2.255
INTERFACE_STATE[1]=up
#
ROUTE_DESTINATION[1]="net 5.1.2.0"
ROUTE_MASK[1]="255.255.255.0"
ROUTE_GATEWAY[0]="5.2.2.254"
ROUTE_COUNT[1]="1"
ROUTE_ARGS[1]=""
Example 3: Package subnet requirements
Figure 7 shows how package subnets can be configured in a cross-subnet configuration, by sharing
one of the heartbeat networks. Some notes regarding this example:
The package subnets are configured with standby interfaces.
If subnet 5.1.2.0 fails site-wide, a package running on node A and using subnet 5.1.2.0 will fail
over to node C or node D on the other site, and start using package subnet 5.2.2.0 instead.
The package subnet 5.1.2.0 on one site may be fully routed to the package subnet on the other site
5.2.2.0, but that is not a requirement. However, often applications running on different cluster
nodes need to communicate with each other across the sites. In those cases, you can choose to use
the fully redundant inter-site link as a communication path instead of the highly available network
cloud. In those cases, these two subnets need to be fully routed at the IP level.