Required Attribute
Required Attribute
|
Description, Type and Dimension, Default, and Example
|
Device
|
List of NICs that you want under MultiNICB control, and the aliases of those NICs. The IPMultiNICB agent uses the NIC aliases to configure IP addresses. The IPMultiNICB agent uses these interface aliases to determine the order of the interface on which to bring the IP addresses online.
- Type and dimension: string-association
- Example:
Device = { "lan0" , "lan4" }
- Example:
Device = { "lan0" = 0, "lan1" = 2, "lan2" = 3 }
- In this example, the MultiNICB agent uses interfaces lan0, lan1, and lan2. The MultiNICB agent passes on the associated interface aliases 0, 2, and 3 to the IPMultiNICB agent.
|
Optional Attributes
Optional Attribute
|
Description, Type and Dimension, Default, and Example
|
DefaultRouter
|
This is the IP address of the default router on the subnet. If specified, the agent removes the default route when the resource goes offline. The agent adds the route back when the group returns online. You must specify this attribute if multiple IP subnets exist on one host; otherwise, the packets cannot be routed properly when the subnet corresponding to the first default route goes down.
- Type and dimension: string-scalar
- Default: "0.0.0.0"
- Example: "192.1.0.1"
|
Failback
|
If set to 1, the virtual IP addresses are failed back to the original physical interface whenever possible. A value of 0 disables this behavior.
|
IgnoreLinkStatus
|
If set to 1, the agent ignores the driver-reported interface status while testing the interfaces. If set to 0, the agent reports the interface status as DOWN if the driver-reported interface status indicates the DOWN state. Using interface status for link testing may considerably speed up failovers.
|
LinkTestRatio
|
This is the ratio of total monitor cycles to monitor cycles in which the agent tests the interfaces by sending packets. At all other times, the agent tests the link by checking the "link-status" as reported by the device driver. Checking the "link-status" is a faster way to check the interfaces, but only detects cable disconnection failures.
If set to 1, packets are sent during every monitor cycle.
If set to 0, packets are never sent during a monitor cycle.
- In this example, if monitor entry-point invoking is numbered as 1, 2, 3, 4, 5, 6, ..., the actual packet send test is done at 3, 6, ... monitor entry-points. For LinkTestRatio=4, the packet send test is done at 4, 8, ... monitor entry points.
|
NetworkHosts
|
List of host IP addresses on the IP subnet that are pinged to determine if the interfaces are working. NetworkHosts only accepts IP addresses to avoid DNS lookup delays. The IP addresses must be directly present on the IP subnet of interfaces (the hosts must respond to ARP requests).
If IP addresses are not provided, the hosts are automatically determined by sending a broadcast ping (unless the NoBroadcast attribute is set to 1). The first host to reply serves as the ping destination.
|
NetworkTimeout
|
Timeout for ARP and ICMP packets in milliseconds. MultiNICB waits for response to ICMP and ARP packets only during this time period.
Assign NetworkTimeout a value in the order of tens of milliseconds (given the ICMP and ARP destinations are required to be on the local network). Increasing this value increases the time for failover.
|
NoBroadcast
|
If set to 1, NoBroadcast prevents MultiNICB from sending broadcast ICMP packets. (Note: MultiNICB can still send ARP requests.)
If NetworkHosts are not specified and NoBroadcast is set to 1, the MultiNICB agent cannot function properly.
Note VERITAS does not recommend setting the value of NoBroadcast to 1.
|
OfflineTestRepeatCount
|
Number of times the test is repeated if the interface status changes from UP to DOWN. For every repetition of the test, the next NetworkHost is selected in round-robin manner. At the end of this process, broadcast is performed if NoBroadcast is set to 0. A greater value prevents spurious changes, but also increases the response time.
|
OnlineTestRepeatCount
|
Number of times the test is repeated if the interface status changes from DOWN to UP. This helps to avoid oscillations in the status of the interface.
|
Checklist for Using MultiNICB
For the MultiNICB agent to function properly, you must satisfy each item in the following list:
Each interface must have a unique MAC address.
A MultiNICB resource controls all the interfaces on one IP subnet.
At boot time, you must plumb all the interfaces that are under the MultiNICB resource and give them test IP addresses.
All test IP addresses for the MultiNICB resource must belong to the same subnet as the virtual IP address.
Tip
The base IP addresses, which the agent uses to test the link status, should be reserved for use by the agent. These IP addresses do not get failed over.
If NetworkHosts is specified, the hosts must be directly accessible on the LAN.
Trigger Script
MultiNICB monitor entry point calls a VCS trigger in case of an interface going up or down. The following arguments are passed to the script:
- MultiNICB resource name
- device whose status changed (for example, lan0)
- device's previous status (0 for down, 1 for up)
- device's current status
- monitor heartbeat
The agent also sends a notification (which may be received via SNMP or SMTP) to indicate that status of an interface changed. The notification is sent using "health of a cluster resource declined" and "health of a clusterresource improved" traps which are mentioned in the VCS User's Guide. A sample mnicb_postchange trigger is provided with the agent. The user may customize this sample script as needed or write one from scratch.
The sample script does the following:
- If interface changes status, it prints a message to the console, for example: MultiNICB: Device lan0 status changed from DOWN to UP.
- The script saves last IP address-to-interface name association. If any of the IP addresses has been moved, added, or removed, it prints out a message to the console, for example: MultiNICB: IP address 192.4.3.3 moved from interface lan1:1 to interface lan0:1
Sample Configuration
VCS Configuration
The following is an example VCS configuration.
include "types.cf"
cluster clus_north (
UserNames = { admin = "cDRpdxPmHpzS." }
Administrators = { admin }
CounterInterval = 5
)
system north
system south
group g11 (
SystemList = { north = 0, south = 1 }
AutoStartList = { north, south }
)
IPMultiNICB ipmnicb (
BaseResName = mnicb
Address = "192.1.0.201"
NetMask = "255.255.0.0"
DeviceChoice = 1
)
MultiNICB mnicb (
Device @north = { lan0 = 0, lan4 = 1 }
Device @south = { lan0 = 0, lan4 = 1 }
NetworkHosts = { "192.1.0.1" }
DefaultRouter = "0.0.0.0"
)
ipmnicb requires mnicb
|