Arista EOS

This page covers administrative access on Arista EOS — chiefly over TACACS+, which is the path we run and verify — and what Taranac sends an EOS switch during 802.1X. It is the device-side counterpart to TACACS+.

EOS keeps the legacy global tacacs-server host style rather than Cisco’s named server blocks, and its timers are global rather than per-server. The result is a shorter configuration than the equivalent on other platforms — with two sharp edges that are worth knowing before you start, not after.

This is a virtual platform. The AAA configuration is not hardware-specific, but as always, verify on your own gear before rolling out widely.

! ── Server and group ────────────────────────────────────────────
tacacs-server host 10.0.0.20 key 7 <OBFUSCATED_KEY>
tacacs-server timeout 30
!
aaa group server tacacs+ TARANAC
   server 10.0.0.20
!
! ── Authentication ──────────────────────────────────────────────
aaa authentication login  default group TARANAC local
aaa authentication enable default group TARANAC local
!
! ── Authorization ───────────────────────────────────────────────
aaa authorization exec default group TARANAC local
aaa authorization commands all default group TARANAC local
!
! ── Accounting ──────────────────────────────────────────────────
aaa accounting exec     default start-stop group TARANAC logging
aaa accounting commands all default start-stop group TARANAC logging
!
ip tacacs source-interface Vlan1

Two spelling differences from Cisco worth noting as you read: the enable fallback keyword is local rather than Cisco’s enable, and the accounting lines end in logging, which sends the accounting records to the local log in addition to the server.

The shared secret lives on the tacacs-server host line and nowhere else — the entry in the group below it carries an address, not a key. key 7 <OBFUSCATED_KEY> is what the switch prints back: you type the secret in the clear, and EOS re-displays it as type 7 afterwards. Write it as key <shared-secret>, or as key 0 <shared-secret> to say the encoding out loud. It has to match the secret on the device’s record in Taranac exactly — see Network devices.

no aaa root — present by default on modern EOS — disables the root account and should stay that way.

aaa authorization commands all default group TARANAC local
aaa accounting commands all default start-stop group TARANAC logging

EOS provides the shorthand that other platforms do not. One line covers every privilege level, for authorization and for accounting.

This is a genuine advantage, and it is worth appreciating what it saves you from. On Cisco IOS and Huawei VRP, the equivalent commands take one privilege level per line with no wildcard, and a level you forget to list is a level the switch never asks about — the command runs unauthorized and unrecorded, silently. EOS closes that whole class of mistake with the word all.

This is the one that bites, and it bites hard enough to end your session.

Apply it in two phases:

1. As the local admin — configure everything above except the aaa authorization commands all line. Save.
2. Log out, log back in as a TACACS+ user who already resolves to privilege 15 with a command set that permits everything — verify that login works first. From that session, apply the aaa authorization commands all line.

Because the second session is authenticated against Taranac and matched by a policy rule, its commands authorize normally and end / write memory go through.

The same ordering logic applies to any change that could deny you the commands needed to reverse it. Keep a second session open, and test the change in a third.

tacacs-server timeout 30

EOS has no per-server timeout — tacacs-server timeout applies to every TACACS+ server on the box. The default is 5 seconds, which is fine for password authentication and too short for anything involving a human.

When a user is enrolled in push MFA, Taranac holds the AAA exchange open while it sends a push to their phone and waits for approval — up to about 30 seconds. At the default timeout the switch gives up long before anyone can reach into a pocket, and the login fails over to local, which looks exactly like a server outage.

The effective approval window is the smaller of the device timeout and Taranac’s own server-side cap, so raising one alone changes nothing. Raise both together.

ip tacacs source-interface Vlan1 fixes the source address of TACACS+ packets, which is what Taranac matches against the registered device.

On a switch with a single SVI and no routing, leaving it unset happens to work. It stops working the moment a second L3 interface appears or routing changes, and the failure is unhelpful: Taranac drops the request as coming from an unknown client without writing a policy decision, so the switch reports a timeout while the server logs show nothing at all. Pin it explicitly. See Network devices.

The reason this keeps happening is structural. An EOS server group stores a copy of the server’s address and ports, not a reference to the block above it. Cisco’s modern syntax puts server name TARANAC in the group, so editing the tacacs server block propagates everywhere; on EOS the two are independent lines that merely happen to agree, and changing one leaves the other behind.

The same trap on the RADIUS side is quieter and worse, because the method list resolves through the group:

radius-server host 10.0.0.20 auth-port 1814 acct-port 1815   ! moved
aaa group server radius TARANAC-NAC
   server 10.0.0.20 auth-port 1822 acct-port 1823            ! stale copy

