Forum Discussion
pjcampbell_7243
Cirrus
CirrusWeird timeouts - any insight
We have a new subnet call it 10.1.18.0 - and only one pool of ours has one pool member on this new subnet.
When I enabled the new pool member, we get very long response times (15-30) seconds on every 7th-10th request (approx. 13 pool members and we are doing round robin).
The timeout occurs on ALL pool members, Not necessarily the member on the new subnet. When we disable the pool member on the new subnet everything instantly works perfectly again.
Can anyone suggest what is going on.
The BIGIP does not have an IP on that new 10.1.18.0 subnet in the self IP list. Not sure if this is relevant or not.
hoolioCirrostratus
Hi PJ,
I can't think of a reason that this would be happening. Maybe incompatible source port reuse? Are you using SNAT for the communication from LTM to the pool members?
Anyhow, I'd suggest capturing tcpdumps on LTM of a failure. You'll want to get the client and serverside communication. You can use a tcpdump command like this to get both sides of traffic:
tcpdump -ni 0.0 -s0 -w/var/tmp/trace.1.dmp host VIP_IP or host NODE_1_IP or host NODE_2_IP or host NODE_3_IP
As this captures all traffic to the virtual server and pool member IP addresses, it could get big quickly. So try to stop the trace as soon as a failure occurs. You can use WinSCP to copy the trace off the unit and Wireshark to analyze it. If you need any help with the capture and analysis you can open a case with F5 Support.
Aaron
pjcampbell_7243Thanks I'll try to do some tcpdumping.
We are using auto map for SNAT. Could it be an issue that the BIGIP doesn't have a self-IP on this subnet? Usually with auto snat the source address from the F5 ends up being the same subnet as the pool member I believe. This is the only subnet we have where the BIGIP does not have a self IP on the same subnet as the pool member... Thanks again.