Forum Discussion
smp_86112
Cirrostratus
Cirrostratustcpdump and Forwarding (IP) Virtual Servers
I am trying to isolate a problem which is resulting in packet loss. The source device is in an external VLAN, and the destination is in an internal VLAN. Simultaneous traces show that the source is sending segments which are not being received by the destination. The problem I've got is that I need to prove that the LTM isn't receiving the lost packets - that the source of the drops is upstream of the LTM. But the traffic destined for the internal VLAN is routed through a Forwarding (IP) virtual server, and I can't use tcpdump to capture it - so I can't prove the LTM isn't at fault. I've tried using the external vlan, the interface number of the external vlan, and interface 0.0 - none are capturing the traffic. Yet if I run tcpdump in the destination directly, I see the traffic being received (with the exception of the lost packets) so I know the LTM is routing it.
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?
- dennypayne
Employee
What you are probably missing is the PVA accelerated traffic. If the traffic is processed inside the ASIC then tcpdump never sees it.
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.
Denny - dennypayneI should add that the PVA no longer exists in newer platforms ( 1600, 3600, 6900, 8900 ). FPGA's have replaced it since they are faster now.
Denny 
smp_86112Thank you for your response - with your help, I even found the doc I had been searching for which explicitly supports your statement: SOL6546">Click here.
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?- dennypaynePVA can only assist with Layer 4 packet-by-packet connections. So any time you invoke the full proxy in tmm (which you have to do in order to use a Standard virtual with separate clientside and serverside TCP profiles), you won't get any PVA acceleration.
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)
Denny 
L4L7_53191Nimbostratus
Regarding the solution linked to above, I personally get nervous changing settings on any 'parent' level profile, so a clean and easy trick is to create a custom fast l4 profile with a name you'll remember - something like "no_pva_trace". It'll inherit all of the parent l4 profile's attributes and then you can disable just the setting(s) you're after. The next time you need to run a dump you can simply bind this custom profile to your VS and do your debugging.
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!
-Matt- L4L7_53191I've created a case with f5 support asking for this solution to be updated with the method suggested above.
-Matt
