Troubleshooting Tip: Port changed to Default VLAN
Description
This article describes the behavior that occurs when a switch port that does not have 'Reset Forced Default' enforced in Group Membership, yet a VLAN change to the Default VLAN is still shown as the reason. This may occur on host status changes often when the user goes on a break and the PC enters Sleep or Hibernate mode.
Scope
FortiNAC and Persistent Agent.
Solution
The main reasons a host may be moved to the Default VLAN are when the switch port has 'Reset Forced Default' enforced in Group Membership, or when the host does not match any Network Access Policy and falls back to the default. This usually happens when a host or adapter attribute changes and the host no longer matches any Network Access Policy. A possible reason in this case is that the host attributes no longer match the conditions defined in the 'User/Host Profiles'. When checking the policy details for the host, it may show empty values:
In the Port changes logs, the reason is mentioned as Default:
 
One possible cause is when the 'User/Host Profile' is configured to check the Persistent agent communication status as follows:
 
When a user goes in a break and if the PC goes in a state of sleep/hibernate this will stops/pause the agent service from running. If FortiNAC is not notified by the network devices that the MAC address is no longer connected in the network for the next 5 minutes, by default (Agent Contact Window on Disconnect) and if it hasn't heard about the agent of that host, it will change the agent communication status 'No Contact'. This is also explained on the quick hint of this option: 'The time after the agent disconnects or communication is lost. If this time expires without the host disconnecting or the agent having communicated, the 'No Contact' flag is set and the 'Persistent Agent Not Communicating' event is generated.'
This may also occur when the offline host status is not detected in time. Typically, the trigger is a MAC address removal, an SNMP trap, a RADIUS Accounting update, or the MAC address not being reported as connected during a scheduled Layer 2 polling.
Troubleshooting commands:
diagnose network device set attribute DEBUG "TelnetServer ForwardingInterface" ip x.x.x.x <- replace with switch IP
diagnose debug plugin enable BridgeManager
diagnose debug plugin enable PolicyHelper
diagnose tail -f output.master
HostRecordUtil.getAbstractPolicy() HostRecord DBID: 405628456489612 - Found 12 Potential Access Policy Matches
Potential Access Policy Match #1 [Policy_1_DomainPC]:
...
HostRecordUtil.getAbstractPolicy() ID [405628456489612] Policy ID [5609337878094568] Filter *NOT* Satisfied:
- {"filterType":"adapter","hostRole":"Role_NETWORK_MGMT"}
HostRecordUtil.getAbstractPolicy() ID [405628456489612] Policy ID [5609337878094568] Host Component: false
HostRecordUtil.getAbstractPolicy() ID [405628456489612] Policy ID [5609337878094568] User Component: true
HostRecordUtil.getAbstractPolicy() ID [405628456489612] Policy ID [5609337878094568] Adapter Component: true
HostRecordUtil.getAbstractPolicy() HostRecord DBID: 405628456489612 Operation Complete In 11ms
Note:
The debug commands should be enabled only temporarily during troubleshooting sessions and should not be kept running for a long time.
Related articles: