F5 Device Certificate renewal process on Active and Standby devices
Hi Team, The SSL certificates on the load balancers we manage (both Active and Passive) are set to expire in July. Could you please share the recommended steps to renew them correctly and ensure a smooth implementation without any service impact? Certificate Expiry Details Active Load Balancer: Expires on July 26th, 2025 Passive Load Balancer: Expires on July 27th, 2025 Please note that in our case, both load balancers are using different certificates.Issue with 2 parallel F5 clusters
Hello everybody and first of all thank you for taking the time to read my issue! The issue that I have is in regards to a migration We have a productive F5 BigIP cluster (Active/Standby), let's call this "Old F5", which has a lot of Virtual Servers in partitions, with specific pools and monitors for each application/service This device also has 2 Vlans, internal (vlan11) and external (vlan10), and 2 interfaces in an LACP that it's tagged on both Vlans, and it's connected to the same one leg to a Cisco APIC It has 2 Self IP addresses (one for each Vlan): 10.10.10.1-Vlan "external" 10.20.20.1-Vlan "internal" (numbers are just for example) It also has 4 Floating IP address (2 for each Vlan) with 2 traffic groups: 10.10.10.2-Vlan external traffic group 1 10.10.10.3-Vlan external traffic group 2 10.20.20.2-Vlan internal traffic group 1 10.20.20.3-Vlan internal traffic group 2 This device (cluster) has to be replaced by another F5 BigIP cluster (let's call this new F5), this device is an identical copy to the old F5 (the config was took from the old one and imported to the new one), meaning same Vlans, monitors, pools, VServers IP addresses etc At the moment this one has the 2 interfaces disabled and a blackhole default reject route set up in order to not interfere with the old F5 which is the productive one. The ideea is to configure the new F5 device with IP addresses from the same subnet (for example 10.10.10.5), and disable all the Virtual Servers so it doesn't handle traffic (the nodes, monitors, pools stay up on both devices), and have the 2 F5 devices, old and new, running in parallel and then move the Virtual servers one by one by just disabling the VS on the old F5 and enable it on the new F5. At this point we also remove the blackhole route, configure the correct default static route (the same which is on the old F5), and enable the interfaces This sounded and looked good, on the new F5 the nodes, pools are green and the Virtual servers are disabled as expected. On the old productive F5 everything is up and green BUT if I try to reach one of the Virtual servers, either by the Virtual IP address or hostname the attempt just times out without any response (if I try to telnet to the VS on port 443 it connects meaning that the old F5 accepts the traffic) I tried to disable on the new F5 also the nodes but still the same behaviour, the only to get it back to work is to disable the interfaces on the new F5 and add the default reject blackhole route. This is not how I imagined it to work, in my mind I was expecting that the old F5 will work as normal, and the new F5 device will see the nodes and pools up (confirming good communication) but don't handle any traffic regarding the Virtual servers because they are disabled. Does anyone have any idea what is causing this issue, why when both F5 devices are up in parallel, the connection to the Virtual server through the old productive F5 times out while that F5 sees both the pools and Virtual servers as up and running. Thank you in advance!
After upgrading from PeopleTools 8.59.11 to 8.61.11 F5 APM is not rewriting the internal URLs
After upgrading from PeopleTools 8.59.09 to 8.61.11 F5 APM is not rewriting all the internal urls for PeopleSoft Portal Application that also has Home page tiles from HRMS 9.2. Clicking on these tiles takes us to Internal URL instead of F5 externally resolvable url. How to troubleshoot this. I have a case opened with F5 support, but interested in any one else using F5 APM for peoplesoft and seeing similar error.
F5 CIS -> NGINX Plus Ingress Controller Integration
Hi, I'm using F5 BIG-IP and NGINX Plus Ingress Controller (NPIC) integrated via IngressLink. While attempting to forward the client IP and port by enabling the Proxy Protocol, we encountered the following issue and are seeking assistance. Configuration BIG-IP: Proxy Protocol enabled via iRule NPIC: Proxy Protocol enabled by adding proxy-protocol: "true" in the ConfigMap during deployment Issue When the Proxy Protocol setting is added to the NPIC ConfigMap, the integration with BIG-IP breaks, and routing to pods through NPIC fails. If this setting is removed, IngressLink functions normally: a Virtual Server is automatically created in the BIG-IP GUI, and responses through the NPIC path work correctly. However, in this case, direct requests to the BIG-IP Virtual Server IP fail. In other words, while F5 CIS installation and IngressLink integration are partially functioning, access via the BIG-IP Virtual Server IP completely fails. If anyone has experienced a similar issue or can offer insights into the cause and how to resolve it, your advice would be greatly appreciated. Any debugging tips or relevant documentation would also be a great help. Thank you.
Problem with sending BotDefense logs to remote server
Hi, I have a question about sending logs to a remote log-management server. When I want to create a bot defense logging profile, it doesn't offer me a remote server in the config menu, but only a local storage, am I doing something wrong? I'm already using a remote server for ASM.. thank you for any advice ===================== I set the same for ASM and the option is already there - I use it fine Bot Defense - creating new Logging Profile ..to see that the option to select a defined Remote Publisher location is missing
