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?
LTM discards DNS responses with ECS option
Hi all, I am using BIG-IP 12.1.3 node to configure Virtual Server with pool of UDP DNS servers, and noticed strange behavior - if I configure VS "DNS Profile" from None to dns, it stops serving DNS queries with EDNS0 ECS option. From network traces I can see that request is forwarded to pool member, which responds with valid DNS answer, which then silently discarded by LTM. Requests with no ECS option are served fine. Any suggestions on why it's happening and how to make it work ? BR