Huawei VRP

This page covers administrative access on Huawei VRP switches over HWTACACS — Huawei’s TACACS+ implementation. It is the device-side counterpart to TACACS+. The 802.1X side of VRP, which has moved more between releases than any other vendor’s, is covered separately at the end.

VRP structures AAA differently from Cisco. Instead of attaching method lists directly to lines, you build named schemes (authentication, authorization, accounting, recording), bind them to a domain, and point the VTY lines at AAA. It is more indirection, but it keeps administrative AAA cleanly separated from everything else on the box.

Taranac ships a Huawei VRP TACACS+ template out of the box, with priv-lvl defaulting to 15 and per-command authorization enabled (exact match style). On a V200 switch the configuration below works against that template with no Taranac-side editing. On V600 the one thing you must change is that default — see Privilege levels.

There is also a Huawei VRP RADIUS template, for sites that answer administrative logins over RADIUS rather than HWTACACS. It carries one mandatory attribute — Huawei-Exec-Privilege (VSA 29, integer, default 15) — alongside Service-Type = Login-User and the usual session and idle timeouts. That path is not what this page configures and was not part of the contributed testing; see RADIUS. It is also the one Huawei path Taranac deliberately leaves on the carrier attribute list, for the reason given below.

VRP builds this up in layers. Each block below is a layer; apply them in order.

hwtacacs-server template TARANAC-TACACS
 hwtacacs-server authentication 10.0.0.20
 hwtacacs-server authorization  10.0.0.20
 hwtacacs-server accounting     10.0.0.20
 hwtacacs-server source-ip source-vlanif 1
 hwtacacs-server shared-key cipher <TACACS_SECRET>

Authentication, authorization and accounting are named separately, even when they all point at the same server. Omitting one of the three lines disables that function without any warning at configuration time.

The address lines carry no port, so they use the HWTACACS default of TCP 49 — which is what a standard Taranac deployment listens on. A deployment that remapped the TACACS+ port must specify it on each of the three lines.

hwtacacs-server source-ip source-vlanif 1 pins the source address, which is what Taranac matches against the registered device. This matters as much here as anywhere: if the source address does not match the address on the device’s entry in Taranac, the request is dropped as coming from an unknown client, and nothing is written to the Taranac logs — the switch reports a timeout while the server appears idle. See Network devices.

Pinning it explicitly matters most on a switch with several Layer 3 interfaces, where the source address otherwise follows the egress interface the routing table happens to pick, and on an HA pair, where it keeps the NAS address the same whichever member is handling management traffic.

hwtacacs-server template TARANAC-TACACS
 hwtacacs-server timer response-timeout 30

VRP’s default response timeout is 5 seconds. Taranac holds the AAA exchange open while the admin taps approve on their phone — up to about 30 — so the default gives up first and falls through to local before the approval can arrive. Raise it on the NAS and on the server together: whichever of the two is shorter is the one that decides.

aaa
 authentication-scheme TARANAC-TACACS-AUTH
  authentication-mode hwtacacs local

hwtacacs local tries HWTACACS first and falls back to the local user database — but only when the server is unreachable or times out.

aaa
 authorization-scheme TARANAC-TACACS-AUTHOR
  authorization-mode hwtacacs local
  authorization-cmd 0  hwtacacs local
  authorization-cmd 1  hwtacacs local
  authorization-cmd 2  hwtacacs local
  authorization-cmd 3  hwtacacs local
  authorization-cmd 4  hwtacacs local
  authorization-cmd 5  hwtacacs local
  authorization-cmd 6  hwtacacs local
  authorization-cmd 7  hwtacacs local
  authorization-cmd 8  hwtacacs local
  authorization-cmd 9  hwtacacs local
  authorization-cmd 10 hwtacacs local
  authorization-cmd 11 hwtacacs local
  authorization-cmd 12 hwtacacs local
  authorization-cmd 13 hwtacacs local
  authorization-cmd 14 hwtacacs local
  authorization-cmd 15 hwtacacs local

Sixteen lines, and all sixteen are load-bearing.

This is the same trap as on Cisco IOS, and it fails the same way — silently, in the permissive direction. Only the spelling differs. Among the vendors documented here, Arista EOS is the outlier that offers a commands all shorthand; Cisco and Huawei both make you enumerate.

On V600 the range stops at 3, so the scheme is four lines rather than sixteen — the levels above it do not exist on that branch:

aaa
 authorization-scheme TARANAC-TACACS-AUTHOR
  authorization-mode hwtacacs local
  authorization-cmd 0 hwtacacs local
  authorization-cmd 1 hwtacacs local
  authorization-cmd 2 hwtacacs local
  authorization-cmd 3 hwtacacs local

aaa
 accounting-scheme TARANAC-TACACS-ACCT
  accounting-mode hwtacacs
!
 recording-scheme TARANAC-TACACS-RECORD
  recording-mode hwtacacs TARANAC-TACACS
!
 cmd recording-scheme TARANAC-TACACS-RECORD

Note that recording-mode hwtacacs TARANAC-TACACS references the server template by name directly, unlike the other schemes which get their server from the domain binding.

aaa
 domain default_admin
  authentication-scheme TARANAC-TACACS-AUTH
  authorization-scheme  TARANAC-TACACS-AUTHOR
  accounting-scheme     TARANAC-TACACS-ACCT
  hwtacacs-server       TARANAC-TACACS

default_admin is VRP’s built-in domain for device-management logins. Binding the schemes here is what actually puts them into service — a scheme that exists but is bound to no domain does nothing.

user-interface vty 0 4
 authentication-mode aaa
 protocol inbound ssh

The tested production configuration ran protocol inbound all, permitting Telnet alongside SSH. For a new deployment use ssh only — TACACS+ protects the AAA exchange between switch and server, not the admin’s session to the switch, so Telnet still puts credentials and every command on the wire in clear text.

The V600 configuration additionally pins the line’s own privilege level and widens the VTY pool:

user-interface maximum-vty 5

user-interface vty 0 4
 authentication-mode aaa
 user privilege level 3
 protocol inbound ssh

aaa
 local-user <BREAK_GLASS_ADMIN> password irreversible-cipher <PASSWORD_HASH>
 local-user <BREAK_GLASS_ADMIN> privilege level 15
 local-user <BREAK_GLASS_ADMIN> service-type terminal ssh

The local keyword in every scheme above is worthless without a local account to fall back to. Give it the branch’s full-administrator level: 15 on V200, 3 on V600.

Both columns were verified against Taranac on the hardware listed above. On V600, 3 is not merely the level the administrator happens to receive — it is the maximum the branch has, which is why a profile written for V200 cannot simply be pointed at a V600 switch.

The practical consequence is that one shell profile cannot serve both branches — a profile returning priv-lvl = 15 to a V600 device asks for a level that does not exist there. Use separate profiles, and separate the devices so a policy rule can tell them apart: either a device group per branch, or distinct rules matching on device. See AAA policy.

This is a good use for device groups generally. Grouping by platform branch means the privilege model is decided once, at the group, rather than remembered per device.

Tested on the V600 switch above with a 5-second response timeout, by blocking TCP/49 from the switch to Taranac while sessions were open. Command authorization fails closed:

The denial looks like an ordinary syntax complaint, which is worth recognising before you go hunting for a typo:

Error: Do not have permission to run the command or the command is incomplete.

Two things follow. The break-glass account still works during an outage, but every command in that session stalls for the full timeout first — the switch asks the dead server before falling back, each time. And the fallback only ever fires on silence: a reject that Taranac actually returned is final, on authorization exactly as on authentication. That is not Huawei-specific — the same caveat holds on Cisco IOS-XE and Arista EOS, and it is a property of how TACACS+ method lists work rather than a per-vendor quirk.

display version
display current-configuration configuration aaa
display current-configuration configuration user-interface
display current-configuration | include hwtacacs

For the server side of it — whether the switch believes Taranac is actually there — ask the template by name:

display hwtacacs-server template name TARANAC-TACACS

Primary-authentication-server : 10.0.0.20:49 Status:UP
Primary-authorization-server  : 10.0.0.20:49 Status:UP
Primary-accounting-server     : 10.0.0.20:49 Status:UP
Current-authentication-server : 10.0.0.20:49 Status:UP
Current-authorization-server  : 10.0.0.20:49 Status:UP
Current-accounting-server     : 10.0.0.20:49 Status:UP
Source-Vlanif                 : 1
Response-timeout-Interval(sec): 5

