Forum Discussion
TCPDUMP capture for Performance Virtual Server
Hi Team,
We are having issue with VIP which is configured with Performance(Layer 4) Virtual Server.
Issue: Application hosted on back-end server is not accessible through VIP. but when we directly try to access the backend server from internal network.. they are able to access..
Observation: We suspect that return route from back end server.. we are not sure whether next-hop gateway for route in server is floating IP on f5 or Firewall IP (L3) . That we yet to check WITH server team...(not getting response from back server team)..
Meanwhile What I thought is that I can do tcpdump capture on LTM for Performance(Layer 4) Virtual Server (VIP) and try to see something i can find in it.
Do I need to capture tcpdump between Client IP and Backend Server.? or between client IP and VIP IP..?
I am unable to understand how to capture the tcpdump for connection flow because tcp session flow for Performance(Layer 4) Virtual Server is different that standard virtual server..?
please help me
First, you can change your your VS to use Auto-map. This would solve the next-hop problem.
Second, you can use this command to capture traffic (from both sides, client and server).
tcpdump -s0 -nnei 0.0:nnnp host <vip> -c 100
REF - https://support.f5.com/csp/article/K13637
KR,
Dario.
- girishbCirrus
Thanks Dario...
I tried with enabling the Automap
on VIP. But it did not work. .
Also captured the tcpdump.. We
found that destination server(backend server) is trying to send multiple
re-transmission SYN-ACK packets as its not receiving ACK packet for SYN-ACK
packets and finally session ending with RST packet from backend server..
We suspect that reverse route
from F5 LTM to back source (client) is having issue. We are checking with
firewall team and also network team to check path
If auto-map is not working, this could be because you are filtering the source IP in one of your firewalls.
Also, take into account that if your SYN-ACK is not reaching your client this could be because your response is sending to the client using a different path (asymmetric traffic) which could be filtering by spoofing in your firewall.
The better way to troubleshoot this is to use tcpdump in any other devices trying to figure out the current path.
BTW, if my last answer was helpful, please remember to set it as "the best" or give me some upvotes.
KR,
Dario.
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