Forum Discussion
Steffen_Beach_8
Nimbostratus
NimbostratusNew connections going to wrong default pool
Hey all,(Default Pool: ApplicationX_a)(Default Pool: WebServiceX_a)(Default Pool: ApplicationX_b)(Default Pool: WebServiceX_b)instantaneously using tmsh scripts, yet for minutes on end we see new connections going to WebServiceX_a pools. We don't have persistence enabled and our applications don't maintain connections to our services. We've been doing our deployments this way for over a year without any issues, but recently we started seeing exceptions from our application. In the exception we could see that old methods from v1.0 were being called. This got us looking at the ltm and we realized that not all new connections were going to the WebServiceX_b pool.
I've got a bit of a problem and I'm trying to get a better understanding of the ltm behavior to help solve a problem.
As part of our regular code deployments, our process is to change the default pool mapped to our application and web service virtual servers to redirect traffic to members in pools with updated code.
Ex. ApplicationX makes SOAP calls to WebServiceX
VirtualServer ApplicationX
Pool ApplicationX_a (members: 1-10 code version 1.0)
Pool ApplicationX_b (members: 11-20 code version 1.1)
VirtualServer WebServiceX
Pool WebServiceX_a (members: 1-10 code version 1.0)
Pool WebServiceX_b (members: 11-20 code version 1.1)
Once code is tested and ready for production, we remap the default pools for the VirtualServers as such:
VirtualServer ApplicationX
Pool ApplicationX_a (members: 1-10 code version 1.0)
Pool ApplicationX_b (members: 11-20 code version 1.1)
VirtualServer WebServiceX
Pool WebServiceX_a (members: 1-10 code version 1.0)
Pool WebServiceX_b (members: 11-20 code version 1.1)
This happens almost
Any ideas why this is happening?
Thanks,
-Beach
hoolioCirrostratus
Hi Steffen,
If the existing client connections have been closed and you see new client connections being sent to the old pools, the only thing I can think of is OneConnect allowing use of existing connections. Do you have OneConnect enabled on the virtual server? If so, one option might be to clear the connection table entries for the specific virtual server. You can do this with b conn. See the 'b conn help' output for details on this.
Aaron- Steffen_Beach_8Aaron,
We're not using OneConnect. I mentioned to our systems team that after they flip to the new pool to run 'b conn server delete' if they see traffic still going to the old pool, but it's just odd that we'd have to do this. We're going to do a deployment tonight so I'm going to write out the traffic information to a file for additional analysis. I'll see what I can come up with.
I wish I could 'b conn server ' via the iControl API. I have a web interface that I could wire up quickly to query and capture data opposed to having a putty session output to a file. - hoolioI'd actually recommend opening a case on this and getting feedback from Support. If you're willing to test this again, they'd probably be looking for tcpdumps during the switch along with 'b conn all show all' output.
Aaron