TTechclick All lessons
HPE Aruba Networking · Fabric · NetConductorInteractive · L2 / L3

Aruba Central NetConductor — One Fabric, Every Role, Zero Trust at the Edge

Underlay. Overlay. Group Based Policy. Cloud Auth. Skip the 60-page design guide — pick a fabric layer below, watch a packet ride the EVPN-VXLAN overlay carrying its role tag live, ask the in-page AI tutor anything, and you're done in 11 minutes.

📅 2026-05-31 · ⏱ 11 min · 3 animated fabric demos · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Aruba Central NetConductor explained the AI-era way — pick a fabric layer, watch a packet ride the EVPN-VXLAN overlay with its GPID role tag live, see Cloud Auth assign a role, and master underlay/overlay/policy in 11 minutes instead of an afternoon.

By the end you will be able to

Pick a fabric layer — jump straight to it

1

Underlay

The OSPF + loopback plumbing every overlay rides on. Get this wrong and nothing else works.

 2

Overlay (EVPN-VXLAN)

iBGP route reflectors + VXLAN tunnels — how any subnet appears anywhere in the fabric.

 3

Policy + Cloud Auth

Roles, GPID, VXLAN-GBP and how Cloud Auth assigns a role from Azure AD / Google.

 4

Troubleshoot

"Fabric pushed but clients can't talk" → 4-step playbook + the CVE you must patch.

The wrong way most people picture a fabric

Ask a fresh L1 "what is NetConductor?" and you usually hear: "It's just Aruba's version of VLANs in the cloud." That answer fails the first real ticket. NetConductor is not "VLANs as a service". It builds a routed fabric where every switch is a tunnel endpoint, and a user's identity — not their cable or VLAN — decides what they can reach.

ELI5: Picture a huge airport. The runways and taxiways are the underlay — the physical roads. The flights are the overlay — they ride those roads but only the control tower (BGP) knows every route. And your boarding pass (your role) decides which gates you may enter, no matter which runway you landed on. NetConductor is the system that paints the runways, runs the tower, and prints the boarding passes — all from one cloud dashboard.

Practitioner: A NetConductor fabric is an EVPN-VXLAN fabric of AOS-CX switches, orchestrated by three Aruba Central wizards: the underlay wizard (point-to-point routed links over OSPF), the fabric wizard (iBGP EVPN + VXLAN tunnels with route reflectors), and fabric segments (VLAN→VNI→VRF stitching). Policy is global: define roles once, push everywhere.

Architect: NetConductor decouples the transport (a stable, loop-free IP underlay) from services (L2/L3 overlays signalled by BGP EVPN), and decouples policy from topology by carrying a GPID in the VXLAN-GBP header. The design goal is identity-driven micro-segmentation that survives moves, adds and changes without re-IPing or re-cabling.

One sentence to memorise: "Underlay carries packets, overlay carries services, policy travels inside the packet." The whole rest of this lesson is that sentence, unpacked and made clickable.

Aruba Central in the cloud pushes config down to a spine-leaf fabric of AOS-CX switches. The underlay is OSPF, the overlay is iBGP EVPN-VXLAN with route reflectors, and clients onboard through Cloud Auth which assigns a role. HPE Aruba Central NetConductor wizards · Cloud Auth · Client Insights HTTPS 443 (config push) Spine / Route Reflector Spine / Route Reflector Edge VTEP A Edge VTEP B Border VTEP VXLAN overlay tunnel (VNI + GPID role tag) 👩 Sneha · role=Employee 📷 IP camera · role=IoT 🌐 Internet / WAN border Underlay (OSPF, physical) Overlay (EVPN-VXLAN tunnel) AOS-CX VTEP
Figure 1 — One control plane (Aruba Central), two data planes (grey underlay, lime overlay), and identity riding inside the tunnel.
Underlay / physical path Overlay / VXLAN tunnel AOS-CX switch (VTEP) Translated / role-tagged field
Warm-up · Q1 of 10 · Remember

