dot1x guest-vlan issues with windows XP

smhussain · ‎07-16-2007

Hi,

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:

int fa0/1

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.

Thoughts? pointers? Comments?

jafrazie · ‎07-17-2007

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?

Let me know ..

smhussain · ‎07-17-2007

Thanks for the reply.

I am aware of the use of auth and guest vlan however I was not quite puzzled about the wait time for the switch before which it assigns non-speaking dot1x machines in the guest vlan.

I am aware about the 62 sec dhcp process and how that ties into this issue as well.

The timeout as you mentioned is 90 seconds ( I thought this was 120) (30 x2 (retries) = 60 x 2 (total retries) = 120.

However I am planning of changing the following timeouts:

dot1x timeout tx-period 1

dot1x timeout supp-timeout 2

dot1x timeout quiet-period 2

dot1x max-reauth-req 1

This is the document I was referring to. Although it covers 4000 series. I am not sure if it applies to others as well. Atleast in my case with the 3560 it 'appears' to apply.

http://www.cisco.com/en/US/docs/switches/lan/catalyst4000/8.3and8.4glx/configuration/guide/8021x.html#wp1021033

jafrazie · ‎07-17-2007

OK, first WRT the documentation reference:

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.

Does this help?

smhussain · ‎07-30-2007

Thanks for the response.

I changed the dot1x timers and it appears to be working now.

Thanks again.