| 1. | What content switch hardware is responsible for providing in-band health checking? What about OOB health checking? |
| Answer: | The connection processor is responsible for providing in-band health checking. The control processor is responsible for providing OOB health checking. |
| 2. | Why do content switches perform delayed binding? |
| Answer: | A content switch must delay the binding of front-end and back-end TCP connections to make load-balancing decisions based on application content. By proxying the front-end TCP connection, the content switch can inspect the application request and select the virtual server that best fits the request. |
| 3. | What is involved in sequence-number remapping? |
| Answer: | Because the content switch performs delayed binding, the real server's sequence numbers are unknown when the content switch establishes a connection with the client. The content switch selects a virtual server and establishes the back-end TCP connection with a real server. To bind the front- and back-end TCP connections together, the content switch must overwrite the real server's sequence numbers with the sequence numbers that the content switch previously synchronized with the client. |
| 4. | What is the major difference between router- and bridge-mode? |
| Answer: | Bridge-mode enables you to configure your VIPs on the same subnet as your real servers, whereas in router-mode your VIPs and serverfarm subnets must be different. |
| |
| 5. | What is the major difference between relative and absolute load calculations? |
| Answer: | Relative load normalizes your real server load calculations with the best-performing real server, whereas, absolute load calculates each real server's load individually. |
| 6. | What is the difference between HTTP header load balancing and HTTP URL hashing? |
| Answer: | HTTP header load balancing is a method of selecting virtual servers. URL hashing is a method of deciding which real server to send the request to after the content switch selects a virtual server. |
| 7. | Why doesn't the CSS store its client to real server associations in the sticky state table with HTTP hash cookies? |
| Answer: | Because hashing is stateless in nature, the CSS can simply recalculate the hash to determine the associated real that should receive the request. However, with source IP sticky, the content switch cannot calculate the originally chosen real server on the fly, so it must store the association in the sticky table for later use. |
| 8. | What type of stickiness should you configure with CSS high availability? |
| Answer: | Because ASR does not synchronize state across redundant CSSs, you should use HTTP cookie-stickinessit is a stateless sticky mechanism by nature, and therefore does not require state synchronization. |
| 9. | What is the major difference between CSS and CSM high availability? |
| Answer: | The CSM does not require support for an active-active configuration because of its high concurrent connection and bandwidth support. However, you may benefit from an active-active scenario with the lower-end CSS models; therefore, the CSS supports an active-active configuration. |
