Backend nodes goes unreachable from active F5
Hi Team , We are facing node reachability issue from Active f5 on evryweeknd (sunday ) but this happens only from the Active F5 and for few VIP/pools only .. We simply failover the f5 to standby and issue resolves and then failback to standby .. Has anyone faced such issue ? We have virtual appliance configured on the ESXi host . Before opening a TAC case , Can anyone confirm if you have faced similar problem ? I did not find anything on the audit logs which indicates some sceduled jobs running at tht time ..What else can be checked ?
Monitoring ephemeral pool members & nodes
Hi, I'm looking to use the dynamic FQDN resolution for nodes / pool members, but have a few queries... If an Ephemeral pool member goes down, does that failure trigger anything on the DNS / Node side? Immediate resolution in case the result has changed etc.? Resolution appears to be wholly at the node level, suggesting the health of the pool member is irrelevant, and always limited to the IP's returned periodically by the DNS lookup attached to the node - and "DNS monitoring" merely means a resolution occured. The documentation about "auto populate" is confusing me. What is the real life difference between Enabled and Disabled? I see that when Disabled, the very first result is always used, however it still creates the Ephemeral node, it's still done periodically etc., so the only meaningful difference seems to be if more than one A is returned at a time. There's reference to Enabled removing members that are no longer being returned, but isn't that already implicitly true for Disabled? If that one result changes, then the pool member will change accordingly. Is it really any more meaningful than "Disabled = ignore additional results, Enabled = create nodes for all answers."? What would it mean for a node to auto populate, but a pool member using that node to NOT be set to do that? I see we only get a single pool member, but multiple nodes... but what is the consequence of this? Is there a reason this would be found useful? How does the node resolution internal work with the DNS Cache option in the system settings? The reoslution does use these settings, right? Would it make sense to set the resolution low ~ 5 seconds and enable caching on LTM, meaning that the name would be resolved almost as soon as the TTL expires on the record, thereby falling out of the cache? Could this be seen as a realistic best practise, or are there dragons hiding around here? Setting node resolution at an arbitrary hour interval as per default seems very dangerous to me. Thanks!
Snippet #7: OWASP Useful HTTP Headers
If you develop and deploy web applications then security is on your mind. When I want to understand a web security topic I go to OWASP.org, a community dedicated to enabling the world to create trustworthy web applications. One of my favorite OWASP wiki pages is the list of useful HTTP headers. This page lists a few HTTP headers which, when added to the HTTP responses of an app, enhances its security practically for free. Let’s examine the list… These headers can be added without concern that they affect application behavior: X-XSS-Protection Forces the enabling of cross-site scripting protection in the browser (useful when the protection may have been disabled) X-Content-Type-Options Prevents browsers from treating a response differently than the Content-Type header indicates These headers may need some consideration before implementing: Public-Key-Pins Helps avoid *-in-the-middle attacks using forged certificates Strict-Transport-Security Enforces the used of HTTPS in your application, covered in some depth by Andrew Jenkins X-Frame-Options / Frame-Options Used to avoid "clickjacking", but can break an application; usually you want this Content-Security-Policy / X-Content-Security-Policy / X-Webkit-CSP Provides a policy for how the browser renders an app, aimed at avoiding XSS Content-Security-Policy-Report-Only Similar to CSP above, but only reports, no enforcement Here is a script that incorporates three of the above headers, which are generally safe to add to any application: And that's it: About 20 lines of code to add 100 more bytes to the total HTTP response, and enhanced enhanced application security! Go get your own FREE license and try it today!
Logging Node Server for BIGIQ ASM Event Logs
Hi Everyone, We are using BIGIP 7000s (version 6.0.1.2) as BIGIQ Centralized Management. We were successful in importing the BIGIP Configurations to the BIGIQ, but client wants to see also the event logs from the ASM. Upon checking some KB, it seems that I will be needing to configure a Logging Node Server. Here are my questions: What are the minimum specs for a logging node server. i found this article indicating the specs. https://support.f5.com/kb/en-us/products/big-iq-centralized-mgmt/manuals/product/big-iq-centralized-management-and-vmware-setup-6-0-0/1.htmlguid-bd42a26b-9fa6-4127-88ab-fe5ab06bd3c2. if we will install it in a vmware, where can i download the ova for the logging node or i can use the OVA for the BIGIQ itself for the license, it was said that we can use the original base registration key, when licensing, there are only two options (BIGIQ Centralized Management and BIGIQ Data Collection Device), to have a logging node, should we choose the BIGIQ DCD? Any help will be greatly appreciated.F5 iRule - Change node dynamically and keep the default pool
Hello, i have written an iRule that changes the destination ip of the http request, it's done by: node $destProxy $destPort after doing that the request goes to the default gateway of the f5 appliance instead of the default pool assigned to the virtual server. i guess the node overrides the default pool. is there a way to use the node inside the iRule and keep the default pool? just to mention, the default pool has more than one nodes so it cannot be the default gateway. thanks orDynamic port selection not working
Hello All. I'm trying to compose an irule that will direct the traffic to a dynamically chosen port in a pool, according to the URL the user uses. After much searching I got to the point where the node and the port are correctly selected, but the NLB disregards the node command and directs the traffic to the original port. The URL is made of 3 letters of the service and 3 digits of the wanted inside-component. Together they compose the destination port. The user uses HTTPS(443), but the NLB has to direct the traffic to the "member:composed-port" according to the URL. The VIP has address and port translation enabled. To be sure of that I included those commands in the irule. The member in the pool is defined with "port=all services". when RULE_INIT { 0 = none, 1 = debug, 2 = verbose set static::APsp_Debug 2 } when CLIENT_ACCEPTED { translate address enable translate port enable } when HTTP_REQUEST priority 1 { Extract the last 3 chars from the hostname (e.g. 200 from ADM200.company.com) set APsp_inside_code [string range [getfield [HTTP::host] "." 1] end-2 end] Extract the first 3 chars from the hostname (e.g. ADM from ADM200.company.com) set APsp_service_code [string range [getfield [HTTP::host] "." 1] 0 2 ] switch -glob [string tolower $APsp_service_code] { "adm" {set APsp_dest_port "60$APsp_inside_code" } "rst" {set APsp_dest_port "64$APsp_inside_code" } default { log local0.error "service code not found. [HTTP::host][HTTP::uri]" HTTP::respond 404 "Not Found" } } } when LB_SELECTED priority 1 { set APsp_dest_node [LB::server addr] replace the host header so the server will think that this is the original request HTTP::header replace Host "company.co.il" go to load balanced member, but with the needed port if {$static::APsp_Debug > 0} { log local0.info "LBserver= [LB::server addr] node=$APsp_dest_node port=$APsp_dest_port" } node $APsp_dest_node:$APsp_dest_port log local0.info "after node command LBserver= [LB::server]" } when LB_FAILED { log local0.error "Selected server $APsp_dest_node:$APsp_dest_port is not responding" HTTP::respond 404 "Not Found" } when SERVER_CONNECTED { if {$static::APsp_Debug > 0} { log local0.info "serverport: [TCP::server_port]" } } Here are the Debug messages: Rule /Common/Event_Logger : Client 10.99.99.99:54565 requested http(s)://adm200.company.com/appbuilder/forms?code=8. Rule /Common/Event_Logger : Client 10.99.99.99:54565 request DIDN'T match any policy rule. Rule /Common/MY_select_port : LBserver= 10.237.214.28 node=10.237.214.28 port=60200 Rule /Common/MY_select_port : after node command LBserver= 10.237.214.28 60200 Rule /Common/Event_Logger : Client 10.99.99.99:54565 farwarded to 10.237.214.28 60200 /appbuilder/forms?code=8. Rule /Common/Event_Logger : Client 10.99.99.99:54565 connected from 10.237.214.253:54565 to node 10.237.214.28:443. Rule /Common/MY_select_port : serverport: 443 Rule /Common/Event_Logger : Client 10.99.99.99:54565 sending request to 10.237.214.28:443. Rule /Common/Event_Logger : Client 10.99.99.99:54565 releasing request to 10.237.214.28:443. Rule /Common/Event_Logger : Client 10.99.99.99:54565 got a response from 10.237.214.28:443. Rule /Common/Event_Logger : Client 10.99.99.99:54565 404 response released from 10.237.214.28:443 Rule /Common/Event_Logger : Connection from 10.237.214.253:54565 to Server 10.237.214.28:443 has closed. As you can see, the node command did the correct selection but the server connect went on with port 443. The pool definition: ltm pool /Common/service_pool { description load-balancing-mode observed-member members { /Common/10.237.214.28:0 { address 10.237.214.28 } /Common/10.237.214.29:0 { address 10.237.214.29 } } monitor /Common/gateway_icmp } Thanks in advance. Gil.Simplifying Application Health Monitoring with F5 BIG-IP
A simple agreement between BIG-IP administrators and application owners can foster smooth collaboration between teams. Application owners define their own simple or complex health monitors and agree to expose a conventional /health endpoint. When a /health endpoint responds with an HTTP 200 request, BIG-IP assumes the application is healthy based on the application owners' own criteria. The Challenge of Health Monitoring in Modern Environments F5 BIG-IP administrators in Network Operations (NetOps) teams often work with application teams because the BIG-IP acts as a full proxy, providing services like: TLS termination Load balancing Health monitoring Health checks are crucial for effective load balancing. The BIG-IP uses them to determine where to send traffic among back-end application servers. However, health monitoring frequently causes friction between teams. Problems with the Traditional Approach Traditionally, BIG-IP administrators create and maintain health monitors ranging from simple ICMP pings to complex monitors that: Simulate user transactions Verify HTTP response codes Validate payload contents Track application dependencies This leads to several issues: Knowledge Gap: NetOps may not fully grasp each application's intricacies. Change Management Overhead: Application updates require retesting monitors, causing delays. Production Risk: Monitors can break after application changes, incorrectly marking services as up/down. Team Friction: Troubleshooting failed health checks involves tedious back-and-forth between teams. A Cloud-Native Solution The cloud-native and microservices communities have patterns that elegantly solve these problems. One widely used pattern is the [health endpoint], which adapts well to BIG-IP environments. The /health Endpoint Convention Cloud-native applications commonly expose dedicated health endpoints like /health, /healthy, or /ready. These return standard status codes reflecting the application's state. The /health endpoint provides a clear contract between NetOps and application teams for BIG-IP integration. Implementing the Contract This approach establishes a simple agreement: Application Team Responsibilities: Implement /health to return HTTP 200 when the application is ready for traffic Define "healthy" based on application needs (database connectivity, dependencies, etc.) Maintain the health check logic as the application changes BIG-IP Team Responsibilities: Configure an HTTP monitor targeting the /health endpoint Treat 200 as "healthy", anything else as "unhealthy" Benefits of This Approach Aligned Expertise: Application teams define health based on their knowledge. Less Friction: BIG-IP configuration stays stable as applications evolve. Better Reliability: Health checks reflect true application health, including dependencies. Easier Troubleshooting: The /health endpoint can return detailed diagnostic info, but this is ignored by the BIG-IP and used strictly for troubleshooting. Implementation Examples F5 BIG-IP Health Monitor Configuration ltm monitor http /Common/app-health-monitor { defaults-from /Common/http destination *:* interval 5 recv 200 recv-disable none send "GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" time-until-up 0 timeout 16 } Node.js Health Endpoint Implementation const express = require('express'); const app = express(); const port = 3000; app.get('/', (req, res) => { res.send('Application is running'); }); app.get('/health', async (req, res) => { try { const dbStatus = await checkDatabaseConnection(); const serviceStatus = await checkDependentServices(); if (dbStatus && serviceStatus) { return res.status(200).json({ status: 'healthy', database: 'connected', services: 'available', timestamp: new Date().toISOString() }); } res.status(503).json({ status: 'unhealthy', database: dbStatus ? 'connected' : 'disconnected', services: serviceStatus ? 'available' : 'unavailable', timestamp: new Date().toISOString() }); } catch (error) { res.status(500).json({ status: 'error', message: error.message, timestamp: new Date().toISOString() }); } }); async function checkDatabaseConnection() { // Check real database connection return true; } async function checkDependentServices() { // Check required service connections return true; } app.listen(port, () => { console.log(`Application listening at http://localhost:${port}`); }); Adopting this health check pattern can greatly reduce friction between NetOps and application teams while improving reliability. The simple contract of HTTP 200 for healthy provides the needed integration while letting each team focus on their expertise. For apps that can't implement a custom /health endpoint, BIG-IP admins can still use traditional ICMP or TCP port monitoring. However, these basic checks can't accurately reflect an app's true health and complex dependencies. This approach fosters collaboration and leverages the specialized knowledge of both network and application teams. The result is more reliable services and smoother operations.Layer 2 nodes migration to Layer 3
Hello, i have 2400 nodes, over 1200 VLANs. my F5s (cluster of two 7050) has direct leg in the VLANs. i need to move this communication to a L3 path. i already have the path and routes ready. now here are my questions: will i experience a hiccup? how do i avoid saturation of port+IP for the backend traffic? i have some dev envs that i can test the solution first. please help
node disabled even though monitor green
BIG-IP 11.4.0 Build 2384.0 Final Pool is green, monitor is green, but in "Members" the single pool node is black : "Available (Disabled) - Pool member is available, monitor disabled" If I select radio button "Enabled (All traffic allowed)" and click "Apply" , it doesn't stick -- it immediately reverts to radio button "Disabled (Only persistent or active connections allowed)". This used to be working. Nothing was changed, either in the pool or the monitor.
