Two data centers, one stretched HA pair: designing WSA placement for 5,200 users
Northwind Health has 5,200 employees across two data centers: DC-A in Dallas and DC-B in Raleigh. All web traffic is currently sent by a PAC file to an active/standby pair of WSA S390s in DC-A running AsyncOS 14.0. Peak egress is 3.2 Gbps at DC-A and 1.1 Gbps at DC-B, and 40 clinics reach the internet over SD-WAN. Security wants transparent interception at both data centers so that unmanaged iOS devices and BYOD clients are filtered without a PAC, per-user policy and reporting for 3,900 domain-joined Windows laptops, and authenticated access for 600 contractors who have no AD account. Each data center has a pair of Catalyst 9500 cores with WCCP enabled. The network team proposes adding two WSAs in DC-B but stretching a single HA pair across both sites "for simpler management," and wants to cut over in six weeks.
1. Should Northwind deploy one HA pair stretched across both data centers or one pair per site? Justify the recommendation with the constraints of WSA high availability and redirection.
Read the worked answer
Deploy one HA pair per site; do not stretch a pair across Dallas and Raleigh.
Why the stretch fails: WSA HA is an active/standby pair that must be Layer 2 adjacent on a dedicated HA interface, with the standby continuously receiving state and configuration. WCCP redirection and the return path are also site-local: the core at each site must be able to redirect to, and receive traffic back from, a cache that is reachable in that failure domain. A stretched pair puts the HA heartbeat and the redirection return path across the DCI, so a DCI flap can cause a failover at the same moment the surviving node is unreachable from one site's core. It also creates a single failure domain for two sites that have independent internet egress.
Sizing implication: in an active/standby pair, each appliance must carry the full site peak alone after failover. Size each DC-B appliance for 1.1 Gbps of inspected traffic and each DC-A appliance for 3.2 Gbps, then add headroom because decryption, anti-malware and DLP inspection reduce the throughput the box can sustain compared with plain proxying. Do not size for half the peak.
Design: DC-A pair serves DC-A egress and the clinics that already backhaul there; DC-B pair serves DC-B locally, removing the SD-WAN hairpin. Keep the PAC file as a fallback path during cutover so a failed WCCP service does not take the business offline.
2. Given the requirement for per-user policy and contractor authentication, should Northwind use explicit proxying, transparent redirection, or both? Explain how identity would be obtained in each case.
Read the worked answer
Use both modes, split by data interface, because the identity requirement drives the choice more than the filtering requirement does.
Windows laptops (explicit): keep them on the explicit proxy with a GPO-delivered PAC. That gives the WSA an authenticated session using NTLM or Kerberos, so per-user reporting and policy work without extra infrastructure. The 407 challenge requires the client to speak proxy authentication, which is exactly what the explicit mode provides.
BYOD/iOS and clinic devices (transparent): challenge-response schemes cannot be used transparently, because the client never sees a proxy challenge. Obtain identity through Cisco ISE/ISE-PIC transparent user identification (or a form-based LDAP login page for non-domain devices), and fall back to an IP-based identification profile for devices that cannot authenticate at all, clearly labelled as low-confidence identity.
Contractors: create sponsored guest accounts in the directory the WSA authenticates against, or federate to a SAML identity provider. Do not put contractors in an unauthenticated IP profile that also serves employees, or their traffic will inherit employee policy and pollute reporting.
Test that the same user resolves to the same identity string across the explicit and transparent paths, otherwise the reporting you promised will split into two identities.
3. What must be verified about routing and PAC removal before the transparent cutover, and what is the rollback position?
Read the worked answer
Transparent interception only works if the WSA is on the forwarding path in both directions. Verify that return traffic from the internet to the client traverses the same WSA that saw the request; the usual clean designs are to make the WSA the last hop before the internet firewall, or to use policy-based routing that is symmetric on both directions. Asymmetric return paths produce failed connections and intermittent resets that look like application faults.
Pre-cutover checks:
- Confirm WCCP service-group membership and that the redirect ACL covers all ports actually in use (80, 443, and any alternate ports), applied inbound on every client VLAN.
- Exclude traffic destined to the WSA itself from redirection, or the appliance will proxy its own updates and health checks.
- Test failover deliberately: pull the HA link, confirm the standby takes over and that the core re-assigns WCCP to the new active node within the expected interval.
- Watch interface throughput, concurrent connections, and CPU during a pilot group; decryption and scanning change the profile substantially versus plain proxying.
Rollback: do not remove the PAC everywhere on day one. Leave it deployed with a proxy-failover/direct-fallback option so a pilot group can revert by GPO, and keep the old explicit listener configured on a data interface. Define a go/no-go metric (for example, session success rate and helpdesk tickets) before the change window closes.