Three things are worth reading here rather than skimming. All three functions must be listed and UP — a missing line is the omitted hwtacacs-server statement from step 1, not a network problem. Source-Vlanif must be the interface whose address is registered for this device in Taranac. And Response-timeout-Interval is the timer discussed above: 5 here means push MFA cannot work, and it is also the delay you will sit through on every command during an outage.

For long output, disable paging for the session only:

screen-length 0 temporary

The temporary keyword matters — it reverts on logout instead of persisting into the saved configuration.

As with any platform, a successful login proves authentication and nothing more. To prove the rest: log in from a second session and run a command your policy should deny — a denial arriving from Taranac is the only real evidence that command authorization is live. Then check that the command appears in Taranac’s accounting, which is what confirms the recording scheme took effect.

The configuration above was contributed and verified on hardware by one operator. What follows is a different kind of knowledge, and it is labelled as such: it is what Taranac puts on the wire for a Huawei switch — read out of the product’s own code — plus two field incidents on customers’ VRP hardware that changed the product. The switch-side dot1x configuration is taught end to end in Build an 802.1X lab and is not repeated here.

Huawei is the vendor this part of Taranac has changed most for. If you run 802.1X against VRP on a release older than 1.2.8, read the CoA section first — that one is taking VLANs away from live users while you read the rest.

Huawei uses two incompatible VSA numbering schemes: one for carrier equipment (BRAS), one for campus switches. FreeRADIUS ships a dictionary for each — dictionary.huawei and dictionary.huawei.v2, whose own header names the campus families (S1720, S2700, S5700, S6720) — and it includes the carrier one by default. Until 1.2.6 Taranac’s 802.1X service inherited that default and read campus switches with the carrier list.

The two lists disagree about the type of eleven attribute numbers, and on this path a type mismatch is fatal rather than cosmetic. FreeRADIUS converts every attribute of a request into a Python object before any Taranac code is reached, so an attribute the dictionary calls a string but the switch filled with binary raises a decode error inside C and fails the entire request. No handler code can catch it; only the dictionary in the daemon image can fix it.

That is exactly what happened on an S5735 running VRP V200R021. With IPv6 enabled on the client the switch sends attribute 253 — sixteen raw bytes of a link-local address. The campus list calls 253 Huawei-Framed-IPv6-Address (ipv6addr); the carrier list calls it Huawei-Web-URL (string). Every EAP-TLS authentication on that switch was rejected before a single rule of the operator’s was consulted. Attribute 153 is one byte away from the same fate: Huawei-Access-Type (integer) on the campus list, Huawei-User-Mac (string) on the carrier one.

Since 1.2.6 the 802.1X service reads campus switches with the campus list. Nothing Taranac itself sends or reads moved: Huawei-Exec-Privilege (29, integer — the vendor auto-detection hint) and Huawei-Data-Filter (82, string — downloadable ACLs) are spelled and typed identically in both files.

Device administration over RADIUS is deliberately still on the carrier list. 802.1X is the path a campus switch takes, and changing both at once would have widened the blast radius of a fix that needed to ship. HWTACACS — everything earlier on this page — is a different protocol and is not affected by any of this. If you see the same symptom on device administration from a Huawei campus switch, tell us.

Taranac’s Huawei dictionary entry rendered downloadable ACLs into an attribute called HW-Data-Filter. No such name exists in either Huawei dictionary — the attribute is Huawei-Data-Filter (82, string), spelled the same in both — so a Huawei dACL could never have reached a switch. It was a typo in the shipped seed data, and it silently produced a reply with no ACL in it.

Correcting the seed is not enough to fix an existing install: the vendor-dictionary seed inserts only keys that are missing, so that your edits survive a restart, which means every installation that had ever booted kept the broken name in its own row forever. Migration 0023 therefore rewrites the stored row on upgrade — but only where the value is still the one Taranac shipped. If you had already replaced that mapping with something of your own, your value stands and the migration leaves it alone.

Vendor ID 2011, auto-detected when a request carries Huawei-Exec-Privilege. That hint only fires if the switch actually sends the attribute, so the deterministic way is to pin the device to the Huawei VRP dictionary entry on its record — an explicit pin wins over detection, and detection wins over the free-text vendor field.

