Multi-Building Hospital Mobility and Guest Anchor Design
A three-building hospital campus has 1,500 APs and 12,000 clinical and corporate clients. Each building has a Cisco 9800-80 HA SSO pair on its own VLANs; the buildings are connected by 10G fiber with 1 ms RTT. Clinical Vocera badges and infusion pumps roam between buildings, and users report badge dropouts at building entrances. Each building currently uses a different clinical subnet, and the controllers are not in a mobility domain. Guest Wi-Fi is locally switched with a captive portal. The CIO wants seamless roaming and a guest anchor in the DMZ. You must design the mobility and VLAN architecture without creating a single huge broadcast domain.
1. Design the mobility architecture across the three buildings.
Read the worked answer
Put the three 9800 HA SSO pairs into one mobility domain with the same mobility group name and consistent software and NTP. Mobility peers allow client state exchange and roaming between controllers. For the clinical badges and pumps, design a dedicated clinical VLAN and subnet that is stretched across all three buildings through the fiber ring, and map the clinical SSID to that VLAN on every controller. That gives L2 roaming because the client keeps the same subnet and default gateway. Keep corporate and guest on separate VLANs and do not stretch those across the campus. Enable fast roaming for the badges and verify the vendor's requirements, because a badge that does not support 802.11r may still need OKC or a well-controlled roam. Do not put all 12,000 clients in one VLAN; only the clinical roaming domain needs to be stretched. This design solves the entrance dropouts while limiting the broadcast domain to the clinical device population.
2. How would you size the clinical VLAN and DHCP scope without creating a large broadcast domain?
Read the worked answer
Estimate the maximum number of clinical devices that can be in the same roaming domain at once, not the total campus client count. If there are 1,200 badges and 800 pumps, a /22 gives about 1,022 usable addresses, which may be too small; a /21 gives about 2,046 usable addresses, which is a better starting point with headroom. Use a single subnet only for the clinical SSID, with DHCP relay to a resilient DHCP pair, and use option 82 or split scopes carefully if the DHCP server is not central. Keep lease times appropriate for devices that roam but do not power off for days. Enable IGMP snooping, DHCP snooping, and storm control on the stretched VLAN. Avoid stretching the corporate VLAN; corporate users can use local subnets per building and reconnect if they move between buildings. The clinical domain is the exception because seamless badge roaming is a clinical safety requirement.
3. How would you design and validate the guest anchor?
Read the worked answer
Create a separate guest SSID on all three controllers and centrally switch it to a dedicated anchor controller in the DMZ, such as a 9800-L or 9800-40, over a mobility tunnel. The anchor owns the guest VLAN and DHCP scope, applies an ACL that allows only Internet-bound traffic, blocks RFC 1918 and management subnets, and enforces client isolation. Use web authentication with an external portal or ISE, rate limiting, and a session timeout. Do not locally switch guest traffic on the campus controllers, because that bypasses the DMZ policy. Validate by joining a guest client in each building, confirming the anchor is the tunnel endpoint, and testing that the client cannot reach internal resources. Then fail the anchor or the tunnel and confirm the guest outage is acceptable or that a standby anchor exists. Test roaming for guest only if the business requires it; guest mobility is usually less critical than clinical mobility.