GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: how difficult can it be, dot1x guest-vlan posted 03/29/2007
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


Hi,
I know there is no need for any 'guest-vlan supplicant' in current
releases, because of the new command 'auth-fail vlan'. But I do not
know which version they are running on the real lab. So let's assume
they have a 3550 running 12.2(25)SE. That's the release that overcomes
some limitations of even older releases by introducing the guest-vlan
supplicant command, while still not supporting auth-fail vlan.
For this specific situation, I tried to find out what the guest-vlan
supplicant command actually changes. In the sentence 'you can use the
dot1x guest-vlan supplicant global configuration command to enable
this optional behavior.' it is NOT clear to me what they are referring
to with 'this behavior'. But maybe this is because I am not natively
speaking english.

Based upon the older pre-12.2(25)SE documentation, it is clear that
when using guest-vlan:
- If client is dot1x capable but authentication fails --> unauthorized
- If the client is not dot1x capable --> guest-vlan

So enabling the command 'guest-vlan supplicant' here must change one
of these to port states I thought. This resulted in my assumption that
using IOS 12.12.(25)SE without enabling guest-vlan supplicant leads to
the following port states:

- If client is dot1x capable but authentication fails --> guest-vlan
- If the client is not dot1x capable --> guest-vlan

Maybe I was not clear enough, I'm sorry.

Maureen


On 3/29/07, Thomas.W.Johnson@xxxxxxxxx <Thomas.W.Johnson@xxxxxxxxx> wrote:
Not sure if I read your question correctly or not.  Are you asking what
the difference is between the two commands?  I believe both commands
perform the same function, allowing users/devices who do support Dot1x
authentication, but fail to properly authenticate to have access to the
guess vlan.

This is from the Cat 3550 command reference, my interpretation was we no
longer use the dot1x guest-vlan supplicant, start using the dot1x
auth-fail vlan command instead.

Before Cisco IOS Release 12.2(25)SE, the switch did not maintain the
EAPOL packet history and allowed clients that failed authentication
access to the guest VLAN, regardless of whether EAPOL packets had been
detected on the interface. In Cisco IOS Release 12.2(25)SE, you can use
the dot1x guest-vlan supplicant global configuration command to enable
this optional behavior.

However, in Cisco IOS Release 12.2(25)SEE, the dot1x guest-vlan
supplicant global configuration command is no longer supported. You can
use a restricted VLAN to allow clients that failed authentication access
to the network by entering the dot1x auth-fail vlan vlan-id interface
configuration command.

Thomas Johnson
JP Morgan Chase
Global Network Implementation

-----Original Message-----
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On Behalf Of
ian
Sent: Thursday, March 29, 2007 6:31 AM
To: maureen schaar; Cisco certification
Subject: Re: how difficult can it be, dot1x guest-vlan

maureen schaar,How are you#!

        Another interesting thing is that for the latest IOS version
(Version 12.2(25)SEE2) , command " dot1x guest-vlan supplicant " has
become a hidden command. It appears no available, but it allows you to
configure. Therefore, i guess .....

======= 2007-03-29 20:25:40 What you've mentioned in your
letter#:=======

>Hi all,
>Once again I am having a hard time understanding a part of cisco
>documentation. It's regarding the dot1x guest-vlan and dot1x
>guest-vlan supplicant.
>
>This is from 3550 12.1(20)EA2
>
>quote/
>dot1x guest-vlan vlan-id
>no dot1x guest-vlan
>
>Usage Guidelines
>
>When you configure a guest VLAN, clients that are not 802.1x-capable
>are put into the guest VLAN when the server does not receive a
>response to its Extensible Authentication Protocol over LAN (EAPOL)
>request/identity frame. Clients that are 802.1x-capable but fail
>authentication are not granted access to the network.
>/quote
>
>I conclude:
>- If client is dot1x capable but authentication fails --> unauthorized
>- If the client is not dot1x capable --> guest-vlan
>
>Then we go to the current documentation (12.2(25)SEE), which says this:
>
>quote/
>'Before Cisco IOS Release 12.2(25)SE, the switch did not maintain the
>EAPOL packet history and allowed clients that failed authentication
>access to the guest VLAN, regardless of whether EAPOL packets had been
>detected on the interface.'
>/quote
>
>Is it me, or is this a total contradiction with what is documented for
>the older release????
>
>My guess is that guest-vlan supplicant is the way to implement the
>auth-fail vlan with releases that do not support auth-fail vlan (in
>which case auth-fail vlan = guest-vlan). I think these are the options
>for IOS 12.2(25)SE (which supports guest-vlan supplicant):
>
>
>dot1x guest-vlan WITHOUT guest-vlan supplicant (based on 12.1 doc):
>- If client is dot1x capable but authentication fails --> unauthorized
>- If the client is not dot1x capable --> guest-vlan
>
>dot1x guest-vlan WITH guest-vlan supplicant:
>- If client is dot1x capable but authentication fails --> guest-vlan
>- If the client is not dot1x capable --> guest-vlan
>
>Can anyone confirm or correct me if I'm wrong?
>
>Thanks.
>
>Maureen
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html

= = = = = = = = = = = = = = = = = = = =


!!!!!!!!!!!!!!!!Have a nice day.



!!!!!!!!!!!!!!!!ian !!!!!!!!!!!!!!!!iyux2000@xxxxxxxxx !!!!!!!!!!!!!!!!!!!!2007-03-29

_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html


********************************************************************** This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. **********************************************************************