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

VMAC and Automatic NAT

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? 

Regards, Maarten
0 Kudos
10 Replies
Highlighted

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

refer to  sk106592

0 Kudos
Highlighted

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.

Regards, Maarten
0 Kudos
Highlighted
Admin
Admin

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.

0 Kudos
Highlighted

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.

Regards, Maarten
0 Kudos
Highlighted
Admin
Admin

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

0 Kudos
Highlighted

Hello, could you solve the problem?

0 Kudos
Highlighted

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.
Regards, Maarten
0 Kudos
Highlighted

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

0 Kudos
Highlighted

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

If it happens again I would certainly open a TAC case for it.
Regards, Maarten
0 Kudos