Extend capacity of the blade on Velos
Hello everyone, for a customer I need to buy another blade for Velos system that permit to extend the capacity of the disk, at the moment i have cofigured a single blade that is it used at 85%, the target is to buy another one, for having a logical drive that is thwe sum of both hard drive. Is it possible to do it ? I have read documentations about it but, i have not found the correct information, in addition you have to say that now, in the first balde there are 9 Tenants who are working in a production environment, so that, the goal is activities, for add the new blade, should not have impacts on the production. Many thanks , in advanced, everyone. Awaiting news,
How to Use ACME with BIG-IP
We are terminating SSL on BIG-IP and considering using KOJOT-ACME for automatic certificate renewal. Could you explain the steps, configuration, and requirements (such as version or model) for using ACME with BIG-IP? We are struggling because we don’t know exactly what needs to be done on the BIG-IP side.TMOS 21.0.0 compatibility
Hello. The BigIP release matrix and the The F5 hardware/software compatibility matrix documents explicitely declare ix000 hardware serie as not compatible with TMOS 21.0.0. However, IHealth promotes it as an upgrade option for our i5600 hardware, and this uncompatibility doesn't match my own comprehension of "Hardware End of New Software Support (EoNSS)" limit, which is not reached yet for this platform until Jan 01 2026. Does that means TMOS 21.0.0 is supposed to be made available later for this hardware, or just that iHealth has a bug, and that I missed something in the definition of EoNSS ? Regards.
/mgmt/toc - not possible to launch rest api rest browser
Hi, could you help please on how to kick off the api rest browser? attaching below the internals Thank in advance after providing my admin credentials, the follwoing response is returned { "code": 400, "message": "URI path /mgmt/logmein.html not registered. Please verify URI is supported and wait for /available suffix to be responsive.", "referer": "https://1.2.3.4/mgmt/toc", "restOperationId": 13525870, "kind": ":resterrorresponse" } Platform ID Z101 Platform Name BIG-IP Tenant Software Version BIG-IP v17.1.3 (Build 0.20.11) Bundle, r5600
High availability Blade
Hello everyone, I would like to know if is possible to configuire high availability on two Blade BX110. At the moment I have only one blade where there are all Tenants and, the capacity of using it, is 85% . The customer want to buy another Blade but, it wants that for every Velos, te two blades build a unique partition. Is it possible to do it by considering that in one blade there are all Tenants in a production environment ? Which type of impact there will be ? To sum up could i configure both blade in high availability with no run the risk to block the services of the Tenants ? I have read that is possible to make a setup of the blades but is not mentioned that this activity could provide, if on the one are presents Tenants, to reset the configuration. Many thanks in advanced for your help. Awaiting your news,Failed to execute iptable cmd: ," CMD="iptables -A SSH_ALLOW_RULES error
Hi Mates, After upgrading rseries F5 OS to 1.5.4, I observed the below error and I am unable to do SSH for my F5 OS machine version 1.5.4 from the network: 10.54.7.0/24. Rest all the networks are working fine and we are able to do SSH to the same F5 OS machine. Is it something that device was unable to update this entry into iptables. Do we have to manually re-configure this rule? ys-host-config[11678]: priority="Err" version=1.0 msgid=0x7001000000000062 msg="Failed to execute iptable cmd: ," CMD="iptables -A SSH_ALLOW_RULES -s 10.54.7.0/24 -p tcp -m state --state NEW --dport 22 -j ACCEPT -w &>/dev/null" ERR="EXITINFO: 4".
XC Distributed Cloud and how to keep the Source IP from changing with customer edges(CE)!
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Old applications sometimes do not accept a different IP address to be used by the clients during the session/connection. How can make certain the IP stays the same for a client? The best will always be the application to stop tracking users based on something primitive as an ip address and sometimes the issue is in the Load Balancer or ADC after the XC RE and then if the persistence is based on source IP address on the ADC to be changed in case it is BIG-IP to Cookie or Universal or SSL session based if the Load Balancer is doing no decryption and it is just TCP/UDP layer . As an XC Regional Edge (RE) has many ip addresses it can connect to the origin servers adding a CE for the legacy apps is a good option to keep the source IP from changing for the same client HTTP requests during the session/transaction. Before going through this article I recommend reading the links below: F5 Distributed Cloud – CE High Availability Options: A Comparative Exploration | DevCentral F5 Distributed Cloud - Customer Edge | F5 Distributed Cloud Technical Knowledge Create Two Node HA Infrastructure for Load Balancing Using Virtual Sites with Customer Edges | F5 Distributed Cloud Technical Knowledge RE to CE cluster of 3 nodes The new SNAT prefix option under the origin pool allows no mater what CE connects to the origin pool the same IP address to be seen by the origin. Be careful as if you have more than a single IP with /32 then again the client may get each time different IP address. This may cause "inet port exhaustion " ( that is what it is called in F5BIG-IP) if there are too many connections to the origin server, so be careful as the SNAT option was added primary for that use case. There was an older option called "LB source IP persistence" but better not use it as it was not so optimized and clean as this one. RE to 2 CE nodes in a virtual site The same option with SNAT pool is not allowed for a virtual site made of 2 standalone CE. For this we can use the ring hash algorithm. Why this works? Well as Kayvan explained to me the hashing of the origin is taking into account the CE name, so the same origin under 2 different CE will get the same ring hash and the same source IP address will be send to the same CE to access the Origin Server. This will not work for a single 3-node CE cluster as it all 3 nodes have the same name. I have seen 503 errors when ring hash is enabled under the HTTP LB so enable it only under the XC route object and the attached origin pool to it! CE hosted HTTP LB with Advertise policy In XC with CE you can do do HA with 3-cluster CE that can be layer2 HA based on VRRP and arp or Layer 3 persistence based bgp that can work 3 node CE cluster or 2 CE in a virtual site and it's control options like weight, as prepend or local preference options at the router level. For the Layer 2 I will just mention that you need to allow 224.0.0.8 for the VRRP if you are migrating from BIG-IP HA and that XC selects 1 CE to hold active IP that is seen in the XC logs and at the moment the selection for some reason can't be controlled. if a CE can't reach the origin servers in the origin pool it should stop advertising the HTTP LB IP address through BGP. For those options Deploying F5 Distributed Cloud (XC) Services in Cisco ACI - Layer Three Attached Deployment is a great example as it shows ECMP BGP but with the BGP attributes you can easily select one CE to be active and processing connections, so that just one ip address is seen by the origin server. When a CE gets traffic by default it does prefer to send it to the origin as by default "Local Preferred" is enabled under the origin pool. In the clouds like AWS/Azure just a cloud native LB is added In front of the 3 CE cluster and the solution there is simple as to just modify the LB to have a persistence. Public Clouds do not support ARP, so forget about Layer 2 and play with the native LB that load balances between the CE 😉 CE on Public Cloud (AWS/Azure/GCP) When deploying on a public cloud the CE can be deployed in two ways one is through the XC GUI and adding the AWS credentials but this way you have not a big freedom to be honest as you can't deploy 2 CE and make a virtual site out of them and add cloud LB in-front of them as it always will be 3-CE cluster with preconfigured cloud LB that will use all 3 LB! Using the newer "clickops" method is much better https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management/deploy-site-aws-clickops or using terraform but with manual mode and aws as a provider (not XC/volterra as it is the same as the XC GUI deployment) https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management/deploy-aws-site-terraform This way you can make the Cloud LB to use just one CE or have some client Persistence or if traffic comes from RE to CE to implement the virtual site 2 CE node! There is no Layer 2 ARP support as I mentioned in public cloud with 3-node cluster but there is NAT policy https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-tos/networking/nat-policies but I haven't tried it myself to comment on it. Hope you enjoyed this article!
