VRRP works on which checkpoint version

[gajendra229]

VRRP works on which checkpoint version ?

[Bob_Zimmerman]

I believe all GAiA versions support VRRP. What are you trying to accomplish, though? I don't think I've ever seen a situation where it's better to use VRRP than ClusterXL New Mode.

[gajendra229]

Just want to know since when they have started VRRP and which one is better ClusterXL or VRRP

[EricAnderson]

VRRP was introduced in GAIA (which was introduced in R75.40).

One of the primary reasons for the introduction of GAIA was to consolidate/replacement both SPLAT and IPSO. The goal was to offer all of the features of each, so that everyone could "upgrade" to GAIA. To support this effort, Check Point wanted/needed to support those who had previously been using VRRP on IPSO.

As to which is better, I break it down to this when teaching (it's still in the curriculum):
- VRRP offers more granularity/control (think priorities/deltas/routers)
- That granularity comes at the cost of more complex configuration, making ClusterXL easier to set up

Keep in mind that the sync component of ClusterXL is still used in either case. The choice of VRRP vs. ClusterXL is only to handle the network-level aspects.

-E

[mcnallym]

The only time that found VRRP better then ClusterXL is down to the Network Environment and the difference between how the two work.

VRRP uses a Virtual MAC address for the HA IP address, which remains constant no matter which box is active
ClusterXL uses the Interface MAC of the Active Node for the HA IP address so upon failover the Gratuitous ARP packets are sent out to update surrounding devices that the MAC has changed for the HA IP address. Have come across situations where the surrounding network devices don't accept the G-ARP packet and so continue to try and use the OLD MAC.

You can however fix this with the use VMAC option which then uses a single Virtual MAC address instead of using the Interface MAC thus the MAC of the HA IP doesn't change upon failover.

Is the only reason that would use VRRP rather than ClusterXL today, but would be more inclined to use the VMAC option in ClusterXL now and only really find Gaia with VRRP where IPSO Boxes come out and Gaia Boxes gone in.

Basically less work to do ClusterXL compared with VRRP so that is what I use, not found any real reason today to continue to use VRRP other then if people used to IPSO they feel more comfortable with it.

[ShadowPeak.com]

The only time that found VRRP better then ClusterXL is down to the Network Environment and the difference between how the two work.

VRRP uses a Virtual MAC address for the HA IP address, which remains constant no matter which box is active
ClusterXL uses the Interface MAC of the Active Node for the HA IP address so upon failover the Gratuitous ARP packets are sent out to update surrounding devices that the MAC has changed for the HA IP address. Have come across situations where the surrounding network devices don't accept the G-ARP packet and so continue to try and use the OLD MAC.

You can however fix this with the use VMAC option which then uses a single Virtual MAC address instead of using the Interface MAC thus the MAC of the HA IP doesn't change upon failover.

Is the only reason that would use VRRP rather than ClusterXL today, but would be more inclined to use the VMAC option in ClusterXL now and only really find Gaia with VRRP where IPSO Boxes come out and Gaia Boxes gone in.

Basically less work to do ClusterXL compared with VRRP so that is what I use, not found any real reason today to continue to use VRRP other then if people used to IPSO they feel more comfortable with it.

The only real use cases for VRRP over ClusterXL are in my opinion:

1) Have the need to present more than one Cluster or Virtual IP (Backup Address) on a single physical or logical interface. VRRP can do this, ClusterXL can't. Generally this indicates more than one IP subnet in use on the same VLAN/segment which is not exactly solid network design...

2) Some kind of external entity (load balancing appliance, dynamic routing protocol such as OSPF) is handling the load balancing of traffic between multiple gateways. VRRP supports doing this, but ClusterXL has its own mechanism for balancing traffic and will interfere with the external entity.

[EricAnderson]

Wow - you guys decided to dive right in to the specific use cases, where I just left it at "granularity/control"

To add to the specific reasons above, one of the cool "old school" uses was to prioritize interfaces (via deltas). You can have more critical ones (like internet and e-commerce web farm) set with higher delta's than less critical (like testing and guest networks). This could allow a gateway with 2 "less important" failures to stay active over another with only 1 "critical" failure. The reason this is silly, of course, is that it's only a benefit if you to have 2 gateways with simultaneous failures. The better solution is to fix the first failure before there's a second!

-E

[Bob_Zimmerman]

The only real use cases for VRRP over ClusterXL are in my opinion:

1) Have the need to present more than one Cluster or Virtual IP (Backup Address) on a single physical or logical interface. VRRP can do this, ClusterXL can't. Generally this indicates more than one IP subnet in use on the same VLAN/segment which is not exactly solid network design...

You can actually do this with simple proxy ARP statements. You just need to get the traffic to the firewall, then the firewall rules only care about the IP. Go ahead, ask me how I know.

I would not use VRRP for a new deployment. If you're tempted to do something which VRRP can do and ClusterXL can't, it's probably a bad idea.

[ShadowPeak.com]

You can actually do this with simple proxy ARP statements. You just need to get the traffic to the firewall, then the firewall rules only care about the IP. Go ahead, ask me how I know.

I would not use VRRP for a new deployment. If you're tempted to do something which VRRP can do and ClusterXL can't, it's probably a bad idea.

Yes you can do that, but my impression is that doing so is not supported. Of course "not supported" isn't the same as "doesn't work" though...

[Bob_Zimmerman]

Yes you can do that, but my impression is that doing so is not supported. Of course "not supported" isn't the same as "doesn't work" though...

It's fundamentally how VSX works internally. The members get real IPs on automatically-allocated weird networks, then the VIPs are on the network the user specifies and are claimed using proxy ARP. I remember writing documentation on how to set up a cluster with off-net member IPs. I'm about 95% sure it's supported.