URL redirect is declared by exactly one entry in the whole shipped dictionary, Cisco IOS / IOS-XE. On VRP, 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. Huawei is not one of them. The full matrix is on NAC policy.

Before 1.2.8, Taranac’s stale-session worker asked the NAS whether a silent session still existed — first with a Disconnect-Request, which disconnected the very users it was checking, and then with an identification-only CoA-Request, on the theory that a CoA carrying no changing attribute is a question.

On VRP it is not a question. Measured on a customer’s CloudEngine S5735-L-V2 running V600R025C00SPC500, with RADIUS debugging on the switch and captures at both ends: an identification-only CoA-Request sent to a session that is definitely alive is answered CoA-ACK in 30–90 ms, and the RADIUS-assigned VLAN is removed from that session. The user stays authenticated and drops to the port PVID. The same CoA-Request carrying the VLAN attributes leaves the session untouched.

RFC 5176 defines no read-only packet. A CoA-Request carries the session’s authorization, and a NAS with replace semantics applies an empty one literally — so the probe changed the state it was meant to observe, on exactly the users who were still online.

Liveness now comes from the accounting stream, read in two windows — see Sessions. One of those windows has a VRP consequence worth knowing: a session for which only the Accounting-Start ever arrived cannot be judged by silence at all, so it is held by age alone (Max Session Duration, 120 hours by default). Taranac’s own note on this path records VRP as sending a single interim update when it learns the client’s IP and then nothing further, which puts an ordinary healthy VRP session in exactly that category. Configure periodic (real-time) interim accounting in the accounting scheme if you want the shorter, more accurate window to apply.

A VRP switch configured with radius-server nas-port-id-format new does not send a port name in NAS-Port-Id; it sends a structured description:

slot=0;subslot=0;port=18;vlanid=121;interfaceName=GigabitEthernet0/0/18

That is 71 characters, into a column that held 64. The insert failed with SQLSTATE 22001, the batch writer retried it unchanged, it failed again — and every authentication that followed queued behind a record that could never land, until the queue filled and began discarding real entries. Authentication itself kept working the whole time, because the log is written after the fact: a Huawei fleet got on the network normally while the operator watched a journal that had simply gone quiet. Device administration over RADIUS had the identical flaw waiting in it.

1.2.6 fixed it in three parts. The column now holds the 253 bytes the RADIUS attribute itself cannot exceed, so no vendor can repeat this; a record that genuinely cannot be written is dropped on its own, loudly, instead of taking every record behind it down; and both Huawei encodings — this one and the 16-digit nas-port-id-format old form — are decoded to a readable interface name, with the raw value kept beside it. The decoding table is on 802.1X authentication.

Entries lost while the log was blocked never reached the database and cannot be recovered.

Named explicitly, because a gap presented as a gap is useful and a gap presented as working is a trap:

• Push MFA on VRP. The response-timeout requirement is understood and the timer is documented above, but no VRP switch has yet completed a push-approved login end to end. Expect the timer to be necessary; do not assume 30 seconds is sufficient until someone has confirmed it.
• Privilege escalation. Taranac’s Huawei VRP template declares enable support, but the super path was not tested on either branch. On V200 the administrator arrives at level 15 already, which makes escalation moot in practice — that is why it went untested, not evidence that it works.
• The switch-side 802.1X configuration. What Taranac sends a VRP switch is documented above and grounded in the product’s code and in two field incidents on customers’ hardware; the matching dot1x configuration has not been written up from a VRP switch in our own lab, as the Cisco one in Build an 802.1X lab has.
• Downloadable ACLs on VRP. The attribute name was wrong until 1.2.6, so a Huawei dACL could never have reached a switch and nobody has exercised one. The name is right now; what syntax VRP accepts inside Huawei-Data-Filter, and whether it wants a sequence number the way Cisco does, is still unconfirmed.

If you run VRP and can close any of these, we would like to hear from you.

• Device configuration — conventions and the rest of the cookbook
• Cisco IOS / IOS-XE — the same ground on another platform
• Network devices — registering the device and its secret
• TACACS+ — profiles, command sets, privilege levels
• AAA policy — the rules that decide what a login gets
• NAC overview — how a session’s liveness is judged
• NAC policy — the full per-vendor CoA matrix
• Troubleshooting — the symptom index