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

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

12 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