Section titles, groupings and weights below are VCDX Academy study groupings, NOT the official Broadcom blueprint structure. Broadcom publishes no section weights. Always cross-check the official exam guide. Official exam guide ↗
Section 1 — Avi Architecture
~20%
Section 2 — Virtual Service Configuratio
~25%
High Weight
Section 3 — Application Profiles
~20%
Section 4 — Analytics and Troubleshootin
~20%
Section 5 — Operations
~15%
Version Evolution
Avi Load Balancer (NSX Advanced Load Balancer, ALB) was acquired by VMware in 2020 and integrated into VCF as the default load balancer, replacing NSX LB. Evolution: (1) Architecture became modular—separate Controller (control plane, Raft consensus) from Service Engines (data plane, DPDK-based). (2) VCF 9.0 integrates Avi as default; NSX LB deprecated. (3) Service Engine deployment modes evolved: bare metal for 100+ Gbps, VMs for small deployments, Kubernetes pods for cloud-native. (4) HA modes: Active/Active (N+M) for redundancy without manual failover, Active/Standby for legacy setups. (5) GSLB (Global Server Load Balancing) enables multi-site deployments with DNS steering and active-passive health checking. (6) Certificate management centralized; OCSP stapling and SNI routing supported. (7) Avi Controller cluster sizing critical: 3-node HA with Raft for production (can tolerate 1 node failure). Key operational: SE sizing directly impacts throughput and connection rate; oversizing wastes resources, undersizing causes queueing.
Learning Outcomes
Understand Avi Load Balancer 30.x Specialist concepts and architecture
Exam Focus:Understand Raft consensus enables HA without external coordination. 3-node cluster can tolerate 1 node failure (2/3 quorum). If you have 1 controller, any failure = complete outage. Never r
Exam Tip:When asked about Avi cluster resilience, mention: (1) Raft quorum (2/3 for 3-node), (2) leader election on failure, (3) read-only mode if quorum lost, (4) split-brain prevention (majority sid
Avi Load Balancer (NSX Advanced Load Balancer, ALB) is a software-defined application delivery controller. Unlike traditional hardware appliances, Avi separates control plane (Controller) from data plane (Service Engines), enabling elastic scaling and multi-cloud deployment.
Client → SE vNIC (ingress) → Virtual Service (VIP)
→ Service Engine process (load balance, SSL termination, WAF)
→ Health check & pool member selection (round-robin, consistent hash, etc.)
→ Backend pool member
← Response (SE encryption/compression, connection tracking)
← Client
Controller Cluster & Raft Consensus
Controller Cluster Architecture:
Avi Controller runs as a 3-node cluster using Raft consensus for distributed decision-making. Only the leader (master) accepts configuration changes; followers replicate state.
Leader Election: One controller elected as leader (via Raft voting)
Configuration Sync: All changes committed to leader's log
Replication: Leader replicates changes to followers
Commit: Change confirmed when majority (2/3) nodes acknowledge
Failover: If leader fails, remaining nodes elect new leader (2s timeout)
Configuration Changes Timeline:
Admin configures Virtual Service via Controller UI
↓ (accepted by Master, logged)
Master logs change locally (immediate acknowledgment to admin)
↓
Master sends "Append Log Entry" to Replicas 1 & 2
↓
Both replicas acknowledge log entry
↓
Master waits for majority (2/3) acknowledgment
↓
Change marked as committed
↓
Master pushes config to all Service Engines (gRPC)
↓
SEs load new config, validate (syntax, semantic checks)
↓
SEs send ACK to Controller
↓
Configuration change complete (end-to-end: ~2-5 seconds for production scale)
Failure Scenarios:
Scenario 1: Replica 1 fails
Master, Replica 2 form quorum (2/3)
Cluster continues accepting config changes
Replica 1 rejoins when online, syncs latest changes
Scenario 2: Master fails
Replica 1 & 2 detect no heartbeat (3-second timeout)
Replicas elect new leader (Raft election: <1 second)
New master accepts config changes immediately
Cluster disruption: <5 seconds
Scenario 3: Split brain (network partition)
Two partitions: Master + 1 Replica vs. 1 Replica
Master partition (2/3) can accept config changes
Replica partition (1/3) cannot (quorum lost)
Configuration changes blocked on replica-only partition
When partition heals, replica partition merges and syncs latest state
Exam Focus:
Understand Raft consensus enables HA without external coordination. 3-node cluster can tolerate 1 node failure (2/3 quorum). If you have 1 controller, any failure = complete outage. Never run single-controller deployment in production.
Service Engines & Deployment Modes
Service Engines (SEs):
Data plane entities running on physical servers, hypervisors, or cloud instances. Each SE is independent; no inter-SE communication required (stateless load balancing).
Service Engine Sizing (vSphere Deployment):
Deployment Mode: Write Access (Avi manages SEs)
Small SE (2vCPU, 4GB RAM):
Throughput: 500 Mbps per SE
Concurrent connections: 20K per SE
Typical scale: 5-10 SEs = 2.5-5 Gbps
Use case: Dev/test, low-traffic production
Cost: Minimal (small VMs)
Medium SE (4vCPU, 8GB RAM):
Throughput: 2 Gbps per SE
Concurrent connections: 100K per SE
Typical scale: 5 SEs = 10 Gbps
Use case: Mid-market production (e-commerce, SaaS)
Cost: Moderate
Large SE (8vCPU, 16GB RAM):
Throughput: 5 Gbps per SE
Concurrent connections: 250K per SE
Typical scale: 3-5 SEs = 15-25 Gbps
Use case: Large enterprise (CDN, financial services)
Cost: Higher
Ultra SE (16vCPU, 32GB RAM):
Throughput: 10 Gbps per SE
Concurrent connections: 500K per SE
Typical scale: 2-3 SEs = 20-30 Gbps
Use case: Hyperscale (cloud providers)
Cost: Significant
Elastic Scaling:
Auto-scale policy: If CPU >70% for 5 min, add new SE
Deactivation policy: If CPU <30%, remove SE (minimum: 2 SEs per SE Group)
Recommendation: Set min=2, max=10 for production (HA + elasticity)
Deployment Modes (Access Level):
Write Access Mode (Avi Manage
Key Takeaways
Exam Focus:Understand Raft consensus enables HA without external coordination. 3-node cluster can tolerate 1 node failure (2/3 quorum). If you have 1 controller, any failure = complete outage. Never run single-controller deployment in production.
SE Sizing and HA Modes: Active/Standby requires manual failover (slower); Active/Active N+M enables automatic redistribution on SE failure (faster RTO). Example: 4 SEs (N=3 active, M=1 spare) loses SE-1 → SE-4 activates, 3 active again. N+M recommended for production. Holodeck constraint: Limited VM resources require smaller SEs; test performance thoroughly.
GSLB Design for Multi-Site: Requires two Avi clusters (primary site + secondary) with DNS steering. Health checks every 10s for failover detection (<30s RTO). BE aware: GSLB does NOT replicate service engine configs; each site must have equivalent VS setup. Virtual service name must be identical across sites (DNS query routes based on health).
Certificate Management: Avi manages certificate lifecycle; supports auto-renewal via ACME (Let's Encrypt). OCSP stapling reduces client latency (client doesn't query OCSP responder). SNI routing enables multi-tenant (different cert per hostname on same VIP). Recommendation: centralize certs in Avi vault, not distributed to each SE.
Avi Controller Cluster Sizing: 3-node minimum for HA (Raft quorum). Single controller = single point of failure. Each node must have 8vCPU/32GB minimum. Data nodes separate from master improves performance (master handles only writes + Raft consensus, data nodes handle analytics queries). Backup/restore via API for disaster recovery.
Avi Controller Cluster Deep Dive — Raft Consensus & HA#
The Avi Controller is the control plane for all load balancing policies, virtual service configurations, and analytics. A 3-node cluster provides HA through Raft consensus, a distributed state machine replication algorithm. Understanding Raft mechanics and failure scenarios is essential for architect-level deployment.
Raft Consensus Overview
What is Raft?
Raft is a consensus algorithm that ensures all nodes in a cluster agree on the same state. Unlike Paxos, Raft emphasizes simplicity and ease of understanding.
QUORUM = N/2 + 1 nodes For 3 nodes: quorum = 2 nodes
→ Can tolerate 1 node failure
→ 2 nodes minimum for consensus (if one fails, 2 remaining quorum)
→ If 2 nodes fail: cluster cannot make decisions (read-only mode)
Raft State Machine & Terms
Each node in a Raft cluster maintains state: leadership, term counter, and log entries (mutations).
NODE STATE (Persistent on disk):
┌─────────────────────────────────────┐
│ Term (epoch counter) │
│ - Incremented on each election │
│ - Used to determine stale leaders │
├─────────────────────────────────────┤
│ Voted For (which candidate this │
│ term; used to prevent duplicate │
│ votes in same term) │
├─────────────────────────────────────┤
│ Log Entries [ { Index, Term, Cmd }] │
│ - Append-only; never deleted │
│ - Each entry: index + term + actual│
│ command (e.g., "create VS foo") │
├─────────────────────────────────────┤
│ Commit Index │
│ - Last log index known to be │
│ applied to state machine │
│ - Updated only by leader │
├─────────────────────────────────────┤
│ Last Applied │
│ - Last log index applied to │
│ application state │
│ - Followers lag behind leader │
└─────────────────────────────────────┘
ELECTION PROCESS:
FOLLOWER TIMEOUT (no heartbeat from leader for 150–300 ms)
→ Increment term
→ Become CANDIDATE
→ Send RequestVote to all peers
→ Vote for self
CANDIDATE WAITS FOR VOTES (1–2 seconds)
→ If majority votes: become LEADER (term 5 → 6)
→ If another candidate becomes leader: follow it
→ If timeout: increment term again; retry election
NEW LEADER (term 6)
→ Send Append Entries heartbeat to all followers immediately
→ Followers reset election timer
→ Cluster stable; can accept new configs
[STABLE AGAIN; C2 is new leader; C1, C3 followers]
Log Replication & Quorum
Write Path (New Configuration):
Client sends request to Leader (Controller-1):
"Create VS 'web-pool'"
Leader appends to own log:
[Index: 43, Term: 5, Cmd: "create VS web-pool"]
Leader sends Append Entries to Followers (C2, C3):
"Log entry 43, please append"
Followers append to log:
C2 & C3 each store entry 43
Followers respond:
"Entry 43 appended successfully"
Leader counts responses:
Self + C2 + C3 = 3/3 (quorum achieved!)
Leader commits entry:
Updates commit index to 43
Leader applies to state machine:
Virtual service "web-pool" created locally
Leader responds to client:
"V
Key Takeaways
Exam Tip:When asked about Avi cluster resilience, mention: (1) Raft quorum (2/3 for 3-node), (2) leader election on failure, (3) read-only mode if quorum lost, (4) split-brain prevention (majority side survives), (5) backup/restore procedure, (6) RTO/RPO implications (fast leader election ~150 ms; b
Service Engine Architecture — Data Plane Excellence#
Service Engines (SEs) are the data plane for Avi, handling all packet processing, load balancing decisions, and connection management. Understanding SE internals—DPDK acceleration, CPU pinning, SE groups, and HA modes—is critical for performance design.
Service Engine Data Plane (DPDK-Based)
What is DPDK?
Data Plane Development Kit; bypasses Linux kernel networking stack. Packets processed in userspace, avoiding context switches and kernel overhead.
CPU utilization: 30–50% (kernel scheduling overhead)
DPDK USERSPACE STACK:
┌────────────────────────┐
│ Avi SE (DPDK app) │ ← Packet poll-mode (no interrupts)
│ │ ← Direct NIC access (hugepages)
├────────────────────────┤
│ NIC Queues (lockless) │ ← Ring buffers
└────────────────────────┘
Latency per packet: 1–5 µs (10x faster!)
CPU utilization: 80–95% (but higher throughput per core)
Virtual Services (VS) are the core unit of load balancing in Avi. Understanding all types—L4, L7 (HTTP/HTTPS, HTTP/2, QUIC), DNS, GSLB—and their configuration matrices is essential for comprehensive design.
Persistence: NONE (each new connection can go to different backend)
TRAFFIC FLOW:
Client 10.0.2.5:54321 → VIP 10.0.1.100:3306
├─ SE receives TCP SYN
├─ Lookup pool member (RR: 10.0.3.10)
├─ NAT: Rewrite src to SE IP (10.0.1.101)
├─ Forward to backend 10.0.3.10:3306
├─ Backend responds; SE receives response
├─ NAT: Rewrite dst to VIP (10.0.1.100)
└─ Send to client (client sees response from VIP)
Client 10.0.2.50:12345 → VIP 10.0.1.101:53
├─ SE receives UDP packet
├─ Create connection entry (5-tuple)
├─ Forward to pool member (RR: 10.0.3.20:53)
├─ Backend responds with DNS answer
├─ SE translates response; send to client
└─ Connection aged out after 2 min of inactivity
DIFFERENCE FROM TCP:
No SYN/ACK handshake; stateless protocol
First packet creates entry; subsequent packets within TTL reuse entry
No connection cleanup (timeout-based)
Faster (no TCP overhead); lower latency
SCTP Virtual Service (Rare; Telecom/Diameter):
Protocol:
Stream Control Transmission Protocol; hybrid of TCP + UDP
├─ Client: GET /api/v1/products
├─ SE intercepts; reads HTTP headers
├─ Content-Switch rule: If URI = /api/* → route to api-pool
├─ Otherwise → route to web-pool
├─ Rewrite rule: Add header "X-Forwarded-For:
"
Pool Selection:
├─ /api/v1/* → api-pool (3 servers on port 8000)
├─ /static/* → cdn-pool (CDN origin cache)
└─ /* → web-pool (3 servers on port 80)
Session Persistence: HTTP Cookie
├─ SE inserts: Set-Cookie: AVIX_ID=se01-conn123
├─ Client stores cookie
├─ Next request includes cookie
├─ SE routes to same backend (session stickiness)
TRAFFIC FLOW:
Client GET http://example.com/api/v1/products
├─ TCP SYN → VIP 10.0.1.102:80
├─ TCP ACK; connection established
├─ Client sends HTTP GET with headers
├─ SE reads headers; matches rule: URI=/api
├─ Select pool member from api-pool (RR or persistent)
├─ Rewrite Host header (if needed)
├─ Forward HTTP GET to 10.0.3.30:8000
├─ Server responds: HTTP/1.1 200 OK
├─ SE adds Set-Cookie header (persistence)
├─ Forward response to client
└─ Connection closed after response (HTTP/1.0) or keep-alive
LATENCY ADDED BY LB:
TCP handshake: 0 ms (simultaneous client + server handshake)
TLS is the foundation of secure web traffic. Architects must understand cipher suite selection, certificate lifecycle management, and the handshake process to design secure, performant load balancing.
Service Engines (SEs) handle application data-plane traffic — they receive client connections, process load balancing decisions, and forward to backend servers. The Controller manages configuration. SDDC Manager and vCenter are infrastructure management.
A 3-node Controller cluster provides a single management endpoint via a cluster VIP with leader election for HA. 2 nodes lack quorum. 1 node has no redundancy. 5 nodes is over-provisioned. Controllers don't forward data-plane traffic.
A Service Engine Group is a logical grouping of SEs sharing HA mode, placement rules, and resource settings. Virtual Services define application front-ends. Pool Groups aggregate pools. Tenants provide RBAC isolation.
Elastic scale-out automatically deploys additional SEs to distribute load when a Virtual Service exceeds the capacity of a single SE. It's not about adding Controllers, resizing VMs, or K8s HPA.
In VCF, Avi integrates via SDDC Manager / VCF Automation with NSX Cloud Connector and vCenter discovery for automated SE deployment and segment attachment. Manual OVA, ToR installs, and VM agents are not the VCF integration model.
The Service Engine makes data-plane forwarding decisions for client traffic — it receives connections on VIPs and distributes to pool members. The Controller provides configuration. Avi Pulse provides cloud insights. NSX Manager handles networking.
With Write Access cloud configuration, the Controller uses OVF deployment through vCenter to automatically deploy SE VMs. PXE boot via SDDC Manager, kickstart files, and manual ISO mounts are not the automated deployment method.
A 3-node Controller cluster provides management/control-plane HA with leader election. Controllers handle no data-plane traffic, don't perform SSL offload, and don't enforce WAF — those are SE functions.
Elastic HA N+M with buffer and scale-out automatically replaces failed SEs using the M buffer, maintaining virtual service availability. Legacy A/S requires manual intervention. Single SE mode has no redundancy. Passive standby is part of legacy HA.
With NSX-T cloud connector, Avi attaches SE data NICs to NSX-T overlay or VLAN segments referenced by the Cloud and Network configuration. Physical VLAN trunks, VMkernel ports, and Standard Switch port groups are not the NSX-T integration method.
HTTP cookie persistence (Avi-inserted) maintains session stickiness across multiple backend servers using browser cookies, surviving NAT and proxy scenarios. Client IP breaks behind NAT. TLS session ID is less reliable. No persistence breaks sessions.
Least Connections routes each request to the server with the fewest active connections, balancing load based on current utilization. Round Robin distributes sequentially. Consistent Hash is for cache affinity. Fastest Response selects by response time.
Configure the HTTP health monitor to treat 302 (redirect) as a success response code since the app legitimately returns redirects. Enabling WAF, switching to UDP, and disabling persistence don't address health check response code expectations.
HTTP request policies or DataScripts enable content switching by routing requests to different pools based on URI path. Separate SE Groups don't provide URL-based routing. Two Controllers and manual DNS entries don't address L7 routing.
Least Connections works best when sessions vary in duration/load — it naturally directs new connections to the least-busy server. When all sessions are short and identical, Round Robin works equally well. It's not UDP-specific or for cookie persistence.
HTTP monitor with custom request /healthz and expected response code 200 validates the application is truly serving traffic. TCP monitor only checks port availability. ICMP checks host reachability. UDP monitor is for UDP services.
SSL termination + re-encryption requires: SSL certificate and SSL profile on the VS (frontend termination) AND SSL enabled on the pool configuration with a pool-side SSL profile (backend encryption). Only pool-side cert or L4 mode don't achieve this.
Persistence is needed so that the same client reaches the same backend server during an authenticated session. Which persistence profile is LEAST likely to break behind a NAT gateway?
Client IP persistence
HTTP cookie (application or Avi-inserted) persistence
HTTP cookie persistence survives NAT gateways because the cookie travels with the HTTP request regardless of source IP. Client IP persistence breaks when multiple clients share a NAT IP. TLS session ID is unreliable. Source port changes with NAT.
L4 (TCP/UDP) virtual service with TCP proxy or Fast Path profile provides Layer 4 load balancing without HTTP awareness. HTTP VS with WAF adds L7 overhead. DNS VS is for DNS. GSLB VS is for multi-site DNS.
L4 application profile passes TCP connections through without Avi terminating or inspecting HTTP content. HTTP profile adds L7 awareness. DNS profile handles DNS queries. System-HTTPS is an HTTP variant.
WAF paranoia level 4 enables the most aggressive rule sets with the highest detection sensitivity but also the highest false-positive potential. Level 1 is the least aggressive. Higher levels don't disable rules or only affect logging.
Enabling WAF increases SE CPU/memory consumption due to request body parsing and signature matching. It doesn't reduce resources, have no impact, or remove SSL termination needs.
iWAF (Avi Web Application Firewall) policy bound to the HTTP virtual service protects against OWASP Top 10 attacks. GSLB handles multi-site DNS. NSX Edge Network Security is for network firewalling. Pool rate limiters throttle requests.
Start in Detection (log-only) mode to observe matches and tune signatures/exclusions before switching to Enforcement. Starting with enforcement or disabled learning risks blocking legitimate traffic from day one.
The Avi DNS virtual service configured as GSLB site DNS answers queries authoritatively at each site. vCenter DNS doesn't participate in GSLB. External BIND is not the Avi mechanism. NSX Manager doesn't serve DNS for GSLB.
Priority-based algorithm with site A at higher priority achieves active/standby — site B only receives traffic when site A health checks fail. Round Robin and Least Connections distribute across both sites. Geo proximity routes by location.
High Server RTT with low Client RTT indicates the network path between SEs and backend servers is the bottleneck — not the client ISP, TLS overhead, or DNS resolution.
Significant logs are a sampled subset capturing only flows with errors, anomalies, or policy matches, reducing storage while preserving diagnostic value. They're not full pcaps, debug traces, or backend syslog.
Background CPU of the Controller primary doesn't affect virtual service health scores. Health scores are composed of Performance (latency/errors), Anomaly penalty (deviation from baseline), and Security (cert status, WAF events).
Check connectivity, timeout thresholds, and server load in health monitor logs to understand intermittent failures. Certificate replacement, persistence changes, and Controller rebuild don't address health check configuration issues.
WAF-enabled application logs include WAF rule match IDs and processing phases, helping identify which CRS rules are triggering. BGP state, vSAN metrics, and Edge routing tables are unrelated to WAF.
The Analytics Profile attached to the virtual service defines what qualifies as 'significant' — thresholds for response time, error codes, and anomaly scores. Application Profile handles HTTP. SE Group controls compute. Cloud controls infrastructure.
The End-to-End Timing chart breaks latency into Client RTT, Total Time, App Response, and Data Transfer, pinpointing where delays occur. Health Score alone doesn't decompose latency. Pool uptime and Controller log rate don't show timing breakdown.
Low Health Score with 'Performance' flagged indicates high latency, connection errors, or resource saturation impacting responsiveness. Expired certificates flag 'Security'. WAF issues flag 'Resource'. GSLB status is separate.
Traffic Capture on the SE(s) hosting the virtual service, filtered by client IP, provides packet-level trace for a specific connection. Controller log export lacks packet detail. vCenter charts show metrics. NSX IDS captures different traffic.
Pool member 'Oper State' = DOWN and Health Monitor failure count in analytics directly indicate health check failures. Throughput, SE CPU, and Controller disk don't specifically indicate member health status.
N+M is the default elastic HA mode providing M buffer SEs shared across Virtual Services for fault tolerance. Legacy A/S is the old model. Active/Active only handles scale but not HA buffering. Single-SE mode has no redundancy.
SE anti-affinity rules spread SEs across ESXi hosts or fault domains, ensuring a single host failure doesn't take out all SEs for a virtual service. They don't force colocation, disable vMotion, or share IPs.
Avi rolling upgrade: Controller cluster first (leader → followers), then SEs in a rolling fashion per SE Group. SEs first would lack new config. Simultaneous upgrade causes downtime. SEs must also be upgraded.
GSLB requires a DNS Virtual Service at each site to answer queries authoritatively. L4 pass-through VIPs handle traffic. Static DNS entries lack dynamic health checking. Shared Controllers across sites aren't required.
Tenants with RBAC role assignments and resource isolation ensure Team A and Team B have separate operational domains. Single default tenant offers no isolation. Separate vCenters is heavy-handed. One SE group per user doesn't provide UI isolation.
The Controller's System Update workflow orchestrates Controller upgrade then rolling SE Group upgrades with minimal downtime. Redeploy from scratch causes extended outage. Manual VM cloning is error-prone. Mismatched Controller/SE versions cause issues.
Avi Terraform provider and Ansible modules leverage the Avi REST API for declarative configuration-as-code. UI-only is not IaC. PowerCLI is for vSphere. SDDC Manager APIs manage VCF infrastructure.
Avi Tenants combined with Roles and Labels (object access policies) scope RBAC for multi-team management. vCenter folders don't scope Avi access. NSX security groups are for firewall policies. vSphere tags don't control Avi RBAC.
The Controller supports scheduled encrypted configuration backups that can be downloaded and restored. Backups are required — config isn't stored in vCenter. Both Controller and SE configs are included. ESXi snapshots are not the supported backup method.
In VCF 9, which product integrates natively with Avi Load Balancer to provide Tier-1 gateway load-balancing replacement in a factory-installed fashion?
vSAN
VCF / NSX with the Avi (NSX ALB) integration, delivering L4-L7 LB as the recommended replacement for built-in NSX LB
VCF / NSX with Avi (NSX ALB) integration delivers L4-L7 LB as the recommended replacement for built-in NSX LB in VCF 9. vSAN handles storage. Aria Ops for Logs handles log management. SRM handles DR.
The management and control-plane component of Avi Load Balancer, typically deployed as a 3-node cluster (one Leader, two Followers) fronted by a Cluster IP; smaller/lab deployments can use a single Controller. Holds configuration, analytics, and API; never handles data-plane traffic. Loss of the Controller cluster does not affect running Virtual Services served by Service Engines.
Service Engine (SE)
The Avi data-plane VM (or container) that actually forwards and terminates application traffic for Virtual Services. SEs are provisioned by the Controller on demand and grouped into SE Groups. Throughput scales with SE count and sizing.
Service Engine Group (SEG)
A logical container for a set of SEs sharing HA mode, networking, and tenant placement. Virtual Services are bound to an SEG, which constrains which SEs can serve them. SEGs are the primary tuning knob for performance and isolation.
Virtual Service (VS)
An Avi application endpoint defined by a VIP, port, application profile, and backend Pool. It is the object clients connect to and the primary configuration unit. A VS can be L4 or L7 depending on its application profile.
Pool (Avi)
A group of backend servers (physical, VM, or Kubernetes endpoints) that a Virtual Service load-balances across, with health monitors, persistence, and algorithms configured at the pool level. Multiple VSes can share a pool. Pools are the membership abstraction behind every VS.
Avi Cloud Connector
The orchestration module in the Controller that integrates with a specific infrastructure (vCenter, NSX-T, AWS, GCP, Linux Server Cloud). The cloud type dictates how SEs are deployed, IPAM behavior, and networking integration.
No-Access Cloud
A Controller-managed cloud where Avi does not deploy SEs itself; operators bring their own SE VMs and attach them. Used when vCenter/NSX credentials are not available or for air-gapped deployments.
NSX-T Cloud (Avi)
Avi cloud type that uses NSX-T as the network source of truth, auto-creating logical segments for SE data NICs and integrating with Tier-1 routers for north-south. Required for Avi-with-VCF and AKO NSX integrations.
Controller Cluster Quorum
Avi Controllers deploy as 1-node (lab) or 3-node cluster (production). Leader is elected; at least 2 nodes must be reachable to accept config writes. Data-plane traffic is unaffected during controller outages because SEs continue forwarding.
SE Group HA Modes
Service Engine Groups support Legacy Active/Standby, Elastic N+M Buffer, and Active/Active. Mode is chosen based on scale, session-sync needs, and VS type; it cannot be changed without redeploying SEs.
Consistent Hash Algorithm
An Avi load-balancing algorithm that routes each client's requests to the same backend based on a hash of a header, cookie, or IP. It provides cache-affinity and predictable distribution without requiring stateful persistence. It is preferred when upstream caches matter.
Health Monitor
An Avi probe (TCP, HTTP, HTTPS, UDP, DNS, or custom script) that periodically tests pool members and removes unhealthy backends from rotation. Monitors are pool-scoped and can be stacked for multi-layer checks. Their configuration is the single biggest lever on apparent availability.
Persistence Profile
An Avi configuration that pins a client to the same backend across requests using IP, cookie, app cookie, custom header, or TLS session ID. Without persistence, stateful apps see inconsistent sessions. Each VS binds one persistence profile at most.
SSL Profile
An Avi policy that defines accepted TLS protocol versions, cipher suites, and session-ticket behavior for a Virtual Service. It is the place where Perfect Forward Secrecy and strict ciphers are enforced. It is referenced from SSL-enabled VSes and can be shared.
DataScript
A Lua-based Avi script that hooks into HTTP request/response lifecycle events for advanced content switching, rewriting, or rate-limiting decisions. It gives Avi extensibility without requiring an external reverse proxy. It is the Avi equivalent of iRules in the F5 ecosystem.
Virtual Service — L4 vs L7
An L4 VS proxies raw TCP/UDP (fast path, fewer features); an L7 VS terminates HTTP/HTTPS and supports content switching, WAF, rewrites, DataScripts. Profile choice determines which analytics and policies are available.
Pool Group
An ordered collection of pools with weights used for blue/green and canary deployments. Traffic is split by configured ratios and can be shifted via a single API call without touching the VS.
Health Monitor Types
Avi supports Ping, TCP, UDP, HTTP, HTTPS, DNS, External (script), GSLB, and Radius monitors. Send/receive strings, response codes, SSL attributes, and per-server overrides shape when a member is declared DOWN.
Passive Health Monitor
A monitor that does not send synthetic probes but marks servers down based on real client traffic errors (5xx, RST, timeout) over a rolling window. Reduces background probe load in large pools.
Persistence Profile Types
Client-IP, HTTP Cookie (insert/passive), App Cookie, TLS Session ID, Custom Header. Each has timeout and sync behavior. Choice depends on app statefulness and presence of client-side NAT.
HTTP Application Profile
An Avi profile that enables L7 features such as connection multiplexing, compression, caching, and HTTP/2. It is the default choice for web workloads. It is required before any HTTP-aware policy can be attached.
L4 Application Profile
An Avi profile that treats traffic as opaque TCP or UDP, forwarding without payload inspection. It has the lowest CPU cost and highest throughput per SE. It is used for protocols where L7 awareness is unnecessary or undesirable (for example, SSH, RDP, custom sockets).
DNS Application Profile
An Avi profile specialized for DNS services, providing DNS load balancing, GSLB DNS responses, and authoritative answers. It is attached to DNS Virtual Services. It is key to Avi's GSLB implementation.
Web Application Firewall (WAF)
The Avi L7 security add-on that inspects HTTP requests against OWASP CRS and custom rules, operating in Detection or Enforcement mode. It provides positive and negative security models. Enabling WAF has a measurable CPU cost on SEs.
WAF Learning Mode
A WAF operational mode that observes traffic to build a positive security baseline (allowed parameters, sizes, endpoints) before moving to enforcement. It reduces false-positive pain on rollout. It requires a representative traffic period to produce a trustworthy model.
SSL/TLS Profile
Controls TLS versions (1.0–1.3), cipher suite list, ECDH curves, and session cache/ticket behavior. Attached to VSs or Pools (for backend re-encryption). Ratings such as 'Modern' and 'Compatible' are templates.
WAF Policy Modes
WAF runs in Detection (log only), Enforcement (block), or Learning (observe and recommend allow-list exceptions). Policy mode can be overridden per rule or per rule-group for progressive rollout.
WAF Core Rule Set (CRS)
The upstream ModSecurity/OWASP CRS ruleset shipped with Avi, organized into paranoia levels (1–4). Higher levels catch more but produce more false positives, requiring tuning via allow-lists.
Positive Security Model
A WAF approach that explicitly defines allowed URLs, parameters, and methods; everything else is blocked. Avi supports this via learned allow-lists or imported OpenAPI/Swagger definitions.
HTTP Policy Set
Rule-based engine attached to an HTTP VS that can redirect, rewrite headers/URLs, switch pools, or run DataScripts. Evaluated in order; first-match actions apply unless configured as 'continue'.
End-to-End Timing
An Avi analytics breakdown of each request's latency into Client RTT, Server RTT, Application Response, and Data Transfer components. It makes latency root cause visible at a glance. It is the first artifact to review for slowness complaints.
Significant Log
An Avi log flagged as noteworthy by built-in heuristics (errors, slow responses, policy hits) and always retained, in contrast to non-significant logs which are sampled. Significant logs preserve the interesting events at low storage cost. They are the default search surface.
Application Health Score
An Avi metric blending performance, security, resource, and anomaly signals into a 0-100 score per Virtual Service. Low scores surface degrading apps before users notice. Clicking a score reveals the contributing factors.
Client Insights
An Avi analytics surface that profiles clients by geography, browser, TLS version, and connection quality. It is useful for content-optimization and security-posture analyses. It is populated automatically from real traffic.
SE Performance Metrics
Per-Service-Engine metrics for CPU, memory, packets-per-second, and flows that reveal data-plane capacity issues. SE metrics are the authoritative signal when VS analytics look healthy but throughput caps out. They inform decisions to scale out or resize SEs.
Client Log Filter
A VS-level filter that controls which client logs are stored as Significant vs Non-significant. Example: log all 5xx as significant, sample 1% of 200s. Helps keep log volume manageable at high RPS.
Virtual Service Analytics Profile
Defines what is considered 'significant' and performance SLO targets (RUM latency thresholds, error-rate thresholds) used to compute the Application Health Score.
End-to-End Timing Breakdown
Per-request latency split across Client RTT, SSL Handshake, Request Processing, App Response, and Data Transfer. Used to localize where latency originates (network vs SE vs server vs client).
Traffic Capture on SE
Controller-initiated PCAP on one or more SEs for a chosen VS/client/pool member, retrieved as a downloadable file. Useful for deep L4/L7 troubleshooting without console access to the SE.
Controller Event Log
Records configuration changes, SE lifecycle events, HA transitions, and license alerts. Filterable by VS, SE, or event type and exportable via syslog.
Elastic HA N+M
An Avi SE HA mode where N active SEs serve traffic and M buffer SEs stand ready to take over on failure, reducing failover time. Avi also offers 'Elastic HA Active/Active' (VS scales across multiple active SEs) as the default for most SE Groups. N+M is chosen when faster failover with pre-provisioned buffer SEs is required; both are more efficient than legacy Active/Standby pairs.
Legacy Active/Standby HA
An older Avi HA mode where each VS has exactly one active and one standby SE. It preserves legacy behavior for simple, small deployments. It is less scalable than Elastic HA and is not recommended for new designs.
Buffer Service Engine
A pre-provisioned SE that carries no active traffic but is ready to absorb load on failure or scale-out, reducing failover time. Buffers are configured per SEG. They trade a small amount of idle capacity for faster recovery.
GSLB (Avi)
Global Server Load Balancing across multiple Avi sites with DNS-based traffic steering by geography, health, and load. It provides cross-site application continuity. It requires a GSLB leader site and synchronized follower sites.
Avi Kubernetes Operator (AKO)
A Kubernetes controller that translates Ingress, Service, and Gateway resources into Avi Virtual Services automatically. It makes Avi the ingress load balancer for VKS, OpenShift, and vanilla Kubernetes. It is the standard integration path in VCF 9.
AKO (Avi Kubernetes Operator) — Deployment Modes
AKO runs in ClusterIP, NodePort, or NodePortLocal mode, and optionally in 'VIP-per-namespace' or shared VIP. Mode affects how Service/Ingress objects map to Avi VSs and how traffic reaches pods.
AMKO (Avi Multi-Cluster K8s Operator)
Extends AKO to synchronize Services across multiple K8s clusters into Avi GSLB, providing multi-region/multi-cluster L7 failover for Ingress/Gateway API resources.
Avi with NSX ALB Integration in VCF
NSX ALB is the recommended LB for VKS Supervisors and modern VCF deployments, replacing built-in NSX LB. Integration uses NSX-T cloud connector and per-Supervisor SE Groups.
GSLB Site Types
GSLB roles include Leader (owns config), Active Follower, and Passive. DNS VSs on each site answer GSLB FQDN queries from their local perspective using health and geo policies.
SE Upgrade Strategies
Controller-driven rolling upgrade of SE Groups, with Suspend (manual), Rolling, or Full-parallel options. Elastic HA allows seamless upgrades as SEs are drained one at a time; Legacy A/S incurs a brief failover.