In a NetConductor fabric, which protocol does the underlay wizard use to make the physical switch-to-switch links routed and loop-free?

Correct: b. The NetConductor underlay wizard configures point-to-point routed links and uses OSPF as the IGP, with loopback0 for OSPF router-id and loopback1 reserved for the VXLAN VTEP source. STP is exactly what a routed fabric eliminates; the overlay (not the underlay) uses BGP.
Warm-up · Q2 of 10 · Apply

Sneha authenticates via Cloud Auth and is assigned role=Employee. As her packet leaves the edge switch into the overlay, where does that role live?

Correct: c. The role maps to a Group Policy ID (GPID) which is carried inside the VXLAN-GBP header. The ingress VTEP stamps it; the egress VTEP reads it and enforces the role-to-role policy. VLAN tags and RADIUS are how the role is derived at the edge, not how it travels across the fabric.
Warm-up · Q3 of 10 · Apply

Within a single NetConductor fabric, how does the fabric wizard keep BGP peerings manageable across dozens of edge switches?

Correct: b. The wizard configures iBGP EVPN on all switches and uses route reflectors (typically the spine/core) so each edge peers only to the RR instead of every other edge — the same scaling trick that keeps a full-mesh VXLAN-EVPN fabric sane. Full-mesh iBGP would explode the peering count.

Four foundations — tap to flip

🛣️
Underlay
tap to flip

The physical routed network — OSPF over point-to-point links, loopback0 for router-id, loopback1 as the VXLAN source. Stable and dumb on purpose.

🧬
Overlay
tap to flip

VXLAN tunnels between VTEPs, with BGP EVPN as the control plane advertising MAC/IP reachability. Any subnet appears anywhere.

🎫
Role / GPID
tap to flip

A client's identity becomes a role, mapped to a numeric GPID carried in the VXLAN-GBP header — so policy follows the user, not the port.

☁️
Cloud Auth
tap to flip

Cloud-native NAC inside Central. Ties into Azure AD / Google Workspace for 802.1X users and MAC-auth + Client Insights for IoT — no on-prem RADIUS box needed.

① Underlay — the boring layer that breaks everything

R

Rahul at TCS ran the fabric wizard on day one, skipped re-checking the underlay, and spent the afternoon staring at "EVPN peer down". The cause? Two leaf loopbacks had overlapping IPs. The overlay can never come up if the underlay can't route loopback-to-loopback.

The underlay's only job: let every switch reach every other switch's loopback1 address. NetConductor's underlay wizard configures point-to-point routed links, brings up OSPF, and reserves loopbacks. In a campus you might have a 10.255.x.x underlay; the fabric VTEP source is loopback1.

AOS-CX — verify the underlay before you blame the overlay 
switch# show ip ospf neighbors
switch# show ip route 10.255.1.2     # remote leaf loopback1
switch# ping 10.255.1.2 source loopback1
Expected output 
Neighbor ID     Pri  State       Dead Time  Address      Interface
10.255.0.11       1  FULL/ -     00:00:34   10.0.12.1    1/1/49
10.255.0.12       1  FULL/ -     00:00:31   10.0.13.1    1/1/50

10.255.1.2/32  via 10.0.12.1, [110/200], ospf
PING 10.255.1.2: 5 packets, 0% loss, rtt min/avg/max 0.4/0.6/0.9 ms

If OSPF neighbors are not FULL and loopback1 is not reachable, stop. Do not touch BGP. The fabric wizard pre-checks the underlay and emits detailed errors if requirements aren't met — read them, don't skip them.

Pause & Predict

You can ping a remote leaf's interface IP but NOT its loopback1. Will the EVPN overlay come up?

No. VTEPs source VXLAN traffic and form BGP EVPN sessions from loopback1. If loopback1 isn't advertised into OSPF (or is unreachable), the tunnel source is dead even though physical links are fine. Fix: confirm loopback1 is in the OSPF process and redistributed/advertised. This is the single most common "fabric pushed but won't form" cause.

② Overlay — EVPN-VXLAN, where subnets become portable

