|
|
|
Included Topics |
A VLAN switch tags packets that originate in a VLAN with a four-byte header that specifies which switch port it came from. No packet is allowed to go from a switch port in one VLAN to a switch port in another VLAN, apart from ports ("global" ports) that are defined so that they belong to all the VLANs.
The cluster member is connected to the global port of the VLAN switch, and this logically divides a single physical port into many VLAN ports each associated with a VLAN tagged interface (VLAN interface) on the cluster member.
When defining VLAN tags on an interface, cluster IP addresses can be defined only on the VLAN interfaces (the tagged interfaces). Defining a cluster IP address on a physical interface that has VLANs is not supported. This physical interface has to be defined with the Network Objective Monitored Private.
|
Note - ClusterXL does not support VLANS on Windows 2000 or Windows 2003 Server. |
It is not recommended to connect the non-secured interfaces (the internal or external cluster interfaces, for example) of multiple clusters to the same VLAN. A separate VLAN, and/or switch is needed for each cluster.
Connecting the secured interfaces (the synchronization interfaces) of multiple clusters is also not recommended for the same reason. Therefore, it is best to connect the secured interfaces of a given cluster via a crossover link when possible, or to an isolated VLAN.
If there is a need to connect the secured or the non-secured interfaces of multiple clusters to the same VLAN you need to make changes to:
This section applies to ClusterXL Load Sharing Multicast Mode only.
When a member that is outside the cluster wishes to communicate with the cluster, it sends an ARP query with the cluster (virtual) IP address. The cluster replies to the ARP request with a multicast MAC address, even though the IP address is a unicast address.
This destination multicast MAC address of the cluster is based on the unicast IP address of the cluster. The upper three bytes are 01.00.5E, and they identify a Multicast MAC in the standard way. The lower three bytes are the same as the lower three bytes of the IP address. An example MAC address based on the IP address 10.0.10.11 is shown below.
When more than one cluster is connected to the same VLAN, the last three bytes of the IP addresses of the cluster interfaces connected to the VLAN must be different. If they are the same, then communication from outside the cluster that is intended for one of the clusters will reach both clusters, which will cause communication problems.
For example, it is OK for the cluster interface of one of the clusters connected to the VLAN to have the address 10.0.10.11, and the cluster interface of a second cluster to have the address 10.0.10.12. However, the following addresses for the interfaces of the first and second clusters will cause complications: 10.0.10.11 and 20.0.10.11.
The best solution is to change to the last three bytes of the IP address of all but one of the cluster interfaces that share the same last three bytes of their IP address.
If the IP address of the cluster interface cannot be changed, you must change the automatically assigned multicast MAC address of all but one of the clusters and replace it with a user-defined multicast MAC address. Proceed as follows:
This section applies to all ClusterXL modes, both High Availability and Load Sharing, and to OPSEC certified clustering products.
Cluster members communicate with each other using the Cluster Control Protocol (CCP). CCP packets are distinguished from ordinary network traffic by giving CCP packets a unique source MAC address.
Default value of fifth byte |
Purpose |
|---|---|
0xfe |
CCP traffic |
0xfd |
Forwarding layer traffic |
When more than one cluster is connected to the same VLAN, if CCP and Forwarding Layer traffic uses Multicast MAC address for the destination, this traffic reaches only the intended cluster.
If the Broadcast MAC address is used for Destination for CCP and for Forwarding Layer traffic (and in certain other cases), cluster traffic intended for one cluster is seen by all connected clusters. If this traffic is processed by the wrong cluster, it will cause communication problems.
The Security Gateway must be able to identify the source MAC address in packets from different clusters connected to the same VLAN. Change the source MAC address of the cluster interface connected to the VLAN, in all but one of the clusters.
To solve in R77.30:
cphaconf cluster_id get cphaconf cluster_id set <value>For more details, see sk36055.
To solve in other versions:
Use these Security Gateway configuration parameters to set more than one cluster on the same VLAN. These parameters apply to ClusterXL and OPSEC certified clustering products.
Parameter |
Default value |
|---|---|
fwha_mac_magic |
0xfe |
fwha_mac_forward_magic |
0xfd |
When you change the values of these parameters, you change the fifth part of the source MAC address of Cluster Control Protocol and forwarded packets. The two values must be different. To avoid confusion, do not use the value 0x00.
The MAC magic parameters are explained in more detail later.
Enabling Interface Link State Monitoring shortens the time it takes for ClusterXL to detect an interface failure. By monitoring the link state (i.e. the electrical state) of an interface, ClusterXL is immediately alerted to connectivity issues concerning a certain network interface, such as a disconnected cable, or an electrical failure (real or simulated) on a switch.
Interface Link State Monitoring requires an interface device driver that supports link state detection. The device driver reports the link state as either connected or disconnected.
Monitoring the interface link state is particularly useful in scenarios where a monitored interface (either a cluster interface or a monitored private interface) sends ICMP ECHO probe requests which are not answered by hosts or routers on the connected subnet.
When enabled, ClusterXL immediately detects when an interface goes down. When disabled, ClusterXL determines whether an interface is malfunctioning by watching subsecond timeout expiration.
Monitoring Interface Link State is enabled by default for R76 and higher.
|
Note - Interface Link State Monitoring requires an interface device driver that supports link state detection, and is supported for Gaia, SecurePlatform, and Linux only. This feature was tested on two cluster interfaces connected directly with a cross-cable. But it also works for interfaces connected to a switch. See sk31336. |
The global parameter fwha_monitor_if_link_state accepts these values:
To enable or disable Interface Link State Monitoring, run this command:
fw ctl set int fwha_monitor_if_link_state <0|1>
When you run this command, the change is not permanent. The Interface Link State Monitoring setting goes back to its default state when you reboot the member.
To enable or disable Interface Link State Monitoring permanently, see SecureKnowledge sk26202.