Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Recurrent Curl to a Virtual Server Fails on the Same Subnet

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.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
Comments on this Answer
Comment made 07-Jul-2018 by kazeem yusuf 212

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)

0
Comment made 08-Jul-2018 by boneyard 5579

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.

0
Comment made 09-Jul-2018 by eben 513

In addition, share the output of "tmsh list ltm virtual <virtual-server-name>"

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 10-Jul-2018 by kazeem yusuf 212

Okay Youssef,i would do so and revert. I'm also wary, it may be a problem with the VIRTUAL environment, as that whole subnet is on our Virtual VMware infrastructure

0
Comment made 10-Jul-2018 by youssef 3631

Hi Kazeem,

In all case capture will allow you to check what's happening (don't forget to check snat).

keep me in touch. good luck.

regards

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 05-Aug-2018 by boneyard 5579

interesting, feels like Hyper-V might not accept certain traffic due to unexpected MAC addresses or such.

0