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

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.

For any vendor without a page yet, the vendor dictionary in Taranac already knows how to encode VLAN, ACL, URL-redirect and CoA for fourteen platform families. The dictionary tells you which RADIUS attributes Taranac will send; what remains is the device-side configuration that accepts them.

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	Taranac → device, for reauthentication and session termination

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.

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.

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