Logging Server-IP with OneConnect
Due to the usage of SNAT (design requirement) the servers are loosing the visibility, which real clients are connecting. Therefor the LTM should provide these information with internal logging (client-IP <-> VS <-> server-IP). But we are also using OneConnect, where logging of all sub-sequent requests of an existing server-side connection are getting "lost". Is there any solution available to still provide such a full logging information with OneConnect enabled? Or is disabling OneConnect the only solution? Thank you! Regards Stefan :)
LTM OneConnect Profile for short API http request
We have some client using API calls to our servers and they are short live request, these web servers are not browsable they just serve API. We have notice request rate is very high which i am seeing 900 TLS almost and i have notice our Web (apache) getting timeout sometime because of very high connection rate on webserver on netstat i am seeing thousands of TIME_WAIT so definitely my server running out of resources even server CPU load is 1% or 2% We are thinking to use OneConnect Profile but not sure its going to benefit us or not and how? I read about OneConnect profile but i am little confused and need some advice how we should utilize it. Question: If we use OneConnect does that means it will open only few connection to server right? We are using Auto Map SNAT so what will be impact on OneConnect Profile also we are using XFF feature to extract client IP. What if we disable HTTP 1.1 on apache webserver which will close connection faster in that case how does OneConnect profile behave? for test i have enabled oneconnect profile on our Dev LTM and send some http request from multiple but i am seeing its opening individual connect to server and not bundle them in single connection (We are using Mask 0.0.0.0) is that how openconnect works?
Large file uploads with a OneConnect profile
I have fairly vanilla http virtual server (running 11.6.1) sitting infront of a websphere application (4 nodes load balanced). The config is as follows: TCP: default tcp HTTP profile: default http Source Address: Auto Map Rewrite profile: myRewrite Access Profile: myAccessProfile OneConnect Profile: default oneConnect Session persistence: Cookie I'm having an issue with Internet Explorer 11. When a user uploads a large file (1GB or larger) via the interface. After every 900-950MB the upload stops and the file is shown as partially complete. The user can resume the upload and it does continue, but I need to stop the upload from pausing mid upload. The upload will successfully complete in one attempt if the user does it with Chrome. The web application uses a jQuery tool to do the file upload. The file is chunked up into 10MB segments and sent through in multiple http requests. I added some log outputs to various events as a first step, and it was the LB events that I found most interesting. when LB_SELECTED { log local0. "member selected: [LB::server]" } when SERVER_CONNECTED { log local0. "from [IP::client_addr]:[TCP::client_port] to vip [IP::local_addr]:[TCP::local_port]" } when LB_FAILED { log local0. "whoops LB failed - [event info]" } With the OneConnect profile in place, I see the LB_SELECTED being fired for each of the 10MB segments being sent through as you would expect. When it gets up around the 900MB mark it seems to establishes a new TCP connection (this takes about 70 seconds). I can see the SERVER_CONNECTED event firing and the client port has changed. This occurs when using both IE and Chrome. However when using IE I also see a LB_FAILED event at the same time, but the [event info] is blank. It's at this point the download pauses in IE. I fired up tcpdump and captured the entire upload process. Right before the new TCP connection is established I can see a RST,ACK sent from the F5 VIP address to the client. I searched the entire capture and it is the only RST, so it doesn't look to have come from the node. I checked the logs to see if we had encountered a port exhaustion (https://support.f5.com/csp/article/K7820), but there was nothing in the logs. There's also no logs stating that the node/pool has been marked as down. Does anyone have any thoughts as to why a new connection would be established? There is clearly traffic being sent down the connection, so idle timeout shouldn't be an issue. Thanks for getting this far 🙂 Cheers, SimonMySQL active connection never bleed off to other pool member
I am running galera MySQL behind F5 with performance Layer 4 type and i have setup 3 mysql node in pool member with Priority so only 1 mysql node will be used and other two will be standby. So everything was good but i found today when i shutdown Primary node which was active and i found my application break and when i have checked logs found: (2006, "MySQL server has gone away (error(104, 'Connection reset by peer'))") So solution was restart application, look like active member mysql connection not bleeding off to other pool member, what is wrong with my setup?
iRule: Log SNAT IP's when using Oneconnect
Hello F5 Friends, I'm at a bit of a loss for how to write an iRule here and I'm hoping you all can help me out. I have a need to send a security vendor the Client Side and Server Side IP addresses used for all connections coming in through my F5. I tested out this iRule below and it logs successfully and forwards off to our vendor successfully within our infrastructure. when SERVER_CONNECTED { # log clientside and serverside connection details to /var/log/ltm log local0. "Clientside connection: SrcIP:Port [clientside {IP::remote_addr}]:[clientside {TCP::remote_port}] to DstIP:Port [clientside {IP::local_addr}]:[clientside {TCP::local_port}] translates to Serverside connection: SrcIP:Port [IP::local_addr]:[TCP::local_port] to DstIP:Port [IP::remote_addr]:[TCP::remote_port]" } Unfortunately, I found out after this was in place that it wasn't generating logs for all connections coming into the associated virtuals. (I have this iRule applied to All virtuals on my F5.) Through some testing I found that this iRule was not logging for connections where the Server Side connection was being reused by the oneconnect profile. Next I tried using the "LB_SELECTED" event instead of "SERVER_CONNECTED" and in this case I see that I'm logging on all HTTP requests that come inbound. So the first event doesn't trigger enough and the second event triggers too often. I was hoping for some help in finding that happy medium. Can someone help me with the right event trigger or logic in the iRule that would log the CS IP's and SS IP's as each new front end connection is established to a back end server when Oneconnect is in the mix? Thanks, Jeff
iRule to disable OneConnect for a list of source IP addresses
I'm trying to resolve an issue with a legacy application that doesn't like OneConnect. All traffic from the legacy application originates from a know list of source IP addresses, which I'm including in an iRule Data Group called 'Legacy_App'. The current iRule is sending traffic from those source IP addresses to a specific pool called 'pool_Legacy'. The virtual server has an http profile and OneConnect profile with a /32 netmask. All other applications connecting to the virtual server are working fine. I'm only looking for a way to disable OneConnect specifically for traffic coming from the addresses in the Data Group 'Legacy_App'. This is what the current iRule looks like: when CLIENT_ACCEPTED { if {[class match [IP::client_addr] equals Legacy_App]} { pool pool_Legacy } } I've seen the OneConnect options for iRules: ONECONNECT::reuse disable ONECONNECT::detach disable Will adding one of those work? Should they be used with the CLIENT_ACCEPTED event?How OneConnect Profile works with Cookie Persistence
1. Preliminary Information This is a hands-on test based on whatK7964explains regarding interaction between OneConnect®profile and Cookie persistence on Keep-Alive connections. OneConnect® changes the default behaviour of making a load balancing decision based on TCP connection to one based on HTTP requests. The fact that back-end server connection can potentially be kept alive and reused for different client requests can cause issues for those who don't completely understand OneConnect®. Whilst working for F5 Support, most cases I had were related to Keep-alive connections, in particular when used with Cookie Persistence. I hope to clarify OneConnect® behaviour with Cookie Persistence in this article in a practical hands-on way. 2. Scenario → Real IP address of Client1 and Client2 does not matter as we'll be focusing on connection between BIG-IP1 and BIG-IP2 Note: BIG-IP is using Cookie persistence (insert) in our example. If you don't understand cookie persistence please refer toK83419154: Overview of cookie persistencefirst. For all tests below, 1st request (from Client1) always create new TCP connection between BIG-IP1 and BIG-IP2 and then 2nd request (from Client2) goes through same TCP connection! Keep this in mind while reading, please! 3. Lab test Results Cookie Persistence only (without OneConnect®) BIG-IP only reads cookie persistence entry once for TCP connection (at first HTTP request) If no cookie is sent to BIG-IP, BIG-IP creates one and hands back to client for first request only over a TCP connection BIG-IP also ignores subsequent cookie persistence entries in subsequent HTTP requests and do not hand further cookies over same TCP connection OneConnect®+ Cookie persistence BIG-IP reads cookie persistence entry for every HTTP request over same TCP connection If no cookie is sent (e.g. new request), BIG-IP takes new load balancing decision and hands cookie back to client every time If cookie is sent BIG-IP persists based on cookie information for every request over same TCP connection 4. OneConnect®and Cookie Persistence over the same TCP connection 4.1 New requests BIG-IP takes load balancing decision after each new HTTP request over same TCP connection: 4.2 Subsequent requests BIG-IP reads cookie persistence entry for each HTTP request and persists: 5.Cookie Persistence ONLY (without OneConnect®) over the same TCP connection 5.1 New requests BIG-IP creates cookie persistence entry and hands to client after 1st HTTP request and no longer creates further entries for subsequent requests: BIG-IP also creates one cookie record for the TCP connection and hands it back to Client1. New request from Client2 goes to Server2 as no new load balancing decision is taken. 5.2 Subsequent requests BIG-IP only reads cookie persistence entry once for TCP connection (at first HTTP request) but ignores entries for subsequent requests: If there were multiple clients with different cookie persistence records pointing to other servers, they would all be ignored and BIG-IP would keep sending requests to Server2 as part of first persistence decision when TCP connection was first established.
Content Switching Load Balancing issue
Hi all, I have an issue with our test setup from where we will build the production configuration. I hope someone can help. The setup is as following: Client >> Virtual (SSL offload) iRule with Datagroup that maps request host to Virtual Virtual >> Round Robin Pool with 2 members on port 80 I created the first virtual to offload all SSL for the sake of managebility because i need to host 300+ sites on their own virtuals to be able to serve different maintenance pages and profiles. Using an iRule and a datagroup i'm able to direct requests to a virtual matching the host header in the client request: Code when HTTP_REQUEST { if { [class match [string tolower [HTTP::host]] equals domain_map_ot] } { virtual [class match -value [string tolower [HTTP::host]] equals domain_map_ot] } That works fine and traffic arrives at the second virtual server. BUT...... The pool attached to the second virtual is setup with Round Robin. But balancing goes wrong and maybe 20 request go to the first, 1 to the second, 30 request to the first, 3 to the second... and so on (estimated numbers). The only way to get is to work as expected (Round Robin), is attaching a OneConnect profile to the second virtual. But there's where i don't get it anymore. Why would i need this and why doen't it work without the OneConnect profile ?
Content Switching Load Balancing issue
Hi all, I have an issue with our test setup from where we will build the production configuration. I hope someone can help. The setup is as following: Client >> Virtual (SSL offload) iRule with Datagroup that maps request host to Virtual Virtual >> Round Robin Pool with 2 members on port 80 I created the first virtual to offload all SSL for the sake of managebility because i need to host 300+ sites on their own virtuals to be able to serve different maintenance pages and profiles. Using an iRule and a datagroup i'm able to direct requests to a virtual matching the host header in the client request: Code when HTTP_REQUEST { if { [class match [string tolower [HTTP::host]] equals domain_map_ot] } { virtual [class match -value [string tolower [HTTP::host]] equals domain_map_ot] } That works fine and traffic arrives at the second virtual server. BUT...... The pool attached to the second virtual is setup with Round Robin. But balancing goes wrong and maybe 20 request go to the first, 1 to the second, 30 request to the first, 3 to the second... and so on (estimated numbers). The only way to get is to work as expected (Round Robin), is attaching a OneConnect profile to the second virtual. But there's where i don't get it anymore. Why would i need this and why doen't it work without the OneConnect profile ?Asynchronous multiplexing client requests in oneconnect session
We are in a process of the virtual server configuration that is able to multiplex many client TCP sessions into one server side session. The TCP payload is simple, non-HTTP and session is single request/response oriented. So far we were successful in configuring TCP client session multiplexing using oneconnect profile and customized pool (request queuing) and member (connection limit) options. The communication between clients and server is synchronized, the first client is served first, the second is next and so on. All client's requests beside serviced client are being held in pool queue until serviced client releases the server side of connection. The next task is to achieve asynchronous communication meaning that each client can send its request through oneconnect session toward the server without waiting for previous request to complete. We were successful in sending asynchronously client requests using iRule and LB:detach in CLIENT_DATA event (see bellow). The problem is to reattach server and client side session when server response arrives. When response arrives LTM has no client side connection to send data to. We are thinking to use iRule that keeps global session table with unique id field (taken from client request and which can be found in server response) and any client session identification (that F5 keeps in its connection table), if possible. There are numerous iRule functions that lack any kind of description or example code. Some of them are LB::connect, LB::context_id, LB::src_tag and LB::dst_tag that can be found useful. Is it possible while hitting server side event in iRule to "see" all client side sessions and to reconnect with the specific one? The other approach I have not tested yet is to use UIE persistence with unique data from the request to pair server and client side. Is there a way to reattach client and server side connection using iRule? Or any other mechanism known to you? Thanks for any help. iRule that enables asynchronous requests in one oneconnect session. when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { TCP::release TCP::collect TCP::notify request } when USER_REQUEST { LB::detach } when LB_FAILED { log local0. "LB_FAILED" }
