Forum Discussion
pratya_52230
Nimbostratus
NimbostratusLTM/LC: ARP not update, after failover firewall
I have bigIP(LTM/LC) in front of checkpoint HA firewall(active/standby)
I did try pinging from my PC located in internal network through checkpoint+F5 to external router.
It seems fine at the first period of continuous ping, but when I tried failover checkpoint firewall by unplug one lan interface on active firewall (node A) to, to force failover to standby-firewall (nodeB),
I found that my ping result was timeout.
I use tcpdump on internal vlan on f5 and found that icmp-request was sent from FW-nodeB (0090.fb31.0947)to F5 correctly, but icmp-reply packet was sent to MAC address of FW-node A(0090.fb31.0917) which is wrong.
I also verified dynamic arp on bigip, and found that dynamic arp on bigip was correct and updated quickly. I tried another ping from another PC from same internal network, ping result is 100% success.
I do not understand why arp on bigip already update, but some process on bigip still remember the invalid mac-address. Anyone have found this problem like me, please kindly help.
note. my PC is 172.18.64.101
- I use SNAT with origin address configured to handle this outbound traffic.
- I config route 172.18.0.0 to VIP of checkpoint firewall as gateway.
hooleylistCirrostratus
Hi Pratya,
I suggest opening a case with F5 Support to get help diagnosing this issue.
Aaron
Joel_MosesI suspect that auto last hop is coming into conflict with your failover here. I'm assuming you're using Checkpoint's clustering/failover solution (ClusterXL) -- it will gratARP to the subnet on failover to get the traffic flowing to the correct interface, but if the F5 has auto last hop on, existing sessions will not follow the new MAC. That's why you can ping from another workstation that didn't previously have a session, but you can't for the system that had a running session when the failover occurred. This differs from some failover protocols that use Multicast MAC (VRRP or HSRP, for example) which use the same VMAC for the virtual IP.
The solution here will probably be to set a static routing table and turn off auto last hop on this LTM; make sure before you do you fully explore the implications it'll have to your network design.
fLyf5_21542Hi All
I am facing exactly the same issue in our environment. Adding static route is not a solution in my case.
Could you please share your f5 case details with us.
... fLy
nitassEmployee
hi fLy,
i think pratya has not opened a case yet. anyway, i agree with Joel.
by the way, may we know why adding static route and disabling auto last hop isn't acceptable?
thanks!- fLyf5_21542The device is in transparent mode, I think routing wont help us in this case.
I have not checked auto last hop, but this term sounds related to Network layer. Please suggest if you have come across similar situation.
...fLY - nitassThe device is in transparent mode
not sure if i understand correctly but if u mean vlangroup and default gateway of device behind bigip is correct, i don't think u need to add static route on bigip. only disabling auto last hop could be enough. can u try?
sol11796: Overview of the Auto Last Hop setting
http://support.f5.com/kb/en-us/solutions/public/11000/700/sol11796.html - fLyf5_21542Could you please tell us if changing Transparency mode from "Translucent" to "Opaque" have any impact in this situation.
- fLyf5_21542Read many documents ; still confused on when to use Opaque :(
Paokung_73346The auto last hop was the cause of this issue. disabling auto lasthop feature can resolve this issue.
Thanks everyone