Unequal loadbalancing for a UDP VIP
We've an UDP VIP configured with udp-datagram profile enabled. We're observing a strange behaviour the way LTM routes the packets to the backend server. There are 5 servers in the pool and most of connections are routed to one server due to this behaviour the resource on that perticular server getting exhausted. I am not sure when we've enabled on data-gram profile. I am assuming the some of the old connections still in the connection table and being handled without data-gram. I tried clear the connection table using below tmm script and did not have any success. Please let us know if there are any other way to clear the connection table. tmsh show sys connection ss-server-addr <server-ip> | grep tmm | awk '{split($1, client, ":"); print "tmsh delete sys conn cs-client-addr " client[1] " cs-client-port " client[2] " cs-server-addr <VIP> cs-server-port 1813"}' | sh
Failover for UDP Performance Layer 4 with One (1) Connection
Hello, I am using the F5 to hopefully load balance or serve as an active-passive configuration for my firewall log pipeline. My firewall successfully sends logs via UDP to the F5 and they make their way to the configured pool member and are visible within my log collection environment, so that works. I tried adding a 2nd server to the pool, but there is no load balancing because there is only one active connection from my firewall. That makes sense. I figured the next best thing that I could attempt was to configure failover so if one node with the active connection goes offline, then my second node will pick up the traffic. I added both nodes to my pool today and turned off the service on my node with the active connection. The F5 UDP health monitor marked the primary node as offline, but the active connection never failed over to the secondary node. I was expecting the F5 to transfer the connection to the secondary node, and I am a bit confused as so why it did not. As I understand, this is potentially because of the connectionless nature of UDP. However, since the F5 marked the node as offline, I thought it would be able to failover the connection. Do you know of any way to enable this active-passive configuration with the F5 using UDP protocol, Performance Layer 4, and two nodes in the pool? Thanks!
Setting connection limit(call limit) to nodes while load balancing sip traffic over UDP
I have the following setup. SIP call is distributed from SBC to F5 LTM over UDP. Created a SIP persistence profile in LTM using call id as persistence key. Calls are being distributed to all nodes in the round robin and SIP messages are getting persisted. My requirement is to load balance the calls to the least active call node and limit the number of active calls to each node. i.e Nodes shall take only x number of active calls at any time. Active call is a call to which BYE is not received yet. Tried setting connection limit to each node but number of connections is always 1 on the statistics page. The connection limit is always 1 as in my case SIP is over UDP, source and destination IP & Port will be same for all calls. Is there any way in F5 LTM where we can limit the number of calls to each node and load balance the calls to the least call-taking node for SIP over UDP?Load Balancing UDP Traffic.
We have two Jitsi Meet servers configured to use different media server ports e.g 10000 and 100001 also turn server port eg 3478 and 3479 respectively. We want a single public ip to distribute udp traffic to these servers based on udp port number but not able to capture the ports using i rule. Any help would be appreciated..HSL request logging profile, requests not showing in logs, how to improve reliability?
How "reliable" is the HSL logging profile capability? Is it known that there may be requests that do not get logged, because of the F5 not sending the UDP packet? Or, if there are requests not being logged, is basically definite that the UDP packets are being dropped, either at the network level or by the log collector (Kiwi syslog server, if it matters)? We have a specific data flow that involves two layers of F5 load balancing: Client -> F5-1 -> F5-2 -> real server We have an HSL request logging profile in place for the VIPs on both F5s. With perfect logging, we would expect to see a 1:1 ratio of requests hitting F5-1 and F5-2 - but we don't, we see many logged requests hitting F5-2 without a corresponding request logged on F5-1. We know for a fact that those requests did come through F5-1, because on F5-2 we log both the client-ip and X-Forwarded-For header, and can see F5-1 the client-IP, and both the original client IP and the F5-1 in the XFF header. In trying to identify the root cause of the missing log messages, are there any logs on the F5s that would indicate if logging is failing, or a rate has been exceeded, or any other kind of issue? We do only have 1 log collector in the associated pool - but the request rate is pretty low, only about 10-15 requests/second; and if that server were being overwhelmed, we would expect to see even drops, not mostly/all F5-1's messages being dropped. In terms of trying to improve reliability, would switching to TCP be advised? Any other suggestions, for either locating the issue, or improving reliability? Thank you!LDAP login into F5 interface takes 30seconds or more
Like the subject says- we're seeing logins take 30 seconds or more when trying to login to the F5 interface with LDAP enabled. Using port 389. Directory service: Windows AD LDAP - The only thing I can think of is that we have UDP blocked and it appears UDP attempts to use UDP before it times out and uses TCP. Anyone else have experience with this?Fault-tolerant DNS load balancing via LTM - preventing any dropped requests?
(sorry if this is a re-post - i posted a few weeks back, but that post appears to be messed up in the devcentral database) Env: LTMs running 13.1.1.4 (we also have GTMs, also at 13.1.1.4, but i don't believe they're relevant) We are encountering times when our internal DNS responders (Infoblox, btw) will drop individual queries, or simply not respond to them. Very infrequently, and a standards-compliant client should simply retry and extend timeout, etc. But for technical reasons, we have been given a requirement to provide a fault-tolerant DNS interface that will not exhibit this behavior. Is there any way to implement such fault tolerance in an LTM VIP that proxies UDP-based DNS requests? "Action on Service Down" and "Request Queueing" seem to be fundamentally connection-oriented (i.e., TCP oriented), based both on their description and some preliminary testing. "Reselect Tries" sounds like exactly what we need, but seems not to be affecting UDP traffic ... We have DNS Controllers (GTMs) as well ... and use them for GSLB ... but it's not clear to me how they could be leveraged for such fault tolerance for our standard DNS services (moving all our zones from Infoblox to the GTMs as authoritative is ... daunting). Any recommendations, iRules to implement the equivalent of request queueing, etc.? Thank you!
F5 LTM and simple centos voice server
i want to load balance 2 centos web servers created pool , pol members with port 5060 created udp profile choose udp for virtual server selected snat automap / in another time created a snat pool connected ip phone to the ip of the virtual server the ip phone registered succesfully but when the first back end server is down or forced down / the phone doesnt register to the second identical one it is stuck on the first
VS fails to process ANY traffic
Currently attempting to configure my F5 to support unidirectional UDP forwarding of raw NetFlow from an upstream router but struggling to move traffic. I can see traffic landing on 1.1 in the GUI statistics and tcpdump (including the traffic I want), however the Virtual Server is showing no 0 packets even being registered, and indeed no expected/goal traffic is going out the 1.5 interface. I've even tried the Stateless configuration as suggested in multiple resources for unidirectional UDP traffic handling (i.e. syslog, NetFlow, etc.) but still no luck. Why would my Virtual Server not be picking up this traffic that is clearly landing on the inbound interface and seems to match the VS configuration?