Forum Discussion
Why the HTTP::status is always 0 when I have a monitor calls another VIP?
Hi, I have a monitor do a healthcheck to another VIP(controller VIP) on the same F5, in this case, whatever the return of contoller server is, the HTTP:status is returned by conteroller VIP to monitor is always 0. On the other hand, if I do a telnet to the controller VIP from my PC, the HTTP:status is returned by conteroller VIP to monitor is normal (200 or other values). So my question is: is there any special logic for the HTTP request from monitor to a VIP?
when HTTP_RESPONSE { log "GET response from SERVER_ADDRESS [IP::server_addr], status is [HTTP::status]" if { $is_healthcheck equals 1 } { if { [HTTP::status] != 420 } { if { [HTTP::status] != 200 } { log "[HTTP::status] [HTTP::payload] - Response status is not 420, ignore it!" } HTTP::respond 200 content 'up' } else { log "Response status is 420, Manual failover!" } } }
4 Replies
- What_Lies_Bene1
Cirrostratus
I'm confused. If this is a Monitor, why is an iRule involved?
- John_Alam_45640Historic F5 Account
No special logic from monitor to VIP. VIP does not know it is talking to a monitor and vice versa.
What about the other headers, does VIP have SNAT enabled. Is the server responding directly to the monitor and bypassing the VIP?
- autumn_wang_728
Nimbostratus
Hi John,
Yes, I set "Source Address Translation" to "auto map". To be clear, the use case likes this: VIP1 -- monitor ---> VIP2, the irules I showed is on VIP2 which is used to change VIP2's behaviors based on the return code/content from server.
And how to check if the server responding directly to the monitor and bypassing the VIP?
Best regards, Autumn Wang
- shaggy
Nimbostratus
If I understand the issue correctly, this may not be possible. SOL10379: A local virtual server IP address cannot be used as a pool member
"...the BIG-IP does not respond to its own ARP requests for locally hosted virtual server addresses, and thus is unable to establish a network connection to a locally hosted virtual server."
You may be able to get around this by adding a management-route for the controller-VIP address which will force F5-initiated connections to that particular VIP address out the management interface. F5 discourages using the management interface for production traffic (SOL13284: Overview of management interface routing (11.x))
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com