aaa authentication dot1x default group TARANAC-NAC follows the group, so every 802.1X and MAB request goes to a port nothing is listening on. There is no timeout to watch and no rejection to read: the endpoint simply never authorizes and Taranac’s NAC log shows no event at all — not a reject, not an unknown NAS — which reads as a supplicant problem and sends you debugging the client. We lost six days to exactly this in our own lab after moving the NAC ports on the server. Fix it in the group, not only on the host line:

aaa group server radius TARANAC-NAC
   no server 10.0.0.20 auth-port 1822 acct-port 1823
   server 10.0.0.20 auth-port 1814 acct-port 1815

show tacacs is the reachability and health view:

switch#show tacacs
TACACS+ server            : 10.0.0.20/49
          Connection opens:       1238
         Connection closes:       1237
    Connection disconnects:          0
       Connection failures:          0
       Connection timeouts:          0
             Messages sent:       1347
         Messages received:       1347
            Receive errors:          0
          Receive timeouts:          0
             Send timeouts:          0
                DNS errors:          0
 Unknown attribute ignored:          0
Unknown attribute failures:          0

TACACS+ server-group: TARANAC
     0: 10.0.0.20/49

Last time counters were cleared: never

Opens tracking closes with zeros across failures and timeouts is healthy. The server-group block at the bottom is where you confirm there is exactly one entry per server.

show aaa counters is the fastest way to see whether the policy is doing anything:

switch#show aaa counters
Authentication
Successful: 107
Failed: 3
Service unavailable: 0

Authorization
Allowed: 459
Denied: 0
Service unavailable: 0

Accounting
Successful: 672
Error: 2
Pending: 0

Session
Opened: 107
Closed: 106

Read it as three separate questions. Service unavailable under Authentication or Authorization is a reachability problem — the server never answered. Failed or Denied means the server answered and said no, which is a policy question, not a network one. And a non-zero Authorization Allowed count is the proof that command authorization is genuinely live, rather than configured but never consulted.

show users detail confirms how the current sessions authenticated:

switch#show users detail
Session Username Roles      TTY   State Duration        Auth           Remote Host
------- -------- ---------- ----- ----- --------------- -------------- -----------
94      taranac  <unknown>  vty3  E     1 day, 1:21:45  group TARANAC  10.6.0.110

Auth: group TARANAC is what you want to see — that session was authenticated by Taranac, not by the local database. Roles showing <unknown> is normal for a TACACS+ session whose profile returns a privilege level rather than a named EOS role; it is not a fault. The built-in Arista EOS TACACS+ template defines exactly one shell attribute, priv-lvl (0–15, default 15), with per-command authorization matched as a regular expression — so a privilege level is what a stock profile returns.

Finally, prove authorization rather than assuming it: log in from a second session and run a command your policy should deny. A denial arriving from Taranac — and the matching increment in the Denied counter — is the only real evidence.

Our EOS switch logs in over TACACS+, and that is the path this page verifies. Taranac has shipped an Arista EOS RADIUS admin-auth template since 1.2.1, though, and it is worth knowing what that template puts on the wire before reaching for it.

The shape is Cisco’s under Arista’s own vendor ID: shell:priv-lvl=15 inside an Arista-AVPair says what shell:priv-lvl=15 inside a Cisco-AVPair says on IOS. The role is the one thing RADIUS can express here that the TACACS+ template cannot — see show users detail above.

Over TACACS+ this question does not arise: enable is a real exchange in the protocol, aaa authentication enable default group TARANAC local drives it, and it is verified on this platform. RADIUS has no such exchange at all.

Taranac 1.2.5 taught the RADIUS handler to answer a privilege escalation anyway, because a family of platforms sends one as an ordinary Access-Request whose User-Name is the synthetic $enab<N>$ — no person in it — answered against the global enable password on Settings → RADIUS. That recognition is purely mechanical: the handler matches the name, $enab<N>$ for any level, and nothing else. It is not a vendor list, and there is no per-vendor switch to turn on.

EOS has an aaa authentication enable command that can point at a RADIUS group, so it is certainly not one of the platforms with no escalation step at all — the group where privilege simply arrives in the login Access-Accept and no second request is ever made, which is where Juniper, NX-OS, FortiOS and MikroTik RouterOS sit. But Arista documents nothing about what the resulting Access-Request contains, and nobody has captured one. Two outcomes are possible, and Taranac assumes neither:

• If EOS sends $enab<N>$ — the Cisco convention — Taranac already answers it, and nothing is needed beyond setting the global enable password.
• If EOS sends the operator’s real name instead, the way Aruba AOS-S, Cisco ASA and AOS-CX 10.15+ do, the request falls through and is answered as an ordinary login, which is what it is: the operator retypes their own password and the switch escalates on the Access-Accept. That path runs the whole login policy, MFA included — the $enab<N>$ path cannot, because a request that names nobody has no user for a second factor to belong to.

