cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post

VMAC Mode on R80.10


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

13 Replies
Admin
Admin

Re: VMAC Mode on R80.10

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.

0 Kudos

Re: VMAC Mode on R80.10

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

0 Kudos
Admin
Admin

Re: VMAC Mode on R80.10

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

Re: VMAC Mode on R80.10

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

Admin
Admin

Re: VMAC Mode on R80.10

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. Smiley Happy

Vladimir
Pearl

Re: VMAC Mode on R80.10

When did the 15600 became a legacy appliance???

0 Kudos

Re: VMAC Mode on R80.10

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

0 Kudos
Admin
Admin

Re: VMAC Mode on R80.10

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

Admin
Admin

Re: VMAC Mode on R80.10

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.

0 Kudos
Vladimir
Pearl

Re: VMAC Mode on R80.10

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 ":" ? 

0 Kudos
Admin
Admin

Re: VMAC Mode on R80.10

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.

Re: VMAC Mode on R80.10

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

0 Kudos
miguel
Iron

Re: VMAC Mode on R80.10

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.

0 Kudos