I have dot1x setup on a 3560. I basically have 3 vlans configured.
All ports are in vlan "guest (vlan 10)" by default. The authenticated "AUTH" vlan is pushed by the radius server after successful authentication. And finally I have a guest/auth-fail vlan for non-dot1x capable machines.
Everything works fine except that when I connect windows XP machine which is not on the domain then I am not assigned to a guest vlan. The port stays in unauthorized state and a "show interface" output shows that the port is up but line protocol is down.
It works sometimes but other times it doesnt.
Is there a trick to it. Also I read an article on ciscos website which was specific to XP and dot1x i.e. the switches waits ~ 180 seconds and you need to plug the cable in/out of the switch to make it to work...I havent tried this yet but anybody has any better ideas then this technique.
I have the standard config:
dot1x port-control auto
dot1x guest-vlan 10
dot1x auth-fail vlan 10
I am thinking of tweaking the "quite period" and the switch-to-client retransmission timeout values.
Note: Like I mentioned earlier. After successful authentication corporate clients are put in the correct vlan. Its just the "guest" vlan piece which is not working.
The Guest-VLAN literally means the VLAN you place a machine in when the device on the other end of the wire cannot speak 1X. The switch figures this out by not getting any response to EAPOL-Identity-Request frames. It takes 90-sec by default for this to happen. If a machine who can speak 1X, or who at least replies to the initial Requests of Identity defined by RFC 3748, then this machine should never go into the Guest-VLAN.
The Auth-Fail-VLAN literally means, 802.1X actually worked and completed, but a negative result or denial of service is typically sought after. But in this case, you don't want to deny service entirely, and instead place the port into a VLAN anyway.
Can you Fwd the reference about this ~180sec thing? Doesn't sound like it makes since, so keen on fixing that.
Also, not sure I can say what your supplicant is actually doing, or how it's configured, but do the above definitions help at least?
Not entirely accurate. If a host fails to respond to the authenticator, the port remains in the connecting state for [tx-period (max-reauth-req + 1)] seconds. A login window even appearing on an XP machine is dependent on the configuration (usually only occurs with MD5). Not sure about the unplugging cables stuff at all ;-). This certainly shouldn't be in there though, since that's not really a workaround for anything. It is correct in saying that 1X-capable hosts should not be placed in the Guest-VLAN. It's also correct in explaining the quiet period during the HELD state after a failed authentication attempt. However, the rest is completely dependent on the Microsoft supplicant. The Microsoft supplicant gives up on 1X entirely after it fails 3 times in a row. No other supplicants do this AFAIK. Since it gives up on 1X, then that explains why the port would be "stuck" in a connecting state. Not sure if this is just trivia or what though in context to the reference.
WRT your configuration:
If you're interested in having 1X timeout any quicker than it does now (see formula above) then the only timers/values you need to bother with are tx-period and/or max-reauth-req. supp-timeout is for non-EAP control packets. The quiet-period is how long the port is in a HELD state when it fails authentication.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...