Hacker News new | past | comments | ask | show | jobs | submit login

I use F5's at work. The F5's do their job very very well, but are very very touchy. I've always considered nginx to be solid, stable, and low-maintenance. I think the opposite about F5 and am worried about this transition.

1) You can't export and re-import a config. Just doesn't work.

2) For the Virtual Appliance (not a recommended scenario by F5, to be fair) it's temperamental about its host and doesn't like to be migrated or moved, and will stop functioning.

3) Upgrades sometimes corrupt/wipe parts of the config, sometimes not.

4) Reboots sometimes corrupt/wipe parts of the config, and sometimes changes to the config are not actually applied until a reboot, even though there's no warning of this behavior.

5) Latest release notes for 12.x (last version I worked with) has a lengthy page detailing known issues. https://support.f5.com/kb/en-us/products/big-ip_ltm/releasen... Why? Why are there so many? Why are most of them critical? Many just shouldn't make it to release.

-edit- It's important to be hopeful. I'd rather land on the side of "nginx makes F5 better" rather than "F5 makes nginx worse".






1: How did you export? and did you try to import into a different unit?

4: In over 10 years of using F5 never seen a reboot break a config. The part about needing reboot to make a config change apply might be https://support.f5.com/csp/article/K13253. In short F5 keeps the old config in RAM and applies it to existing connections. when the latter expire, the old config is gone. Can be very annoying indeed when you are not aware of it. You can delete connections manually though. No need for reboot.

3/5: Yes, all their releases have a list of all known issues. It's a bit odd indeed, but I think it's a good thing. Plan your upgrades carefully.


Existing connections using the config when they were initiated is intended to prevent inconsistencies when changes are being made, these inconsistencies could lead to connections being dropped en mass after a config change.

I use F5s at work, heres some responses:

1) You can, if you are careful about what your doing. UCS archives are only intended to be restored on the same machines, restoring them on a different machine requires considering the master key for secret encryption and omitting the license from the UCS. If your restoring it on another model F5, you might be going about things in a sub-optimal way.

2) This typically relates to how stuff like VMWare deals with disk issues or migration. In (some versions) VMWare if there is a disk IO operation thats taking too long, it will pause the VM. It also pauses the VM when you use DRS or live migrate. IF your using a failover pair or cluster this will cause a failover because well, the other device went away for a period of time.

3) Ive only ever seen ASM config lost after an upgrade, and its usually because the unit was not relicensed before upgrading and wasnt licensed for the new version as a result.

4) Ive seen this happen an it was usually because something was in a bad state and rebooting just poked it into failing. Also, always save sys config after making changes in tmsh, it doesnt auto-save (same behavior as Cisco).

5) Because F5 has a policy of publishing a bug in the release notes and in bug tracker if it was ever seen by a customer. Contrast this with some other vendors who very selectively publish bug information.


Thanks for your responses. A good foil to my complaints. My experience is very selective.

I agree on 5, too - I'd rather have the bug published and at least know that it's been seen and is being worked on, but still, it's a little disheartening to look at an update you're about to install and see its list of breaks is longer than its list of fixes.


> [...] omitting the license from the UCS.

I believe this has improved in recent releases.

It used to be that if you tried importing a config, and you were not properly licensed, the import would bomb out in annoying ways.

In newer versions the import will at least pull in and save everything (AFAICT), but anything not licensed will simply not be active. Once you cut the proper cheques then things should work.


> 1) You can't export and re-import a config. Just doesn't work.

Besides normal archives (that are just tgz files) or manual config changes and re-loading, try "(tmsh) load sys config merge from-terminal (or file)". It is going to be a gamechanger. ;-) Takes any config snippet from "(tmsh) list..." or the bigip.conf files without rewriting into create/modify statements and add/replace-all-with blocks. No problem to import even large configs like 100KB at once, all as an atomic transaction.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: