Device configuration

The rest of the documentation describes Taranac’s side of a deployment: devices, policies, profiles and command sets. This section is the other half — what you actually type on the switch, router or firewall so it talks to Taranac.

Each page here is a vendor cookbook: working configuration blocks, the verification commands that prove they took effect, and the failure modes specific to that platform. The examples are taken from real devices, not assembled from vendor marketing docs, and every page states exactly which platform and software version it was verified on.

Platform	Device admin (TACACS+)	Device admin (RADIUS)	NAC (802.1X / MAB)
Cisco IOS / IOS-XE	Verified	Verified	See the lab guide
Huawei VRP	Verified (contributed)	—	—
Arista EOS	Verified	—	See the lab guide
Fortinet FortiGate	Verified — profile-based, no per-command	—	—
MikroTik RouterOS	Not supported by the platform	Verified — group-based, no per-command	Verified — 802.1X, MAC auth, CoA
Other vendors	—	—	Vendor dictionary

This table is about these pages, not about what Taranac supports. Built-in vendor knowledge is considerably wider than the five cookbooks — see What ships built-in below. A dash in a column means no page covers that combination yet, never that the platform is out of reach.

The NAC column is deliberately thin here: the switch-side 802.1X and MAB configuration is taught end to end in Build an 802.1X lab, and the vendor pages link to it rather than repeat it. What the vendor pages add on top is the platform-specific detail — command spelling that changed between software trains, and the verification commands that differ from one release to the next.

Vendor knowledge lives in three separate registries, and they are not the same set — a platform present in one is often absent from another, because not every platform speaks both protocols and not every platform does NAC at all. Read them as three answers to three different questions.

Registry	What ships	What it decides
TACACS+ templates — 18	Cisco IOS / IOS-XE, NX-OS, ASA, IOS-XR, SD-WAN vManage · Juniper JunOS · Arista EOS · Huawei VRP · Fortinet FortiGate · Palo Alto PAN-OS · HP/Aruba ArubaOS-CX and ArubaOS-Switch · H3C / HPE Comware 7 · Nokia SR OS · Ruckus / Brocade ICX (FastIron) · Extreme EXOS · Extreme SLX-OS · Calix AXOS	The shape of a TACACS+ profile: which service the platform authorizes under, which attributes it accepts, which of them are mandatory. See TACACS+.
RADIUS templates — 15	Cisco IOS / IOS-XE and NX-OS · Juniper JunOS · Fortinet FortiGate · Palo Alto PAN-OS · HPE/Aruba Switch · Huawei VRP · MikroTik RouterOS · Arista EOS · Aruba CX (AOS-CX) · Nokia SR OS · H3C / HPE Comware · Ruckus ICX / Brocade (Foundry) · Extreme EXOS · Generic RADIUS	The reply attributes of an administrative login answered over RADIUS. See RADIUS.
NAC vendor dictionary — 16	Cisco IOS / IOS-XE and NX-OS · Arista EOS · Juniper · MikroTik RouterOS · Huawei VRP · H3C / HPE Comware · Aruba (AOS-CX / Controllers) · HPE ProCurve / ArubaOS-Switch · Fortinet FortiGate / FortiSwitch · Dell N-Series · TP-Link · 3Com · Extreme EXOS · Ruckus ICX / Brocade (Foundry) · Generic (RFC standard)	How an 802.1X authorization result — VLAN, ACL, redirect — is encoded for that switch, and how a CoA is delivered to it. See NAC policy.

Two things the table is easy to over-read:

• There is no generic TACACS+ template. RADIUS and the NAC dictionary each carry a fallback that speaks standard attributes; TACACS+ does not, because on TACACS+ the attribute a platform wants is the authorization. A platform with no template is configured with raw AV-pairs on a profile, not rescued by a fallback.
• A dictionary entry does not make every vendor equal. All sixteen entries encode a VLAN, a named ACL and a session timeout. A downloadable ACL is declared by four (Cisco IOS / IOS-XE, Cisco NX-OS, Juniper, Huawei VRP) and URL redirect by exactly one — Cisco IOS / IOS-XE. Native reauthentication is declared by three (Cisco IOS / IOS-XE, Cisco NX-OS, Juniper); every other entry, the generic RFC one included, delivers a reauthentication as a Disconnect, so the endpoint reconnects rather than re-authenticating in place. The full matrix, port bounce included, is on NAC policy.

The dictionary tells you which RADIUS attributes Taranac will send; what remains is the device-side configuration that accepts them, and that is what a vendor page is for.

Verified means verified. Every page opens with a table naming the exact platforms and software versions the configuration was tested on. Where a block has not been run on real hardware, it is marked as such inline. Configuration that gets pasted into production switches is the wrong place to be optimistic.

Placeholders. Configuration blocks use these consistently, so you can search and replace across a whole page:

