What Is BIG-IP?
tl;dr - BIG-IP is a collection of hardware platforms and software solutions providing services focused on security, reliability, and performance. F5's BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions. That's right, the BIG-IP name is interchangeable between F5's software and hardware application delivery controller and security products. This is different from BIG-IQ, a suite of management and orchestration tools, and F5 Silverline, F5's SaaS platform. When people refer to BIG-IP this can mean a single software module in BIG-IP's software family or it could mean a hardware chassis sitting in your datacenter. This can sometimes cause a lot of confusion when people say they have question about "BIG-IP" but we'll break it down here to reduce the confusion. BIG-IP Software BIG-IP software products are licensed modules that run on top of F5's Traffic Management Operation System® (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software can run on hardware or can run in virtualized environments. Virtualized systems provide BIG-IP software functionality where hardware implementations are unavailable, including public clouds and various managed infrastructures where rack space is a critical commodity. BIG-IP Primary Software Modules BIG-IP Local Traffic Manager (LTM) - Central to F5's full traffic proxy functionality, LTM provides the platform for creating virtual servers, performance, service, protocol, authentication, and security profiles to define and shape your application traffic. Most other modules in the BIG-IP family use LTM as a foundation for enhanced services. BIG-IP DNS - Formerly Global Traffic Manager, BIG-IP DNS provides similar security and load balancing features that LTM offers but at a global/multi-site scale. BIG-IP DNS offers services to distribute and secure DNS traffic advertising your application namespaces. BIG-IP Access Policy Manager (APM) - Provides federation, SSO, application access policies, and secure web tunneling. Allow granular access to your various applications, virtualized desktop environments, or just go full VPN tunnel. Secure Web Gateway Services (SWG) - Paired with APM, SWG enables access policy control for internet usage. You can allow, block, verify and log traffic with APM's access policies allowing flexibility around your acceptable internet and public web application use. You know.... contractors and interns shouldn't use Facebook but you're not going to be responsible why the CFO can't access their cat pics. BIG-IP Application Security Manager (ASM) - This is F5's web application firewall (WAF) solution. Traditional firewalls and layer 3 protection don't understand the complexities of many web applications. ASM allows you to tailor acceptable and expected application behavior on a per application basis . Zero day, DoS, and click fraud all rely on traditional security device's inability to protect unique application needs; ASM fills the gap between traditional firewall and tailored granular application protection. BIG-IP Advanced Firewall Manager (AFM) - AFM is designed to reduce the hardware and extra hops required when ADC's are paired with traditional firewalls. Operating at L3/L4, AFM helps protect traffic destined for your data center. Paired with ASM, you can implement protection services at L3 - L7 for a full ADC and Security solution in one box or virtual environment. BIG-IP Hardware BIG-IP hardware offers several types of purpose-built custom solutions, all designed in-house by our fantastic engineers; no white boxes here. BIG-IP hardware is offered via series releases, each offering improvements for performance and features determined by customer requirements. These may include increased port capacity, traffic throughput, CPU performance, FPGA feature functionality for hardware-based scalability, and virtualization capabilities. There are two primary variations of BIG-IP hardware, single chassis design, or VIPRION modular designs. Each offer unique advantages for internal and collocated infrastructures. Updates in processor architecture, FPGA, and interface performance gains are common so we recommend referring to F5's hardware pagefor more information.
Difference between session user-disabled and state user-down
Both these put the member down but how do they deal with the connections and why do we have two options? root@(bigip2)(cfg-sync In Sync)(Active)(/Common)(tmos) modify ltm pool app1 members modify { 10.1.62.240:80 {session user-disabled state user-down }} root@(bigip2)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool app1 ltm pool app1 { members { 10.1.62.240:http { address 10.1.62.240 session user-disabled state user-down } And the next one: root@(bigip2)(cfg-sync In Sync)(Active)(/Common)(tmos) modify ltm pool app1 members modify { 10.1.62.243:80 {session user-disabled }} root@(bigip2)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool app1 ltm pool app1 { members { 10.1.62.240:http { address 10.1.62.240 session user-disabled state user-down } 10.1.62.241:http { address 10.1.62.241 monitor http session monitor-enabled state down } 10.1.62.243:http { address 10.1.62.243 session user-disabled state down } 10.1.62.244:http { address 10.1.62.244iControl REST: Working with Pool Members
Since iControl REST is the new kid on the block, it's bound to start getting some of the same questions we've addressed with traditional iControl. One of these oft-asked and misunderstood questions is about enabling/disabling pool members. The original poster in this case is actually facing a syntax issue with the allowable state issues in the json payload, but I figured I'd kill two birds with one stone here and address both concerns going forward. DevCentral member Rudi posted in Q&A asking for some assistance with disabling a pool member. He was able to change some properties on the pool member, but trying to change the state resulted in this error: {"code":400,"message":"invalid property value \"state\":\"up\"","errorStack":[]} The REST interface is complaining about an invalid property, mainline, the "up" state. If you do a query against an "up" pool member, you can see that the state is "unchecked" instead of up. { "state": "unchecked", "connectionLimit": 0, "address": "192.168.101.11", "selfLink": "https://localhost/mgmt/tm/ltm/pool/testpool/members/~Common~192.168.101.11:8000?ver=11.5.1", "generation": 63, "fullPath": "/Common/192.168.101.11:8000", "partition": "Common", "name": "192.168.101.11:8000", "kind": "tm:ltm:pool:members:membersstate", "dynamicRatio": 1, "inheritProfile": "enabled", "logging": "disabled", "monitor": "default", "priorityGroup": 0, "rateLimit": "disabled", "ratio": 1, "session": "user-enabled" } You might also note the session keyword in the pool member attributes as well. This is the key that controls the forced offline behavior. The mappings for these two values (state and session) to the GUI state of a pool member are as follows GUI: Enabled {"state": "unchecked", "session": "user-enabled"} GUI: Disabled {"state": "unchecked", "session": "user-disabled"} GUI: Forced Offline {"state": "user-down", "session": "user-disabled"} So to change a value on a pool member, you need to use the PUT method, and specify in the URL the pool, pool name, and the pool member: curl -sk -u admin:admin https://192.168.6.5/mgmt/tm/ltm/pool/testpool/members/~Common~192.168.101.11:8000/ \ -H "Content-Type: application/json" -X PUT -d '{"state": "user-down", "session": "user-disabled"}' This results in changed state and session for this pool member: { "state": "user-down", "connectionLimit": 0, "address": "192.168.101.11", "selfLink": "https://localhost/mgmt/tm/ltm/pool/testpool/members/~Common~192.168.101.11:8000?ver=11.5.1", "generation": 63, "fullPath": "/Common/192.168.101.11:8000", "partition": "Common", "name": "192.168.101.11:8000", "kind": "tm:ltm:pool:members:membersstate", "dynamicRatio": 1, "inheritProfile": "enabled", "logging": "disabled", "monitor": "default", "priorityGroup": 0, "rateLimit": "disabled", "ratio": 1, "session": "user-disabled" } Best tip I can give with discovering the nuances of iControl REST is to query existing objects, and change their default values around in the GUI and re-query to see what the values are supposed to be. Happy coding!Client unable to bind to LDAPs through LTM virtual for LDAPS
I have setup my F5 LTM 11.4.0 to have a virtual server that is receiving LDAP requests over 636. I have a profile setup with a cert/key for the client communication and a server profile setup with no cert/key (as I will use the cert being served up by the AD resource). I made 2 virtuals technically as I did one manually and the other through the iApp .. both failed. The client application attempts to connect and get a "unable to connect". Installed 2 third party tools and get the same type of error messages. When I setup the F5 LTM to have no cert/key on the client and whistle the transaction through - it works. Even when I use 636 on the server side, it works (appears to rule out the AD cert). However, once I put the client cert/key back in - it fails. So everything points to either a cert issue or an F5 configuration issue. I'm not sure how to troubleshoot it as the certificate really does look valid. (Correct SAN, Key Usage, SHA1 algorithm, etc.) Even the tcpdump analysis simply states: SYN/ SYN,ACK/ ACK/ cert exchange/ change cipher spec x3/ ACK/ RST,ACK - Why the hell did it send a reset packet? Any advice on how to troubleshoot this?
Gather a list of virtuals and or pools that are offline state and provide duration
Hi, I am looking for a way in tmsh to provide a list of offline VIPs/pools. In addition to that, I want to know how long they were offline. I know I can sift through the LTM logs but that will take too long for what I want to accomplish. If I go to the GUI, I can list a set of VIPs/Pools based on 'offline' status, however it does not provide duration, just shows the current state.
LTM/GTM Combo w/ multiple partitions - Datacenters creation outside Common
I have two F5 BIG-IP Virtual Editions each with LTM and GTM modules. We've created a secondary partition on each to allow for future expansion. All of the LTM config is deployed outside of the common partition. I've managed to make my way through getting the SSL certs shared between both devices with the bigip_add command and have verified with iqdump. The next step was to add the Datacenters to the GTM configuration. I have the secondary (non-common) partition selected, however, when I create the Datacenter objects they are always created in the "Common" partition. Beings I wasnt able to create the Datacenters in the new partition in any obvious way I ran with the assumption that this was expected behavior. Now when I move on to create the Server objects for the GTM/LTM devices I am able to do so successfully and they pull back and show all VS online. Moving on to creating pools is where the problems start. When I attempt to create a Pool I get this "An error has occurred while trying to process your request." I should note that currently each device is configured with a single Self IP and the GTM listener is attached to that IP address. Also, the following is found in the GTM log. No additional log entries are generated when I attempt to create a Pool. Oct 5 03:16:03 brsl011a alert gtmd[4530]: 011ae0f2:1: Monitor instance /Common/bigip 130.24.107.45:80 UNKNOWN_MONITOR_STATE --> UP from 130.24.107.41 (UP) Oct 5 03:16:03 brsl011a alert gtmd[4530]: 011a6005:1: SNMP_TRAP: VS /PP2-Main-Exch/cgt-pp2-exch-preprod_app/cgt-pp2-exch-preprod_ad_http (ip:port=130.24.107.45:80) (Server /Common/ns2.wip-pp.contoso.com) state change blue --> green Oct 5 03:16:04 brsl011a alert gtmd[4530]: 011ae0f2:1: Monitor instance /Common/bigip 130.24.107.50:135 UNKNOWN_MONITOR_STATE --> UP from 130.24.107.41 (UP) Oct 5 03:16:04 brsl011a alert gtmd[4530]: 011a6005:1: SNMP_TRAP: VS /PP2-Main-Exch/cgt-pp2-exch-preprod_app/cgt-pp2-exch-preprod_rpc (ip:port=130.24.107.50:135) (Server /Common/ns2.wip-pp.contoso.com) state change blue --> green Oct 5 03:16:07 brsl011a alert gtmd[4530]: 011ae0f2:1: Monitor instance /Common/bigip 130.24.107.42:80 UNKNOWN_MONITOR_STATE --> UP from 130.24.107.41 (UP) Oct 5 03:16:07 brsl011a alert gtmd[4530]: 011a6005:1: SNMP_TRAP: VS /PP2-Main-Exch/cgt-pp2-exch-preprod_app/cgt-pp2-exch-preprod_owa_http (ip:port=130.24.107.42:80) (Server /Common/ns2.wip-pp.contoso.com) state change blue --> green Oct 5 03:16:09 brsl011a alert gtmd[4530]: 011ae0f2:1: Monitor instance /Common/bigip 130.24.107.44:443 UNKNOWN_MONITOR_STATE --> UP from 130.24.107.41 (UP) Oct 5 03:16:09 brsl011a alert gtmd[4530]: 011a6005:1: SNMP_TRAP: VS /PP2-Main-Exch/cgt-pp2-exch-preprod_app/cgt-pp2-exch-preprod_oa_https (ip:port=130.24.107.44:443) (Server /Common/ns2.wip-pp.contoso.com) state change blue --> green Oct 5 03:16:10 brsl011a alert gtmd[4530]: 011ae0f2:1: Monitor instance /Common/bigip 130.24.107.43:443 UNKNOWN_MONITOR_STATE --> UP from 130.24.107.41 (UP) Oct 5 03:16:10 brsl011a alert gtmd[4530]: 011a6005:1: SNMP_TRAP: VS /PP2-Main-Exch/cgt-pp2-exch-preprod_app/cgt-pp2-exch-preprod_as_https (ip:port=130.24.107.43:443) (Server /Common/ns2.wip-pp.contoso.com) state change blue --> green I have a couple of questions. 1) are the Datacenters being created inside the common partition instead of the secondary partition an expected result or should I be able to create Datacenters and have them show in my secondary partition? 2) Knowing the above is currently true (datacenters in common partition) when I go to create the Pools would this be a cause for the error? Thanks to anyone who actually read this lengthy post and to anyone who can help out! Cheers
iRules base on URL matching
I have following irulesand its working but now i have requirement to match URL developers and developer(without "s") so how do i match that string? also i want to redirect developers.vivox.com (both without s) to http to https so i don't know where do i put that rule in following code? when HTTP_REQUEST { log local0. "client: [IP::remote_addr] -> [HTTP::host][HTTP::uri]" if { [string tolower [HTTP::host]] equals "developers.example.com"}{ pool DEV_pool } else { pool QA_pool } }
