Proper syntax for using quotes in monitors send/recv?
For http monitors, we generally look at our application's status page. This returns the output from various tests, with both the test name and result surrounded by quotes. It's my understanding that quotes need to be prefaced with a backslash in order for them to be properly processed. I didn't have any problems with this until I tried "load sys config" from TMSH, and realized it's not liking the syntax: (Active)(/Common)(tmos) create ltm monitor http MyMon send 'GET /MyApp/Status\r\n' recv '\"httpStatus\":\"OK\"' (Active)(/Common)(tmos) load sys config Loading configuration... /config/bigip_base.conf /config/bigip_user.conf /config/bigip.conf 01070642:3: Monitor /Common/MyMon parameter contains unescaped " escape with backslash. Unexpected Error: Loading configuration process failed.
LDAP monitor behaviour
Hi Just wanted to check that my understanding of how an LDAP monitor behaves. Forgive the long background 😉 We had an incident where users couldn't authenticate because an AD Query in our access policy was failing. AD agent: Query: query with '(|(sAMAccountName=bloggsjoe))' failed Our current monitor still had the domain controller as up, so all users attempting to authenticate from that point failed. We forced the domain controller offline so it would send to the next in the pool (priority group), and users were able to authenticate. I am looking to configure an LDAP monitor to attach to the pool of controllers used to authenticate users. It is configured to do an ldap search looking for a particular account. I have mandatory attributes set to true, so if the search fails it should mark the member down. ltm monitor ldap /Common/ldap_dc_monitor { base "OU=Service Accounts,DC=prod,DC=local" chase-referrals yes debug no defaults-from /Common/ldap description "LDAP monitor for domain controllers used for auth" destination *:389 filter sAMAccountName=f5_apm interval 10 mandatory-attributes yes password *********** security tls time-until-up 0 timeout 31 username f5_apm@prod.local } I'm hoping this monitor will mimic the AD query, so if we have an occurrence where the primary domain controller has an issue with the search, it will be marked down and the next in the priority group will take over. If I change the filter to something I know will fail I can see the pool members get marked down. However what I wasn't expecting was it takes the full timeout before it gets marked down. I turned on debug and tailed the monitors log file for the primary controller. I could see the response from the controller come back straight away, but it still waits the full timeout before bringing the member down no attributes were received for filter 'SAMAccountName=blah' Is that expected behaviour? I was expecting the member to be marked down as soon as the above response was received Cheers, Simon
LTM monitor - help
I have a pool with 2 servers 10.0.0.1 and 10.0.0.2 that runs multiple websites, i'm looking to have multiple monitors attached to the pool one for each url. the below send and receive strings. Question is the below correct and what is the traffic flow in other works does it check the below url by sending to each server or will it resolve example1.test.co.uk to its external url and test aginst that GET / HTTP/1.1\r\nHost: example1.test..co.uk\r\nConnection: Close\r\n\r\n HTTP/1.1 200 OK any help would be goodLTM Health Monitors
Hi team. I want to ask a question about health monitors. I have a Web site (www.example.com) behind the Load Balancer. I created a health monitor and I wrote send string : ''GET / HTTP/1.1\r\nHost:www.example.com\r\nConnection: Close\r\n\r\n'' I wrote recieve string : HTTP 1.1 200 OK And application is avaliable. VS is online (green circle) Then I changed receive string to : ''GET / HTTP/1.1\r\nHost:www.f5lab.com\r\nConnection: Close\r\n\r\n. So I replaced host with an unrelated name. And application is available again :) VS is online (green circle) How should we interpret this? Do you know good article or videos about send and recieve string? Thank you..Auto-Enable after Receive Disable String
I've been looking at the Receive Disable String on some HTTP monitors, and we can confirm that when the monitor detects the string the pool members do in fact get disabled, but when the receive string is returned instead the member never gets returned to enabled. Is this normal? or is there a way to automatically re-enable the member once it's functioning again? Thanks in advance.