Now the magic. Each AOS-CX switch is a VTEP. The fabric wizard builds BGP EVPN as the control plane so VTEPs learn which MAC/IP lives behind which remote VTEP — no more flood-and-learn across the whole campus. A VLAN maps to an L2VNI; a VRF maps to an L3VNI.

Diagram of a VXLAN encapsulated frame showing the outer IP/UDP header sourced from loopback1, the VXLAN-GBP header containing VNI and GPID role tag, and the inner original Ethernet frame. What the wire actually carries: a VXLAN-GBP frame INNER (original client frame) Inner Eth: MAC src/dst Inner IP: 10.20.5.40 → 10.20.9.12 L4 + payload VXLAN-GBP HEADER Flags · reserved GPID = role (e.g. 1010) VNI = 5020 (segment) OUTER (underlay) Outer IP: lo1 → lo1 UDP dst 4789 Outer Eth + + Ingress VTEP stamps the GPID (role) + VNI. Egress VTEP reads GPID and enforces role-to-role policy, then strips the wrapper.
Figure 2 — Encapsulation, left to right: the underlay only routes the outer header; the role (GPID) and segment (VNI) ride in the middle; the client never knows.

▶ Watch a packet ride the overlay (with its role)

Click Play. Sneha's laptop talks to a server on a different leaf. Each stage lights up.

① CLIENT 10.20.5.40 (Sneha) → 10.20.9.12 (HR app)
Sneha is on Edge VTEP A; the HR app sits behind Edge VTEP B.
▼
② INGRESS VTEP Switch A maps Sneha's role=Employee → GPID 1010, picks VNI 5020
▼
③ ENCAP Frame wrapped in VXLAN-GBP (GPID 1010, VNI 5020), outer IP = lo1 A → lo1 B, UDP 4789
▼
④ UNDERLAY OSPF routes the outer packet hop-by-hop to loopback1 of VTEP B. Spines never see the inner data.
▼
⑤ POLICY (egress) VTEP B reads GPID 1010 → checks Employee→HR-App role policy → allow
▼
⑥ DECAP + DELIVER Wrapper stripped, original frame delivered to 10.20.9.12. Reply takes the mirror path.
Press Play to step through the overlay journey. Each Next advances one stage.
Remember the enforcement point

For role-to-role policy, enforcement happens at the destination egress VTEP (it needs to know both source GPID and destination role). For all other policies, enforcement is at the source ingress. Memorise: role-to-role = egress; everything else = ingress. This is a classic exam trap.

Quick check · Q4 of 10 · Apply

During encapsulation, which switch stamps the GPID role tag into the VXLAN-GBP header?

Correct: a. The ingress VTEP derives the client's role (via 802.1X / MAC-Auth / Client Insights) and stamps the matching GPID into the VXLAN-GBP header. Central distributes the role→GPID and policy definitions once; it does not touch live packets. Spines just route the outer header.
Pause & Predict

A new VLAN is added on Edge VTEP A only, but its matching L2VNI is never created on Edge VTEP B. Sneha (on A) can't reach a host in that VLAN behind B. Why?

Missing VLAN-to-L2VNI mapping on the remote VTEP. EVPN only advertises reachability for VNIs a VTEP actually has configured. If VTEP B has no L2VNI entry for that segment, it never imports the route, so the broadcast domain simply doesn't extend there. Aruba's own debug guide tells you to verify that non-directly-attached VLANs have proper L2VNI-VLAN entries. With NetConductor, you fix this by extending the fabric segment, not by hand-editing one switch.

③ Policy + Cloud Auth — identity becomes the firewall

Roles and policies are defined once, globally in Aruba Central and distributed to every fabric device. You don't write ACLs per switch. You say "Employees may reach the HR app; IoT cameras may reach only the NVR" — and NetConductor's policy manager translates that into the GPID rules each VTEP enforces.

P

