Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
May 04, 2009

tcpdump 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?
config
design

6 Replies

Sort By
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    May 04, 2009
    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
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    May 04, 2009
    I 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_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    May 04, 2009
    Thank 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?
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    May 05, 2009
    PVA 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_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 19, 2009
    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_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 19, 2009
    I've created a case with f5 support asking for this solution to be updated with the method suggested above.

     

     

    -Matt