Forum Discussion

Brett_11768's avatar
Brett_11768
Icon for Nimbostratus rankNimbostratus
Aug 05, 2011

Best Practice - Apply f5 updates and hotfixes

We have recently purchased several LTM's both pysical 6900's and VE's. We would like to impliment an update and hotfix policy using Industry best practices.

 

 

I figured this is as good a place to find out how the BIG-IP's are handled then any.

 

 

Please, if you dont mind, could you share your insight and experiences with the f5 LTM updates and hotfixes and how your company (no need to mention the company name) handles both?

 

 

What, if any, policy do you have regarding these?

 

 

Thank you very much,

 

 

Brett
  • 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

     

  • I would like to add a question to this as well when dealing with Best Practices. I have two LTMs in an Active-Standby pair running 11.2. When I run iHealth on my QKview files, there are fixes that would be implemented with 11.4 and some with 11.5.1. 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? Thanks in advance!

     

  • 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. :-)