Lab 5: Support and Troubleshooting

In this lab you will review basic troubleshooting commands on the BIG-IP

Objective:

• Perform a TCPDump to watch traffic flow.
• Obtain web page information via Curl.

Troubleshoot using TCPDump or Curl.

1. Go to your www_vs (10.1.10.100) virtual server and set Source Address Translation to None.
   1. Now browse the web site. You will not be able to access it even though the status of the virtual is available.
      1. Because BIG-IP is not the server’s default gateway the server’s response goes around the BIG-IP.
   2. The web administrator tells you everything is fine as far as he can see and thinks the issue is with the BIG-IP, because they ALWAYS think the issue is with the BIG-IP.
   3. You begin by debugging the client connections to the web servers through the BIG-IP using TCPDump.
2. SSH to the management port of your BIG-IP. Remember the BIG-IP is a full proxy. You will need two TCP dumps and therefore two SSH windows for the client-side connection and the server-side connection.
   1. First let’s see what if we are hitting the virtual server. At the Linux CLI prompt:
      1. tcpdump –i <client vlan name> host –X –s128 10.1.10.100 and port 80
         1. This is a little overkill, but a good example of syntax. We will only look at traffic headed for the virtual server, we will see the first 128 bytes (-s128) in ASCII (-X).
   2. Go to your browser and attempt to access the virtual server. You should see something like this:

17:38:40.051122 IP 10.1.10.1.43932 > 10.1.10.100.http: S522853636:522853636(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
0x0000: 0ffe 0800 4500 0034 0a40 4000 4006 0699 ....E..4.@@.@...
0x0010: 0a80 0a01 0a80 0aeb ab9c 0050 1f2a 1d04 ...........P.*..
0x0020: 0000 0000 8002 2000 3d10 0000 0204 05b4 ........=.......
0x0030: 0103 0302 0101 0402 ........
17:38:40.051169 IP 10.1.10.100.http > 10.1.10.1.43932: S 245310500:245310500(0) ack 522853637 win 4380 <mss 1460,sackOK,eol>
0x0000: 0ffe 0800 4500 0030 27ef 4000 ff06 29ed ....E..0'.@...).
0x0010: 0a80 0aeb 0a80 0a01 0050 ab9c 0e9f 2424 .........P....$$
0x0020: 1f2a 1d05 7012 111c 2a0e 0000 0204 05b4 .*..p...*.......
0x0030: 0402 0000 ....
17:38:40.053644 IP 10.1.10.1.43932 > 10.1.10.100.http: . ack 1 win 64240
0x0000: 0ffe 0800 4500 0028 0a41 4000 4006 06a4 ....E..(.A@.@...
0x0010: 0a80 0a01 0a80 0aeb ab9c 0050 1f2a 1d05 ...........P.*..
0x0020: 0e9f 2425 5010 faf0 7018 0000 ..$%P...p...
17:38:40.053648 IP 10.1.10.1.43932 > 10.1.10.100.http: P 1:416(415) ack 1 win 64240
0x0000: 0ffe 0800 4500 01c7 0a42 4000 4006 0504 ....E....B@.@...
0x0010: 0a80 0a01 0a80 0aeb ab9c 0050 1f2a 1d05 ...........P.*..
0x0020: 0e9f 2425 5018 faf0 43c5 0000 4745 5420 ..$%P...C...\ GET.
0x0030: 2f20 4854 5450 2f31 2e31 0d0a 486f 7374 /.HTTP/1.1..Host
0x0040: 3a20 3130 2e31 3238 2e31 302e 3233 350d :.10.1.10.100.

3. From the dump you can see you are are hitting the virtual server. Your original client IP is in the first line of the dump 16:44:58.801250 IP <client_ip>.41536 > 10.1.10.100.http: going to the virtual server. The dump clip shows the TCP three-way handshake between the client and the virtual server and the initial part of the request GET/ HTTP/1.1 Host: 10.1.10.100

3. In the second SSH window we will do an expanded tcpdump for the sake of interest.
   1. tcpdump –i <server vlan name> -X –s128 host <client IP>
   2. Hit your virtual server again. You see packets with your client IP heading for the servers. They just aren’t responding. So we could reasonably suspect a server issue.
4. First, let’s check to see if the server is responding to HTTP on port 80. On the BIG-IP in an SSH window:
   1. Do a <ctrl-c> to escape out of tcpdump, if you are still in it, and use curl to test the server. You should get output similar to to whats below.

curl –i <server ip of a pool member

You should get output similar to what is below. The -i switch tells curl to output the HTTP header information also.

[admin@ip-10-1-1-4:Active:Standalone] ~ # curl -i 10.1.20.11
HTTP/1.1 200 OK
Date: Tue, 29 Jun 2021 18:49:41 GMT
Server: Apache/2.4.10 (Debian)
X-Powered-By: PHP/7.0.17
Cache-Control: no-cache
Vary: Accept-Encoding
X-COLOR: (null)
Content-Length: 7819
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <!-- The above 3 meta tags *must* come first in the head; any other head content must come *after* these tags -->
    <title>F5 vLab | Home</title>

2. The server is responding to the BIG-IP when directly connected, but not through the virtual server. Sounds like the server is routing around the BIG-IP, which means the BIG-IP is not the default gateway.

Turn SNAT Automap back on the www_vs virtual server