Checkout logouts and a monitor that marks healthy servers down
An online retailer runs a checkout application on a BIG-IP LTM virtual server with a single pool containing four members in Dallas and four in Frankfurt. Cookie persistence is enabled in insert mode with a 30-minute expiration. SNAT is set to automap. During a flash sale, European customers report being logged out mid-checkout, and application logs show requests arriving from 10.10.20.10 rather than the client address. At the same time, operations notices that all Frankfurt pool members are marked down every night at 02:00 for about three minutes, even though the application responds normally to browser traffic. The health monitor is an HTTP monitor with a send string of GET /health HTTP/1.1\r\n\r\n and a receive string of OK. The application team recently added virtual hosting and now returns 400 for requests without a Host header. The business wants both symptoms fixed without changing the application.
1. Explain why European customers are being logged out and why the application sees 10.10.20.10. What would you change?
Read the worked answer
The nightly Frankfurt monitor failure is the likely trigger for the logouts. Cookie persistence inserts a cookie that points at the pool member selected for that client. When the monitor falsely marks all Frankfurt members down, BIG-IP stops using them and sends those clients to Dallas. If checkout session state is stored locally on the Frankfurt servers, moving the client to Dallas loses the cart and login state. The flash sale makes the symptom visible because more European customers are active during the false-down window.
10.10.20.10 is the self IP that SNAT automap selected on the egress VLAN. Automap does not preserve the client address; it hides every client behind a BIG-IP address. If the application needs the original client IP for logging or fraud checks, insert X-Forwarded-For in the HTTP profile or with an iRule and make the application trust that header only from the BIG-IP. If the application truly needs the client IP at the IP layer, disable SNAT on that virtual server and ensure the servers route return traffic through the BIG-IP; that has its own routing and security consequences. Do not treat X-Forwarded-For as a substitute for fixing the monitor.
2. Diagnose the nightly Frankfurt pool-member downtime and give the corrected monitor configuration.
Read the worked answer
The send string has no Host header. After virtual hosting was enabled, the application returns 400 for requests without a Host header, so the monitor receives an error page instead of OK and marks every Frankfurt member down. The Dallas members may be marked down too, but the incident is reported in Frankfurt because that is where the user impact appears.
Change the send string to include the correct Host header, for example GET /health HTTP/1.1 with Host: portal.example.com, Connection: close, and a blank line. Match the receive string to a stable response, such as 200 OK or a known body string, and make sure the health endpoint does not depend on a user session or a backend that is expected to be slow. Verify manually from the BIG-IP with curl before attaching the monitor.
Also review timing. An interval of 5 seconds with a timeout of 16 seconds and multiple retries can turn a brief application pause into minutes of downtime. Use a timeout at least three times the interval, and confirm the up and down retry counts. Test by stopping the application on one Frankfurt member and watching the monitor state change.
3. What persistence design would you recommend for a checkout application spanning two data centers, and what are the trade-offs?
Read the worked answer
Cookie persistence is appropriate for HTTP checkout because it is independent of client NAT and proxy addresses, but it is not a session-replication strategy. Keep cookie persistence within a pool, and fix the monitor first so members are not falsely removed. If the application stores sessions locally, a member failure or a data-center failover will still lose those sessions; the durable fix is shared session state or replication between Dallas and Frankfurt.
If the business wants each region to stay in its local data center, use DNS or a global traffic manager to direct European clients to Frankfurt and US clients to Dallas, with cookie persistence inside each local pool. That reduces latency and cross-site session loss. If both data centers are active for the same pool, cookie persistence still works, but a cookie pointing at a failed member must fall back somewhere, and the application must tolerate the loss.
Avoid source-IP persistence here: many European mobile clients share carrier NAT addresses, and SNAT automap would make every client look like the same BIG-IP address. The trade-off of cookie persistence is that clients that refuse cookies lose affinity, so the application should degrade gracefully.