Packet based load balancing instead of connection based (default)
Hi everyone, I have a requirement to load balance iso 8583 echo messages across two servers in a pool. I used a performance Layer 4 virtual server to attempt achieving this because I reckon that is the type of virtual server that could fulfill the requirements of load balancing all the requests across the 2 servers in the pool. However, requests are only being sent to one pool member. I also tried to craft an iRule (see below) to do this, still requests are only sent to one pool member. when CLIENT_ACCEPTED { log local0. "ACCEPTED !!" TCP::collect } when CLIENT_DATA { log local0. "DATA !!" #to get the length of messagein hexadecimal,the length info can be get from the first 2 byte binary scan [TCP::payload] H4 len log local0. $len #convertlentodecimal scan $len %x len log local0. $len #totalmessage length is length + 2 set len [expr { $len + 2} ] if {[TCP::payload length] < $len} { TCP::collect [expr {$len - [TCP::payload length]}] return } TCP::release $len TCP::notify request TCP::collect } when LB_SELECTED { log local0. [LB::server] } when SERVER_CONNECTED { log local0. "Server Connected !!" TCP::collect } when SERVER_DATA { log local0. "response: [TCP::payload]" TCP::release TCP::notify response TCP::collect } Has anyone done packet-based load balancing before? Any ideas?
Fast L4 profile & MSS
Hi, we're using Performance L4 VIP (wildcard service), with Fast L4 profile attached to it. The fast L4 profile propagates the change of the MSS value. Since the Protocol Profile (Client) is a "Client" type of profile, I wonder if there is a possibility to limit MSS to both sides, to the client, and to the server side. This can be done on a standard type of VS... What is the impact on the box in case of changing profile type to standard? We have a large number of connections.
Exchange 2016 using N-Path Outlook Connection Issues
Hi all, Our Security Team have a requirement to see the real client IP in the email logs for Exchange 2016. We were previously using SNAT with no issues however it was not possible to get the client IP into the logs. We've deployed a new VIP using the N-Path iApp and configured the Loopback Adaptors and pre-requisite ARP settings on each of the adaptors. The VIP is configured without persistence (pool is using Round Robin) and I've setup a check using the Outlook anywhere server health check. The solution is working well for the most part, however Outlook clients are experiencing issues where they show up as connected to Exchange however they are unable to send/receive emails until Outlook is closed and opened again. It seems like a timeout issue or something similar and whatever is happening the client doesn't really seem to be aware of it. I've tried increasing the timeout on the iAPP from 51 seconds, to 180s, 300s, up to 15 minutes or so. I wondered if there was any guidance for Exchange with regards to various timeouts for N-Path as documentation is pretty limited. I've seen some questions referring to LDAP that talk about 2 hour + TTL on the N-Path but the iApp hints that this should not be required as this timeout only covers the initial client connection. Any help/guidance would be greatly received. Kind Regards Spencer
TCP Handshake Bug
I have a question, has anyone found the knowledge base (kb) for the TCP Handshake bug on the LTM (Hey guys this is the actual code name of the F5 bug but we are still looking for the KB for this one (597089-3)? This bug appears to have the behavior of overriding the Idle timeout value with the TCP Handshake Timeout value and currently the fix is to disable the PVA Acceleration (FastL4 for us) of that virtual instance. Any assistance for this would be greatly appreciated. Thanks in advance
Control file types for SFTP VIP (FastL4) iRule?
Hello Folks, One of the customers has deployed the SFTP VIP (Performance L4) on a custom port i.e. 4848 and that is working well without any issues. Later, customer wants to control file types on this VIP. This means, only XML should be allowed, and rest of the files should be declined. Since it is SFTP and we are using FastL4, I doubt we can sniff the communication without having "PrivateKey", correct me if I am wrong. I was wondering if we can fetch such details from TCP iRule event/commands with bearing all the limitations in mind? Thank you, DarshanF5 impact for fastL4 reassemble-fragments option (CVE-2015-4638)
Hi I've got issue about https://support.f5.com/kb/en-us/solutions/public/17000/100/sol17155.html Which is occur with fastL4 profile reassemble-fragments option. I may be upgrade to fix this issue but before that I have to workaround this. Workaround method is enable reassemble-fragments on fastL4 profile. So I want to know Did we have any Impact or disadvantage to make fastL4 vs (like forwarding vs) to reassemble-fragments ? Thank you very much