rSeries clean shut down
I am remotely managing some rSeries appliances for a customer. Two of the appliances must be physically moved soon. I have found KB articles telling me what NOT to do when powering off a rSeries appliance, but I have not found a document with a recommended shut down process. Naturally, I will remotely set all tenants from Deployed to Provisioned first. Engineers on site can will have hands on the appliances. Which method will provide the cleanest shut down for F5OS: console in to AOM and select "P" option, or use the LCD (I assume there is a "Power Off" option)? Or is there is another method? Thank you.F5 Distributed Cloud Customer Edge on F5 rSeries – Reference Architecture
Traditionally, to advertise an application to the internet or to connect applications across multi-cloud environments enterprises must configure and manage multiple networking and security devices from different vendors in the DMZ of the data center. CE on F5 rSeries is a single vendor, converged solution for all enterprise multi-cloud application connectivity and security needs.F5OS support for TACACS+ over CLI
We ran into issues deploying rSeries and VELOS platforms on the network at our company using a custom form of TACACS+. Our implementation allows for application-specific domains with unique ports and keys. We had issues with it until we added the attribute value pairs to the TACACS+ domain profiles: Admin (unlimited_config): F5-F5OS-UID=1001 F5-F5OS-GID=9000 Operator (unlimited_enable): F5-F5OS-UID=1001 F5-F5OS-GID=9001 This change resolved the access issues via GUIand we are able to access using our TACACS+ credentials, but it does NOT work via CLI for access using the same credentials. We already have a case out to F5 about this, but I was wondering if anyone else is experiencing the same implementation challenge on accessing CLI using TACACS+.
rSeries and tenant upgrades
I manage four r5900 appliances, hosting 16 tenants. The appliances are running F5OS-A 1.5.0; the tenants all run BIG-IP 15.1.10.2. We all know, of course, that the most recent QSN was released today. Normally, I'd upgrade everything to the latest version. However, where F5OS-A 1.7.0 is concerned, there is a "Known Issue" that raises a big red flag. In the release notes, 1380705-1 : BIG-IP tenant is stuck during boot up after doing tenant upgrade from 15.1.x to 17.1.x The issue description says this will not happen with every tenant. But it just has to happen once to ruin a day, right? In the past, I have always upgraded the appliance OS before upgrading the tenants. That just seemed to make sense. Given this issue, though, I am considering upgrading all of the tenants to BIG-IP 17.1.1.3 first, then upgrading the appliances to F5OS-A 1.7.0. Does anybody know of any pitfalls to this approach?
F5 Rseries HA
Dears, I know that there is no HA between rseries appliance, and the HA will be configured between tenants on each appliance, my question her about when i prepare to configure HA between Tenant so before making this i will configure the network setting and VLAN on F5OS so I will need a dedicated interface and HA VLAN between two tenants on each appliance so what is the next step after I configured the network setting on Appliance (F5OS), and what i need to confirm on the network setting that i will configure on each appliance (F5OS) to make HA between the two tenants
R-Series Appliance No GUI ( host system gui ) after 1.7.0 upgrade
After running the 1.7.0 upgrade for the r-series 5000 appliance - the login screen does not display in a browsers. Admin and Root passwords are as they were before upgrade. mgmt-ip settings are the same. Device can ping it's upstream router in the mgmt-ip network. the device mgmt-ip address does not reply to ping ( or any request [ ssh, http...]) from the console I can see the whole running config - it is the same as before the upgrade Any help is appreciated, Dave Mehlberg
