Profiler Drift After a DHCP Scope Change
A university uses FortiNAC-F to profile 3,000 endpoints across 40 VLANs. After a DHCP scope change, the profiler starts classifying 120 IP phones as Windows 10 and 60 personal laptops as Unknown. The phones support DHCP option 55 fingerprints and LLDP; the laptops use randomized MAC addresses that change daily. The registration portal is enabled, but the helpdesk reports that returning students must re-register every morning. The Microsoft DHCP server was moved to a new subnet, and the FortiNAC DHCP fingerprinting listener is connected to a spanned port. A new wireless SSID uses client isolation, and the service desk has not changed any profiler rules. The network team wants to keep registration simple for students and still identify managed phones for voice VLAN assignment.
1. Which profiling inputs should you validate first, and what would explain the IP phones being classified as Windows 10?
Read the worked answer
Start with the inputs that changed: DHCP fingerprinting and LLDP. Confirm that the spanned port still receives DHCP traffic from the new server subnet and that the FortiNAC listener sees the phone VLANs. Then open a misclassified phone's endpoint record and compare its DHCP option 55 fingerprint and LLDP system description with the profiler rules. The likely explanation is rule order or a weak fingerprint: a Windows rule is matching a generic option 55 pattern before the phone rule, or LLDP is not reaching FortiNAC because the phone port or AP does not pass it. Check the profiler rule priority and whether the phone vendor OUI is present. Do not simply add a MAC OUI rule for all phones; verify LLDP first, then add a specific higher-priority voice rule with the observed LLDP or DHCP vendor class.
2. Why must returning students re-register every morning, and what design change fixes it?
Read the worked answer
Because their laptops use randomized MAC addresses, FortiNAC sees a new endpoint each day. Registration that is keyed only to the MAC address cannot recognize the device as the same one, so the student is treated as unknown again. The fix is to stop using the MAC as the primary identity. Use an 802.1X or portal login that binds the device to the student's user account, or deploy the persistent agent so the device carries a stable identity. Configure the registration policy to allow multiple devices per user and to age out stale randomized endpoints. If the school wants to keep MAC-based registration for some devices, enable randomized-MAC detection and treat those clients differently rather than letting them loop through registration. Test with one student account over two days and confirm the same device record is reused.
3. How do you correct the phone classification without breaking Windows detection?
Read the worked answer
Add a voice-specific profiler rule above the Windows rule, but base it on evidence that is actually present. Use the phone's LLDP system description or a vendor-specific DHCP class, plus the phone OUI as a secondary signal. Keep the Windows rule for real Windows fingerprints, but make it require more than a generic option 55 value. Clear one phone's endpoint record, reconnect it, and confirm it profiles as a phone and receives the voice VLAN. Then test a Windows laptop on the same switch model to ensure it still matches the corporate rule. Finally, monitor the profiler dashboard for a day; if phones still fall through, capture LLDP from the access port and compare it with the rule. Rule order and specificity matter more than adding many broad rules.