You do not have to guess which one you have from the outside. A recognised escalation is badged enable → 15 beside the synthetic name in the authentication log, so a single enable attempt from an EOS switch answers the question. The mechanism itself is on RADIUS → Privilege escalation (enable). If you run EOS admin auth over RADIUS, we would like to hear which shape your switch sends.

The switch-side 802.1X and MAB configuration for EOS is covered step by step in Build an 802.1X lab, including the two independent commands CoA needs and why having only one of them fails silently. It is not repeated here.

Vendor ID 30065, and the first thing to know about it is how it gets chosen. Vendor auto-detection matches on vendor-specific attributes present in the request, and the Arista entry declares none — so an EOS switch is never recognised from its own traffic. It is resolved by the pin on the device record, failing that by the device’s free-text vendor field (arista and arista eos both map to this entry), and failing that by the generic entry, which knows nothing Arista-specific. Pin it, and the guessing stops.

The two blanks matter. A downloadable ACL has no attribute to travel in on EOS, so an authorization profile carrying one has nothing to send here — reference an ACL that already exists on the switch by name instead. URL redirect is declared by exactly one entry in the whole shipped dictionary, Cisco IOS / IOS-XE; on EOS a captive portal is reached by putting the endpoint in a holding VLAN whose gateway forces the portal, not by a redirect attribute.

CoA is narrower than Cisco’s in the same way:

A native CoA-Request re-authentication is declared by only three entries in the shipped dictionary — Cisco IOS / IOS-XE, Cisco NX-OS and Juniper — and Arista is not one of them. A VLAN change, by contrast, is a real CoA-Request on every vendor in the dictionary. The full matrix is on NAC policy.

What this page adds is what the verification output looks like when it is working. show radius is the single most informative command on an EOS NAC deployment:

switch#show radius
RADIUS server             : 10.0.0.20, authentication port 1814, accounting port 1815
Dynamic authorization UDP port: 3799
             Messages sent:        510
         Messages received:        510
         Requests accepted:         85
         Requests rejected:          5
       Requests challenged:        420
          Requests timeout:          0
    Requests retransmitted:          0
             Bad responses:          0
         Connection errors:          0
                DNS errors:          0
     CoA requests received:          0
      DM requests received:          1
             CoA ACKs sent:          0
              DM ACKs sent:          1
             CoA NAKs sent:          0
              DM NAKs sent:          0
    Accounting Starts sent:          8
      Interim Updates sent:         27
     Accounting Stops sent:          8

Three things to read out of it:

• CoA is genuinely working. DM requests received: 1 with DM ACKs sent: 1 means Taranac sent a Disconnect-Message and the switch accepted it. Note that the switch’s running configuration contains no radius-server dynamic-authorization line — the port is at its default, so EOS hides it. This is exactly why CoA on EOS must be verified by behaviour rather than by reading the configuration: Dynamic authorization UDP port: 3799 in this output, and the DM counters moving, are the evidence. An empty CoA/DM counter set on a deployment that should be using CoA means it is silently going nowhere. Note which pair of counters moved: because EOS has no native re-authentication action, a Reauthenticate issued from Taranac lands in the DM counters too, not the CoA ones.
• Requests challenged: 420 far exceeding accepts is normal, not alarming. EAP is a multi-round conversation, so each successful authentication produces several Access-Challenge exchanges before the accept.
• Accounting is flowing. Starts matching Stops, with interim updates, is what produces sessions in Taranac. A switch that authenticates but sends no accounting shows up in the auth log with zero sessions.

Per-port state needs an interface — show dot1x on its own returns % Incomplete command rather than a summary, unlike the Cisco equivalent:

switch#show dot1x interface Ethernet3
Dot1X Information for Ethernet3
--------------------------------------------
Port control: auto
Forced phone authorization: disabled
EAPOL: enabled
Host mode: multi-host authenticated
MAC-based authentication: enabled
MAC-based authentication host mode: Unconfigured
MAC-based authentication always: disabled
Quiet period: 60 seconds
TX period: 10 seconds
Maximum reauth requests: 2
Ignore reauth timeout: No
Auth failure VLAN: Unconfigured
Unauthorized access VLAN egress: No
Unauthorized native VLAN egress: No
EAPOL authentication failure fallback: Unconfigured

Port control: auto with EAPOL: enabled and MAC-based authentication: enabled is a port doing 802.1X with MAB as the fallback.

• Device configuration — conventions and the rest of the cookbook
• Cisco IOS / IOS-XE — the same ground on another platform
• Huawei VRP — and another
• Network devices — registering the device and its secret
• TACACS+ — profiles, command sets, privilege levels
• RADIUS — templates, profiles and privilege escalation
• NAC policy — authorization profiles and the CoA matrix
• Build an 802.1X lab — the NAC side of this platform