> On Jul 29, 2016, at 10:48 AM, Torry, Andrew <[email protected]> wrote: > > I know the database can handle it (as it has already held in excess of 30,000 > nodes in testing) but what I am concerned > about is the ‘Captive Portal’ performance with that number of devices > potentially all trying to register within a short > period of time. > > The most we have reached so far this summer is a sustained period of 8 > registrations/min but I am expecting that to be > much much higher when students arrive on campus this Autumn. > > We are not using 802.1X but are just relying on Mac Authentication Bypass for > the wired and MAC filtering on the WiFi. > > Also our PF server is running in Out-of-Band mode using VLAN assignment and > DHCP services are offloaded to the main > network servers (Using a UDP Redirector to forward DHCP events to the PF > server). Hi Andrew, The RADIUS server should be able to handle it, especially if you are only using MAC Auth and not 802.1x. You are correct that the bottleneck may end up being the captive portal. I have seen cases where the httpd processes were overwhelmed by the raw number of requests made by devices stuck behind it. What often happens is that unregistered devices will connect automatically to the MAC authenticated SSID and get placed into the registration VLAN. Once in there they will make http queries for every active app on the device, trying to call home for things like the weather, stock quotes, Pokemon Go scores and whatnot... So the single most effective thing you can do is to activate the "parking" feature of PacketFence. That feature sends http requests made by devices that have been behind the portal for too long to a different, lightweight httpd process so that they don't impact the main captive portal and affect everyone else. It's essentially a way to detect that a device is running in someone's pocket and not actually in use by a human. To activate that feature, go in the admin GUI under Configuration > Main > Parking and set a value higher than 0 for the "Parking Threshold". That value will be number of seconds a user has behind the captive portal before the device is considered to be "unmanned" and placed behind the parking portal. A value like 1800 would make sense there. The other thing you might want to tweak is the "Max Enable" for the parking violation. That number will be the maximum number a user can get out of behind the parking portal without requiring a PF admin to intervene on their behalf. I think the default value is a bit low. Make it 100, or 999 for that matter. You'll find that setting in Configuration > Compliance > Violations. Look for the "parking" violation and you will find the "Max Enable" under the "Remediation" tab. Other than that, I would also add more memory to your VM. Make it 16Gb. That will allow you to ride out the peaks. Make sure you have a large enough subnet to support a lot of devices in the registration VLAN at the same time. A /24 won't do. Consider a /20 to be on the safe side. You could also consider an active/active configuration to spread the load, but that is another story altogether. There is a guide just for that : https://packetfence.org/doc/PacketFence_Clustering_Guide.html <https://packetfence.org/doc/PacketFence_Clustering_Guide.html> Best regards and good luck! -- Louis Munro [email protected] <mailto:[email protected]> :: www.inverse.ca <http://www.inverse.ca/> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu <http://www.sogo.nu/>) and PacketFence (www.packetfence.org <http://www.packetfence.org/>)
------------------------------------------------------------------------------
_______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
