From: maureen schaar (maureen.schaar@gmail.com)
Date: Thu Mar 29 2007 - 11:12:47 ART
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@chase.com <Thomas.W.Johnson@chase.com> 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@groupstudy.com [mailto:nobody@groupstudy.com] 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@gmail.com
> !!!!!!!!!!!!!!!!!!!!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.
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART