I am surprised no one else has a similar issue using a 2960 switch. The reason we don't want to have to configure aВ VLAN on NPS is we have many VLANs in our LAN and even switches with multiple VLANs on the same switch. If IВ configure NPS to send VLAN 150 when the client gets remediated and is compliant it will send VLAN 150 and move the siwtch port from VLAN 10 to VLAN 150. I have run debug dot1x and debug radius on the Cisco switch (2960) and I do see NPS send the change to VLAN 10 to the switch and then after the client is remediated it sends VLAN 0 (because I have no VLAN confiured on the NPS) but the switch ignores the change.

The client does not move to the compliant VLAN. Client moves from noncompliant_vlan to compliant_vlan, network interface will cycle up/down during this process. If you then create a third VLAN interface it will shut down the second one you created, and so on. If you try to create another VLAN interface, it will automatically issue a 'shut' on the default VLAN. This is typically the default VLAN (VLAN 1). One thing that you might check in the switch configuration is to issue a 'show interface' or just 'sh int' - I am not sure about the 2960, but on the 2950 you can only have one active VLAN interface at any given time. There are a lot of messages so be prepared to turn debug off again quickly and capture the debug information to a text file for analysis. Some other things you can do to troubleshoot is to enable dot1x and/or RADIUS debug on the switch to watch the transactions. You might want to configure a static IP address to eliminate all DHCP issues and see if it has any effect. NPS is not evaluating the client as expected. NPS evaluates the client correctly, but there is a communication problem between NPS and the switch. The client SoH isn't reaching NPS for evaluation. If the client is not moving to the correct VLAN, I think one of three things could be happening. So, the first thing to check is that NPS successfully received the updated health status from the client, evaluated it, and matched the correct policy. The network policy is indeed what is configured with the VLAN. You will see the network policy that is matched. OnВ NPS there should be an event every time the client is assigned a different health status and moves VLANs. I assume that you are issuing a 'show vlan' on the switch to see that theВ client port isВ has not moved to a new VLAN. Hi, Getting stuck in a VLAN is a different issue than being unable toВ release a DHCP configuration.

Can you trace through the steps above and tell me which step is broken? Thanks, -Greg Just because you see the events on NPS doesn't mean the VLAN switch is occuring correctly. As I said, and similar to what Cisco said (I think), NPS sends the instructions to the switch, but the switch must obey them. If the client is not moving from the noncompliant VLAN to the compliant VLAN (step 8)В even though you do see events 6272, 6278 (step 7) then the issue is not with DHCP but rather with the VLAN switch. Client receives a DHCP address on the compliant VLAN. NPS matches the access request to the noncompliant policy (Event ID 62 occur),В and sends tunnel attribute to the switch instructing it to place the client in the compliant_vlan. Client automatically remediates and sends a new access request with health status. Client receives a DHCP addressВ on the noncompliant_vlan. Client moves from compliant_vlan to noncompliant_vlan, network interface will cycle up/down during this process. NPS matches the access request to the noncompliant policy (Event ID 62 occur),В and sends tunnel attribute to the switch instructing it to place the client in the noncompliant_vlan. Client sends a new access request with health status. Healthy client in compliant_vlan becomes noncompliant (ex: firewall is turned off). Hi, The process should work as follows: 1.

802.1x cisco 2950 switch