Best Practice - Apply f5 updates and hotfixes

Hi Brett,

 

 

It's generally a good idea to keep LTMs close to up to date. I'd sign up for the mailing lists to get notified when new security issues are fixed and new versions are released:

 

 

http://support.f5.com/kb/en-us/pages/technews.html

 

 

I generally suggest to customers to move to a new major version once a minor version is released 11.0.1 for example for v11. Ideally you stay current, but not on the bleeding edge.

 

 

sol8986: F5 software lifecycle policy

 

http://support.f5.com/kb/en-us/solutions/public/8000/900/sol8986.html

 

 

Aaron

It depends on the number of environments and LTMs you are supporting. With under 10, it is a lot easier to stay current. When you go past 50 or 75 scattered all over on varying hardware it gets harder to be consistent. It also depends a lot on how F5 gives you an upgrade path. The jump from v9 to v10 basically took a hardware swap to execute anywhere except a lab environment (because they changed the way disk partitioning was handled, there was no fallback option once you applied v10).

 

 

The support center (like all vendors) will push you to the latest release and hot fix, but reality is a bit different at times. So don't let up on them when they say "there is no hot fix, you need to upgrade". Often, you'll be forced to employ a temporary work around that in due course becomes more permanent than temporary. (e.g. When config sync'ing from standby to active boxes under v10.1, pool members on the active box may randomly be marked as "session limit exceeded" with a hidden bit, so they will get no traffic even though they should ... Work around is to update the pool on the active box to clear the bit ... So we have a "touch.pl" script that touches all pools {many hundreds} on the active box after a config sync ... Of course, fixed in v10.2.1)

 

 

With virtually every release there are minor differences as that you can run into (v10.0 to v10.1 to v10.2 changed the way monitors worked with CRLF). READ THE RELEASE NOTES! But don't expect everything to be in there. So other than hot fixes, you really need to rollout new releases in an orderly manner (lab>dev>int>cert>prod) testing and watching along the way. Of course, if you are understaffed and not so risk adverse, you can go pretty quickly in the migration cycle. :-)

 

 

The more maturity and tooling you build on or for the platform, the more "migration maintenance burden" you must accept. For example, we parse the /config/bigip.conf file, and from 9.2 through to 10.2 there have been dramatic changes which we have had to accommodate for. The more iRules you write, the more maintenance you might enjoy. So like anything, if you don't exploit the features, upgrading is a breeze. If you really stretch the platform, you are stretching yourself as well.

 

 

You will really want to keep TMOS consistent across all as much as possible since the minor differences will drive you nuts keeping track and saying "we can't do the there because we are on an older version". In general, for my shop we apply version upgrades once a year, and at most one or two hot fixes a year (only if critical because of bugs we hit). We use Enterprise Manager which helps the migration effort.

 

 

Hope that helps!

Hi Ed, Posted By Ed Hammond on 08/13/2011 06:26 AM

 

... So we have a "touch.pl" script that touches all pools {many hundreds} on the active box after a config sync ...

 

What does "touches .. pools" mean?

 

R's, Alex

 

Are there any differences when upgrading minor versions as opposed to doing major versions (i.e. 10.x to 11.x)? Is the preparation any different?

 

procedure should be same (i.e. re-activate license, upgrade standby, failover, test test and test, upgrade active, failover back, test test and test).

 

minor version upgrade should have less issue. :-)