TCP close vs active close and timers
Hi, I already read few great post here as well as some articles but I am still not sure how things are working on BIG-IP. First of all I wonder if there is a way to monitor connection states via some command on BIG-IP (like FIN_WAIT, TIME_WAIT etc.). I know on the host subsystem netstat -ano can be used, but this command is not reporting any TMM managed connections. When tmsh show sys connection cs-client-addr all-properties is used there is as well no info about current connection state. I can probably use tmsh show ltm profile tcp for that - but that is only possible in test environment when I can just send single connection, not so easy in production 😞 So I can do watch -n 1 'tmsh show ltm profile tcp lamp-cs-tcp-lan-optimized | grep 'Connections' -A9' for that. Now I have issue which timers are used on what situation. Scenario 1 (all performed on v11.2.0HF7) Client connects to VS BIG-IP send FIN-ACK to client What kind of close is used for such scenario? Rather not standard close when connection initiator (client) sends FIN, so I guess active close like that: Now which timers will be used for such case by BIG-IP? My guess is: Fin Wait Close Wait Time Wait Let's say BIG-IP received ACK to FIN but not FIN from client. Which timer will be used? What state connections is - still FIN_WAIT_1? Or not because there is no FIN from client? From monitoring I can see that BIG-IP is entering FIN-WAIT/CLOSING state and stays in this state until Idle Timeout expires - pitty that there is no way to say if it's FIN-WAIT or CLOSING state. Why so? Because there is no FIN from client? If I will send FIN-ACK from client then connection enters TIME-WAIT state immediately after BIG-IP replies with ACK. So why Fin Wait timer is not triggered here? Scenario 2 Client connects to VS Client send FIN-ACK to BIG-IP I assume that we have now standard close like that: Timers used seems to be only: Close Wait Time Wait Fin Wait is not used as this is state on client side not on BIG-IP side - or I am wrong? Another question is what action is performed after each timer expires (assuming BIG-IP closes connection - I guess happens usually more often on server side than client side): Fin Wait - BIG-IP already send FIN, entered FIN_WAIT_1, no ACK from client. Will this timer be triggered, if so what will happen when expired: RST from BIG-IP (if Reset On Timeout enabled?) Nothing Timer will not trigger and Idle Timeout will be used - consider that from test it seems that nothing happens and Idle Timeout is used Close Wait - BIG-IP received FIN from client, entering CLOSING state, same question as above - what happen if there will be no ACK to BIG-IP FIN? Time Wait - BIG-IP send ACK to client FIN and received ACK to its own FIN - that part seems to be working, TIME-WAIT state is reported and disappear after Time Wait timeout (2s) PiotrCan you stop RST from being sent by VIP
I work for a large regional public transportation company. We are in the beginning process of rolling out phones with a VoIP over the top application on them. This will eliminate the need for radios (radio transmittion towers are now very expensive). I have determined that, for whatever reason, these phones send a DNS request on TCP port 853 and with that the VIP sends an RST to the requesting phone. That in turn resets the connection, the VoIP app beeps, disconnects for 30 sends, and then reconnects. I have both the phone and app vendor looking at this but thought I would see what it would take to mask this problem from the F5 side. I do realize that all DNS traffic currently hits this VIP, so at this time I am only exploring my options. John
