What is the best way to view an old configuration (UI or CLI)?
Can we deploy a temporary (disconnected) VE and restore the configs? It seems you can't upload .ucs files to iHealth to inspect. We recently migrated from hardware F5 BIG-IP platforms to VEs, and now need to check how logging was configured since we're getting tons of logs from them now, so we can compare configurations. I made a .ucs config backup file for each node before wiping them for decommissioning, but not a QKView file, so we can't upload the .ucs file to iHealth to troubleshoot. If I deployed a VE to a test environment (without active network connections), could we load/restore the .ucs backup so that we could view settings in the UI (preferable) or CLI? Is there a better way to view previous settings/configs? If this is possible, do we need to deploy the VE as the same exact firmware version? We also jumped from 15.1.x to 17.1.x when we migrated to the VEs from the 5250v platform and the configs we need to view are for 15.1.x. Thanks in advance.Create a BIG-IP HA Pair in Azure
Use an Azure ARM template to create a high availability (active-standby) pair of BIG-IP Virtual Edition instances in Microsoft Azure. When one BIG-IP VE goes standby, the other becomes active, the virtual server address is reassigned from one external NIC to another. Today, let’s walk through how to create a high availability pair of BIG-IP VE instances in Microsoft Azure. When we’re done, we’ll have an active-standby pair of BIG-IP VEs. To start, go to the F5 Networks Github repository. Click F5-azure-arm-templates. Then go to Supported>failover. You have several options at this point. You can chose which templates to use based on your needs, failing over via API calls, via upstream load balancers, and NIC counts. Read each readme to determine your desired deployment strategy. When you already have your subnets and existing IP addresses defined but to see how it works, let’s deploy a new stack. Click new stack and scroll down to the Deploy button. If you have a trial or production license from F5, you can use the BYOL or BIG-IQ as license server options but in this case we’re going to choose the PAYG option. Click Deploy and the template opens in the Azure portal. Now we simply fill out the fields. We’ll create a new Resource Group and set a password for the BIG-IP VEs. When you get to the questions: The DNS label is used as part of the URL. Instance Name is just the name of the VM in Azure. Instance Type determines how much memory and CPU you’ll have. Image Name determines how many BIG-IP modules you can run (and you can choose the latest BIG-IP version). Licensed Bandwidth determines the maximum throughput of the traffic going through BIG-IP. Select the Number of External IP addresses (we’ll start with one but can add more later). For instance, if you plan on running more than one application behind the BIG-IP, then you’ll need the appropriate external IP addresses. Vnet Address Prefix is for the address ranges of you subnets (we’ll leave at default). The next 3 fields (Tenant ID, Client ID, Service Principal Secret) have to do with security. Rather than using your own credentials to modify resources in Azure, you can create an Active Directory application and assign permissions to it. The last two fields also go together. Managed Routes let you route traffic from other external networks through the BIG-IPs. The Route Table Tag means that anytime this tag is found in the route table, routes that have this destination are updated so that the next hop is the IP address of the active BIG-IP VE. This is useful if you want all outbound traffic to go through the BIG-IP or if you want to send traffic from a bunch of different Vnets through the BIG-IP. We’ll leave the rest as default but the Restricted Src Address is good way to put IP addresses on my network – the ones that are allowed to connect to the BIG-IP. We’ll agree to the terms and click Purchase. We’re redirected to the Dashboard with the Deployment in Progress indicator. This takes about 15 minutes. Once finished we’ll go check all the resources in the Resource Group. Let’s find out where the virtual server address is located since this is associated with one of the external NICs, which have ‘ext’ in the name. Click the one you want. Then click IP Configuration under Settings. When you look at the IP Configuration for these NICs, whenever the NIC has two IP addresses that’s the NIC for the active BIG-IP. The Primary IP address is the BIG-IP Self IP and the Secondary IP is the virtual server address. If we look at the other external NIC we’ll see that it only has one Self IP and that’s the Primary and it doesn’t have the Secondary virtual server address. The virtual server address is assigned to the active BIG-IP. When we force the active BIG-IP to standby, the virtual server address is reassigned from one NIC to the other. To see this, we’ll log into the BIG-IPs and on the active BIG-IP, we’ll click Force to Standby and the other BIG-IP becomes Active. When we go back to Azure, we can see that the virtual server IP is no longer associated with the external NIC. And if we wait a few minutes, we’ll see that the address is now associated with the other NIC. So basically how BIG-IP HA works in the Azure cloud is by reassigning the virtual server address from one BIG-IP to another. Thanks to our TechPubs group and check out the demo video. ps
F5 VE on Proxmox
Has anybody been successful running F5 BIG-IP VE on Proxmox? Proxmox: Operating System: Debian GNU/Linux 10 (buster) Kernel: Linux 5.0.18-1-pve Architecture: x86-64 F5 VE: virtual edition 14.1.2.2 from downloads.f5.com I tried both qcow2 and .ova(scsi) licensing with trial license obtained from F5 single NIC mode According to https://clouddocs.f5.com/cloud/public/v1/matrix.html, Debian should be supported distribution. Following instructions on https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-setup-linux-kvm-13-0-0/1.html. Creating new VM in Proxmox: OS: guest OS Linux, 2.6 Kernel, no media for OS Hard Disk: bus SCSI, VirtIO SCSI, NFS storage, QEMU format (qcow2), 100GB CPU: 4 sockets Memory: 8GB Network: bridge vmbr0 openvswitch with appropriate vlan tag, VirtIO, no firewall VM is created replacing just created qcow2 on remote storage with downloaded F5 qcow2 image. VM is started I am able to get prompt in Proxmox console, log in with default root account. But then mcpd keeps on restarting - constantly every few seconds. Logs show errors caused by permission errors. For some reason F5 is complaining that it cannot create "/shared/.snapshots_d/" because of permission problem. However permissions of "/shared" are OK. When I create .snapshots_d folder manually as root, mcpd no longer restarts, no more console errors... I run config utility to setup management IP/mask/gateway. As expected in single NIC mode, https port is automatically configured to 8443. I am able to reach GUI configuration utility and login as admin. Up until now everything looks fine. When trying to license the VM, I am able to generate dossier, also receive the generated license file from F5. But when I apply the license to the VM and click next, it acts as if nothing has happened. GUI keeps showing VE is not yet licensed. LTM logs says: err mcpd: License file open fails, Permission denied. "/config/bigip.license" has read permission for all and write for tomcat. Those are expected permissions for the license file. Funny though, content of /config/bigip.license is now actually populated with the correct new license. But "Registration Key" in "tmsh show sys hardware" is empty. There are several other file system related warnings or errors in logs.. so I suspect that the whole issue is with how F5 VE is accessing file system on Proxmox. But I don't know what to check or fix further. Is it even possible to run F5 VE on Proxmox? (although F5 clearly states it should be.) thx.
Web interface showing "Starting web server" and CLI shows "logger: Re-starting mcpd" every 2 seconds after shutting down 13.1.0.5 Build 0.0.5 Virtual
I have an F5 LTM virtual machine loaded up on a GNS3 VM for a lab. The virtual machine is activated with interfaces/VLANs and a couple pools/VIPs and a policy. When I go to shut down the virtual, I am greeted with the web interface saying... Starting web server Please do not reboot your device. The device is starting services required for the communication with the configuration utility. This process takes approximately 1-2 minutes. and then it runs for 30+ minutes. Logging in to the console with the root account results in endless logger: Re-starting mcpd I have tried... touch /service/mcpd/forceload Forcing a file system check on the next system reboot I should also note that the CLI shows that the LTM is INOPERATIVE so I cannot issue TMSH commands. This issue has happened to me earlier in the week and I just decided to install it as a new VM but I do not want to have to do that every time I need to shut down my host. The lab is only temporary and for testing so I just need to make sure things work but I do not want to have to keep the virtual machine running when I am done for the day in order to keep this machine working. I should also mention this is just a trial license. Any help would be much appreciated.
F5 BIG-IP LTM VE Trial 12.1.0 : "Error 51133, F5 registration key is not compatible with the detected platform "
Trying to test F5 BIG-IP LTM VE 12.1.0 Trial version. I have downloaded the qcow2 image FBIGIP-11.3.0.39.0.qcow2 and received a registration key by email which leads to the error: Error 51133, F5 registration key is not compatible with the detected platform - This platform, "Z100k", cannot be activated with this registration key "LFXEXUX-FNRBUYU". ` Consulted similar issues in this forum, but no one gives a clear answer about the cause. But the below inf.(look the screenshots) seams to suggest that I am using the wrong key and that there is no registration key for 12.1.0.     [http://hpnouri.free.fr/misc/f5/Selection_202.png](http://hpnouri.free.fr/misc/f5/Selection_202.png) [http://hpnouri.free.fr/misc/f5/Selection_203.png](http://hpnouri.free.fr/misc/f5/Selection_203.png) [http://hpnouri.free.fr/misc/f5/Selection_204.png](http://hpnouri.free.fr/misc/f5/Selection_204.png) [http://hpnouri.free.fr/misc/f5/Selection_205.png](http://hpnouri.free.fr/misc/f5/Selection_205.png) **show /sys hardware** `Sys::Hardware Chassis Information Chassis Name Chassis Type Maximum MAC Count 1 Registration Key - Hardware Version Information Name HD1 Type physical-disk Model virtio Parameters -- -- Manufacturer 6900 SerialNumber virtio-vda Size 126.00G Firmware Version 1.0 Media Type HDD Name HD2 Type physical-disk Model virtio Parameters -- -- Manufacturer 6900 SerialNumber virtio-vdb Size 100.00G Firmware Version 1.0 Media Type HDD Name cpus Type base-board Model QEMU Virtual CPU version 2.1.2 Parameters -- -- cache size 4096 KB cores 2 cpu MHz 3292.520 cpu sockets 0 cpu stepping 3 Platform Name BIG-IP Virtual Edition BIOS Revision Base MAC 00:b2:d4:7f:4d:00 System Information Type Z100 Chassis Serial 00000000-0000-0000-000000000000 Level 200/400 Part Switchboard Serial Switchboard Part Revision Host Board Serial Host Board Part RevisionWhy so high Ping Latencies in VE LTM ?
Hello, I'm evaluating a VE LTM Trial, 25 Mbps, BIG-IP 12.1.1 Build 2.0.204 Hotfix HF2 It's running on Hyper-V on Windows Server 2012R2. When I run ping from the Hyper-V console window of the LTM VM I can measure the following times: ping -I 172.27.50.1 172.27.50.151 = **7 ms .. 30 ms** (pinging from the LTM internal static self-IP to another VM attached to the same Virtual Switch) ping -I 172.27.50.1 172.27.50.161 = **7 ms .. 30 ms** (pinging from the LTM internal static self-IP to another VM reached through the external network, through a physical switch) ping -I 172.27.50.1 172.27.51.1 < 1 ms (pinging from the LTM internal static self-IP to the LTM external static self-IP) ping -I 172.27.50.1 172.27.52.1 < 1 ms (pinging from the LTM internal static self-IP to the LTM management address) ping -I 172.27.50.1 172.27.51.51 = **2 ms .. 4 ms** (pinging from the LTM internal static self-IP to any of the configured LTM Virtual Servers) pings between the two devices over the HA VLAN are even higher: tens of ms ! I reserved what I judge to be the recommended amounts of vCPU and memory to the LTM VE. I have also disable Virtual Machine Queues in the PhyNICs and in the LTM VNICs. Has someone suggestions of configurations to check/change, or troubleshooting procedures to reveal the cause of the high latencies above ? Many thanks!Default Route into OSPF
I am unable to advertise a default route 0.0.0.0/0 from the F5 into ospf. I have an F5 VE running 12.1.1 on KVM-QEMU. IMI is running and I have neighbor relationships with the appropriate routers. All other routes that I test are added without issues, but I do not see the 0.0.0.0/0 route being advertised into ospf. MY ZebOS config: [root@F5-INTERNET-01:Active:In Sync] config cat zebos/rd0/ZebOS.conf ! no service password-encryption ! interface lo ! interface tmm ! interface Core ip ospf priority 0 ip ospf mtu-ignore ! interface Internet ! router ospf ospf router-id 10.246.3.250 redistribute kernel passive-interface Internet network 10.246.3.0 0.0.0.255 area 0.0.0.0 ! line con 0 login line vty 0 39 login ! end Here is the LTM Configuration: ltm virtual /Common/Test { destination /Common/0.0.0.0:0 ip-protocol tcp mask any profiles { /Common/fastL4 { } } source 0.0.0.0/0 translate-address enabled translate-port disabled } ltm virtual /Common/test2 { destination /Common/10.10.10.1:80 ip-protocol tcp mask 255.255.255.255 profiles { /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } ltm virtual /Common/test3 { destination /Common/20.20.20.0:0 ip-protocol tcp mask 255.255.255.0 profiles { /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port disabled } ltm virtual-address /Common/0.0.0.0 { address any arp disabled icmp-echo disabled mask any route-advertisement enabled server-scope none traffic-group /Common/traffic-group-1 } ltm virtual-address /Common/10.10.10.1 { address 10.10.10.1 arp enabled icmp-echo enabled mask 255.255.255.255 route-advertisement enabled server-scope none traffic-group /Common/traffic-group-1 } ltm virtual-address /Common/20.20.20.0 { address 20.20.20.0 arp disabled icmp-echo disabled mask 255.255.255.0 route-advertisement enabled server-scope none traffic-group /Common/traffic-group-1 } What is the issue?BIG-IP VE - qemu on an Apple Silicon Macbook
Hey all, I was wondering if anyone has managed to spin up a BIG-IP VE on an Apple Silicon Macbook using qemu? I've been using this guide: https://clouddocs.f5.com/cloud/public/v1/kvm/kvm_setup.html As a reference point, but this is obviously written from the persepctive of a native x86 chipset on the host. I've tried playing around with what I believe are the relevant settings, but the guest just crashes virt-manager every time I try to launch it. Don't suppose anyone has been through this pain and come out the other side successfully and could lend a hand? Thanks!Get Started with BIG-IP and BIG-IQ Virtual Edition (VE) Trial
Welcome to the BIG-IP and BIG-IQ trials page! This will be your jumping off point for setting up a trial version of BIG-IP VE or BIG-IQ VE in your environment. As you can see below, everything you’ll need is included and organized by operating environment — namely by public/private cloud or virtualization platform. To get started with your trial, use the following software and documentation which can be found in the links below. Upon requesting a trial, you should have received an email containing your license keys. Please bear in mind that it can take up to 30 minutes to receive your licenses. Don't have a trial license? Get one here. Or if you're ready to buy, contact us. Looking for other Resources like tools, compatibility matrix... BIG-IP VE and BIG-IQ VE When you sign up for the BIG-IP and BIG-IQ VE trial, you receive a set of license keys. Each key will correspond to a component listed below: BIG-IQ Centralized Management (CM) — Manages the lifecycle of BIG-IP instances including analytics, licenses, configurations, and auto-scaling policies BIG-IQ Data Collection Device (DCD) — Aggregates logs and analytics of traffic and BIG-IP instances to be used by BIG-IQ BIG-IP Local Traffic Manager (LTM), Access (APM), Advanced WAF (ASM), Network Firewall (AFM), DNS — Keep your apps up and running with BIG-IP application delivery controllers. BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS handle your application traffic and secure your infrastructure. You’ll get built-in security, traffic management, and performance application services, whether your applications live in a private data center or in the cloud. Select the hypervisor or environment where you want to run VE: AWS CFT for single NIC deployment CFT for three NIC deployment BIG-IP VE images in the AWS Marketplace BIG-IQ VE images in the AWS Marketplace BIG-IP AWS documentation BIG-IP video: Single NIC deploy in AWS BIG-IQ AWS documentation Setting up and Configuring a BIG-IQ Centralized Management Solution BIG-IQ Centralized Management Trial Quick Start Azure Azure Resource Manager (ARM) template for single NIC deployment Azure ARM template for three NIC deployment BIG-IP VE images in the Azure Marketplace BIG-IQ VE images in the Azure Marketplace BIG-IQ Centralized Management Trial Quick Start BIG-IP VE Azure documentation Video: BIG-IP VE Single NIC deploy in Azure BIG-IQ VE Azure documentation Setting up and Configuring a BIG-IQ Centralized Management Solution VMware/KVM/Openstack Download BIG-IP VE image Download BIG-IQ VE image BIG-IP VE Setup BIG-IQ VE Setup Setting up and Configuring a BIG-IQ Centralized Management Solution Google Cloud Google Deployment Manager template for single NIC deployment Google Deployment Manager template for three NIC deployment BIG-IP VE images in Google Cloud Google Cloud Platform documentation Video: Single NIC deploy in Google Other Resources AskF5 Github community (f5devcentral, f5networks) Tools to automate your deployment BIG-IQ Onboarding Tool F5 Declarative Onboarding F5 Application Services 3 Extension Other Tools: F5 SDK (Python) F5 Application Services Templates (FAST) F5 Cloud Failover F5 Telemetry Streaming Find out which hypervisor versions are supported with each release of VE. BIG-IP Compatibility Matrix BIG-IQ Compatibility Matrix Do you have any comments or questions? Ask here
