Consolidating 28 applications onto a two-node VE pair
A regional insurer is consolidating 28 departmental web applications onto a two-node BIG-IP VE pair running on VMware. Each VE is licensed for 500 Mbps and has 8 vCPU and 16 GB RAM. Three business units insist on administering only their own objects, and two acquired applications use the same 10.20.0.0/16 address space. The security team requires TLS 1.2 or later on the client side, but the payments application must remain encrypted from client to server; all other applications can terminate TLS at the BIG-IP. Peak aggregate throughput is estimated at 380 Mbps, and the team is worried about SSL CPU cost. The network team wants a design that can be deployed without changing application IP addresses. The pair must also support maintenance of either node without dropping established connections.
1. Design the partition and route-domain layout. Explain where the two overlapping applications should live and how you would keep each business unit from seeing or changing another's objects.
Read the worked answer
Use partitions as the administrative boundary, one partition per business unit or per application team, and place each team's virtual servers, pools, monitors, and iRules in its own partition. Create users with a role such as Application Editor or Manager and restrict their partition access to that partition only; do not give them the All partition. Partition administrators cannot manage route domains or other partitions, which is the separation the business units need.
The two applications that share 10.20.0.0/16 cannot both use route domain 0. Put one in a non-default route domain, for example 10.20.10.10%1, and the other in a different route domain or leave it in route domain 0. Create the required VLAN and self IP in each route domain so the virtual server has a path in and out. Using route domains avoids re-addressing the applications, but it adds operational complexity: monitor strings, pool member addresses, and iRules may need the %rd suffix, and troubleshooting must account for the route domain.
Keep shared infrastructure objects, such as route domains and VLANs, owned by the platform team, not by the application partitions.
2. The payments application owner says 'end-to-end encryption' means the BIG-IP must never see plaintext. How do you reconcile that with the security team's TLS 1.2+ requirement, and what do you configure for the other applications?
Read the worked answer
Those two requirements conflict if 'never see plaintext' is literal. A TCP virtual server with an SSL passthrough design forwards encrypted bytes, so the BIG-IP cannot inspect, insert headers, run ASM, or enforce a minimum TLS version; TLS version enforcement would have to happen on the server or at another control point. If the security policy genuinely forbids decryption anywhere in the ADC, the BIG-IP cannot be the TLS 1.2+ enforcement point for that flow. Escalate the conflict rather than silently choosing one requirement.
If 'end-to-end' means encrypted on every wire segment but decryption and re-encryption at a trusted intermediary is acceptable, configure SSL bridging: a client SSL profile with TLS 1.2 and 1.3 enabled, plus a server SSL profile so traffic to the payment server is re-encrypted. The BIG-IP sees plaintext briefly, so this must be explicitly approved.
For the other applications, terminate TLS at the BIG-IP with a client SSL profile that disables TLS 1.0 and 1.1, use an HTTP profile, and send clear traffic to the pool only on a trusted network segment. Document which applications are passthrough, bridged, or terminated.
3. Given the 500 Mbps license and 380 Mbps estimate, what capacity checks and topology choices would you make before cutover?
Read the worked answer
On an active/standby pair, the active node must carry the full 380 Mbps, which is 76 percent of the 500 Mbps license before accounting for protocol overhead and SSL. That is too close to the ceiling to treat as comfortable. Confirm the license limit with tmsh show sys license, then measure real throughput with a representative mix of TLS 1.2/1.3, cipher suites, key sizes, and session reuse; software crypto on a VE will not match dedicated hardware.
Check CPU and SSL transactions per second under load, not just bits per second. Enable session resumption, prefer ECDSA certificates where clients support them, and disable legacy ciphers. If measurements show the active node approaching the license or CPU limit, consider active/active with carefully separated traffic groups, or a larger VE license, rather than relying on failover headroom.
During maintenance, failover must move both the traffic group and the floating self IPs without dropping established connections. Test that explicitly, and confirm that the surviving node can carry the full load on its own.