Exam F5CAB5 Topic 3 Question 44 Discussion
Actual exam question for F5's F5CAB5 exam
Question #: 44
Topic #: 3
Question #: 44
Topic #: 3
A BIG-IP Administrator configured a virtual server with a pool of 3 members and selected the Round Robin load balancing method to evenly distribute traffic across the pool members. During initial testing, the virtual server failed to respond to http requests.
Plaintext
ltm virtual http.vs {
destination 10.10.1.100:http
ip-protocol tcp
mask 255.255.255.255
pool http.pool
profiles {
tcp{}
}
serverssl-use-sni disabled
source 0.0.0.0/0
translate-address enabled
translate-port enabled
}
ltm pool http_pool {
members {
10.10.1.101:http {
address 10.10.1.101
session monitor-enabled
state checking
}
10.10.1.102:http {
address 10.10.1.102
session monitor-enabled
state checking
}
}
monitor tcp
}
What configuration change on the BIG-IP will resolve this issue?
Plaintext
ltm virtual http.vs {
destination 10.10.1.100:http
ip-protocol tcp
mask 255.255.255.255
pool http.pool
profiles {
tcp{}
}
serverssl-use-sni disabled
source 0.0.0.0/0
translate-address enabled
translate-port enabled
}
ltm pool http_pool {
members {
10.10.1.101:http {
address 10.10.1.101
session monitor-enabled
state checking
}
10.10.1.102:http {
address 10.10.1.102
session monitor-enabled
state checking
}
}
monitor tcp
}
What configuration change on the BIG-IP will resolve this issue?
Suggested Answer: A Vote an answer
The issue described is a classic case of asymmetric routing in a "one-arm" or same-subnet topology.
Symptom Analysis: The Virtual Server (10.10.1.100) and the pool members (10.10.1.101 and 10.10.1.102) are on the same subnet.
The Problem: When a client sends a request to the VIP, the BIG-IP translates the destination IP but keeps the client's original source IP. The server receives the packet and sees a source IP from a different subnet. Instead of sending the response back to the BIG-IP, the server sends it directly to its default gateway. The client receives a response from the server's IP, which it doesn't recognize, causing the connection to fail.
The Solution: Enabling SNAT Auto Map ensures the BIG-IP changes the source IP of the packet to its own self-IP. This forces the pool member to send the response back to the BIG-IP, which then translates it correctly and sends it to the client.
Incorrect Options: Adding an HTTP profile (Option B) or an HTTP monitor (Option C) would enhance the configuration but would not fix the underlying Layer 3 routing issue causing the traffic drop.
Symptom Analysis: The Virtual Server (10.10.1.100) and the pool members (10.10.1.101 and 10.10.1.102) are on the same subnet.
The Problem: When a client sends a request to the VIP, the BIG-IP translates the destination IP but keeps the client's original source IP. The server receives the packet and sees a source IP from a different subnet. Instead of sending the response back to the BIG-IP, the server sends it directly to its default gateway. The client receives a response from the server's IP, which it doesn't recognize, causing the connection to fail.
The Solution: Enabling SNAT Auto Map ensures the BIG-IP changes the source IP of the packet to its own self-IP. This forces the pool member to send the response back to the BIG-IP, which then translates it correctly and sends it to the client.
Incorrect Options: Adding an HTTP profile (Option B) or an HTTP monitor (Option C) would enhance the configuration but would not fix the underlying Layer 3 routing issue causing the traffic drop.
by Sigrid at Jul 07, 2026, 09:55 AM
0
0
0
10
Comments
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Report Comment
Commenting
You can sign-up / login (it's free).