Forum Discussion

sundogbrew's avatar
sundogbrew
Icon for Altocumulus rankAltocumulus
Jul 17, 2015

IPV6 logging question

So I have a VIP that seems to be getting IPV6 traffic but the pool isn't incrementing, I am looking for a way to log to see where it is breaking along the way? Or any other suggestion of how to figure that out. Thanks Joe

 

2 Replies

  • Generally speaking, I would start with

    tcpdump
    :

    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:

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

    tcpdump -nni 0.0 arp
    
  • Thanks Vernon, Thats exactly what I was looking for. I will try that out. Thanks Joe