I'm currently testing 802.1x in our evironment and one of the things I want to do is mac-address authentication (basically a machine trying to connect to a port has to come up against our ACS server with these addresses). I can get it to work but for some reason it takes close to 5 minutes for it to authenticate. This seems to be the case whether its a reboot of the same mac address or a new mac-address. I'm thinking this might be something on the switch to ACS side because the ACS server doesn't receive an authentication request until a few minutes after the machine is plugged in. Anyone ever seen something like this?
Here is a sanitized copy of the switch config:
no service pad
service timestamps debug uptime
service timestamps log datetime
enable secret 5 blah
enable password 7 blah
username blah password blah
aaa authentication login default group tacacs+ local
aaa authentication dot1x default group radius
aaa authorization config-commands
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ none
aaa authorization network default group tacacs+ local
aaa accounting auth-proxy default start-stop group radius
aaa accounting dot1x default start-stop group radius
aaa accounting system default start-stop group radius
aaa session-id common
clock timezone UTC -5
clock summer-time UTC recurring
ip dhcp snooping vlan 1
ip dhcp snooping
cluster commander-address mem
no file verify auto
spanning-tree mode pvst
spanning-tree extend system-id
vlan internal allocation policy ascending
switchport mode access
switchport port-security maximum 2
switchport port-security aging time 1
switchport port-security violation protect
switchport port-security aging type inactiv
dot1x pae authenticator
dot1x port-control auto
dot1x host-mode multi-host
dot1x guest-vlan 23
ip dhcp snooping limit rate 100
switchport trunk encapsulation dot1q
switchport mode trunk
ip dhcp snooping trust
switchport mode dynamic desirable
ip address 10.10.10.1 255.255.252.0
no ip route-cache
ip http server
ip http access-class 1
ip http secure-server
tacacs-server host 10.10.10.6
tacacs-server key 7 blah
radius-server host 10.10.10.6 auth-port 1645 acct-port 1646 key 7 blah
radius-server source-ports 1645-1646
radius-server vsa send accounting
radius-server vsa send authentication
alias exec macsh sh mac-address | include
alias exec arpsh sh arp | include
line con 0
line vty 0 4
access-class 1 in
password 7 blah
line vty 5 15
password 7 blah
ntp clock-period 36029099
ntp server 10.10.10.9
While it should not take 5 minutes, it may take some time. The reason is fundamentally due to 802.1X also being enabled.
At link up, the port will be enabled for 802.1X first, and enter immediately into the state-machine for 802.1X. That directly means no traffic should be processed by the network (and the MAC isn't even known by the switch either). 802.1X operates this way by default, but could time-out. So, once 802.1X times out (90-sec by default), and THEN the device plugged in sends traffic (completely variable), the MAC can be initially learned by the switch, and checked against the backend for authorization.
Hence, this functionality currently serves as a supplemental authentication technique for devices incapable of speaking 1X only. Optionally, if you need decrease the time to time-out on 1X, see the tx-period (default 30) and the max-reauth-req (default 2) on the port. You can get it down to ~2-sec if you want.
Hope this helps,
Thanks jafrazie. This is good info. I do know it takes a little time but I can't imagine it should take this long. I need this to be as transparent to the user as possible. I also noticed that at times when you unplug a machine and replug, and reboot, the port authenticates fine (drops it on the right vlan) but the IP address isn't assigned. From showing debug logs its missing a line where it says GLEAN something to IP (I don't have the exact line). This I guess is a bug where the machine sends a request to the dhcp server before the dot1x can authenticate that port?
Also, what does TxPeriod do? Is it 30 second timeout before it attempts another request?
A couple of things here.
* Not sure about a debug and an DHCP with a debug from your reeference. Suffice it to say though, that if you're running 1X on a port, don't even expect DHCP to work (or anything else for that matter) until 802.1X has authorized the port (and out of the way of the data-plane). And DHCP is completely controleld from the client anyway, that should have predictable timing, expected operation, etc.
The tx-period is a timer written into the 1X spec. An authenticator (switch) has the responsibility of re-transmitting frames it expects an answer to. In this case, it's the very first frame (EAPOL-Id-Request) when the switch is looking for a suppliant. The tx-period (30-sec default) is the period for how often the switch will re-transmit the frames. 30-sec is the recommended timer from the 1X spec (since packet loss should be a null concern). But in your case, bear it in mind, if your wanting a non-1x port to "enable". The Guest-VLAN and MAC-Auth-Bypass can only execute after 802.1X has timed out. So, you may want to consider tweaking the timer down in the interest of giving this non-1X device some "more immediate" access. There's security built-in to trying 1X first, however, so there's no silver bullet recommendation here.
The other value I mentioned before was max-reauth-req. This is how many times 1X will REtransmit the initil EAPOL-Id-Req frame before giving up on the fact that a supplicant is not there.
So effectively, the formula for timing out on 1X for these supplemental techniques is.
[tx-period * (1+max-reuath-req).]
Hope this helps,
Yes that is exactly what I'm seeing here. The computer makes a DHCP request before 1x can authenticate properly which is really bad, heh. What's odd is when I first tested this a few months ago I was pretty sure the port would authenticate pretty instantaneously (if not, less than a minute at most). The only difference between what I'm testing now and what I tested then were the IOS levels (SEE1 now, SEE back then).
I'll try toggling the TX-period and max-reauth-req numbers and see if there's any improvement. Also, when you mean non-1x you mean just any client I have that isn't using the 1x client from the O/S or not supporting 1x at all (only printers here prob are the ones don't support 1x).
My setup also is similar to yours. I have enabled the MAC authentication bypass and also configured guest VLAN. Its working perfectly fine for me.
Please let me know how to restrict this Guest VLAN from communicating with other VLANs.
Since routing is enabled for this Guest VLAN subnet all the subnets are communicating.
Please let me know how to restrict this VLAN communication to only itself.
It is up to you, but this deployment guide will probably help. Look at the "Network Virtualization Solutions" page on CCO.
Hope this helps,
Thanks for your reply.
I have one more query regarding MAC authentication using Cisco ACS.
I import the bulk MAC address using the CSutility to Cisco ACS internal database.
I use the command below in my filename.txt file
This adds my MAC address entry in my Cisco ACS internal database
I would like to add the realname field also using the Csutility . Please let me know the way of doing the same.