Arista SD-Branch Part 7: Configuring RadSec Between EOS Switches and AGNI

14 October 2026 CloudVision AGNI SD-Branch Arista Campus RadSec PKI Ansible

RadSec is the link between every switch and AGNI, and it is the step most likely to go wrong, because it depends on certificates on both ends. This post walks through the switch side by hand, then reviews the community eos_agni_radsec Ansible role that automates it. The commands come from Arista’s published lab material and the role’s source. I have not run them.

What has to exist

For a RadSec session to come up, three things must be in place on the switch.

A private key and a signed client certificate for the switch.
The AGNI RadSec CA certificate, so the switch trusts the server.
An SSL profile that ties those together.

Then a RADIUS server entry that uses TLS, pointing at the RadSec hostname that AGNI shows under its RadSec settings.

Step 1: key and CSR on the switch

Generate an RSA key, then a certificate signing request. Arista’s guidance is that the common name must be the switch MAC address and the DNS subject alternative name must be the switch hostname. These commands follow the form the role uses. The MAC and names are examples.

security pki key generate rsa 2048 agni-private.key
security pki certificate generate signing-request key agni-private.key parameters common-name 001c.7312.34ab country GB state Cornwall locality Falmouth organization Example organization-unit Branch subject-alternative-name dns branch-sw01

The command prints the CSR. Copy all of it, including the BEGIN and END lines.

Step 2: sign the CSR in AGNI

In AGNI, add the switch as an access device and choose to get a client certificate. You can paste the CSR for a single device, upload a CSR file, or upload a zip for many. AGNI returns a signed certificate. Separately, download the RadSec CA certificate from AGNI’s RadSec settings, and note the RadSec server hostname shown there.

Step 3: get the files onto the switch

The switch must allow SCP, which means local login and exec authorization need to be set. The lab guide uses:

aaa authentication login console local
aaa authorization exec default local

The role checks for aaa authorization exec default in the running config and fails if it is missing. With that in place, copy both files to flash and then into the certificate store:

copy flash:branch-sw01.crt certificate:
copy flash:radsec_ca_certificate.pem certificate:
dir certificate:

Step 4: the SSL profile

configure
management security
   ssl profile agni-server
      certificate branch-sw01.crt key agni-private.key
      trust certificate radsec_ca_certificate.pem

Check it:

show management security ssl profile agni-server

The profile state should read valid. A mismatch between the certificate filename in the profile and the file you actually copied is the most common reason it does not. Arista’s own lab text refers to a certificate by one name and a rename step produces another, so match the profile to the real filename.

Step 5: point RADIUS at AGNI over TLS

The RADIUS side goes in a server group. The syntax visible in public AVD discussion is:

aaa group server radius AAA-AGNI-GROUP
   server radsec.beta.agni.arista.io vrf MGMT tls

I could not find a public source that quotes the exact keyword that binds the SSL profile to the RADIUS server, so confirm that line against the EOS command reference for your release. In Arista’s lab, a Static Configuration configlet carries all four pieces: the SSL profile, the RADIUS server using it, the server group, and the 802.1X authentication and accounting methods. In AGNI, the device then shows as connected under its access device list.

The eos_agni_radsec role

eos_agni_radsec automates steps 1, 2, 3 and 4. It uses arista.eos and ansible.netcommon over network_cli with paramiko, and needs three environment variables for the AGNI API: AGNI_KEY_ID, AGNI_KEY_VALUE and AGNI_ORG_ID. The tasks run in this order.

Assert the environment variables and CSR fields are set.
Check that aaa authorization exec default exists on the switch.
Log in to AGNI and keep the session cookie.
Fetch the RadSec CA certificate and push it to the switch.
Generate the key, and build the CSR with the system MAC as common name and the hostname as DNS SAN.
Send the CSR to AGNI’s enrolment API and save the returned certificate.
Copy the certificate to the switch, build the SSL profile, and assert the state is valid with no errors.

A minimal playbook:

- name: Configure SSL profile for AGNI RadSec on EOS switches
  hosts: GLOBAL
  gather_facts: no
  tasks:
    - name: Run the eos_agni_radsec role
      ansible.builtin.import_role:
        name: eos_agni_radsec
      vars:
        agni_base_url: "https://beta.agni.arista.io"
        eos_csr_info:
          country: "GB"
          state: "Cornwall"
          locality: "Falmouth"
          organization: "Example"
          organizational_unit: "Branch"

What to know before using it

It stops at the SSL profile. Configuring AGNI as the RadSec server on the switch is listed on the role’s roadmap, not done. Pair it with a configlet for the RADIUS and 802.1X lines.
It overwrites. The README warns that an existing AGNI SSL profile, key and certificates are replaced. There is no rotation logic, so a re-run replaces credentials on every switch it targets.
The default URL is the beta tenant. Set agni_base_url for your own environment.
Credentials travel in a URL. The login call puts the key ID and key value in a GET query string. Query strings end up in proxy and server logs, so run it from a trusted control node and treat the key as exposed if those logs are shared.
Secrets stay in the environment. That is the right choice over putting them in inventory, and it fits the pattern I described in Ansible Deep Dive Part 6.