Forum Discussion
Ryan_Bachman_78
Jan 30, 2012Nimbostratus
TCP profile and Idle Timout
Hello -
Hoping someone can help me identify why the expected RST is not being sent. I have an issue with long running AJAX sessions running on my web servers. We recently switched from LVS to bigip LTMs, and rather than figure out a solution in our application code, wanted to see if the idle timeout on the F5 would help us. In a test environment, I have a tcp profile set to enable reset on timeout and a value of 120 seconds. I start a session for a client, and then browse away and watch the idle time climb. Eventually hits 360 seconds (even though a b client x.x.x.x idle timeout shows 120) where my php code closes the session with a FIN, ACK. Don't know where else to check on my system as to why it won't send a rst when the idle time hits 120 on the session.
Thanks for all the help.
- hooleylistCirrostratusHi Ryan,
- nitassEmployeejust in case you have not yet seen this sol.
- Ryan_Bachman_78NimbostratusThanks to both of you for the quick reply. So is it my understanding that I can't enforce timeouts using Auto SNAT? Is there really no way to configure this setting? The lvs I replaced was configured for direct return, so in order to install the F5 in a transparent fashion, we deployed it in a 'router on a stick' fashion. If I switch the VS to use fasthttp profile, I have a solution to my problem, but the business wants to maintain original IPs so I need to inject XFF headers into the requests. All my traffic is HTTPS, so fasthttp is not an option at this time. I am including the config of the VS, but it sounds like I know my answer. Just don't know if there is an easy solution to my problem. Thanks.
- mikand_61525NimbostratusDo you need snat automap then?
- Ryan_Bachman_78NimbostratusI agree with your assessment that the one arm configuration might not be the best solution, but at this time it is what I have to work with. I needed something that provided a zero downtime implementation, and I have multiple services on what you would consider the internal subnet, that need to call into the Virtual Servers. How would the F5 handle traffic for requests to a VIP on the external interface, just to turn it around and load balance it back in. There are other factors that led me to decide with a one arm deployment as well. I might re-address the architecture at a later date, now I am just frustrated with getting this LTM to send out RSTs when my connections exceed the idle timeout settings. I like your suggestion, and will start exploring what that is going to take to get done.
- nitassEmployeemy bigip seems sending reset correctly after timeout (10 seconds). do you have packet trace file? is there any suspicious there?
[root@ve1023:Active] config b virtual bar list virtual bar { snat automap pool foo destination 172.28.19.79:23 ip protocol 6 profiles mytcp {} } [root@ve1023:Active] config b pool foo list pool foo { members 200.200.200.101:23 {} } [root@ve1023:Active] config b profile mytcp list all|grep -i 'reset\|idle\ timeout' reset on timeout enable idle timeout 10 [root@ve1023:Active] config b self 200.200.200.10 list self 200.200.200.10 { netmask 255.255.255.0 vlan internal allow default } [root@ve1023:Active] config tcpdump -nni 0.0 port 23 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes 18:41:28.917155 IP 192.168.206.154.59953 > 172.28.19.79.23: S 1839157534:1839157534(0) win 8192 18:41:28.917199 IP 172.28.19.79.23 > 192.168.206.154.59953: S 3471835166:3471835166(0) ack 1839157535 win 3780 18:41:28.919066 IP 192.168.206.154.59953 > 172.28.19.79.23: . ack 1 win 260 18:41:28.919113 IP 200.200.200.10.59953 > 200.200.200.101.23: S 3121687173:3121687173(0) win 4380 18:41:28.920109 IP 200.200.200.101.23 > 200.200.200.10.59953: S 1369647150:1369647150(0) ack 3121687174 win 5840 18:41:28.920119 IP 200.200.200.10.59953 > 200.200.200.101.23: . ack 1 win 4380 18:41:31.803183 IP 192.168.206.154.59953 > 172.28.19.79.23: P 91:93(2) ack 141 win 260 18:41:31.803204 IP 200.200.200.10.59953 > 200.200.200.101.23: P 91:93(2) ack 141 win 4520 18:41:31.803209 IP 172.28.19.79.23 > 192.168.206.154.59953: . ack 93 win 3872 18:41:31.804131 IP 200.200.200.101.23 > 200.200.200.10.59953: . ack 93 win 46 18:41:31.804143 IP 200.200.200.101.23 > 200.200.200.10.59953: P 141:143(2) ack 93 win 46 18:41:31.804149 IP 172.28.19.79.23 > 192.168.206.154.59953: P 141:143(2) ack 93 win 3872 18:41:31.904491 IP 200.200.200.10.59953 > 200.200.200.101.23: . ack 143 win 4522 18:41:31.905163 IP 200.200.200.101.23 > 200.200.200.10.59953: P 143:237(94) ack 93 win 46 18:41:32.005274 IP 200.200.200.10.59953 > 200.200.200.101.23: . ack 237 win 4616 18:41:32.010343 IP 192.168.206.154.59953 > 172.28.19.79.23: . ack 143 win 260 18:41:32.010358 IP 172.28.19.79.23 > 192.168.206.154.59953: P 143:237(94) ack 93 win 3872 (1) 18:41:32.213283 IP 192.168.206.154.59953 > 172.28.19.79.23: . ack 237 win 259 (2) 18:41:43.870221 IP 200.200.200.10.59953 > 200.200.200.101.23: R 93:93(0) ack 237 win 4616 (3) 18:41:43.870241 IP 172.28.19.79.23 > 192.168.206.154.59953: R 237:237(0) ack 93 win 3872
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects