VMAC and Automatic NAT

[Maarten_Sjouw]

Yesterday we were doing a migration of a cluster which has some Automatic NAT's that are using IP's in the same range as the external IP of the gateways.

Months ago we had issues with this customer when we had a cluster failover which was returned shortly after, around 10 minutes. After the primary member was restored the router just kept using the mac address of the backup gateway and only after the 4 hour cache of the router was flushed, it restored the proper mac address.

We decided to change the cluster to use VMAC instead and setup proxy arp (for the manual NAT) to use the VMAC as well. Now you would expect the cluster to show the VMAC adresses when you see the response on 'fw ctl arp' but it will only show the manual NAT proxy arp entries with the VMAC and all automatic NAT are just using the interface mac and I really do not understand why.

As when we yesterday moved from openserver on R77.30 to Appliance with R80.10 we were really surprised to see this behavior as again we had problems with those blasted routers not picking up the gratuitous arps sent when switching the cluster (during failover tests).

Only by sending them manually by using arping we could get it all back to work again.

This just one of the reasons why I really prefer VRRP, as there the automatic NAT just use the VMAC, as it should.

Anyone else having similar problems or are the clusters I have checked so far (about 4 ClusterXL and 2 VRRP) the only ones with these problems or has nobody ever wondered? 

[Kosin_Usuwanthi]

I have issue like you and fixed by remove cloning groups on Gaia.

refer to  sk106592

[Maarten_Sjouw]

You mixing things up, the thing that works fine is the Proxy ARP, the problem is that the Automatic NAT uses the wrong MAC address for proxy ARP, it uses the member interface MAC, not the VMAC.

Cloning group is not enabled.

[PhoneBoy]

Looks like there have been issues along these lines in the past: Automatic NAT IP addresses are assigned with a physical MAC addresses of the cluster members instead... 

Probably worth a TAC case.

[Maarten_Sjouw]

That SK refers to VRRP having the same problem, which was solved in R75.45, but here we are talking about R77.30 and R80.10

We were already working on opening a case but worked around the problem for now with manual NAT's and Manual Proxy ARP's.

[PhoneBoy]

I didn't say it was exactly the same issue, but one in a similar vein.

[bryanastudillo]

Hello, could you solve the problem?

[Maarten_Sjouw]

I'm sorry, but the release that we were running 18 months ago is no longer on these boxes, I think those are running R80.30 now.
I also have no recollection for which customer we were facing these issues, in this case it can be about 10 different customers.

[bryanastudillo]

Hello,

Thanks for you response. Well, I have a similar issue with vmac and automatic nat, eventually the L3 switch stopped sending traffic to the cluster, the solution was to clearing the switch arp table. 

On the switch, before cleaning the arp table I saw that in its arp table the IP addresses had associated a vmac quite similar to the vmac of the cluster with the difference that the last hexadecimal value was: FF while the vmac of the cluster ended in: 02.

So the point is to know if the cluster is sending a wrong vmac or if the switch is saving it incorrectly

[bryanastudillo]

Or if there is a reason that the cluster has changed its vmac without having made any changes.

[Maarten_Sjouw]

If it happens again I would certainly open a TAC case for it.