Citrix XenServer Big-IP Upgrade help
I am looking to upgrade our stand alone BIG-IP on xenserver. Currently running 15.1.2.1. It looks like I can just upgrade to 17 based on K13845. I am stuck on exactly what file to download. I also read K51113020 on how to do the upgrade, but I am a little hesitant because it doesn't reference XenServer specifically. Looking at the files on the download page, I am not sure if I just pull an OVA file? The VM guy seems to think that is really for a new install not an upgrade. I will take any tips, tricks or strategies to make this a simple upgrade. Thanks in advance. JohnBIG-IQ Reporting for Subscriptions and ELA - How to Generate and Revoke Licenses for Isolated BIG-IP VE Instances
October 2018 Rev:D Scenario Some network designs may disallow BIG-IQ from reaching BIG-IP VE instances over the network due to network design, network partitioning, security reasons... you get the idea. BIG-IQ’s usual operation requires BIG-IQ to connect to port 443 on the BIG-IP VE’s management IP address. However, when the networks are partitioned in a way that does not allow the BIG-IQ to connect to the BIG-IP, a system outside of BIG-IQ is required to: POST an operation to generate a license GET the license from BIG-IQ Copy the license to the target BIG-IP VE instance And later, when the BIG-IP VE is no longer operational, revoking the license from BIG-IQ. This document explains how to manage licenses on BIG-IP VEs in this network design. Step 1: Gather your BIG-IP VE information for the licensing operation In order to successfully license BIG-IP VE, BIG-IQ needs specific information from the BIG-IP VE to be licensed. Log into the BIG-IP VE instance using “root” credentials Execute the following command: # get_dossier -b TBD -c Record the MAC address. You will also need to know the hypervisor your BIG-IP VE is running on. Example: [root@biq1-yabba-dabba-do:Active:Standalone] config # get_dossier -b d -c F5_BIOS_ID=Phoenix Technologies LTD 6.00 04/05/2016 VMware Virtual Platform None F5_MAC=00:50:56:bf:02:02 F5_PROBES=0x01000013 F5_SYS_UUID=543ff2ec-1c2f-844a-23d0-1e226b90678e F5_KEY=d F5_VERSION=BIG-IQ 6.0.1 0.0.469 Step 2: Requesting a License from BIG-IQ for your BIG-IP VE For this step, you need to have the following information: The name of the license pool in BIG-IQ you want to license the BIG-IP VE from The IP address of the BIG-IP VE device The MAC address (from step 1) The hypervisor type The offering name you wish to assign to the BIG-IP VE instance We’ll walk you through each one. The name of the pool comes from your BIG-IQ centralized management console. To get the name of the pool: Log into BIG-IQ Click the Devices tab On the left navigation, open LICENSE MANAGEMENT On the left navigation, click on Licenses Here you will see your license pools – the pool names are shown in the red rectangle in the example screen shot below. In this case, there are two pools “Engineering-Pool” and “IT-Pool” The next one we’ll discuss is the offering (service catalog) name, this will become important when we form the JSON request for the post. Click on your pool name, this will open the properties of the pool It looks as shown in the following diagram, highlighted by the red rectangle: The BIG-IQ API allows you to specify one or two “search keywords” to be used for matching the offering you wish to assign to your BIG-IP VE instance. For example, the first search keyword could be the feature level you’d like and the second the throughput, such as “LTM” and “10G”. Or, you can just specify the entire offering name as the only search keyword for an exact patch, such as “F5-BIG-MSP-LTM-5G-LIC-DEV”. Once you have the information available, form your JSON request, here is an example you can start with, we’ll take you through each part: { "licensePoolName": "Engineering-Pool", "command": "assign", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34", "hypervisor": "vmware", "unitOfMeasure": "yearly", "skuKeyword1": "LTM", "skuKeyword2": "10G" } Elements Description licensePoolName Name of your pool as previously discussed in this article command The request to BIG-IQ to assign/allocate a license for this instance of BIG-IP VE address IP of your BIG-IQ (use the management IP) assignmentType must be 'unreachable': this instructs BIG-IQ to avoid trying to POST the license to the BIG-IP VE macAddress The MAC addressed obtained using method previously discussed hypervisor Underlying hypervisor hosting the BIG_IP VE you wish to license. Valid values are "aws","azure","gce","vmware","hyperv","kvm", and "xen". unitOfMeasure Must be "yearly" when you are using a license pool as part of the F5 subscription license or Enterprise Licensing Agreement (ELA) programs. skuKeyword1 Is the first search keyword skuKeyword2 Is the second search keyword The search keywords are optional; if none are specified, you’ll get the first license pool BIG-IQ matches on. If only one is specified, you’ll get the first license pool finds matching the search string. Here is an example with a single search keyword: { "licensePoolName": "Engineering-Pool", "command": "assign", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34", "hypervisor": "vmware", "unitOfMeasure": "yearly", "skuKeyword1": "F5-BIG-MSP-LTM-3G-LIC-DEV" } Next, you need to POST your JSON body to BIG-IQ. You’ll need to enable basic authentication on BIG-IQ in order to use username and password authentication, the default is to use token- based authentication. To enable basic authentication, log into BIG-IQ console as “root” and enter “set-basic-auth on”. For the example below, we’ll use CURL – the JSON body is stored in a file named “getlicense.txt”. # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X POST -T getlicense.txt "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member-management" In this case, the BIG-IQ is at 10.255.65.16 and we’re using the admin login account on BIG-IQ with password “admin”. Your POST must go to “/mgmt/cm/device/tasks/licensing/pool/member- management” This results in the following return, if BIG-IQ has accepted your request: { "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "command": "assign", "generation": 1, "hypervisor": "vmware", "id": "64100009-e20c-4add-9d3f-6cf4ed6fde31", "identityReferences": [ { "link": "https://localhost/mgmt/shared/authz/users/admin" } ], "kind": "cm:device:tasks:licensing:pool:member-management:devicelicensingassignmenttaskstate", "lastUpdateMicros": 1531492957761866, "licensePoolName": "Engineering-Pool", "macAddress": "FA:16:3E:1B:6D:34", "ownerMachineId": "9890115d-3e0b-4e7f-a9a0-ebb22c5747e4", "selfLink": "https://localhost/mgmt/cm/device/tasks/licensing/pool/member-management/64100009-e20c-4add-9d3f-6cf4ed6fde31", "skuKeyword1": "F5-BIG-MSP-LTM-3G-LIC-DEV", "status": "STARTED", "taskWorkerGeneration": 1, "unitOfMeasure": "yearly", "userReference": { "link": "https://localhost/mgmt/shared/authz/users/admin" } } IG-IQ is an asynchronous, task-based design, as such, the license is not returned when the POST completes, but rather, the acceptance of your request to BIG-IQ. To get the license, you must poll the “selfLink” (highlighted above). # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X GET "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member-management/64100009-e20c- 4add-9d3f-6cf4ed6fde31" If successful, this GET will return the license for the BIG-IP VE instance described in the JSON request in the “licenseText” field of the JSON body. For brevity, it is omitted. If there was an error encountered, the error text is returned in the “errorMessage” field of the JSON return body. Step 2: Place the License on BIG-IP VE To complete the licensing operation, you’ll need to extract the license from the “licenseText” element in the returned JSON. You’ll need to login to the BIG-IP VE instance as “root” and do the following: Place the licenseText on the BIG-IP VE instance at the following location and file name: /config/bigip.license Restart BIG-IP VE services: bigstart restart At this point, your BIG-IP VE is licensed. Step 3: Revoking and Returning the License to BIG-IQ When your BIG-IP VE instance is no longer needed, it is time to return the license to the pool. This is called a revoke operation. You’ll need to gather the following information: The name of the license pool on BIG-IQ The IP address of the BIG-IP VE The MAC address of the BIG-IP VE Please see the information in the “Step 1” section on how to obtain and gather this information. The JSON body is then formed, here is an example: { "licensePoolName": "load7afterfix", "command": "revoke", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34" } The “command” must be “revoke” to return the license to the pool. Here is the example CURL command to the revoke, the JSON body is stored in a file called “revokelicense.txt”: # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X POST -T revokelicense.txt "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member- management" If successful, this request will return a JSON body similar to the following: { "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "command": "revoke", "generation": 1, "id": "c7348b6a-6973-4372-9b66-f07c40bd0fd5", "identityReferences": [ { "link": "https://localhost/mgmt/shared/authz/users/admin" } ], "kind": "cm:device:tasks:licensing:pool:member-management:devicelicensingassignmenttaskstate", "lastUpdateMicros": 1531490803422235, "licensePoolName": "load7afterfix", "macAddress": "FA:16:3E:1B:6D:34", "ownerMachineId": "9890115d-3e0b-4e7f-a9a0-ebb22c5747e4", "selfLink":"https://locahost/mgmt/cm/device/tasks/licensing/pool/member-management/c7348b6a-6973-4321-8f66-f07e41bf0ed4", "status": "STARTED", "taskWorkerGeneration": 1, "userReference": { "link": "https://localhost/mgmt/shared/authz/users/admin" } } Similar to the licensing operation, you can poll the selfLink using a GET operation to monitor BIG-IQ’s progress in finishing up the revoke.
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!
Creating logs from a Virtual Server
Extremely new here , so forgive me, and I'm also trying to improve an existing production system. We have an Active Directory infrustructure and we have three critical services where we actually authenticate to the applicable 3rd party, and in turn they access our network through the F5 to authenticate to one of our three load balanced domain controllers. initially, we thought it would just be a matter of turning on our Active Directory Audit policies and dump the logs to our graylog server and we'd be able to monitor success and failure security logs. This has proven to be insufficient because you can't really get good authentication information from AD Domain controllers directly about specific server logins because that type of audit is best performed at the server level receiving the login requests. The other problem is these 3rd party servers are possesed by the 3rd partys. We had a theory that since the 3rd party servers use a url that points to the F5, we should be able to get the type of security logs we want from the virtual server that passes off the request to the DC's. What we like to know is how do we configure this virtual server to first create its security logs and then to dump them to our greylog server. Thanks in advance for any information.
Mitigating 40Gbps DDoS Attacks with the new BIG-IP VE for SmartNICs Solution
Introduction First off, if this is the first you’ve heard of this new solution please do go and either check out this Lightboard Lesson or review this Newsroom Article for more context and to bring yourself up-to-speed with what it is and how it works. In a nutshell though, the BIG-IP VE for SmartNICs solution is comprised of a high performance BIG-IP AFM VE integrated with an Intel FPGA PAC N3000 SmartNIC. By programming an FPGA embedded within the SmartNIC to assume responsibility for detecting and mitigating DDoS attacks, we can offload this function from BIG-IP VE. Processing and blocking all malicious DDoS packets within the FPGA before they reach the network infrastructure alleviates much of the strain such attacks usually place on VE CPU resources while significantly bolstering DDoS performance. If all that sounds too much like marketing fluff for your liking, the purpose of this article is to show just how significant those performance improvements are and how this solution really can protect cloud environments against a range of voluminous, complex attacks. To do so, we are going to compare the performance of the BIG-IP AFM VE for SmartNICs solution against a High Performance BIG-IP AFM VE (software-only) when handling the four different DDoS attack scenarios below: 1.TCP SYN-ACK Flood Attack 2.UDP Flood Attack 3.ICMPv4 Flood Attack 4.Combination of UDP Flood, ICMPv4 Flood and TCP SYN-ACK Flood Attacks Diagram A shows our basic setup, we have an Ixia acting as client and server generating both Malicious and Normal Traffic through the N3000 SmartNIC and BIG-IP VE. Diagram B shows 3.5Gbps of baseline Normal Traffic to show the effect of the malicious traffic on both software-only and then with hardware mitigation ON (SmartNIC FPGA enabled). Note: We are generating Malicious and Normal Traffic off separate ports of the Ixia to max out the malicious traffic port. Diagram A - Simplified layout of the Test Harness Diagram B - Baseline 3.5Gbps of Normal Traffic (Goodput) Test 1 – TCP SYN-ACK Flood Attack Below in Figure 1 you will see a TCP SYN-ACK Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.6Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 1 – SYN-ACK Flood Mitigation with High Performance AFM VE (Software-only) Next in Figure 2 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 31.3% CPU usage. Figure 2 – SYN-ACK Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 2 – UDP Flood Attack Below in Figure 3 you will see a UDP Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.2Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 3 – UDP Flood Mitigation with High Performance BIG-IP VE AFM (Software-only) Next in Figure 4 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 31.3% CPU usage. Figure 4 – UDP Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 3 – ICMPv4 Flood Attack Below in Figure 5 you will see an ICMPv4 Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.2Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 5 – ICMPv4 Flood Mitigation with High Performance BIG-IP AFM VE (Software-only) Next in Figure 6 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 29.8% CPU usage. Figure 6 – ICMPv4 Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 4 – Combined SYN ACK Flood, UDP Flood Attack and ICMPv4 Flood Attack Last, we are going to send a combined attack to show a complex mitigation scenario. We will be using the full 40G capability of the Ixia port to generate malicious traffic while still maintaining 3.5Gbps of Goodput from a second stream off another Ixia port. Below in Figure 7 you will see a complex multi-vector attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 0.8 Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 7 – Combined attack mitigation with High Performance BIG-IP AFM VE (Software-only) In figure 8 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 40Gbps with no effect on the 3.5Gbps of Goodput with only 27.4% CPU usage. Figure 8 – Combined attack mitigation with BIG-IP AFM VE for SmartNICs Wrap up From the results it is very clear that with the FPGA enabled on the Intel PAC N3000 SmartNIC, BIG-IP AFM VE can handle single or complex multi-vector attacks without affecting the CPU or normal traffic flowing through the system. With software-only mitigation the CPU must deal with every packet entering the system which quickly exhausts resources. With the assistance of the FPGA on the SmartNIC the malicious traffic is blocked before it ever reaches the CPU, preventing saturation. Our normal traffic or Goodput is allowed through without interruption; this is important because it reflects a customer application, web page, VOIP or other traffic which should not be affected during an attack otherwise the attacker has met their objective. In summary we have shown you that using a Common Off The Shelf (COTS) server in conjunction with a SmartNIC and BIG-IP VE delivers protection similar to our BIG-IP iSeries appliances in an augmented software VE (VNF) solution. Figure 9 – Magnitude of different DDoS attacks both solutions were capable of mitigating Additional Resources ·F5 Cloud Docs – BIG-IP VE for SmartNICs ·F5 & Intel Solution Brief - BIG-IP VE for SmartNICs
BIG IP VM - Interface unintialized
Hi Team, I have installed Big IP VM edition in Esxi Server, after instial setup. We found interface 1.1, 1.2, etc are uninitialized state even after associating Interal, external and HA interface to vlan in Virtual machine. Still it show as unintialized only. Please share your inputs.Is AOM available in BigIP VE (Running in ESX)?
Hi there, I am setting up my first pair of virtual edition (VE) BigIPs currently and struggle to get AOM network access running. When using physical BigIPs ESC-( does the trick, but when trying to enter this via the ESX console, as soon as I type ESC I get ^[ so I won't be able to access the AOM menu. Looking at K14594: Accessing the AOM Command Menu I am not seing VEs listed anywhere. So am I right that VEs generally do not offer any AOM at all and the idea is to do all the maintenance/troubleshooting via the ESX console? If not - how do you configure network access to the AOM for VEs? Cheers, Torsten
Get Back Speed and Agility of App Development in the Cloud with F5 Application Connector: Part 4 of 4
The challenge The speed and agility of the cloud is lost—dev must request environment changes from IT again. The solution Use the F5 Application Connector to automatically update the BIG-IP. In the last post, we showed how to get the stability and security of hosting BIG-IPs in the same data center as cloud servers (aka Cloud Interconnect). While this is a great solution, it re-created the problem of the dev team filing tickets with IT in order to move application servers to production. Enter the Application Connector from F5. With the Application Connector, any time you create or delete an application server in the cloud, the BIG-IPs automatically know about it, and update their configuration accordingly. And though the example below is talking about AWS, the application connector can be used in multiple clouds, helping prevent lock-in to any one cloud. The Application Connector is made up of two components: The Application Connector Proxy, which isdelivered as aDocker container that's deployed in a cloud environment The Application Connector Service Center, which isdeployed as an iAppsLX package on the BIG-IPs The Application Connector Proxy establishes an outbound connection to the BIG-IPs, using a secure TLS tunnel to encrypt traffic between the cloud app servers and BIG-IPs. In our example, we're showing the Application Connector in conjuction with Cloud Interconnect, but your BIG-IPs can be physical or virtual (aka BIG-IP VEs), andcan be on-premise or in a remote location. Auto-discovery of nodes As we said, after some initial configuration, the BIG-IPs are automatically updated with the latest nodes. In AWS, nodes are discovered and published automatically, and as of June, 2017, similar functionality is also planned for Azure and Google. With these functions, you eliminate the need for manual updates to the BIG-IP; developers no longer have to contact IT every time they add/remove cloud servers. In the following example, DevOps has chosen to disable two nodes in the Application Connector Proxy. This change is then reflected in the Application Connector Service Centeras well. The Application Connector Service Centerlets NetOps/SecOps access a full list of nodes and their statuses, no matter which cloud they are in. You can choose to disable automatic publishing to the BIG-IP, thus giving you the power to select which nodes you would like the BIG-IP to see. Scale out to other clouds You can now use multiple clouds and have BIG-IP automatically updated with all the nodes. Even if your IP address ranges overlap across multiple clouds, Application Connector handles it without issue. Security When you use the Application Connector, no public IP addresses need to be directly associated with the application servers. Because of this, the apps are hidden from clients and bad actors. Another security benefit it centralized encryption. Encryption keys no longer need to be stored in the cloud next to the application servers, but instead are stored on the BIG-IPs and can be shared across multiple clouds. Consistent Services & Policies When you're using the Application Connector, services configuration like load balancing, WAF, traffic manipulation, and authentication, as well as the policies that go with them, are all centrally managed on the BIG-IP by NetOps/SecOps/IT. Low Maintenance After the initial configuration of the Application Connector, no management or maintenance is necessary. It’s simpler than maintaining a VPN tunnel and it’s small—you don’t have to worry about it taking up too many resources. DevOps no longer has to request changes whenever they add/remove app servers. They can update the Application Connector proxy any time they choose. Get Started with Application Connector You probably want to get started, so here is a doc for you.https://support.f5.com/kb/en-us/products/app-connector/manuals/product/f5-application-connector-setup-config-1-1-0.html And when you’re ready, you can download the Application Connector from downloads.f5.com: https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=F5_Application_Connector And finally, in case you missed it, here are the previous posts: Successfully Deploy Your Application in the AWS Public Cloud: Part 1 of 4 Secure Your New AWS Application with an F5 Web Application Firewall: Part 2 of 4 Shed the Responsibility of WAF Management with F5 Cloud Interconnect: Part 3 of 4