Priya at HCL needed to stop IP cameras from talking to laptops. Old way: VLAN ACLs on 40 switches, drift within a month. NetConductor way: one role IoT-Camera, one role-to-role policy "IoT-Camera → Employee: deny", pushed fabric-wide. The GPID travels with every camera packet, so enforcement is consistent on any switch the camera plugs into.

Where does the role come from? Cloud Auth vs ClearPass

Cloud Auth lets clients connect to wired and wireless networks securely and automatically by integrating with your existing cloud identity store — Azure AD / Entra ID or Google Workspace — for 802.1X corporate users, and MAC-auth + Client Insights for the printers and cameras that can't do 802.1X.

A decision flowchart starting from whether identity lives in a cloud store, whether the device supports 802.1X, and compliance constraints, leading to Cloud Auth, Client Insights, or ClearPass. Picking the brain that assigns the role Client connects Identity in cloud (Azure AD / Google)? yes Device 802.1X-capable? yes → Cloud Auth (802.1X) no → MAC-Auth + Client Insights no / on-prem only Need deep posture, guest portal, air-gap → on-prem ClearPass All paths end the same way: client gets a role → role maps to GPID → policy follows the packet
Figure 3 — Cloud Auth covers the cloud-identity + IoT majority; ClearPass still wins for guest portals, deep posture, and air-gapped sites.

▶ Cloud Auth onboarding — from cable to role

A new employee laptop plugs into the fabric. Watch identity become a GPID.

① CONNECT Laptop connects to SSID/port → switch starts 802.1X
▼
② CLOUD AUTH Switch forwards credentials to Central Cloud Auth → checked against Azure AD
▼
③ ROLE Identity = "sneha@infosys" → policy maps to role = Employee
▼
④ GPID BIND Edge VTEP binds role → GPID 1010 for this client session
▼
⑤ ENFORCED Every packet now carries GPID 1010; any VTEP enforces Employee policy consistently
Identity is checked once at onboarding; the resulting role rides every packet afterward. Tap Play.
Quick check · Q5 of 10 · Analyze

A fleet of IP cameras can't do 802.1X. You want them auto-classified and put in an IoT role without manually tagging MACs. Which Cloud Auth feature does this?

Correct: c. Client Insights uses AI-based profiling to fingerprint non-802.1X devices and drive automated segmentation/enforcement, paired with MAC-Auth. Static VLANs are the old manual model NetConductor replaces; guest portals are for visitors; eBGP communities are unrelated transport.

④ Troubleshoot — "fabric pushed, clients can't talk"

The config committed green in Central. Clients still can't reach each other. Here's the 4-step ladder, top to bottom — fix the lowest broken layer first.

①
Underlay first
tap

show ip ospf neighbors + ping remote loopback1. No reachability = nothing above will work. Fix here before anything else.

②
EVPN peering
tap

show bgp l2vpn evpn summary. Edges should be Established to the route reflector. Down = RR/loopback issue.

③
VNI / VTEP
tap

show interface vxlan + verify L2VNI-VLAN entries exist on BOTH VTEPs. A missing remote VNI silently drops the segment.

④
Role / GBP
tap

Confirm the client got the expected role and the role-to-role policy isn't an implicit deny. Wrong role = correct transport, blocked traffic.

AOS-CX — is the EVPN overlay actually up? 
switch# show bgp l2vpn evpn summary
switch# show nae-script    # (optional) Central-pushed validation
Expected output 
Neighbor        AS       MsgRcvd  MsgSent  Up/Down    State
10.255.0.1      65001    14021    14033    2d04h      Established
10.255.0.2      65001    14002    14010    2d04h      Established

VRF : default   Local AS : 65001   RR-client : yes
Pause & Predict

OSPF is FULL, EVPN is Established, the VNI exists on both VTEPs — but two specific roles still can't talk. Which layer is broken?

Policy, not transport. When the underlay, overlay and VNI are all healthy, a role-pair that can't communicate points at the Group Based Policy: either the role-to-role rule is set to deny, or the client landed in the wrong role. Check the derived role first (often a Cloud Auth / Client Insights mismatch), then the role-to-role policy in Central. This is the single biggest source of "the network is up but the app is down" tickets in NetConductor.
Patch this before you ship: the CVE engineers ignore

