F5 platform EoSD and Software EoSD is different. Which one need to use?
Hi We use F5 2000s with version 15.1.x From platform EoSD, It's already expired but from software EoSD. it's still available question is Which one should I use? If i use WAF and I believe attack signature will release if EoSD is still available...... question is right now will my attack signature still update? 2 what is different?Error when downloading from downloads.f5.com
I was given a task to update our F5 Viprion's software version this weekend. However, upon checking for the latest software version on F5's downloads website, I came across an error which is: Export Compliance Check - Failure All downloadable files are presented with this error when I tried to download.F5 Software Upgrade (14.1.0.6) UNABLE TO INSTALL IMAGE
Hey Guys!!!!! So I have done many software code upgrades in my life but I am having issues while upgrading from 12.1.4 to 14.1.0.6 & I am wondering if you guys could possibly help me. I have tried pulling the image via SCP from my desktop to the F5, tried using Curl and pulling the image from the F5, & also tried to import via GUI. When pulling the image I can see the ISO file under the intended directory (/shared/images) but I can't seem to figure out why the BIP-IP won't let me install the new ISO file I have pulled & ran a MD5 checksum on. Please any suggestions are appreciated. # Successful MD5 Checksum [root@1034180-O3-F5EC:Active:Standalone] images # md5sum --check BIGIP-14.1.0.6-0.0.9.iso.md5 BIGIP-14.1.0.6-0.0.9.iso: OK # Pulled Image [root@1034180-O3-F5EC:Active:Standalone] images # ls | grep 14.1.0.6 BIGIP-14.1.0.6-0.0.9.iso BIGIP-14.1.0.6-0.0.9.iso.md5 # Not able to install new Image (Only showing current ISO Image but no 14.1.0.6 image....) root@(1034180-O3-F5EC)(cfg-sync Standalone)(Active)(/Common)(tmos)# install sys software image Options: create-volume Configuration Items: BIGIP-12.1.4.0.0.8.iso Cheers, Chase Woodard Mantra Networking Consulting | Rackspace Hosting
Installation of 14.1.2.6 fails
Hi All, We have two customers which are trying to install 14.1.2.6 on a partition prior to upgrade from 14.1.2.5. But the installation fails right away with the following erros in /var/log/liveinstall.log *** Live install start at 2020/07/06 18:08:23 *** info: tm_install::BootLoader::BootLoader_mboot_sync_from_old_conf -- Configurations match. info: Daemon-driven execution indicated by ENV variable. info: Repository tm_install version/release is 2.12.0.6/4.0 info: System tm_install version/release is 2.12.0.6/4.0 info: Platform id is C117 /dev/sdd: No medium found sfdisk: cannot open /dev/sdd for reading info: Basic disk format validation passed. info: >++++ result: info: mount: /dev/mapper/vg--db--sda-set.2._usr is already mounted or /mnt/tm_install/30655.GyI1Fy/usr busy info: /dev/mapper/vg--db--sda-set.2._usr is already mounted on /usr info: /dev/mapper/vg--db--sda-set.2._usr is already mounted on /opt/.sdm/usr info: /dev/mapper/vg--db--sda-set.2._usr is already mounted on /opt/.sdm/lib info: /dev/mapper/vg--db--sda-set.2._usr is already mounted on /opt/.sdm/lib64 info: >---- error: status 8192 returned by command: mount -oro /dev/vg-db-sda/set.2._usr /mnt/tm_install/30655.GyI1Fy/usr 2>/dev/null info: >++++ result: info: umount: /mnt/tm_install/30655.GyI1Fy/shared: not mounted info: >---- error: status 8192 returned by command: umount /mnt/tm_install/30655.GyI1Fy/shared Terminal error: Could not access configuration source; sda, 2 *** Live install end at 2020/07/06 18:08:27: failed (return code 2) *** I could not find anything related in the F5 knowledge base articles. Customer already tried to delete an create a partition again, but this did not solve the issue. Anyone else facing the same issue? Anyone has a solution? Regards, Martijn
Software Installation aborting at about 97%
Hello, I want to update a Virtual F5 from 14.1.2.3to 14.1.2.4. but when install-process reaches about 97% the GUI reloads. I've tried it from the CLI: the same, I see the Messages about restarting cbrd, apm_websso0, dynconfd, ... the diskspace should be fine: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--sda-set.2.root 419M 78M 315M 20% / devtmpfs 3.9G 4.0K 3.9G 1% /dev tmpfs 3.9G 2.3M 3.9G 1% /dev/shm tmpfs 3.9G 2.2M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/mapper/vg--db--sda-set.2._usr 5.0G 4.0G 761M 85% /usr /dev/mapper/vg--db--sda-set.2._config 2.1G 1.4G 626M 69% /config /dev/mapper/vg--db--sda-set.2._var 2.9G 1.3G 1.5G 47% /var none 3.9G 19M 3.9G 1% /var/tmstat prompt 4.0M 28K 4.0M 1% /var/prompt /dev/mapper/vg--db--sda-dat.appdata 25G 961M 23G 5% /appdata /dev/mapper/vg--db--sda-dat.share 20G 5.9G 13G 32% /shared none 3.9G 30M 3.9G 1% /shared/rrd.1.2 /dev/mapper/vg--db--sda-dat.log 2.9G 180M 2.6G 7% /var/log none 3.9G 0 3.9G 0% /var/loipc /dev/loop0 298M 298M 0 100% /var/apm/mount/apmclients-7182.2019.923.1603-4727.0.iso any Ideas, where to look for? another virtual F5 updatet the same Version without problems
Software upgrade Host Hypervisor and VCMP's planning
Hi All, I am working for a company which asked me to plan a software upgrade of their Big-IP Platform 10250v (D113) which is a cluster of 2 devices in Active/Passive mode. They have the Host running on release of v13.1.0 (released 19/12/2017) and their VCMP's (5 in total) in a mix of v13.1.0.8 (released 26/06/2018) and v14.1.2.2 (released 14/11/2019). I looked up the details and at this moment their platform is as of 21st of April 2020 in EoNSS State which means no upgrade to v16x anymore in the near future but v15.1.x is supported. So far not a problem and I proposed to bring the full cluster to the latest release of v14.1.x first and in a next phase to v15.1.x so they can benefit of the latest security stuff and on long term support release to be compatible as long as possible on this platform (they wan't to look for a replacement in 2022 but not sooner). Now their remark was that the HostHypervisoris not parsing any traffic and only hosting the VCMP's so they don't see the need on upgrading that platform and only want to focus on the VCMP's. In the documentation I found it's perfectly OK to do this as long as you're running anything from v11.4.1 HF3 - v15.1.0.11.3.0 on the Host and same for the Guest. F5 however recommends running the most recent version on both Host and VCMP. So my question is now is if anyone has an ideahow I could"convince/proof"that the Host upgrade is preferred as well? In the release notes there is the huge list of improvements but nothing specific in regards Host vs VCMP. For now I plan to do the VCMP's only but would like to do the Host as well.
Understanding LTM folder in configuration
https://support.f5.com/kb/en-us/solutions/public/13000/600/sol13649.html A Sync-Only device group must be associated with a folder other than the / or /Common folders. Sometimes it's confusing to understand the folder concept in LTM. It seems related to partition and device group. Can anyone help me to understand this ?F5 update check issue
We have "Update check" Enabled on F5 and its weekly schedule but in same page it is showing. Why it is saying last update was on 2014? Last Checked Version11.6.0.0.0.401 Latest Update CheckFri Dec 26 04:02:09 EST 2014 (Automatic) Available UpdateSoftware is up-to-date. Available HotfixHotfix-BIGIP-11.6.0.2.0.405-HF2 iso installation file Geo Location Software Version Last Checked Version1.0.1-20140703.99.0 Latest Update CheckFri Dec 26 04:02:09 EST 2014 (Automatic) Available Updateip-geolocation-1.0.1-20141204.119.0 End User Diagnostics (EUD) Software Version Last Checked Version2.6.0.8.0 Latest Update CheckFri Dec 26 04:02:09 EST 2014 (Automatic) Available UpdateEUD_T-2.6.0.9.0.isoWhy you should not use clustering to scale an application
It is often the case that application server clustering and load-balancing are mistakenly believed to be the same thing. They are not. While server clustering does provide rudimentary load-balancing functionality, it does a better job of providing basic fail-over and availability assurance than it does load-balancing. In fact, load balancing has effectively been overtaken by application delivery, which builds on load balancing but is much, much more than that today. Clustering essentially turns one instance of an application server into a controlling node, a proxy of sorts, through which requests are funneled and then distributed amongst several instances of application servers. Sounds like load-balancing, on the surface, but digging deeper will reveal there are many reasons why application server clustering will not support long-term scalability and efficiency. Aside from the obvious hardware accelerated functions provided by an application delivery controller (a.k.a. modern load balancer), there are a number of other reasons to look to options other than application server clustering when you are trying to build out a scalable, efficient application architecture. Here are the top three reasons you should reconsider (or not consider in the first place) a scalability solution centered around application server clustering technology. JUST LOAD BALANCING ISN'T EFFICIENT Simple load balancing is not efficient. It uses industry standard algorithms ultimately derived from network load balancing to distribute requests across a pool (or farm) of servers. Those algorithms don't take into consideration a wide variety of factors that can affect not only capacity of an application but the performance of an application. There is no intelligence, no real awareness of the application in an application server clustering architecture and thus the solution does not utilize resources in a way that squeezes out as much capacity and performance from applications. Application server clustering also lacks many of the features available in today's application delivery controllers that enhance the efficiency of servers and supporting infrastructure. Optimization of core protocols and reuse of connections can dramatically increase the efficiency and performance of applications and neither option is available in application server clustering solutions. That's because the application server clustering solution relies on the same core protocol stack (TCP/IP) as the application server and operating system, and neither are optimized for scalability. LACK OF SUPPORT FOR CLOUD COMPUTING and VIRTUALIZED ENVIRONMENTS Dynamism is the ability of your application and network infrastructure to handle the expansion and contraction of applications in an on-demand environment. If you're considering building your own private cloud computing environment and taking advantage of the latest style of computing, you'll want to consider options other than application server clustering to serve as your '"control node". Aside from failing to exhibit the four core properties necessary in a cloud computing infrastructure (transparency, scalability, security, and application intelligence), application server clustering itself is not designed to handle a fluid application infrastructure. Like early load balancers, it expects to manage a number of servers in a farm and that the number (and location) will remain the same. Its configuration is static, not dynamic, and it is not well-suited to automatically adjusting to changing infrastructure conditions in the data center. Virtualization initiatives put similar demands on controlling solutions like application delivery and application server cluster controllers; demands that cannot be met by application server cluster controllers due to their static configuration nature. IT ISN'T SCALABLE When it comes down to it there is only one reason you really need to stay away from application server clustering as a mechanism for scaling your applications: application server clustering doesn't scale well. Think about it this way, you are trying to scale out an application by taking an instance of the application server (the one you need to scale, by the way) and turning it into a controlling node. While the application server clustering functionality is likely capable of supporting twice the number of concurrent connections as a single instance running an application, it isn't likely to be able to handle three or four times that number. You are still limited by the software, by the operating system, and by the hardware capabilities of the server on which the clustering solution is deployed. The number of web sites that are static and do not involve dynamic components served from application servers of some kind are dwindling. Most sites recognize the impact of Web 2.0 on their customer base and necessarily include dynamic content as the primary source of web site content. That means they're trying to serve a high number of concurrent customers on traditional application server technology solutions. Scaling those applications is an important part of deploying a site today, both to ensure availability and to meet increasingly demanding performance requirements. Application server clustering technology wasn't designed for this kind of scalability, and there's a reason that folks like Microsoft, Oracle/BEA, and IBM partner with hardware application delivery solution providers: they know that in order to truly scale an application, you're going to need a hardware-based solution. Application server vendors build application servers that are focused on building, deploying, and serving up rich, robust applications. And every one of them has said in the past, "Use a hardware load balancer to scale." If the recommendation of your application server vendor isn't enough to convince you that application server clustering isn't the right choice for scaling web applications, I don't know what is.
