Technical Forum
Ask questions. Discover Answers.
Showing results for 
Search instead for 
Did you mean: 

Two 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 looks of it outbound traffic out to the internet stops.

The health monitor used is the default HTTPS. I've created a custom monitor to GET a file from the backend pool members which marks the nodes as up, but the apps still don't work. The backend servers are running IIS10.0.

Some versions of the F5 software work, most do not. Working versions are, 14.1.4, and All other versions seem to not work. As soon as the upgraded device is made active (in the HA pair) the VSs go down. Packet captures don't seem to show the issue, but they do indicate for some reason there's a 75 second+ pause in the response from the pool members. This isn't there when one of the working versions is active so I don't think this is an issue with the pool member.

The traffic passes through two sets of Checkpoint firewalls, and is NATed each time on these firewalls on the way to the internet.

Could anyone provide information as to why this would work with some versions of the BIG-IP software, and not others?




@JN_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.

F5 Employee
F5 Employee

In addition to Paulius, I suggest you start with uploading a qkview to iHealth, from there it might be able to identy any issues.

With code upgrades, the ciphers also get upgraded.  This can cause some server connectivity issues.

My first stop would be the ltm logs to see if there are any iRule errors, cipher errors, or health monitor timeouts.

I also suggest getting up to the latest 15.1.x train so you have all the latest hotfixes.

Hi @JN_AU , 
in addition to @Ben_Novak and @Paulius , 
use F5 Bug scrub portal to identify any Bugs before proceeding on your upgrade , maybe you hit in a bug. 
This is the URI to use it :

Let me give you brief about Bug tracker , you will add your target virsion and filter on (blocking , Critical , High ) issues also filter on ( TMOS , LTM ) Bugs. 
so Based on your design and scenario I think you may find some thing related to your issue.

>> Note , Running Bug Scrub for a target version you aim to use it for upgrade is very crucial before Upgrade , indeed ! 

Mohamed Kansoh


Hi All,

Thanks for the replies.


The health monitor and everything works fine when using the working versions - 14.1.4 or It's only when a different version is made active that the issues start. Nothing else changes in the environment, the only difference is the F5 upgraded version (no routing/firewall changes).

I went and compared the versions - 14.1.4 to, and to (also tested not working).

Comparing 14.1.4 (working) to (non-working), the only difference I could see in the config was under the virtual addresses for the VIPs, they had 'icmp-echo enabled' in (non-working version).

Comparing (working) to (non-working) I couldn't see any differences in the config.


I uploaded QKViews to iHealth but they didn't shed any light on the issue unfortunately. I've had a case open for quite some time with F5 for this issue. No errors come up in the logs when this issue happens that I've found so far.

Unfortunately every version I've tried in 14.x over 14.1.4 has not worked - same thing with anything over in the 15.x branch. I also can't leave these F5s running as they are 2000s, and only up to 15.1.2 is officially supported.


Thanks for letting me know about the bug tracker. I did search this for the versions listed but unfortunately couldn't find anything related to these issues I'm facing.

@JN_AU If you are not able to share your configuration the only other thing that I can recommend is performing a code upgrade without copying the configuration over to the new installation and then configuring the F5 from scratch to see if it works after that. You should be able to load the configuration quickly by gathering all the configuration through the CLI and then loading it using the following command. Aside from this as a last resort, this might be something that you have to wait for F5 to respond on.

load sys config from-terminal merge