Forum Discussion
Smarter UDP monitor
Gotcha. So your scenario was with the default UDP monitor configured on the pool. And when your backend servers went down, the pool members were still marked up. This is obvious.
Reason: We all know UDP is a connectionless protocol. Its a fire and forget and does not worry about the response it gets.
If you apply the default UDP monitor, you'd see that it does have send data "default send string" and the recv as none. This means, your sending your data to the backend servers and expecting nothing (fire & forget) and marking it Up. Often whenever we use the default UDP monitor, its a recommended practice to add an icmp monitor along with udp monitor. This is because, your host may have gone down for some reason, but it would fail to reply back with host unreachable message, since the UDP does not care of the response, it would still think its Up. Which is why you put an icmp monitor along with the default udp monitor.
You can refer this article too.
Also if you would want to stick with 1 monitor (UDP) alone, you should know what data you have to pass and what the response would be from the server. Based on that you can configure your custom UDP monitor. If the expected response does not come within the timeout, it will be marked down.
Hope you got the idea.
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