Re: Default violation mode - dot1x

You guys rock.

Sorry for the delay in my response ... fro some reason, I did not see this
email till just a little while ago.

These are very good; thanks. BTW team, here is the debugs when this
happens:

SW1#
*Mar 1 01:03:16.163: dot1x-ev(Gi0/9): Sending EAPOL packet to group PAE
address
*Mar 1 01:03:16.163: dot1x-ev(Gi0/9): Role determination not required
*Mar 1 01:03:16.163: dot1x-ev(Gi0/9): Sending out EAPOL packet
*Mar 1 01:03:47.033: dot1x-ev(Gi0/9): Sending EAPOL packet to group PAE
address
*Mar 1 01:03:47.033: dot1x-ev(Gi0/9): Role determination not required
*Mar 1 01:03:47.033: dot1x-ev(Gi0/9): Sending out EAPOL packet
*Mar 1 01:04:17.903: dot1x-ev(Gi0/9): Received an EAP Timeout
*Mar 1 01:04:17.903: %DOT1X-5-FAIL: Authentication failed for client
(Unknown MAC) on Interface Gi0/9
*Mar 1 01:04:17.903: dot1x-ev(Gi0/9): Sending event (2) to Auth Mgr for
0000.0000.0000
*Mar 1 01:04:17.903: %AUTHMGR-7-RESULT: Authentication result 'no-response'
from 'dot1x' for client (Unknown MAC) on Interface Gi0/9

*Mar 1 01:04:17.903: dot1x-ev(Gi0/9): Deleting client 0x84000003
(0000.0000.0000)
*Mar 1 01:04:17.903: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for
client (Unknown MAC) on Interface Gi0/9
*Mar 1 01:04:17.903: %AUTHMGR-7-NOMOREMETHODS: Exhausted all authentication
methods for client (Unknown MAC) on Interface Gi0/9

*Mar 1 01:04:17.920: dot1x-ev:Delete auth client (0x84000003) message
*Mar 1 01:04:17.920: dot1x-ev:Auth client ctx destroyed
*Mar 1 01:04:17.929: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet0/9, changed state to up
*Mar 1 01:04:18.944: %AUTHMGR-5-SUCCESS: Authorization succeeded for client
(Unknown MAC) on Interface Gi0/9

Many thanks again, very very helpful.

Andrew

On Tue, Oct 20, 2009 at 10:28 AM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:

> All_from_NJ, all,
>
> 1. When you configure multi-host mode authentication, then violation does
> not even come into play. This is so because when you authenticate and
> authorize the port for the first device in multi-host mode operation, then
> anyone that comes along is allowed into the port and hence, no violation
> could occur. This explains the behavior you are seeing there.
>
> 2. Violation mode and Guest VLAN are two mutually exclusive. When a device
> does not respond to dot1x (or fails MAB, if configured) the port is placed
> into the Guest VLAN. Now the operational mode of the port effectively
> becomes multi-host (because anyone that comes along gets access on the port
> will do so via the configured Guest VLAN) and hence no violation could
> occur. Now, if anyone even authenticates and gets authorized on the port
> (the Guest VLAN does not get deployed) and a second device comes along and
> causes a violation on the port, this is when the mode plays a role here.
> Yes, the default is shutdown (err-disable) but you also have protect and
> restrict (similar to normal Port Sec violations).
>
> 3. Violation could occur in single-host and multi-domain modes only (not
> multi-auth and multi-host) and is only applicable to successful
> authentication scenarios. In single-host mode, after a successful
> authentication, any additional device (mac address) that is seen on the wire
> cause violation to occur on the port. In multi-domain (MDA) mode, when an
> additional mac is seen (after successful authorization of each domain, DATA
> and VOICE) on either of the domains, causes a violation to occur.
>
> Anyway, hope this helps clarify it abit and not confuse you even further.
>
> Sadiq
>
>
> On Sun, Oct 18, 2009 at 12:41 PM, Ryan West <rwest_at_zyedge.com> wrote:
>
>> Andrew,
>>
>> Was authentication event no-response action authorize vlan 11 left on the
>> config when you testing the violation action? Unless you actually have a
>> RADIUS server responding with a User Reject message, the no-response action
>> is going to take precedence.
>>
>> -ryan
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> ALL From_NJ
>> Sent: Sunday, October 18, 2009 12:14 AM
>> To: Cisco certification
>> Subject: Default violation mode - dot1x
>>
>> Hey team,
>>
>> Another question from a lab I did tonight.
>>
>> If you have configured a guest vlan, and the client does not respond to
>> authentication requests it will fail over the this vlan. The debugs are
>> most interesting during this process. If anyone is labbing this, I found
>> this to be helpful to my learning.
>>
>> BTW - for anyone wanting to see this, this is pretty easy to lab test.
>> Just
>> configure dot1x on a device that does not support it, and configure a
>> guest
>> vlan. Enable debugs and watch. Here are my configs (pardon the new
>> commands ... I recently upgraded everything)
>>
>> interface GigabitEthernet0/9
>> switchport mode access
>> authentication event fail action authorize vlan 10
>> authentication event no-response action authorize vlan 11
>> authentication host-mode multi-host
>> authentication port-control auto
>> dot1x pae authenticator
>> end
>>
>> Question - what happens if you type dot1x violation-mode shutdown? In my
>> lab, I tested this and it still fails over to the fail vlan. Not sure I
>> understand this ... after all, if you configure the violation mode to be
>> shutdown, why would the port stay up and become a member of a vlan?
>>
>> Humm ...
>>
>> Also, I believe the default violation mode is 'shutdown'. Can anyone
>> confirm this? I think this makes sense ... and it seems that the guest
>> vlan
>> command over rides this violation mode command.
>>
>> Many TIA,
>>
>> --
>> Andrew Lee Lissitz
>> all.from.nj_at_gmail.com
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> CCIE #19963
>

-- 
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net