highlights and lowlights of the daily business of network engineers

If you come from the Cisco world, Huawei WLAN HA can look a little unfamiliar at first. The good news: once you stop trying to force a “dedicated HA cable for everything” mindset onto it, the design gets a lot cleaner.

This post walks through a practical AirEngine 9700-M1 active/standby design using VRRP and HSB, how AP join works with a shared CAPWAP IP, how licensing behaves on the standby node, and why a dedicated HA link often adds more complexity than value.

All IPs, usernames, serials, MAC addresses, and identifiers below are sanitized and rewritten.

The basic idea

The clean Huawei pattern looks like this:

1. two controllers with their own real IPs on the CAPWAP VLAN
2. one shared VRRP VIP for AP join and CAPWAP traffic
3. one shared VRRP VIP for management access
4. HSB syncing AP, DHCP, and access-user state between the nodes
5. wireless config sync tied to the active controller role

Think of it like this:

• VRRP gives you the floating identity
• HSB gives you the stateful failover logic
• capwap source ip-address makes APs talk to one logical controller endpoint

If you know Cisco 9800, the mental model is roughly:

• VRRP VIP = the stable logical endpoint your APs and admins care about
• HSB = the state replication / active-standby glue
• wireless config sync = the “don’t let the standby drift away” mechanism

Example topology

Here is a sanitized version of the design:

Controller A (active)
  CAPWAP VLAN: 198.51.100.20/28
  CAPWAP VIP : 198.51.100.19
  MGMT VLAN  : 203.0.113.36/28
  MGMT VIP   : 203.0.113.35

Controller B (standby)
  CAPWAP VLAN: 198.51.100.21/28
  CAPWAP VIP : 198.51.100.19
  MGMT VLAN  : 203.0.113.37/28
  MGMT VIP   : 203.0.113.35

AP network route:
  198.51.110.0/23 via 198.51.100.17

flowchart LR
    APs[APs in routed networks]
    GW[Gateway 198.51.100.17]
    VIP[CAPWAP VIP 198.51.100.19]
    MGMTVIP[MGMT VIP 203.0.113.35]
    A[Controller A
198.51.100.20
203.0.113.36
Active]
    B[Controller B
198.51.100.21
203.0.113.37
Standby]

    APs --> GW
    GW --> VIP
    VIP --> A
    VIP --> B
    MGMTVIP --> A
    MGMTVIP --> B

From an AP point of view, the important address is not the real IP of either controller. It is the shared CAPWAP VIP.

That is the first big mindset shift.

VRRP: the floating identity

On Huawei, I like to separate the logical roles clearly:

• one VRRP group for management
• one VRRP group for CAPWAP

Sanitized example:

interface Vlanif200
 description CAPWAP
 ip address 198.51.100.20 255.255.255.240
 vrrp vrid 39 virtual-ip 198.51.100.19
 vrrp vrid 39 priority 150
 vrrp vrid 39 preempt-mode timer delay 60
 vrrp vrid 39 authentication-mode simple plain 
<redacted>

interface Vlanif201
 description MGMT
 ip address 203.0.113.36 255.255.255.240
 vrrp vrid 38 virtual-ip 203.0.113.35
 vrrp vrid 38 priority 150
 vrrp vrid 38 preempt-mode timer delay 60
 vrrp vrid 38 authentication-mode simple plain </redacted>
<redacted>
 management-interface

On the standby controller, you use the same VIPs and vrids, but lower priorities.

If you are coming from Cisco:

• this is conceptually close to HSRP or VRRP on two SVIs
• one node owns the VIP, the other waits

The important part is not just “VIP exists.” It is “VIP exists in the right place.”

For Huawei WLAN HA, that means:

• APs should use the CAPWAP VIP
• admins and management services should use the management VIP

HSB: the stateful part

VRRP alone gives you floating IPs. It does not, by itself, give you stateful WLAN failover.

That is where HSB comes in.

Sanitized example:

hsb-service 0
 service-ip-port local-ip 198.51.100.20 peer-ip 198.51.100.21 local-data-port 10241 peer-data-port 10241
 service-keep-alive detect retransmit 3 interval 6

hsb-group 0
 track vrrp vrid 39 interface Vlanif200
 bind-service 0
 hsb enable

hsb-service-type access-user hsb-group 0
hsb-service-type dhcp hsb-group 0
hsb-service-type ap hsb-group 0

This is the part many people miss.

The CAPWAP VIP is the face of the cluster. The hsb-service between the real CAPWAP-side IPs is how the two controllers exchange state.

That means:

1. local-ip and peer-ip are the real node addresses
2. track vrrp ties the HSB group to the active CAPWAP role
3. hsb-service-type ap is what makes AP state replication relevant

In short:

• VRRP says who is active
• HSB helps the active and standby behave like a coordinated pair

flowchart TD
    V39[VRRP 39 on CAPWAP VLAN]
    VIP39[CAPWAP VIP]
    HSB[HSB service]
    APSTATE[AP state]
    DHCPSTATE[DHCP state]
    USERSTATE[Access-user state]

    V39 --> VIP39
    V39 --> HSB
    HSB --> APSTATE
    HSB --> DHCPSTATE
    HSB --> USERSTATE

HSB is not config sync

This is one of the easiest mistakes to make when you first touch Huawei WLAN HA.

You see HSB, you see a healthy active/standby pair, and your brain wants to assume:

“Cool, so the whole config must be synced too.”

Not quite.

Huawei splits this into two different planes:

1. HSB for runtime state
2. wireless configuration synchronization for WLAN config objects

That split is actually pretty sensible once you get used to it.

What HSB syncs

The HSB part is about operational state, not about every line of config on the box.

In this style of design, the interesting bits are usually:

• AP state
• DHCP state
• access-user state

Sanitized example:

hsb-service 0
 service-ip-port local-ip 198.51.100.20 peer-ip 198.51.100.21 local-data-port 10241 peer-data-port 10241
 service-keep-alive detect retransmit 3 interval 6

hsb-group 0
 track vrrp vrid 39 interface Vlanif200
 bind-service 0
 hsb enable

hsb-service-type access-user hsb-group 0
hsb-service-type dhcp hsb-group 0
hsb-service-type ap hsb-group 0

That gives you the runtime glue between the two controllers.

What wireless config sync does

Wireless config sync is the part that keeps the WLAN object model aligned.

That is the stuff like:

• SSID profiles
• security profiles
• VAP profiles
• AP groups
• radio / RRM profiles
• other WLAN-facing objects

Sanitized example on Controller A:

wlan
 master controller
  master-redundancy track-vrrp vrid 39 interface Vlanif200
  master-redundancy peer-ip ip-address 198.51.100.21 local-ip ip-address 198.51.100.20 psk </redacted>
<redacted>

And on Controller B:

wlan
 master controller
  master-redundancy track-vrrp vrid 39 interface Vlanif200
  master-redundancy peer-ip ip-address 198.51.100.20 local-ip ip-address 198.51.100.21 psk </redacted>
<redacted>

That is the config-level relationship between the two nodes.

If you want to trigger or schedule actual synchronization, that is a separate step again, for example with manual or scheduled synchronization commands depending on how you operate the pair.

Putting both together

If you want the simple version:

• HSB keeps the standby operationally aware
• master-redundancy keeps the WLAN config model aligned

Same subnet, same HA design, different jobs.

This is the sanitized side-by-side picture.

Controller A:

interface Vlanif200
 ip address 198.51.100.20 255.255.255.240
 vrrp vrid 39 virtual-ip 198.51.100.19
 vrrp vrid 39 priority 150

hsb-service 0
 service-ip-port local-ip 198.51.100.20 peer-ip 198.51.100.21 local-data-port 10241 peer-data-port 10241
 service-keep-alive detect retransmit 3 interval 6

hsb-group 0
 track vrrp vrid 39 interface Vlanif200
 bind-service 0
 hsb enable

hsb-service-type access-user hsb-group 0
hsb-service-type dhcp hsb-group 0
hsb-service-type ap hsb-group 0

wlan
 master controller
  master-redundancy track-vrrp vrid 39 interface Vlanif200
  master-redundancy peer-ip ip-address 198.51.100.21 local-ip ip-address 198.51.100.20 psk </redacted>
<redacted>

Controller B:

interface Vlanif200
 ip address 198.51.100.21 255.255.255.240
 vrrp vrid 39 virtual-ip 198.51.100.19
 vrrp vrid 39 priority 50

hsb-service 0
 service-ip-port local-ip 198.51.100.21 peer-ip 198.51.100.20 local-data-port 10241 peer-data-port 10241
 service-keep-alive detect retransmit 3 interval 6

hsb-group 0
 track vrrp vrid 39 interface Vlanif200
 bind-service 0
 hsb enable

hsb-service-type access-user hsb-group 0
hsb-service-type dhcp hsb-group 0
hsb-service-type ap hsb-group 0

wlan
 master controller
  master-redundancy track-vrrp vrid 39 interface Vlanif200
  master-redundancy peer-ip ip-address 198.51.100.20 local-ip ip-address 198.51.100.21 psk </redacted>
<redacted>

That is why I like to think of Huawei HA in layers:

1. VRRP decides who owns the service identity
2. HSB synchronizes runtime state
3. master-redundancy synchronizes WLAN config logic

flowchart LR
    VRRP[VRRP role ownership]
    HSB[HSB runtime sync]
    WLANSYNC[Wireless config sync]
    APJOIN[AP join continuity]
    CFG[SSID / VAP / AP group consistency]

    VRRP --> HSB
    VRRP --> WLANSYNC
    HSB --> APJOIN
    WLANSYNC --> CFG

What usually gets synced, and what stays local

In practice, this is the operational rule of thumb I use.

Usually synced or intentionally aligned in the wireless plane:

• SSID profiles
• security profiles
• VAP profiles
• AP groups
• radio / RRM / regulatory-domain profiles
• AP-related WLAN object definitions

Usually runtime-synced through HSB:

• AP runtime state
• DHCP runtime state
• access-user runtime state

Usually still box-local or node-specific:

• hostname
• local interface IP addresses
• VRRP priorities
• HSB local-ip and peer-ip
• master-redundancy local-ip and peer-ip
• management source settings
• local files, images, web packages
• license file activation location

That last point matters a lot.

Even in a healthy HA pair, you should not assume every box-local item becomes magically identical just because HSB is healthy.

Cisco analogy

If you want a Cisco-flavored mental model:

• VRRP = floating endpoint ownership
• HSB = runtime failover/stateful behavior
• wireless config sync = the “keep the policy model aligned” layer

That is why I would not describe Huawei HSB as “the config sync feature.”

It is only one part of the bigger HA story.

CAPWAP source IP: the part that makes AP join elegant

This line is one of the most important ones in the whole design:

capwap source ip-address 198.51.100.19

That tells the controller to use the shared CAPWAP VIP as its source identity for AP-facing CAPWAP communication.

Why this matters:

1. APs learn one logical controller endpoint
2. failover becomes cleaner, because the CAPWAP identity does not bounce between node-local addresses
3. DHCP Option 43, static AP config, and manual ac-list entries can all point to the same shared IP

Again, Cisco analogy:

If you are used to thinking in terms of “what is the controller address the AP should trust and join to,” the Huawei answer here is: the CAPWAP VIP.

Not the node IP.

AP join flow

A practical AP join flow looks like this:

1. AP gets an IP address
2. AP learns the controller endpoint through DHCP Option 43, static config, or a configured AC list
3. AP targets the shared CAPWAP VIP
4. the active controller answers using that shared logical identity
5. HSB keeps the standby aware enough to support failover behavior

sequenceDiagram
    participant AP as AP
    participant DHCP as DHCP Server
    participant VIP as CAPWAP VIP
    participant ACT as Active Controller
    participant STBY as Standby Controller

    AP->>DHCP: Request address and controller discovery
    DHCP-->>AP: IP config + Option 43 / controller hint
    AP->>VIP: CAPWAP discovery / join
    VIP->>ACT: Active node owns VIP
    ACT-->>AP: Join response
    ACT->>STBY: Replicate runtime state via HSB

Example AP-side logic on the controller:

wlan
 ap-type AirEngine57xx type-id 192
 ap-type AirEngine87xx type-id 247
 temporary-management psk </redacted>
<redacted>
 ap username ap-admin password cipher </redacted>
<redacted>

 ap-id 0 type-id 247 ap-mac aaaa-bbbb-cccc ap-sn SN-EXAMPLE-0001
  ap-name lab-ap-01
  ap-group LAB-APG
  address-mode dhcp
  ac-list 198.51.100.19

Two useful reminders here:

1. newer AP models may need explicit ap-type entries if the software train does not know them yet
2. the type-id must match the AP model exactly

DHCP Option 43: point to the VIP, not the box

For Windows DHCP, the Huawei-style Option 43 payload is usually easiest to think about in its raw form:

030D3139382E35312E3130302E3139

Sanitized breakdown:

03    = Huawei AC/WLC sub-option
0D    = ASCII length
3139382E35312E3130302E3139 = ASCII hex for 198.51.100.19

