VSX Cluster + Bond + Proxy ARP: To VMAC or not to VMAC

[FedericoMeiners]

Hello,

Hope you're doing well, recently I had to design an architecture that supports a VSX cluster of 2 gateways( active/passive) in R80.20 or R80.30

We have bonded interfaces and manual NAT entries in many VS. When I started researching about Proxy ARP in VSX I found a blog entry from @_Val_ about how to approach this design:

http://checkpoint-master-architect.blogspot.com/2014/08/setting-proxy-arp-for-bonded-interface.html

Long story short, you have the following options:

1. Create a Virtual Switch and attach the bond to that virtual device and setup the proxy ARP on the virtual link between the vswitch and the vsystem.
2. Configure VMAC on VSX cluster and add Proxy ARP entries on that VMAC
3. Let the bond as it is.

As stated in the blog post, solution 2 and 3 are more viable, my question is the following: ¿Which option is the recommended one?

From my point of view is always best to deploy as most default as possible, option 3 would be the best, also I had some issues with VMACs.

My concern is how Check Point handles the MAC of the bond interface, when you set it up one of the interface's MAC address is chosen and is used by the bond and the N interfaces. However it seems that there was a time when this MAC could change, reffer to SK111675:

"MAC address for Bond interface changes after reboot. This affects the Proxy ARP configuration if the client is manually configuring the Bond interface's MAC address in the Proxy ARP.

This problem was fixed. The fix is included in:

Check Point R80.10
Jumbo Hotfix Accumulator for R77.30 - since Take_210"

In theory it should be safe to just use de MAC of the bond.

Would be great to have your opinion on this matter, 

Thanks for reading,

Federico Meiners

[Wolfgang]

Federico,

ther's another way to add a proxy arp entry to a gateway without configuring via the GAiA portal/ clish or using local.arp

Add a host object with your external IP to your rulebase and configure automatic NAT (static). As NAT-IP use the same external IP, add the relevant gateway and do a policy install. With this host object the gateway adds an proxy arp entry to the the gateway with the correct MAC.

We use this with loadsharing bond and active/passive bond and VSX. It works too with vMAC.

Wolfgang

[FedericoMeiners]

Wolfgang,

That's actually a clever work around, will test it on my lab and keep it mind.

Thanks!!

[Maarten_Sjouw]

Regarding using a VMAC or not, we have been using a lot of VRRP in our Nokia days and the VMAC was default there always.
That said, most of the problems taht occur with the VMACs are related to switches doing "security" features that break the proper working of VMAC switching (cluster failover). but the main advantage is that woth VMAC ther upstream and downstream devices do not need to change the mac for the VIP, as it remains the same.
We have seen multiple occasions where in a ClusterXL environment multiple cluster failovers did end up with no longer accessible VIP's. The mechanism for the failover is using gratuitous ARP (tell everyone this MAC belongs to this IP) and sometimes they get missed. This will not happen when you have a VMAC as the MAC does not change.

[Wolfgang]

I agree with Maarten,

using vmac would be the best solution.

I know one issue if using vmac.......sk102270.

If you use vmac there are two MAC-addresses used. One for sending packets out from gateway (physical MAC of sending host) and the vmac is used for incoming packets (telling all other devices the association vmac <=> Cluster_VIP). If you use my described way for NAT you get an arp entry Cluster-VIP => vmac. 

We saw the same behaviour shown in sk102270 with some HPE switches, but this could be solved with newest firmware release on the HPE-switches.

Wolfgang