VMAC Mode on R80.10

[Alexander_Wilke]

Hi,

what do you think about the fact that R80.10 Gateways in VMAC Mode (ClusterXL, High Availability, Active/Standby) is only publishing its VMAC to clients for ingress traffic but then for egress traffic the Gateway will always use its physical MAC address and not the VMAC?

So clients address the firewall using the VMAC of the firewall but all traffic outgoing from the firewall to clients/servers has the physical MAC address as source-address. So it is a kind of "asynchroneous MAC address routing" - clients sends traffic to VMAC, firewalls sends traffic with physical MAC.

So is VMAC mode really what it should or should it better be named "VMAC lite" ?

What do you think is the reason for not using real "VMAC" for all kind of traffic like e.g. Cisco is doing it with HSRP? Performance issues? Bad internal design?

Regards

[PhoneBoy]

The original message was posted during the EA timeframe.

Now that GA is released, I'd be curious if you're seeing the same behavior or not.

[Alexander_Wilke]

Hi,

probably best way would be if you compare VMAC mode (Unified MAC) which is on the R76SP.50 JHFA Take 72 and the VMAC mode on the legacy appliances R80.x and R77.x.

Then you will know what I mean. Or you talk directly to Shay Naveh - we already discusses this many times with him.

So from my Point of view 64k / R76SP.50 is working like it should, R77.30 and R80.10 for legacy appliances (12200, 12600, 21700, 15600) is not working as it should. Still uses different MAC addresses for receiving traffic and for sending traffic.

Regards

[PhoneBoy]

I'm curious if this is causing a real issue somehow or if it is merely a cosmetic one.

[Alexander_Wilke]

Yes, it is causing real issues. That is the reason why Shay Baveh was here for several days of discussion and understanding the Network.

I can tell you two issues we are dealing with since years:

1.) If we have a Solaris Server and this Server starts with PXE boot it addresses the VMAC - which is the address of the Default Gateway. The answer from the boot p Server - which is forwarded by the Gateway - is now the physical MAC address of the active Gateway. The Solaris Server discards this packet because it does not receive the answer from the same MAC address it forwarded the request to. So it is asymetric and it will not work. as a poor Workaround the Solaris colleagues address the physical IP address of the active Gateway to get it working.

2.) Cisco has a Feature called "conversational learning" implemented in its so called "Fabric Path". Fabrich Path is a Feature which is there for the communication and forwarding of traffic between several cisco components (Switches L", Routers L3) which are part of the same Fabric Path Domain. Connected devices like Firewalls, Servers and so on are - of course - not part of this Fabrich Path Domain. So within this Domain cisco makes sure - using "Conversational learning" - that there will be no spoofed MAC addresses learned on devices which will overload the CAM (MAC-Address table). So "Conversational learning" will make sure, that MAC addresses will only be learned and saved on a port if there was a bi-directional conversation between two Hosts with the same MAC-address combinatuion.

Example:

The Client A (xx:xx:xx:xx:xx:AA) Forwards the traffic to the FW-VMAC (xx:xx:xx:xx:xx:FE) and the answer packets are are forwarded from the FW-PHYS-MAC (xx:xx:xx:xx:xx:34) to the Client A (xx:xx:xx:xx:xx:AA) then These MAC addresses will not be learned because there was no successfully bi-directional conversation betweetween the same tuple of MAC addresses. The unwanted result is that the Switches are flodding (not broadcasting) this traffic on all ports

[PhoneBoy]

I understand the situation.

Unfortunately, it is operating as intended at the moment.

The good news is that you're talking to the person that can help address the issue on the R&D side.

[Vladimir]

When did the 15600 became a legacy appliance???

[Alexander_Wilke]

I am sorry for any confusion. English is not my native language. Probably I should say "scalable plattforms" and "not scaleable plattforms".

[PhoneBoy]

Just to update, it looks like we expect to address this difference as part of R80.20.

[PhoneBoy]

And to further clarify: this will be addressed with the R80.20 with the new (Linux 3.10) kernel.

Which means the R80.20 that is out as of this writing does not address this.

[Vladimir]

Aahh.. I do not think you are clarifying 

I thought we didn't get the 3.10 kernel in the R80.20 GWs...

Did you mean to "" the line after the ":" ? 

[PhoneBoy]

R80.20 for Management (only) has the new kernel.

R80.20 for Gateways / Standalone still has the old (2.6) kernel.

R80.20 with the new (3.10) kernel for Gateways is still in EA.

[Alexander_Wilke]

This is really confusing but this is checkpoint as I know it 😉
Nevertheless thanks for the update.

[miguel]

I've encountered the same issue as originally posted by Alexander_Wilke, using R80.30 3.10 on 5100 appliance.

VMAC mode still initiates traffic and uses the physical MAC instead of the VMAC.

My intended use-case with VMAC was specifically for my WAN interface (eth1, on 5100 appliances) where the ISP provides internet service with a Coax-based modem. I'm assigned a static IP address, but only the first MAC address seen will bind to that MAC from the ISP's perspective. Any MAC changes are ignored (until a very long aging timer expires). But I still wanted HA to work, and allow me to fail over between my units without much disruption.

Unfortunately, the R80.30 3.10 kernel did not change the behaviour. Upon bootup of the firewall, it still sent out traffic with its physical MAC (along with the VMAC), but physical MAC was first. This caused the ISP to semi-permanently bind to the physical MAC of the firewall, thus negating the use-case of VMAC in my environment.

Note: ISP put my modem in bridged mode, and I'm using a public IP on my wrp128 interface. I did not want to do double-NAT behind the modem's internal NATing.

[Carsten_R]

Embedded GAIA is also affected by that "behaviour" 😞

[GArndt]

Hi all,

There is another usecase for VMACs:
Internet -> External-HA-GW (ClusterXL active/standby + VIPs+VMACs) -> Loadbalancer F5 <- Internal-HA-GW (ClusterXLa/s + VIPs+VMACs) <- Company-Intranet
The F5 Loadbalancer has no routing table due to a very wide range of networks used on Intranet (multiple changes a day).
So, on F5 the activated mode: "auto last hopp" creates a table, where the originating MAC-Address from an access to F5 is listed. In this case the MAC of one of the HA-GWs (egress)!

My question: In R80.xx is this the cluster's VMAC-address or the interface's physical MAC-address?

Has there been a change in behaviour since R77.30 (for there it seems to work with VMAC!)
We are planning urgently to upgrade to R80.xx but this might be a concern how to deal with it.

(The F5 guys do not want to alter routing tables multiple times a day!)

[BigLeBeauski24]

Hello,

I was wondering if there were any updates to this topic?  I have a cluster of 3100s on R80.30 Take 155 exhibiting the same behaviour where traffic sent to the VIP (destined to the VMAC) is then replied to using the VIP as the source and the physical MAC of the active member as the MAC source address.  It is causing problems with the ISP's setup.  This ISP does not support G-ARP so we need to use VMAC.  The VMAC seems to work as the ARP table of the modem is correctly assigning the VIP to the VMAC and sending traffic correctly.  However, it is not accepting the reply traffic because the source MAC is not the VMAC.  

Any help on this would be greatly appreciated!

Thanks,

Dave

[Daniel_]

I also asked TAC (and R&D) about that issue. The answer was for R80.40:
"We can confirm that this is by design the mentioned SK [sk117412] refers only to ARP the member send the traffic with its MAC and uses the VMAC only for ARP."

So no VMAC for "real" traffic. I never expected this behavior when I turned on VMAC mode...

Someone tested this behavior with f5 auto last hop feature? Without auto last hop you don't have some accelerated security features (e.g. K16887)