f5os
30 TopicsF5 BIG-IP SSL Orchestrator Layer 2 Services with rSeries & VELOS
Introduction F5 rSeries & VELOS are rearchitected, next-generation hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. F5 rSeries & VELOS are key components of the F5 Application Delivery and Security Platform (ADSP). rSeries & VELOS rely on a Kubernetes-based platform layer (F5OS) that is tightly integrated with F5 TMOS software. Going to a microservice-based platform layer allows rSeries & VELOS to provide additional functionality that was not possible in previous generations of F5 BIG-IP platforms. The introduction of a new tenant-based architecture changes many things, including how you configure BIG-IP. Some of these changes affect the network configuration for Inline Layer 2 Services. By default, BIG-IP tenants only have a small set of internal MAC addresses available to them. However, Layer 2 Services (or Bridging) require additional MAC addresses. You must assign an adequate number of MAC addresses to what is called a “MAC pool”. A single Layer 2 Service requires two unique MAC addresses. The MAC Pool must have sufficient MAC addresses based on the number of Layer 2 Services you need. The following KB articles contain additional information on configuring MAC Pools on a BIG-IP rSeries or VELOS platform: K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems Demo Video F5OS Configuration Let’s review the Network configuration on F5OS for a BIG-IP Tenant. From Network Settings select VLANs. Here you can see I have 6 Interfaces configured with VLANs. There’s a Lan VLAN for connectivity from the internal network to the BIG-IP. A Wan VLAN for connectivity from the BIG-IP to the internet. Then there are 4 “L2” VLANs configured to support two Inline Layer 2 Services with SSL Orchestrator. From the Interfaces screen you can associate the VLANs with the physical Interfaces. Next, allocate the VLANs to your BIG-IP Tenant. This is also where you configure the MAC Pool Size for your current BIG-IP Tenant. The MAC Pool can only be changed when the Tenant is not running. From Tenant Management > Tenant Deployments, you can stop the current Tenant if it is already running. Do this with caution during a change window or prior to deployment. Check the box next to the name of the Tenant you wish to configure, “big-ip-kevin” in this example. Then click Configure. Click OK to stop the Tenant When it’s stopped click the name of the Tenant to edit the configuration. Note the VLANs that are allocated to this BIG-IP Tenant: Find the section on MAC Data/MAC Block Size. Set the allocation to Small (8), Medium (16), or Large (32) depending upon your needs. I set mine to Medium. A Small allocation would be sufficient for this deployment but I want to leave room to add more Layer 2 Services in the future. Click Save & Close Click OK to update the configuration You can Deploy the Tenant now that the changes have been made Click OK to Deploy F5 BIG-IP Configuration Minimal configuration is needed on the BIG-IP since F5OS handles the underlying physical interfaces and VLANs. Check the status of the VLANs from Network > VLANs. From here we can see the VLAN configuration from F5OS is reflected in the BIG-IP. Define any Self IPs from Network > Self IPs Now we’re ready to configure SSL Orchestrator. In the interest of time, I will skip to the Network and Services configuration. From Services List click Add Service Double-click on Generic Inline Layer 2 Under Network Configuration click Add Select the L2 VLANs for this Inline L2 Service. Click Done. Click Add again and select the L2 VLANs for this Inline L2 Service. Click Done. It should look like the following: Click Save at the bottom For the Interception Rule select the Lan VLAN under Ingress Network and move it to the right. Click Save & Next at the bottom The Network configuration is now complete. SSL Orchestrator is configured with a Generic Inline Layer 2 Service that contains two Layer 2 “servers” Conclusion F5 rSeries & VELOS are hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. They are key components of the F5 Application Delivery and Security Platform (ADSP). In this article, you learned how to configure MAC Pools on rSeries and VELOS in order to create Layer 2 Inline Services with SSL orchestrator. Related Content K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems SSL Orchestrator CloudDocs: Creating an Inline Layer 2 Service F5 rSeries: Next-Generation Fully Automatable Hardware F5 VELOS: A Next-Generation Fully Automatable Platform
27Views0likes0CommentsF5OS VLAN naming length restrictions
I must notice, that there seems to be a length restriction when creating VLANs on F5OS. I'm allowed to enter long names on F5OS-level without any warnings or errors, but when assigning them to a tenant, the name within the tenant will be truncated if its longer than 31 characters. It looks like this, means there is a suffix in the format of "-T<VLAN-ID>.0" On F5OS-level it looks like this: Is this a normal behavior? Can or will this be fixed? And are there any other such restrictions for other configuration items? For your reference, we are running F5OS 1.8.3 and BIG-IP 17.5.1.3. Thank you! Regards, Stefan :)16Views0likes0CommentsSNMP Monitoring/OIDs for rSeries
I'm currently configuring the required OIDs for monitoring our new rSeries, but I'm wondering if the provided MIBs contain all information? I'm searching especially the values from the GUIs dashboard for Memory Utilization and Storage Utilization like in the following screenshot: Also the mentioned "Base OS Version" and "Service Version" details seems to be not part of the MIB. I only found it under the OID .1.3.6.1.2.1.1.1.0 -> SNMPv2-MIB::sysDescr.0 = STRING: F5 rSeries-r5600 : Linux 3.10.0-1160.119.1.f5.1.el7_8.x86_64 : Appliance services version 1.8.3-23453. Where does the GUI render these information from? Is it possible to poll these details via SNMP as well? Any more details would be very helpful! Thank you! Regards, Stefan :)52Views0likes2CommentsF5OS login with admin/root failed via console
Right now we have a new rSeries installed, which is currently only accessible via console cable. First login with default password was fine and changing password was also successful. Then I prepared the device with our default configuration including TACACS authentication. Also appliance-mode is enabled. All configurations were commited successfully. Now when I try to login in again, it failed with "login incorrect" error, but the password is definitely correct. What's the reason for this and how can I get access again? Or do I need to wait until the management port is up and TACACS server is reachable? Or how can I fully reset the device again? Power cycle and then interrupting the boot process? Is there a documentation available, how to perform this? Thank you! Regards, Stefan56Views0likes1CommentRemove alerts showing r-series LCD/Dashboard.
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Especially R5+ with 1.8.0+, may you will see unexpected "interface down" alerts. You could use this one-liner in rseries Bash. Hope it helps :p [root@appliance-1 ~]# date;docker exec system_manager /confd/scripts/f5_confd_run_cmd 'show system alarms alarm state | csv' Mon Sep 1 14:32:24 JST 2025 # show system alarms alarm state | csv ID,RESOURCE,SEVERITY,TEXT,TIME CREATED 263169,interface-1.0,WARNING,Interface down,2025-06-11 02:24:43.512626724 UTC 263169,interface-10.0,WARNING,Interface down,2025-06-11 02:24:43.514048068 UTC 263169,interface-2.0,WARNING,Interface down,2025-06-11 02:24:43.517935094 UTC 263169,interface-5.0,WARNING,Interface down,2025-06-11 02:24:43.526179871 UTC 263169,interface-6.0,WARNING,Interface down,2025-06-11 02:24:43.528668180 UTC 263169,interface-7.0,WARNING,Interface down,2025-06-11 02:24:43.530864483 UTC 263169,interface-8.0,WARNING,Interface down,2025-06-11 02:24:43.533197062 UTC 263169,interface-9.0,WARNING,Interface down,2025-06-11 02:24:43.535438297 UTC [root@appliance-1 ~]# date;docker exec system_manager /confd/scripts/f5_confd_run_cmd 'show system alarms alarm state | csv'|grep 263169|cut -f 2 -d ,|xargs -I{} docker exec alert-service /confd/test/sendAlert -i 263169 -r clear-all -s {} Mon Sep 1 14:33:27 JST 2025 Alert Sent Alert Sent Alert Sent Alert Sent Alert Sent Alert Sent Alert Sent Alert Sent [root@appliance-1 ~]# date;docker exec system_manager /confd/scripts/f5_confd_run_cmd 'show system alarms alarm state | csv' Mon Sep 1 14:33:54 JST 2025 # show system alarms alarm state | csv % No entries found. <---------- REMOVED. [root@appliance-1 ~]# Ideas came from: https://cdn.f5.com/product/bugtracker/ID1644293.html https://my.f5.com/manage/s/article/K000150155228Views2likes1CommentR2600 device and tenant/partition configuration
Hello, I'm working with configuration on r2600 where is one tenant with multiple vlans. On tenant perspective I want to add each vlan to specific partition. How to do this in correct way for rSeries? There is a bug http://cdn.f5.com/product/bugtracker/ID1231889.html which says that all vlans need to be in Common partition. On vCMP or bare metal there was an option to create vlan in partition, add it to route domain and then configure all other things (IP, routes, etc). So - what is proper way? Where can I find F5 document?678Views0likes14CommentsCredentialed Scanning - F5OS - Rseries
After solving the remote authentication issue previously with F5OS. My next question is related to credentialed scanning on R series appliances running F5OS. The tenable agent logs in via SSH and tries to run commands in the shell to pull system information. This has never been on issues on the iseries appliances and BIG-IP guests as they allow uses directly to the shell upon login. All linux commands run as intended. F5OS is a new beast for me to understand as it dumps you into its own OS. The shell is protected and only root at the local level is allowed access to the linux shell. This is the issue I face with credentialed scanning. Authentication works perfectly fine but the ability to run the proper commands at the appropriate level seems to be locked and it doesn't appear I can grant shell access to remote accounts. Anyone have any experience running authenticated scans on their rseries appliances with f50S?267Views0likes1CommentAutomate F5OS license activation using ansible
Hello, working to automate the process of licensing the F5OS platform (r-series) using ansible but with the version we have in our production we cannot use F5OS ansible galaxy modules so we are using ansible uri module to get dossier from F5OS r-series system by API. any-leads on how to achieve this license activation which requires dossier signing from "https://activate.f5.com/license/dossier.jsp" or if anyone can lead me to how the payload to this site should look like ?Solved144Views0likes4CommentsF5OS Tenant Radius Issues
Hello All, Finished deploying new R-Series equipment to replace some i-Series. Working through some issues that I hope there is an easier solution for in regards to radius authentication on tenants/guests running on my new appliances. I cannot seem to get the tenants running on my r-series appliances to use the Mgmt IP address for radius authentication. They seem to want to use a self-ip that is within the network on the gateway for the default routing domain. For additional information the configuration on the i-series were ported over via UCS files to my r-series tenants. They're near identical besides new MGMT ips. Quick breakdown of what works for Radius R-Series Appliance (F5OS) - MGMT 1.1.1.1 <---Radius auth works using MGMT IP - Makes sense, no virtual routers - BIG-IP Tenant - MGMT 1.1.1.2 <-----Radius fails (Uses self-ip 10.10.10.10) - BIG-IP Tenant - MGMT 1.1.1.3 <-----Radius fails (Uses self-ip 23.23.23.23) - BIG-IP Tenant - MGMT 1.1.1.4 <-----Radius fails (Uses self-ip 5.5.5.5) The self IPs are all on different networks that serve different purposes on different security zones on my firewall. The solution as it stands now is allow the specific reporting self-ips to reach my radius server. I'd rather not do that if I can find a way to force to tenants to use their mgmt IP.Solved87Views0likes2Comments