CONVERT C113 TO r 4000
Hello, I have a cluster of two 4000 units (HW Type C113) that I need to convert to r4000s. As the architecture has changed (F5OS-A and Tenant on the r4000) I am just trying to get a tenant up and running to start with. Our config is that we have a dedicated network for management connected to the MGMT port - and it is working fine. Our data network is running at 10GB and is connected to 5.0 using a SFP - the GUI shows it as UP. However, when I try to create a tenant and put it on that network, I cannot get to it at all. If I change the IPs in the tenant definition to one on the MGMT network then I can reach it. There is one port group - 8x10GB. I've created a VLAN that matches what the switch uses, and whether I set it as TAGGED or UNTAGGED I see nothing. I upgraded the unit (as they are new) to F5OS-A 1.8.,3, and have both BIGIP-151.10.8-0.0.30-ALL and BIGIP-17.5.1.3-0.0.19-ALL available for tenants. Thanks, Brian
Question about adding VEs to existing physical appliance device group without ASM licenses
We're in the process of migrating our old physical appliances to virtual appliances. I'm at the point of adding the new VEs to the existing device group. Our physical appliances have ASM licenses, but we don't have ASM licenses for the VEs yet. Management is still in discussion about on-prem licenses or distributed cloud services. When attempting to sync the new VEs, I get a sync error for 'ASM feature not licensed'. Do I need the ASM license to sync these together, or is there another method I can use? The new VEs aren't in the ASM device group. If I need the license, would a trial license work momentarily? If they decide to opt for the distributed cloud services, what are my next steps to getting these appliances synced?
BIG-IP i11000 – License compatibility with TMOS versions above 14.1.2 and Web GUI inaccessible
We are currently working on the recovery of an F5 BIG-IP i11000 appliance and would like guidance. The device boots normally and console access is available. However, the system remains in an INOPERATIVE state and the Web GUI is not accessible. MCP and related services do not fully initialize. A valid license file exists locally at /config/bigip.license. The license is bound to TMOS version 14.1.2. We understand that this license may only be valid for TMOS 14.1.2.x hotfix versions. The system currently has installation images for TMOS versions 15.x, 16.x, 17.x and later available. We would like clarification on the following points. Does a license bound to TMOS 14.1.2 support only version 14.1.2.x, or can it run versions above that? If the license is limited to 14.1.2.x, is reinstalling TMOS 14.1.2 on a new volume the correct recovery approach? Can an incompatible TMOS version cause the Web GUI to fail, MCP not to start correctly, and the system to remain in an INOPERATIVE state? Our goal is to restore full functionality while remaining compliant with the existing license, without performing an upgrade. Any guidance would be appreciated. Thank you. Lucas Felipe de Jesus Moura
Does XC DNS support health monitoring for CNAME records?
Hi everyone, I have a question regarding health monitor with CNAME records in the XC DNS Load Balancer. If I configure a Type A DNS Load Balancer in XC, I can attach a DNS pool with health monitor. However, if I configure a Type CNAME DNS Load Balancer with a CNAME-type pool, I can't select any health monitor for the CNAME pool. Our goal is to monitor a server service hosted in a third-party cloud and avoid the cloud edge service going down. Once the XC DNS detect a service failure, then it will reply with the fallback dns record (from another cloud service) to the user. Is there have any other way to monitor the health of CNAME pool ? Regards, Ding
rSeries Configuration Backup
Hi Guys, I am currently facing an issue with the F5OS backup process when a remote server is not available. My requirement is to take a configuration backup locally. At present, I am using the F5OS API to trigger the backup generation; however, in some cases—especially when the configuration size is large—the backup creation takes longer than expected or fails to complete before the subsequent download task is executed. This causes the overall workflow to fail. I believe this limitation could be addressed by allowing the remote host and remote path fields to be optional, so that backups can be generated and managed locally without dependency on an external server. This would improve reliability and flexibility, particularly for environments with large configurations or restricted infrastructure. - name: Create backup config and import it to remote server f5os_config_backup: name: foo remote_host: builds.mydomain.com remote_path: /uploads/upload.php timeout: 300 state: present Currenlty i am using below API Call. POST https://{{rseries_appliance1_ip}}/api/data/openconfig-system:system/f5-database:database/f5-database:config-backup { "f5-database:name": "F5OS-BACKUP-APPLIANCE1{{currentdate}}" } Pause 2-3mins is one of the option but Appreciate your ideas. Thanks
VIPRION B2250 to VELOS CX410 and BIG-IPr10900 migration
Hello Expert, I would like to migrate all configurations as-is from VIPRION B2250 to VELOS CX410 and BIG-IP r10900. Do you have any reference materials or step-by-step guides/documents that can help with this task? Any KDB articles or related documentation would also be very helpful. Kindly share them if available. Thank you.
