There are three servers in the pool: 172.16.20.1, 172.16.20.2, and 172.16.20.3, with the virtual IP address
10.0.20.88.
A user CANNOT connect to an HTTP application. To understand the problem and find a solution, the LTM Specialist runs two concurrent traces on the LTM device, with the following results:
Trace on client side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.423759 IP 172.16.20.100.53875 > 10.0.20.88.80: S 998346084:998346084(0) win 5840 <mss
1460,sackOK,timestamp 67942058 0,nop,wscale 4>
22:22:07.424056 IP 10.0.20.88.80 > 172.16.20.100.53875: S 4671780:4671780(0) ack 998346085 win
4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392362490 67942058,sackOK,eol>
22:22:07.424776 IP 172.16.20.100.53875 > 10.0.20.88.80: . ack 1 win 365 <nop,nop,timestamp 67942058
2392362490>
22:22:07.424790 IP 172.16.20.100.53875 > 10.0.20.88.80: P 1:149(148) ack 1 win 365
<nop,nop,timestamp 67942058 2392362490>
22:22:07.424891 IP 10.0.20.88.80 > 172.16.20.100.53875: . ack 149 win 4528 <nop,nop,timestamp
2392362491 67942058>
22:22:12.024850 IP 10.0.20.88.80 > 172.16.20.100.53875: R 1:1(0) ack 149 win 4528
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Trace on server side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on internal, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.424881 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss
1460,nop,wscale 0,nop,nop,timestamp 2392362491 0,sackOK,eol>
22:22:08.424893 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss
1460,nop,wscale 0,nop,nop,timestamp 2392363491 0,sackOK,eol>
22:22:09.625082 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss
1460,nop,wscale 0,nop,nop,timestamp 2392364691 0,sackOK,eol>
22:22:10.825194 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss
1460,sackOK,eol>
4 packets captured
4 packets received by filter
0 packets dropped by kernel
What should the LTM Specialist do to solve the problem?
-- Exhibit -
-- Exhibit --
Refer to the exhibit.
A server administrator notices that one server is intermittently NOT being sent any HTTP requests. The server logs display no issues. The LTM Specialist notices log entries stating the node (172.16.20.1) status cycling between down and up. The pool associated with the virtual server (10.10.1.100) has a custom HTTP monitor applied.
Which tcpdump filter will help trace the monitor?
A web developer has created a custom HTTP call to a backend application. The HTTP headers being sent by the HTTP call are:
GET / HTTP/1.1
User-Agent: MyCustomApp (v1.0)
Accept: text/html
Cache-Control: no-cache
Connection: keep-alive CookiE. somecookie=1
The backend server is responding with the following:
HTTP/1.1 400 Bad Request DatE. Wed, 20 Jul 2012 17:22:41 GMT Connection: close
Why is the HTTP web server responding with a HTTP 400 Bad Request?
-- Exhibit-
-- Exhibit -
Refer to the exhibit.
Users receive an error when attempting to connect to the website https://website.com. The website has a DNS record of 195.56.67.90. The upstream ISP has confirmed that there is nothing wrong with the routing between the user and the LTM device.
The following tcpdump outputs have been captured:
External Vlan, filtered on IP 168.210.232.5
00:25:07.598519 IP 168.210.232.5.33159 > 195.56.67.90.https: S 1920647964:1920647964(0) win 8192 <mss 1450,nop,nop,sackOK>
00:25:07.598537 IP 195.56.67.90.https > 168.210.232.5.33159: S 2690691360:2690691360(0) ack 1920647965 win 4350 <mss 1460,sackOK,eol>
00:25:07.598851 IP 168.210.232.5.33160 > 195.56.67.90.https: S 2763858764:2763858764(0) win 8192 <mss 1450,nop,nop,sackOK>
00:25:07.598858 IP 195.56.67.90.https > 168.210.232.5.33160: S 1905576176:1905576176(0) ack 2763858765 win 4350 <mss 1460,sackOK,eol>
Internal Vlan, filtered on IP 168.210.232.5
00:31:46.171124 IP 168.210.232.5.33202 > 192.168.100.20.http: S 2389057240:2389057240(0) win 4380 <mss 1460,nop,wscale 0,sackOK,eol>
What is the problem?
-- Exhibit -
-- Exhibit --
Refer to the exhibit.
The virtual server is listening on port 443.
What is the solution to the problem?
