Hotspot deployment topologies
Central Switching/Local Switching
This term is related to the way the Wireless infrastructure will manage the traffic from your guests to Internet. Local switching means that the Wi-Fi Access Point will send the guest traffic to the local LAN/WAN/Firewall infrastructure.
In Central switching, the Access Point will send this traffic to a central collection point (usually the wireless controller hosted in Data Center) in order to be centrally managed (in terms of routing and security).
This schema from Cisco explains this clearly:
Source: This excellent article (in French) by the excellent Federico Ziliotto
Captive portal redirection
When a guest user connects to your hotspot service, you want him to enter some informations before having access to Internet.
The most used method is to redirect the guest HTTP traffic to a web captive portal hosted by the hotspot solution. This can be achieved either by the wireless infrastructure itself (the feature is usually called Web Authentication) or by the hotspot solution itself (in this case, the hotspot solution has to be on the path between guests and Internet).
DHCP, DNS, firewall, web security and other network features
When deploying a Hotspot service, we usually focus on the captive portal itself but it is important to remember that we need to implement several network services for the guest to reach Internet:
- DHCP and DNS to connect the network and resolve URL
- Firewall and/or Web Security to filter Internet access and log the traffic (for analytics and regulatory purpose)
Now you know all the technical terms, let me describe the two main deployment topologies. The choice between the two will be driven by your network configuration. If you have a unique Internet access in a central location (Data Center or Head Quarter), you will most probably deploy the hotspot service centrally. On the contrary, if your location has its own access to Internet, your Hotspot deployment will be distributed.
This topology relies on the Central switching feature of the wireless infrastructure and all network services available in the central location (DHCP, DNS, security…).
Advantages: This topology can be deployed very quickly because all the network services are provided by the Data Center. It means there is no need to apply any network change on the remote locations (in some companies, this is a huge argument).
If you plan to deploy an appliance-based Hotspot solution, you will need only 1 (or a couple) appliance.
Drawbacks: In one word, scalability! Not only you will use your private network connectivity (your costly MPLS?) to send all the guest traffic to the DC and then to Internet but also you may face some scale challenges in the DC. For example, the capacity planning of the central guest subnet can become a nightmare because any device trying to connect on the Hotspot will use a DHCP lease (even if it stays for a few seconds). If you have 3000+ sites over the world, I will let you imagine the size of the scope. I faced this situation a few months ago on a Wi-Fi infrastructure: 2000+ IP addresses used but only 40 authenticated users. This is mainly because of devices automatically checking for Internet enabled Wi-Fi networks.
When using this topology, you will rely on your remote site’s network to deploy the hotspot service. The Wi-Fi access points will switch the traffic locally in a dedicated VLAN and the local infrastructure will connect that VLAN to the Hotspot service (whatever it is appliance based or cloud based).
Advantages: Efficient, because the path from the guest to Internet is short. Scalable as the capacity planning is done location per location. Cost effective if you are using the local internet access for other purposes (employee web surfing or backup to the main connection).
Drawbacks: The time to deploy can be very important as you will need to apply some changes on each location. This is especially true for appliance-based hotspot because you need to deliver and install the appliance everywhere. Be careful about monitoring also, as the service is provided locally, your central monitoring may not be compatible.
Depending on your current network infrastructure, you will find a topology to apply. My own experience proves that we usually deploy both topologies: the central one to activate the service quickly and then the distributed one later on. Remember to rely on the distributed Internet link for others services (WAN backup, employee web surfing, out of band management…), it will leverage the cost of these links.