802.1x and DHCP

[geoff.tappenden]

we have an issue with DHCP and the guest VLAN, what basically happens is while waiting for authorisation from the Radius server the XP client gets put into the guest vlan where it leases an ip address from the Guest VLAN DHCP Server. Once the client has Been authorised it gets switched across to the secure VLAN but then does not attempt to aquire a new lease with the DHCP for the secure VLAN. I thought that the switching process would trigger The DHCP discover process again, but it seems to just sit there with the wrong ip!!

Any Views would be welcomed

thanks

[jafrazie]

Couple of points on what the Guest-VLAN should mean:

It means no 802.1x. More simply, it means no EAPOL. Assuming no timers have been tweaked on the switch, it should take about 60-90-sec to deploy the Guest-VLAN on a switch after link up.

So I'm assuming this means that your PC is not capable of speaking EAPOL during this time. If this is the case, I would rectify why your PC is not capable of speaking EAPOL during the first 90-sec of link on a port.

Or, the issue could be that EAPOL is there, and auth is just timing out for some reason (and the supplicant is giving up on the session completely). The switch should not be placing a port into the Guest-VLAN anyway if this happens. If it is, let us know what image and switch type you have, so we can recommend a fix.

Now, overall, this is the "IP re-assignment" problem anyway. Example: If you dot1x-authenticated a machine into one VLAN, then a user into another VLAN, how does the supplicant know to get a new IP Address?

For Meetinghouse: This is a configurable utility (it just BCast renews for a DHCP Address everytime the supplicant sees an EAP-Success).

For Microsoft: You need KB826942 for Windows XP, and KB822598 for Windows2000.

Hope this helps.

[r-marchetti]

I wasn't able to find hotfix KB822598 for Windows2000 on Microsoft site; is it the right number?

Thanks

Reagards

Roberto

[jafrazie]

Type-o.

http://support.microsoft.com/kb/822596

[geoff.tappenden]

Jason thanks for your reponse, we know that we have an issue with the radius timing out which is being looked into as a seperate issue , i'll try to expain the setup a little better

The guestVlan as i have called it is really our old network Vlan and is basicly for legacy pc's.We are currently rolling out a new infrastructure and pc's so 801.1x is being used to authenticate the MAC addresses of the new pc's basicaly creating a auto switching system between the old and new Vlans, as a large amount of users have notebooks this saves on port config tasks

the system is not wireless and runs on cat6500 switches.

so you can see when the users connect thier new pc or notebooks they often get serviced by the Legacy DHCP Server because of the radius taking time to authenticate causing the notebook to be placed on the legacy Vlan until the authentication is recieved.

this would not be a problem if we could get the notebook to start DHCP discovery again to obtain the correct ip once the 802.1x authentication has taken place and the pc is on the correct VLAN.

it would be good to know how the NIC of the PC sees the switch between vlans, as it seems to be transparent which is why it mantains a DHCP lease obtained before the switch over which is essentially our problem.

[jafrazie]

The NIC never sees a transition beetween VLANs. All it's capable of seeing is an EAP-Success frame. It's just a matter of what the supplicant can then do with that information (see my earlier post).

Also, I'm confused on your setup, so let me try to re-state what you said.

Your existing "old network" VLAN has been configured as a Guest-VLAN for 802.1x. Your "new network" VLAN is assigned via RADIUS/802.1x dynamically on the port.

So, like I said before, it auth is timing out, and EAPOL is really going out on the wire, then we need to find out 2 things.

1) Why auth itself is taking so outrageously long.

2) Why the switch port is placing the port into a Guest-VLAN when it shouldn't be (b/c if it even smells a supplicant on the wire, it shouldn't).

The DHCP fixes you talk about would be fixing the symptom (not the problem).

Have I go this right?