Forum Discussion
AltocumulusSmarter UDP monitor
Had a unique situation a couple months ago. Storage back end on our entire VM environment went down so that left most of our VMs with essentially 100mb drives. However the systems were still ping-able by IP address therefore for some of our systems that are behind a virtual server, if it had a basic UDP/TCP monitor assigned to the pool, the server was technically still available according to those health monitors.
I'm trying to come up with a smart monitor for a UDP system that would take the server offline if something like that were to happen again. Any recommendations? Was thinking of a netcat style monitor but the problem is that I can't exactly pull out the VM host storage from under it again to test if the health monitor will work and fail correctly.
jaikumar_f5Noctilucent
Are you saying that you had your backend server down but since you had a simple udp monitor or some gateway monitor, the ltm marked the pool Up and started sending traffic and ultimately you had an impact.
b_1For some services yes. The majority have better checks assigned.
- jaikumar_f5
Were you able to follow the below suggestion.
- b_1
Yeah I would just assign the ICMP monitor per node is what that seems like.
- jaikumar_f5
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.