For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

NiHo_202842's avatar
NiHo_202842
Icon for Cirrostratus rankCirrostratus
Jan 11, 2017

vIP gARP without Self IP in vIP range

Hello,   Currently we are running version 11.5.1 with no Self IPs defined in the vIP VLANs/subnets. Traffic is flowing through the vIPs without any problems. During a failover, some vIPs are not a...
arp
cloud
fail over
LTM
self ip
Ed_Summers's avatar
Ed_Summers
Icon for Nimbostratus rankNimbostratus
Jan 12, 2017

I had always attributed that to timing and traffic patterns. Possibly the upstream device's ARP cache expired (or was very close) for those VIPs prior to failover, so that newly-initiated traffic caused the upstream device to catch the correct MAC post-failover. If a VIP was configured to maintain sessions during a failover (such as connection mirroring), 'return' traffic would prompt the upstream device to catch the new MAC as well.

 

In the end I'd recommend MAC masquerading, as Kai Wilke did in your post on that subject. We had some failover issues that we suspect was the upstream device not receiving or not able to process the GARPs correctly. Masquerading effectively resolved that.