Forum Discussion
JN_AU
Altostratus
AltostratusTwo virtual servers go down after an upgrade
Hi Everyone, I'm wondering if anyone has seen this behaviour before. After I perform an upgrade, two virtual servers out of about 10 go down. The applications using these VSs stop working, from the ...
Hi All,
This looks to have possibly been this bug: https://my.f5.com/manage/s/article/K85805058
The actual issue was on pool members behind the F5 - they used the F5s as a gateway to get to the internet using an IP forwarding VS. When the issue occurred these pool members were unable to get to the internet. It looks like the standard HTTPS health checks failed because the pool members were timing out trying to load internet content.
After further examination of packet captures it was observed there was possibly async traffic (based on MACs observed).
The fix was to create a new FastL4 profile and make sure 'loose init' and 'loose close' were enabled. This profile was then used on the ip forwarding VS, and it looks like this has solved the issue.
14.1.5.6 was installed and is so far working fine.
Paulius
MVP
MVPJN_AU I would check the following.
1. Is the health monitor making it to the destination? You can verify this with either a tcpdump or wireshark on the destination device.
2. Are the firewalls between the F5 and the destination blocking any communication from the F5s? For health monitors you would be looking for the F5 self-IPs for the active and standby unit.
3. Is the same routing in place for the new code version F5 and old code version F5?
4. Have you compared the old and new configuration of the F5s to see what is different. I have found the easiest way to do this if you don't have a BIG-IQ is to generate an SCF before the code upgrade and after and then diff the two files. The following URL should help with this.