AOS-CX has had critical advisories — most notably CVE-2026-23813 (CVSS 9.8), an unauthenticated admin-password-reset / auth-bypass affecting AOS-CX 10.17.0001 and below, 10.16.1020 and below, 10.13.1160 and below, and 10.10.1170 and below; plus a chain of command-injection issues (CVE-2026-23814/23815/23816). The CX 10000 series also had a firewall packet-forwarding flaw (CVE-2024-54010). A fabric is only as trustworthy as the switches running it — a hijacked VTEP can stamp any GPID it likes. Patch AOS-CX and restrict management access before you call a fabric "zero-trust".

Pro tips that save afternoons

1. Pre-stage and verify the routed underlay before running the fabric wizard — it pre-checks and will refuse with detailed errors. 2. Define roles + policies in Central before onboarding clients, so the first packet already has the right GPID. 3. For SD-WAN sites, use Multi-Fabric EVPN to carry VRF + role natively across fabrics — don't re-derive roles at each site. 4. Keep loopback IPs unique and in OSPF; 80% of "won't form" tickets die here.

Quick check · Q6 of 10 · Analyze

You need consistent Employee and IoT roles to apply across three campus fabrics joined by SD-WAN. Which NetConductor capability carries the VRF + role natively between fabrics?

Correct: d. Multi-Fabric EVPN provides end-to-end segmentation across an SD-WAN fabric by carrying the VRF and Role information natively in the data plane, so Group Based Policy stays consistent everywhere. Re-running wizards or per-site ACLs reintroduces exactly the drift NetConductor exists to remove.
A left-to-right five-step timeline of the order you build a NetConductor fabric, each step with its key artifact, and a reminder that you never hand-edit individual switches. Build order — do it in this sequence or chase ghosts 1 Underlay wizard OSPF + loopbacks 2 Fabric wizard iBGP EVPN + RR + VTEPs 3 Fabric segments VLAN → VNI → VRF 4 Roles + policy global GPID rules 5 Cloud Auth clients onboard Golden rule: configure in Central, never hand-edit one switch. Manual drift on one VTEP is the #2 cause of "it worked yesterday".
Figure 4 — Build bottom-up (transport → services → identity). Skip a step and you debug it later, slower.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from HPE Aruba TechDocs + Airheads Q&A. For complex prod issues, paste your show bgp l2vpn evpn summary + show interface vxlan output into chat.techclick.in.

📝 Wrap-up — four more

You've already answered 6 inline. Four left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.

Q7 · Analyze

After a power event, one edge switch came back with its loopback1 address accidentally duplicated from another leaf. What symptom appears first?

Correct: b. loopback1 is the VXLAN tunnel source and BGP EVPN session source. Two leaves claiming the same loopback1 means the underlay can't deterministically route to "the" VTEP — tunnels and EVPN sessions flap. The role layer is downstream; it only looks broken because the transport beneath it is unstable. Unique loopbacks are non-negotiable.
Q8 · Analyze

A laptop authenticates fine and gets role=Employee, the overlay is healthy, yet it cannot reach the HR app behind another leaf. Where do you look first?

Correct: c. Transport is healthy and the role is correct, so the block is policy. Role-to-role policy is enforced at the destination egress VTEP — check whether Employee→HR-App is allowed, or whether a default-deny is catching it. NetConductor's value is that you fix this once in Central, not on 40 switches.
Q9 · Evaluate

Your org already runs Azure AD and wants the fastest path to identity-based segmentation across a new AOS-CX campus, with no appetite to deploy an on-prem NAC appliance. Which design is the soundest?

Correct: a. Cloud Auth is purpose-built to integrate with a cloud identity store (Azure AD / Google Workspace) and assign roles with no on-prem RADIUS box, while Client Insights covers the non-802.1X IoT. That role then drives GBP across the fabric. Hand-maintained ACLs reintroduce drift; deploying ClearPass "to avoid the cloud" contradicts the stated no-appliance constraint; trusting ports is not zero-trust.
Q10 · Evaluate

