Why does the 3rd McAfee cluster member located on a separate chassis at a DR site not become "active"?
Is a 3 member cluster supported on a separate chassis? Yes
Why does the 3rd McAfee cluster member located on a separate chassis at a DR site does not become "active"?
While checking the cluster status with 'cf cluster status' get the following message:
Policy and Peer Connection Status
mfedr_1VA.local (secondary - pending connection to Crossbeam master)
Below are the technical mechanics related to how a newly installed MFE Node comes online and attempts to become a part of an existing cluster.
fwregisterd - When a newly installed member comes online, it uses a TCP connection to "discover" any other members
Note- If 'cf cluster status' lists any members, then fwregisterd connected successfully
resolverd - uses a tcp connection to exchange policy back and forth between the "master" node and the "child" nodes
faild - members use multicast to determine whether or not a member is in a good state.
Note: If a new installed member comes online and does not find other cluster members due to a connectivity (multicast) issue, it will form its own separate cluster.
Run tcpumdp on the sync interface . If the new member isn't getting multicast traffic, which points toward a connectivity issue against multicast traffic with the devices between the two X-Series chassis. Please refer to the screenshot of the packet traces below.
Consult your network team to troubleshoot the "multicast" issue
Once the "multicast" issue is resolved, remove the standalone cluster define on the DR site (cf cluster destroy force=yes), reboot and reinstall the new member and check if it comes up active.
If the new member still does not become active, please contact Bluecoat and McAfee support for further troubleshooting
Imported Document ID: 000019014
Subscribing will provide email updates when this Article is updated. Login is required.