TCP profile configuration for VIP-targeting-VIP
Here is my setup... Client -> VIP (APM Enabled) -> LTM Policy -> VIP (Application) -> Pool (Members) I am using the default "tcp-mobile-optimized" profile both client and server side connections for EACH virtual server. When deployed into PROD, I noticed the TMM memory increased by 1GB when I went to the VIP-targeting-VIP configuration. When running a single VIP configuration, the memory usage was lower. Are there any recommendations for modifying how the tcp profiles should be configured for the external SS and internal CS tcp configuration? I want to take advantage of the features in tcp-mobile-optimized but I don't want to waste unnecessary memory at the same time. I'm not sure how the Proxy Buffer Low/High values effect the traffic flow when multiple VIPs are involved in the conversation.
ToS getting reset to 0 when egress from LTM
Scenario: Micrsoft Lync front-end servers. Their gateway is on the LTM. Client requests to the front-end are balanced by virtual servers on a variety of ports. The Lync servers are configured to mark their SSL-TLS SIP traffic (port 5061) as AF31. From packet captures, I have found that the markings are in tact while traversing the link to the LTM back-end network. However, when getting capture from the front-end interfaces, the DSCP has been reset to 0. I have a TCP profile set on the virtual server that is listening on 5061, which has the options enabled to pass-through ToS and QoS. What else am I missing here? I found a bug that looks somewhat related, but I am not running a SIP profile and this traffic is TCP. http://support.f5.com/kb/en-us/solutions/public/14000/000/sol14019.html
TCP Connection Failed After Adding New Members
TCP Connection Failed After Adding New Members. We have an HTTPS VIP that targets a pool. The VIP is open to the internet and the SSL cert is on the LTM. Formerly the pool had 2 members within the same compartment as the LTM. We recently added 2 new members to the pool. The new members are actually in a different compartment. The traffic has to go out our compartment's firewall and into the other compartment's firewall. (The other compartment is physically located just across the hall.) When we have these two new members activated, our monitoring tools are reporting "TCP connection failed" errors on 5 to 10% of the connections. We also received at least one complaint from customers about receiving intermittent connection errors. As soon as we deactivate the new members, the TCP issues go away. I am thinking we need to tweak the tcp profile but I am open to any suggestions. We are currently using the default tcp profile. The LTM is currently running 11.4.1 hf8. Thanks!mptcp-mobile-optimized and Hardware SYN Cookie Protection
Does anyone know why the TCP protocol profile mptcp-mobile-optimized ships with Hardware SYN Cookie Protection disabled? It is still enabled on tcp-mobile-optimized. Here is a copy of my two profiles, which should be the default: ltm profile tcp mptcp-mobile-optimized { abc disabled app-service none congestion-control illinois defaults-from tcp delay-window-control disabled delayed-acks disabled dsack disabled ecn enabled hardware-syn-cookie disabled init-cwnd 16 limited-transmit enabled mptcp enabled nagle enabled pkt-loss-ignore-burst 0 pkt-loss-ignore-rate 0 proxy-buffer-high 131072 proxy-buffer-low 131072 rate-pace enabled receive-window-size 131072 reset-on-timeout disabled selective-acks enabled send-buffer-size 262144 slow-start enabled timestamps enabled } ltm profile tcp tcp-mobile-optimized { abc disabled app-service none congestion-control high-speed defaults-from tcp delay-window-control disabled delayed-acks disabled dsack disabled ecn enabled init-cwnd 16 limited-transmit enabled nagle enabled pkt-loss-ignore-burst 0 pkt-loss-ignore-rate 0 proxy-buffer-high 131072 proxy-buffer-low 131072 receive-window-size 131072 reset-on-timeout disabled selective-acks enabled send-buffer-size 131072 slow-start enabled timestamps enabled }
javascript fails with var is undefined
We use F5 with several upstream servers without SSL termination, and after our application update we faced some strange issues with undefined variables and pending xhr requests. Is there some advices for configuring F5 for slow and big server responses, does tcp-lan-optimized profile suitable for it?TCP profile selection for small API call traffic
I was reading about TCP profile tcp-lan-optimized and tcp-wan-optimized traffic, currently we are using default tcp profile and we are not seeing any issue so far because our application is all API case so no human interaction or browsing there because our transaction is very small few api call but our traffic coming from all over the world over Internet. Should we use wan and lan tcpd profile? Should i disable Nagle on LAN side and enable it on WAN side? or any other stuff i should keep in mind?
Poor performance from VMware clients
Hello We are experiencing poor performance from VMware-based clients when connecting to an application behind the F5s. If the VMware-based clients connect directly to the back-end server it does not have the poor performance problems. However there are no issues when the client connecting to the F5/Application is a proper hardware laptop. The application end-goal is to retrieve multiple images to the client. This is an internal application, so no Internet facing. In the F5 tcpdumps I see lots of TCP Window Update and TCP Zero Window from the VMware-based client, this is not the case when the client is the hardware laptop. I've tried various tcp-profiles: tcp, tcp-lan-optimized, tcp-legacy, etc. But no luck. Anybody perhaps experienced similar issue? Many thanks,
