F5 Migration between DCs
I have couple of F5's in a data center and want to migrate to single F5 in different DC. All the F5 configurations including the VIP's, Profile, certificate needs to be consolidated into single F5. What approach need to be taken to migrate the config's. Would GUI or CLI migration approach or advise the best way forward. Any help Appreciated.
Multiple two-way SSL client Profiles - possible?
Hello To simply describe my situation: multiple end-users with client SSL certs generated by different CAs (down to rootCAs, which are different) one VIP to server them all and perform two-way SSL with "peer-cert-mode required" in the client-ssl profile. the FQDN for the VIP is the same for all end-users, so the server-side certificate is the same for all of them platform used: redundant BigIP LTM i4800 running v17 My initial reaction was to "bundle" all the different CAs into one file and use it as such under the client-ssl profile (it works) But... I was thinking if I could create and attach to the VIP multiple client-ssl profiles for each of the CAs (each with its own defined ca-file), using the same server-side certificate (with at least one of these profiles to have the sni-default set to true), and also keeping the "peer-cert mode required" for each of these distinct client-ssl profiles. Would this even be possible, what would this break or what gotchas I should be aware of,? ltm profile client-ssl mTLS-profile1 { ca-file firstCA.crt cert serverSide.crt chain serverSide-chain.crt key serverSide.key peer-cert-mode require retain-certificate false sni-default true } ltm profile client-ssl mTLS-profile2 { ca-file secondCA.crt cert serverSide.crt chain serverSide-chain.crt key serverSide.key peer-cert-mode require retain-certificate false sni-default false } ltm profile client-ssl mTLS-profile3 { ca-file thirdCA.crt cert serverSide.crt chain serverSide-chain.crt key serverSide.key peer-cert-mode require retain-certificate false sni-default false } ltm virtual server-fqdn-vip { ... profiles { mTLS-profile1 { context clientside } mTLS-profile2 { context clientside } mTLS-profile3 { context clientside } } ... } Thank you in advance Adrian
R5600 LAG question
Is is recommended to add ports into LAG from different pipelines? If we configure a LAG with port 3 from pipeline 1 and port 7 from pipeline 2. What will happen if port 3 from pipeline 1 goes down? Would it impact the traffic? I am trying to understand pros and cons of adding ports into LAG from same pipeline and different pipelines. I could not find a clear F5 reference document or SK article.
APM Portal access and ECMAScript compatibility
I notice that ECMAScript (ES13) is supported as stated in version 21.1 release note https://techdocs.f5.com/en-us/bigip-21-1-0/big-ip-release-notes/big-ip-new-features.html#portal-access-ecmascript-es13-support-for-modern-javascript-applications As I know, latest version in 17.1 can also use the latest cache-fm-Modern.js file. Does it imply that latest version in 17.1, say 17.1.3.2, also support ECMAScript (ES13)? https://my.f5.com/manage/s/article/K000148786
APM Policy Migration Between Standalone TMOS 17.1.3 Systems
Hi everyone, We're migrating a single production APM policy from an i4600 to an r4600 appliance. Both systems are running TMOS 17.1.3, and the new appliance will not be part of the existing DSC cluster. We tried exporting/importing only the APM policy, but the import fails because referenced objects are missing on the target system. A full UCS restore would also migrate many unused objects that we don't want. Is there a supported way to: Analyze an APM policy and list all required dependencies before import? Export/import only the APM Customization GUI (HTML/CSS/JavaScript templates)? Migrate a single APM policy without restoring the entire APM configuration? Any recommended best practices for this scenario would be appreciated. Thanks in advanced!F5 CIS applying iRule from one VirtualServer definition to another
Hi everyone, I am experiencing a strange behavior with F5 Container Ingress Services (CIS) where an iRule defined in one VirtualServer resource is being applied to a different VirtualServer on BIG-IP. The setup: I have two VirtualServer manifests sharing the same IP address and partition, but serving different ports — one for HTTPS (443) and one for HTTP (80). The HTTP VirtualServer (cis-dev-80) has the iRule /Common/https-301-redirect explicitly defined, which is expected — it redirects HTTP traffic to HTTPS. I'm not using the parameter httpTraffic because I need the http status code 301 instead of 302. The HTTPS VirtualServer (cis-dev-443) has no iRules defined in its manifest. # cis-dev-443 — no iRules defined spec: virtualServer HTTPSPort: 443 tlsProfileName:dev-tls-profile ... # cis-dev-80 — iRule intentionally defined here only spec: virtualServerHTTPPort: 80 iRules: - /Common/https-301-redirect ... The problem: After CIS reconciles, BIG-IP shows the iRule /Common/https-301-redirect attached to both virtual servers — including cis-dev-443, which should not have it. This causes HTTPS traffic to be redirected back to HTTPS in a loop. Questions: Has anyone else encountered this behavior? Does this needs a different configuration? Any help or pointers to related issues or F5 support articles would be appreciated. Environment: CIS version: 2.20.3 AS3 version: 3.55.0 Kubernetes version: v1.22 Thanks in advanceMigration doubt
Scenario is: 4 serie i2600 forming sync-group GTM. Being two diferent cluster HA active/standby LTM. First ill change one pair and another day the another. My idea for migrating an LTM/GTM pair from the iSeries platform to the rSeries platform is as follows: We used same cables from i series and same names and IPs to do it easier to customer First, I disconnect all the cables from the standby iSeries unit. The active iSeries unit will remain active in standalone mode. Next, I connect the interfaces used for the synchronization and failover network from both iSeries appliances to the new rSeries appliances. The HA pair has already been configured on the new rSeries units, so one will be active and the other will be in standby. Once the standby rSeries node is in place, I connect all the service cables to it. After all the service cables have been connected and I have verified that everything looks correct (ARP entries, pools, etc.), I proceed to run the bigip_add and gtm_add commands against the active iSeries node. It is important to note that the iSeries and rSeries appliances will never form an HA cluster with each other. After running both commands, I verify that everything is operating correctly before forcing the active iSeries node offline and allowing the rSeries node to become active. If I face any issues while running the bigip_add or gtm_add commands, since the new rSeries nodes use the same hostnames and IP addresses as the previous iSeries appliances, I may need to remove the trusted certificates associated with the old appliances from the other BIG-IP devices before attempting the commands again. Anything to keep in mind? or any potencial issie doing like that?? Would it be necessary or recommended to temporarily take the GTM cluster being migrated out of service, or is there no significant risk in keeping it operational? Its my first GTM migration in a bit lost.Doubt adding F5 in sync-group
I need to replace an LTM-GTM cluster. I will replace the standby node first. The sync-group are 4 devices. My question is about adding it to the GTM sync group. Should I run only the gtm_add command, or do I also need to run the bigip_add command? I'm not sure whether joining a sync group requires both commands or just one of them. I'd also like to know where each command should be executed. I understand that gtm_add is run on the new node being added, but is bigip_add also run on the new node? how can i delete the old nodes for the sync-group when its donde the change?OSPF Route Advertisement for Floating Self IP in Active/Standby HA
Hi all In an Active/Standby HA deployment using OSPF network statements to advertise connected VLAN prefixes, both BIG-IPs advertise the same connected subnet. When the floating self IP is used as the server default gateway and also selected by SNAT Automap, how is traffic redirected to the new Active after failover if the old Active continues advertising the connected prefix with a lower OSPF cost? Is there any recommended design or best practice from F5?
