- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- ClusterXL VMAC - No ARP replies
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ClusterXL VMAC - No ARP replies
I am testing ClusterXL with VMAC in a lab.
3 x VMs:
1 x Management
2 x Gateways
3 x virtual switches:
1) Linked to physical VLAN
2) Private vswitch for cluster sync
3) Private vswitch for clients LAN side of CP gateways
Management:
eth0: External vSwitch: 172.22.1.102/24
Gateways:
eth0: External vSwitch: 172.22.1.103/24, 172.2.1.104/24 vIP: 172.2.1.105/24
eth1: Sync: 172.16.0.1/30, 172.16.0.2/30
eth2: Private LAN: 192.168.0.252/24, 192.168.0.253/24, vIP: 192.168.0.254/24
I have a Windows 10 VM running Wireshark connected via eth2, DHCP from the firewall.
DHCP is enabled on both gateways:
Address pool: GW1: 192.168.0.1-192.168.0.99, GW2: 192.168.0.101-192.168.0.199
When I enable VMAC on the cluster, as soon as I install the policy, I can see that 192.168.0.254 disappears from the client's ARP table and wireshark shows no reply to ARP requests from the client.
- Labels:
-
ClusterXL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which version / jumbo is used and how are the vSwitches configured?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which version / jumbo is used and how are the vSwitches configured?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the link. That allowed me to work out what the issue was - I was missing the Hyper-V equivalent of forged transmit (MAC address spoofing). Have enabled that on the NICs now and VMAC is working as expected.
