Recurrent Curl to a Virtual Server Fails on the Same Subnet

Forums Technical Forums
, , , , , ,
1

On my network, recurrent curl tests to a virtual server (10.184.1.12) only fail when the source ip is on the same subnet. (eg,10.184.1.78)

When recurrent curl tests are performed from any other subnet (eg,10.243.2.3 or 10.123.34.5) to the destination virtual server (10.184.1.12), they NEVER fail.

Are there any leads to what can warrant this.

2

Hi Kazeem,

It could be that the backend servers are trying to respond directly to the user that initiated the curl instead of F5. If this is the case, the user RST the connection. Do you have SNAT in place?

3

Hi Kazeem,

It could be that the backend servers are trying to respond directly to the user that initiated the curl instead of F5. If this is the case, the user RST the connection. Do you have SNAT in place?

4

another chance is the listening on VLANs setting, is that enabled and not on all VLANs?

5

HI,EBEN,SNAT is in place.

However,I have a one-armed mode scenario.

The virtual server,back-end servers and snatch pools are all in the same subnet (10.184.1.x)

6

HI,EBEN,SNAT is in place.

However,I have a one-armed mode scenario.

The virtual server,back-end servers and snatch pools are all in the same subnet (10.184.1.x)

7

packet captures will probably help a lot, one on the big-ip to see where traffic halts and one on the server to see what happens there.

8

packet captures will probably help a lot, one on the big-ip to see where traffic halts and one on the server to see what happens there.

9

In addition, share the output of "tmsh list ltm virtual "

10

In addition, share the output of "tmsh list ltm virtual "

11

Hi,

Can you check that snat is set to automap (to avoid asymetric routing).

Then during curl can you process a capture:

tcpdump -nni 0.0 host 10.184.1.12 and host 10.184.1.xxx

where 10.184.1.xxx is your source IP in the same subnet that you VS.

You can see firts if you have an response from F5 and if the response come from Self IP.

Keep me update.

regards

12

Hi All, Thanks for your help,after further trubleshooting,i made a discovery with the help of our Virtualization team. The problem only exists on nodes built with Microsoft Hyper-V, but the Virtual machines built with VMWARE don’t have the problem.

I will find out why that behavior existson Hyper-V and update here.

Thanks,All