Placeholder	Meaning
10.0.0.20	The Taranac server’s address, as reachable from the device
10.0.0.11	The device’s own management address
<TACACS_SECRET>	The device’s TACACS+ shared secret, matching its tacacs_key in Taranac
<RADIUS_SECRET>	The device’s RADIUS shared secret, matching its radius_secret in Taranac
TARANAC	The AAA server-group name — arbitrary, but used consistently in examples

Secrets are per device. A device’s secret must match the value stored on that device’s entry in Taranac byte for byte; see Network devices for the device → device group → global inheritance chain.

Every device-side configuration points at these ports. They are the defaults of a standard Taranac deployment; a deployment that remapped them in its environment file must use its own values, and every device configuration has to move with them.

Service	Port	Used by
TACACS+	49/tcp	Device administration — login, enable, command authorization, accounting
TACACS+ over TLS	6049/tcp	Same, encrypted transport
RADIUS (device admin)	1812/udp auth, 1813/udp acct	Administrative login on platforms that do AAA over RADIUS
RADIUS (NAC)	1814/udp auth, 1815/udp acct	802.1X and MAB endpoint authentication
CoA / Disconnect	3799/udp (default)	Taranac → device, for reauthentication and session termination

The CoA row is the one entry in that table Taranac does not simply own. 3799/udp is the default destination, and the port a CoA is actually sent to is resolved device → device group → nac.coa_port. A platform that listens elsewhere — Cisco’s legacy 1700 is the common case — must either be told to listen on 3799 or have the right port set on its device or device-group record, and a mismatch is silent: the switch never answers, which is indistinguishable from an unreachable device. See CoA settings.

Two things on the Taranac side must be true before any of this works, and both fail silently from the device’s point of view:

• The device is registered, with the address Taranac will actually see in the request — not necessarily the address you think of as the device’s management IP. If the device sources AAA packets from a different interface than the one you registered, Taranac treats the request as coming from an unknown client and drops it without writing a policy decision. Each vendor page shows how to pin the source interface.
• A policy rule matches, returning a profile. A device that authenticates but lands the user at the wrong privilege level, or with no shell at all, is usually a policy problem rather than a device problem. See AAA policy.

Some device-side behaviour is wrong on several platforms at once, so Taranac deals with it centrally rather than in a vendor page. Worth recognising, because each of these reads on the device as a policy fault:

• A device escalating privilege over RADIUS. RADIUS has no enable exchange, but a family of platforms sends one anyway — Cisco IOS / IOS-XE, Cisco Business, H3C Comware 7 and Eltex ESR — as an Access-Request whose user name is the synthetic $enab<N>$. It names nobody, so it is answered against a global enable password rather than reported as a user who does not exist; see Privilege escalation. Platforms that send the real user name for enable (Aruba AOS-S, Cisco ASA, AOS-CX 10.15 and later) need none of this.
• A device that omits an attribute separator. Each TACACS+ authorization attribute is required to carry a = or *; some platforms — Edgecore ECS4100 is the reported one — send a bare <cr> as an argument of its own. Read strictly that invalidates the whole request, so login succeeds and every single command is denied, with an empty profile in the authorization log pointing at a policy that was never consulted. Tolerate Malformed AV-Pairs is on by default and ignores the offending pair; see Settings.
• An attribute your equipment defines and FreeRADIUS does not ship. Both RADIUS services accept a pasted vendor dictionary — Settings → RADIUS for device administration, Settings → NAC for 802.1X — after which the name is usable like any other. Before that, a profile referring to it sends nothing, with no error anywhere. See Custom attribute dictionary.

Pages marked contributed were tested by Taranac users on their own hardware, not in our lab. That is the only way a cookbook covers more platforms than one lab can hold, and contributions are genuinely welcome.

What makes a contribution usable:

• The exact platform and software version — model number and full version string. “A Huawei switch” cannot be put in a Verified-on table; S5735-L24P4S-A1, V200R021C00SPC100 can.
• What you actually tested, as opposed to what the configuration ought to do. Authentication only, or command authorization too? Accounting verified by looking at the records, or assumed from the configuration?
• The configuration with secrets removed — placeholders in place of keys, hashes and passwords. Please do not send working credentials.
• Output from the verification commands, not just the command names. Knowing what healthy looks like on a platform is often more useful than the configuration itself.
• Anything that surprised you. A default that had to be changed, a command that had to be applied in a particular order, a step that silently did nothing. The warnings on these pages come almost entirely from someone hitting the problem first.

Extreme SLX-OS and Calix AXOS ship built-in TACACS+ templates but have no page here yet — a verified configuration for either is exactly what this section is short of.

Send it through support, and tell us how you would like to be credited.

• Network devices — registering devices, secrets, device groups
• TACACS+ — profiles, command sets, the enable chain
• RADIUS — templates, profiles, reply attributes
• Build an 802.1X lab — the switch side of NAC, end to end