The real lesson is simple:

Use the shared CAPWAP VIP, not the real IP of Controller A or Controller B.

That gives APs one stable destination.

Licensing in active/standby mode

This is another area where people tend to overcomplicate things.

In an active/standby Huawei setup, the normal pattern is:

1. the active node has the activated AP license file
2. the standby node shows the synchronized AP resource state
3. the standby does not need to look like a separately operated standalone controller with a fully independent licensing story

In practice, you validate the behavior, not just the file placement:

display license resource usage

What you want to see is not just “a file exists somewhere.”

What you want to see is:

• AP capacity is visible in the cluster context
• standby reflects the expected resource availability

flowchart LR
    LIC[License activated on active node]
    RES[Cluster resource visibility]
    STBY[Standby sees AP capacity]

    LIC --> RES --> STBY

If you come from Cisco, think less “two independent boxes with completely separate licensing expectations” and more “one HA pair with an active owner and synchronized standby state.”

Why a dedicated HA link usually does not help here

This is the part that seems to surprise a lot of people.

On paper, a dedicated HA link sounds nice. In practice, for this Huawei design, it often does not buy you much.

Why?

1. The real HA path already lives where the WLAN role lives

The important logical path is the CAPWAP-side network where:

• the real node IPs live
• the CAPWAP VIP lives
• VRRP role is decided
• HSB service is bound

So if your active/standby logic already depends on that segment, adding another “special HA cable” does not magically improve AP failover.

2. APs do not care about your private HA cable

APs care about the shared CAPWAP endpoint.

They do not benefit from a second, private controller-to-controller link if the actual CAPWAP design already has clean L2/L3 adjacency and the HSB service is stable.

3. It adds moving parts

A dedicated HA link means more things to document, monitor, and troubleshoot:

• another VLAN or subnet
• another set of interface assumptions
• another failure domain
• more chances for config drift

In other words: more wiring, more exceptions, more edge cases.

4. It can distract from the real path that matters

The failure domain that matters most is usually not “can the controllers see each other on a special side link?”

It is:

• can the active controller still serve APs through the CAPWAP-side design?
• is the shared VIP still owned by the correct node?
• is the HSB state still healthy over the actual service-facing network?

When a dedicated HA link can still make sense

There are edge cases where you might want one:

1. the two controllers cannot share the relevant L2 design for the CAPWAP-side HA model
2. security or operational policy requires strict separation
3. you are forced into a different HA model by design constraints

But in a normal same-segment VRRP HSB deployment, I would keep it simple.

The key command relationships

If you want the short version of “what depends on what,” here it is.

Underlay chain

VLAN -> Trunk -> Vlanif -> Route -> VIP reachability

flowchart LR
    VLAN[VLAN]
    TRUNK[Trunk / Port-channel]
    VLANIF[Vlanif]
    ROUTE[Routing]
    VIPR[VIP reachability]

    VLAN --> TRUNK --> VLANIF --> ROUTE --> VIPR

HA chain

Vlanif CAPWAP -> VRRP 39 -> HSB service -> HSB group -> AP / DHCP / access-user sync

flowchart LR
    VC[Vlanif CAPWAP]
    VR[VRRP 39]
    HS[HSB service]
    HG[HSB group]
    RT[Runtime sync]

    VC --> VR --> HS --> HG --> RT

AP onboarding chain

DHCP Option 43 / ac-list -> CAPWAP VIP -> capwap source ip-address -> AP join

flowchart LR
    DISC[Option 43 / ac-list]
    VIPJ[CAPWAP VIP]
    SRC[capwap source ip-address]
    JOIN[AP join]

    DISC --> VIPJ --> SRC --> JOIN

Licensing chain

active controller license -> cluster resource visibility -> standby capacity reflection

flowchart LR
    AL[Active license]
    CR[Cluster resources]
    SC[Standby capacity view]

    AL --> CR --> SC

If one part of the chain is wrong, the whole story gets weird fast.

Final thoughts

The nicest Huawei 9700-M1 HA designs are usually the boring ones.

Use:

1. a clean CAPWAP VLAN with real node IPs
2. a shared CAPWAP VIP for APs
3. a shared management VIP for admins
4. HSB over the same service-relevant path
5. the active node to own the license and the standby to reflect synchronized capacity

And unless you have a very specific reason not to, skip the dedicated HA link.

In this design, simple is not a compromise. Simple is the point.