Forum Discussion
New Virtual Servers are sending RESETS to all the traffic
Hello Everyone! On our F5 cluster, if we create any new VS, it is just Reseting all the traffic. Configuration of one of the VS is as
ltm virtual VPN { description VPN_VS destination 10.194.1.155:https fallback-persistence ABC_desti ip-protocol tcp mask 255.255.255.255 persist { ABC_source { default yes } } pool XYZ profiles { clientssl { context clientside } tcp { } } source 0.0.0.0/0 source-address-translation { type automap } vs-index 21 }
(tmos) list ltm pool XYZ ltm pool XYZ { description "ABC Production" members { AEABUABCAPP01.FGHDJ.COM:hosts2-ns { address 10.194.1.176 session monitor-enabled state up } aeabuABCapp02.FGHDJ.com:hosts2-ns { address 10.194.1.177 session monitor-enabled state up } } monitor http
}
TCPDUMP of the VS
11:04:08.432224 IP 10.194.1.52.56387 > 10.194.1.155.https: SWE 2768861009:2768861009(0) win 8192 11:04:08.432271 IP 10.194.1.155.https > 10.194.1.52.56387: R 0:0(0) ack 2768861010 win 0 11:04:08.432276 IP 10.194.1.52.56388 > 10.194.1.155.https: SWE 3343896122:3343896122(0) win 8192 11:04:08.432287 IP 10.194.1.155.https > 10.194.1.52.56388: R 0:0(0) ack 3343896123 win 0 11:04:08.694935 IP 10.194.1.52.56389 > 10.194.1.155.https: SWE 2484741480:2484741480(0) win 8192 11:04:08.694960 IP 10.194.1.155.https > 10.194.1.52.56389: R 0:0(0) ack 2484741481 win 0 11:04:08.934903 IP 10.194.1.52.56387 > 10.194.1.155.https: S 2768861009:2768861009(0) win 8192 11:04:08.934951 IP 10.194.1.155.https > 10.194.1.52.56387: R 0:0(0) ack 1 win 0 11:04:08.934956 IP 10.194.1.52.56388 > 10.194.1.155.https: S 3343896122:3343896122(0) win 8192 11:04:08.934967 IP 10.194.1.155.https > 10.194.1.52.56388: R 0:0(0) ack 1 win 0
=============================================================================
After enabling RESET logging following logs were taken
Mar 19 09:38:07 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50811, [0x1ee0645:1729] Policy action Mar 19 09:38:07 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50812, [0x1ee0645:1729] Policy action Mar 19 09:38:07 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50811, [0x1ee0645:1729] Policy action Mar 19 09:38:07 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50812, [0x1ee0645:1729] Policy action Mar 19 09:38:08 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50811, [0x1ee0645:1729] Policy action Mar 19 09:38:08 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: Per-invocation log rate exceeded; throttling. Mar 19 09:38:09 EMS-AAT-LB-1 err tmm1[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50813, [0x1ee0645:1729] Policy action Mar 19 09:38:09 EMS-AAT-LB-1 err tmm1[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50813, [0x1ee0645:1729] Policy action Mar 19 09:38:10 EMS-AAT-LB-1 err tmm1[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50810, [0x1ee0645:1729] Policy action Mar 19 09:38:10 EMS-AAT-LB-1 err tmm1[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50813, [0x1ee0645:1729] Policy action
============================================================================== Now I dont know what to make out of these reset logs. Can someone please look into this
- Andy_McGrath
Cumulonimbus
Resets are being send because of Policy action
According to your logs you are hitting the Virtual Server address on port 80 not 443:
Mar 19 09:38:07 EMS-AAT-LB-1 err tmm[19589]: 01230140:3: RST sent from 10.194.1.155:80 to 10.194.1.52:50811, [0x1ee0645:1729] Policy action
Your TCP dump is showing you are hitting port 443 but could be for a different reason. Test again and post the logs when you are hitting HTTPS and check the reason code here: K13223: Configuring the BIG-IP system to log TCP RST packets
Recent Discussions
Related Content
* 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