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 connection is refused as coming from an address outside the inventory: the switch sees a failed server, and Taranac logs a Not in the inventory row from the unexpected address in the Authentication Log and raises the Unknown TACACS+ device alert. 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 50 seconds — so the default gives up first and falls through to local before the approval can arrive. Whichever of the two is shorter decides: at 30 the switch does, and raising it up to 50 gives the admin more time; beyond 50 Taranac’s own cap 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 what was measured on customers’ VRP hardware. The switch-side dot1x configuration is taught end to end in Build an 802.1X lab and is not repeated here.

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. Taranac’s 802.1X service does not keep that default: it reads campus switches with the campus 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 measured, not theoretical. 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). Read with the carrier list, every EAP-TLS authentication on that switch is rejected before a single rule of the operator’s is 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.

Nothing Taranac itself sends or reads depends on the choice: 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 stays on the carrier list. 802.1X is the path a campus switch takes. 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 renders downloadable ACLs into Huawei-Data-Filter (82, string), spelled the same in both Huawei dictionaries. A name that exists in neither — HW-Data-Filter, for one — would silently produce a reply with no ACL in it, so if you edit the entry’s dACL mapping, keep that exact name.

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.

Taranac never asks a NAS whether a silent session still exists, and nothing in Taranac closes a session on the strength of a NAS’s answer. A Disconnect-Request would disconnect the very user being checked, and the obvious alternative — an identification-only CoA-Request, on the theory that a CoA carrying no changing attribute is a question — is destructive on VRP. The device card’s CoA test is refused for Huawei too, for a different reason: VRP does not answer at all for a session it does not know, so silence would read as a fault on a correctly configured switch.

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 such a probe changes the state it is meant to observe, on exactly the users who are still online. The symptom, if anything on your network sends such CoAs, is users who authenticate correctly, work for a while, and then quietly lose their assigned VLAN without ever being disconnected.

Liveness 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

Taranac stores NAS-Port-Id up to the 253 bytes the RADIUS attribute itself cannot exceed, so no vendor encoding overflows it. 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.

Logging is written after the fact, so it can never hold up authentication. A log record that genuinely cannot be written is dropped on its own, loudly, rather than blocking the records queued behind it.

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 measurements 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. No Huawei dACL has been exercised on a switch. 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