IPV6 logging question

Generally speaking, I would start with

tcpdump

• SOL411: Overview of packet tracing with the tcpdump utility

It's usually easiest to dump on the 0.0 interface (which captures traffic copied between the switch and forwarding planes) first, as in:

tcpdump -nni 0.0 host 

where is the IP address of traffic from a client. If you are not using SNAT on the Virtual Server, you should see the traffic arrive on the client-side and be proxied on the server-side. For example, if the client is [2002:abcd::1], the Virtual Server is [2001:0101::a:200]:80, and the Pool Member is [2001:0101::b:a]:80, then you should expect to see a flow like this:

  [2002:abcd::1]  -  [ SYN ]      -> [2001:0101::a:200]:80
  [2002:abcd::1]  <- [ SYN, ACK ] -  [2001:0101::a:200]:80
  [2002:abcd::1]  -  [ ACK ]      -> [2001:0101::a:200]:80
  
  [2002:abcd::1]  -  [ SYN ]      -> [2001:0101::b:a]:80
  [2002:abcd::1]  <- [ SYN, ACK ] -  [2001:0101::b:a]:80
  [2002:abcd::1]  -  [ ACK ]      -> [2001:0101::b:a]:80

That is, you should see the completion of the TCP three-way handshake on the client-side, then the same on the server-side (notice that, on the server-side, without SNAT, the source address matches the address of the client). If you are using the http profile on the Virtual Server, you may see one or more additional packets between the client-side and the server-side handshakes (this is http late-binding). Naturally, if your Virtual Server is UDP, or an IP Forwarding Virtual Server, things will look different.

If you don't see a flow like this, look for TCP RSTs coming either from the BIG-IP directly, or from the Pool Member (which would then be proxied to the client). If rests are being sourced from the BIG-IP itself, you can log the reason:

• SOL13223: Configuring the BIG-IP system to log TCP RST packets

If there are no resets, then verify that ARP is completing on the server-side:

tcpdump -nni 0.0 arp