A vendor rep claims: "Because policy rides in the VXLAN-GBP header, you can leave AOS-CX unpatched — the fabric is already zero-trust." Is the claim sound?

Correct: d. GBP enforcement depends on the VTEP being honest. CVE-2026-23813 (CVSS 9.8) lets an unauthenticated attacker reset the admin password — a compromised VTEP can stamp arbitrary GPIDs or rewrite policy, collapsing the whole zero-trust premise. "GBP therefore no patching" is exactly backwards: identity-in-the-packet only works if the device carrying it is patched and management access is restricted.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

🧠 Lock it in — explain it back

Self-explanation: In your own words, type how a single packet from Sneha's laptop reaches the HR app on another leaf — name the underlay, the overlay, and where the role is enforced. Writing it beats re-reading it.

👫 Teach a friend: Explain "underlay carries packets, overlay carries services, policy travels inside the packet" to a teammate in 60 seconds. If they get it, you've got it.

📒 Glossary — the 8 terms that matter

Underlay
The physical, routed IP network (OSPF + loopbacks) that simply carries the outer VXLAN packet between switches.
Overlay
The virtual network of VXLAN tunnels, signalled by BGP EVPN, that lets any VLAN/subnet appear anywhere in the fabric.
VTEP
VXLAN Tunnel Endpoint — an AOS-CX switch that encapsulates and decapsulates VXLAN, sourced from loopback1.
BGP EVPN
The control plane that advertises MAC/IP reachability across the fabric, replacing campus-wide flood-and-learn.
VNI
VXLAN Network Identifier — a 24-bit segment ID; L2VNI maps a VLAN, L3VNI maps a VRF.
GPID
Group Policy ID — the numeric tag for a client's role, carried in the VXLAN-GBP header so policy follows the user.
Cloud Auth
Aruba Central's cloud-native NAC that derives roles from Azure AD / Google Workspace (802.1X) and Client Insights (IoT).
Multi-Fabric EVPN
Carries VRF + role natively across fabrics over SD-WAN, keeping Group Based Policy consistent end to end.

📚 Sources

  1. HPE Aruba Networking TechDocs — Aruba Central NetConductor User Guide (overlay fabric, fabric wizard, fabric segments). arubanetworking.hpe.com
  2. HPE Aruba Networking — NetConductor Architecture Guide (Validated Solution Guide) — underlay (OSPF + loopbacks), iBGP EVPN route reflectors, GPID / VXLAN-GBP, role-to-role enforcement at egress.
  3. HPE Aruba Networking TechDocs — Cloud Authentication and Policy Feature Guide + Cloud Auth FAQs (Azure AD / Google Workspace, MAC-Auth + Client Insights).
  4. HPE Aruba Networking — AOS-CX EVPN-VXLAN Guide + Debugging & Troubleshooting (L2VNI-VLAN verification, EVPN summary).
  5. HPE Aruba Networking — What's New (Central 2.5.8 / AOS-10.6): Multi-Fabric EVPN, Extended-Edge / Scaled-Access fabric design.
  6. HPE Security Bulletin / CSA Singapore AL-2026-023 — AOS-CX CVE-2026-23813 (CVSS 9.8) auth-bypass, CVE-2026-23814/15/16 command injection; CX 10000 CVE-2024-54010.
  7. Aruba Airheads community + r/networking — practitioner threads on underlay/loopback gotchas and NetConductor vs Cisco SDA; CBT Nuggets "Aruba vs Cisco".

What's next?

You've built the fabric and put roles on the wire. Next we go deep on how those roles get derived for the messy real world — guests, BYOD laptops, and unmanaged IoT — with ClearPass Guest, Onboard certificates, and Device Insight profiling.

Next · Aruba ClearPass Guest, Onboard & Device Insight → ← Recap Aruba Architecture