Problem

Arista has released new 802.1x features and commands in EOS 4.23, but has yet to update the documentation. My macOS clients were still receiving EAP requests from the switch, which presented an authentication window to the end-user, even though the supplicant would ultimately be authorized based on its MAC address.

Sample EAP request from a pcap:

No.     Time           Source                Destination           Protocol Length Info
      1 0.000000       AristaNe_00:00:00     Nearest-non-TPMR-bridge EAP      60     Request, Identity

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface en1, id 0
Ethernet II, Src: AristaNe_00:00:00 (00:00:00:00:00:00), Dst: Nearest-non-TPMR-bridge (00:00:00:00:00:00)
802.1X Authentication
    Version: 802.1X-2004 (2)
    Type: EAP Packet (0)
    Length: 5
Extensible Authentication Protocol
    Code: Request (1)
    Id: 1
    Length: 5
    Type: Identity (1)

Solution

Configure dot1x

First, we need to enable dot1x on the switch. There are two main parts to this; dot1x, and aaa.

dot1x
   radius av-pair service-type
   mac-based-auth radius av-pair user-name delimiter none lowercase

The service-type line is optional, but you may want to include it so you can make that specification in your Connection Request Policy and/or Network Policy (i.e.: “framed” vs “call check”).

For more info on the service-type definition: check out RADIUS TYPES on the IANA website

The delimiter line is new as of EOS 4.23.1 according to Arista support. However, I have yet to find it in their release notes/TOI. In my case, I’m using Windows NPS as my RADIUS server. My MAC addresses are added as users in Active Directory Users & Computers, with the MAC address as both the username and password with no delimiter. Without this line, the Authenticator (switch) will forward on the MAC as it receives it from the first packet. In the case of a macOS client, it will be sent as ab:00:ab:00:ab:00:ab:00 when we need it to come in as ab00ab00ab00ab00.

Define the RADIUS server

To define the RADIUS server, you only need to configure the second line that follows. In my use-case, we have multiple switch vendors using the same NPS instance. In order to utilize separate CRPs and NPs, I opted to define av-32 (NAS identifier). Additionally, I’m sending my RADIUS traffic over the management VRF. You may be sending it over the default VRF.

radius-server attribute 32 include-in-access-req format $some.text.here
radius-server host nps-01.advertisingemergency.net vrf mgmt key 7 (removed)

Define the authentication list for dot1x requests

The final global/non-interface-specific config is to set the authentication list used for dot1x.

aaa authentication dot1x default group radius

You may have multiple RADIUS servers and therefore use a server group. For my environment, I only have the one, so we’ll leave it as “default.”

Interface config

Configuring the interfaces can be as simple or complex as you’d like. For my configuration, there weren’t a lot of special needs. However, this is where the Arista documentation was lacking. Here’s an example interface configuration from a 7020:

interface Ethernet1
   description dot1x_enabled_port
   dot1x pae authenticator
   dot1x authentication failure action traffic allow vlan 100
   dot1x reauthentication
   dot1x port-control auto
   dot1x eapol disabled
   dot1x mac based authentication

So let’s break this down, line-by-line…

dot1x pae authenticator

This configures the port as an Authenticator. For dot1x to work, we need a Supplicant (typically the client or host), Authenticator (typically the switchport), and Authentication Server (typically a RADIUS server).

dot1x authentication failure action traffic allow vlan 100

An optional, but good practice, is to have a default or failback VLAN. Think of this as a public or client network. It shouldn’t have access to your production network/servers, and probably only allows for a simple internet connection. Consider a guest bringing in their own laptop for a presentation and connecting to one of your network drops (first off, shame on them!). The failure VLAN may grant them internet access, but that’s it. Note that this will apply not only to unknown clients, but any clients that you don’t have married to a VLAN in your RADIUS server.

dot1x reauthentication

This is another optional, but recommend line. Once a Supplicant (machine/client) successfully connects and is granted access to a VLAN, we probably want to verify their membership throughout the day. The default reauthentication period is one hour (3600 seconds). Note that a reauthentication request is a different service-type (recall radius av-pair service-type in my config above).

dot1x port-control auto

This puts our interface port into the unauthorized state by default, and allows it to become authorized if granted access by the Authentication Server.

dot1x eapol disabled

This is the line that drove me nuts! Arista support claims this command, like the delimiter config, was added in EOS 4.23.1. However, it cannot be found in the documentation/command guides.

I did actually find mention of it in the 4.23.1 release notes. However, the command is not shown.

Support for per port control knob for sending and receiving EAPOL packets. (400019)

Without this entry in the interface config, the macOS Supplicants were presented with the 802.1x authentication window, even though MBA was configured (the next config line). While the macOS client would still authenticate properly and be assigned to the correct VLAN, it was cumbersome to the end-user.

dot1x mac based authentication

Last, but certainly not least, this line tells the port to use MBA (MAC-based authentication).