I've noticed in other cases this inability to capture tcpdump traces when a Forwarding (IP) virtual server is involved. Can someone explain to me why I can't see this traffic?
In addition with normal virtual server communication, the LTM maintains seperate client and server TCP connections which can be managed independently with seperate TCP profiles. Does the LTM manage also seperate TCP connections in Forwarding (IP) Virtual Server traffic in a similar manner, or are these TCP connections not managed at all?
If the forwarder shows Full or Assisted for PVA acceleration, then that's likely the problem. You can create a fastL4 profile that specifically disables PVA and apply that to the forwarding virtual and then you should be able to see the traffic.
If you want to be more granular, you could create a forwarding virtual specifically for the application port involved and just apply the modified profile to that. That way you won't affect other traffic.
I have had situations where PVA acceleration caused problems for certain applications, so you can either turn PVA off as a temporary troubleshooting method, or you may find that leaving it off fixes your packet loss problem as well.
I still have a question about how the LTM handles connections. Is there a concept of "Server" and "Client" TCP profiles/connections with PVA-assisted traffic? Or are such connections completely unmanaged?
SOL 4832 has links to several pdf's (version specific) with tables showing what features will demote PVA from full and/or assisted acceleration. (Click here)
I personally think this is way cleaner than the solution's (sol6546) method because you'll not impact any other Virtual Servers that use the parent fastl4 profile. Profile inheritance is a Good Thing!