inverse-inc/packetfence — pull request #147 by julsemaan (2014-05-16 13:36:16+00:00)
Title: Feature/mab floating device

RADIUS floating device support for PacketFence.

For review, discussion and merge.

See : https://wiki.inverse.ca/focus/PacketFence/Devel/RnD/2014/FloatingDevicesImprovement

Works on Juniper EX4200

Detection :
* On an Access-Request of a floating device it disconnects then deletes the macs present in the location log in case another device triggered a request before it.
* It configures the switch to accept an unlimited number of devices on the floating device port and leaves mac auth enabled.
* Then PF will know there is a floating device on this port from the location log entry.
* When other devices connect to this port it returns the configured PVID or the normalVlan depending on the mode of the floating device (see below).
* When the switch sends the accounting stop for the floating device, the port is unconfigured from the floating device mode and it's locationlog entry closed.

Additionnal devices connecting to the port (access floating):
* When the floating device is not configured in trunk in PacketFence, this flow applies.
* PF will receive a RADIUS request and if a floating device is in the location log for that interface it will accept it with the PVID of the floating device.
* In this mode, all devices connecting to this port are accepted with the floating device VLAN.

Additionnal devices connecting to the port (trunk floating):
* PF will receive a RADIUS request and if a floating device is in the location log for that interface it will lookup the VLAN tag to return as it does normally (registration, isolation or normal)
* In this mode access control is done directly by PacketFence. The port becomes a 'sub-switch'.

Current limitations :
* In order to not open multiple location log entries per port PF doesn't keep the location of the devices connected behind the floating device. This means in trunk mode there can't be any deauth in case a MAC needs VLAN reevaluation. Access mode works fine since it never needs deauth.
* Devices connected before the floating need to be disconnected to have them on the correct VLAN and this is not done asynchronously. This shouldn't be a big issue since the mac limit on the switch will make us deauth one client in the worst case.
* If a switch is a floating device in trunk mode then the devices in different VLANs behind it could have communications problems between them. Since they are on two different networks outside of the floating but on the same in the floating, a switch could forward the packets between both devices that are on different IP subnets. Tested with a Cisco 2950 as a floating and didn't get this behavior (SSH + ping working fine between devices connected in the floating).
* (Juniper) The flap-on-disconnect option has to be deactivated programaticaly by PF. Because of the way the Juniper switch has to be configured, the flap-on-disconnect cannot be configured through inheritance on Juniper. Doesn't change the behavior but makes ugly switch configs