Architecture Overview

Aviatrix multi-cloud overlay across AWS, Azure, and GCP — 3 CSPs, 3 regions each, centralized NGCN Account

Cloud Providers

Total Regions

App Fabric Controllers

Hybrid Edge Controller

Colocations

Edge Spoke GWs (total)

Global Architecture — Aviatrix Overlay

Click components for details · Hover tags to highlight

Aviatrix Overlay

Aviatrix provides a software overlay on top of each CSP's native underlay networking. Controllers manage transit gateways and spoke gateways across all three clouds via a unified control plane.

NGCN

NGCN Account

The centralized network account ("NGCN Account") hosts all Transit Gateways (E/W) and firewall infrastructure. App spoke GWs in workload accounts attach to these transit GWs. Not a "shared services" account — purpose-built for network transit.

AFC

App Fabric Controllers

9 App Fabric Controllers — 1 per region per CSP (AWS: Central/East/West, Azure: Central/East/West, GCP: Central/East/West). Each manages E/W Aviatrix Transit GWs and App Spoke GWs within that region.

HEC

Hybrid Edge Controller

A single Hybrid Edge Controller manages BOTH the Hybrid Edge Transit GWs (in each region of each CSP) AND the physical Edge Spoke GWs deployed in the Equinix and Cologix colocations.

Equinix Colo

Equinix colo is preferred for AWS connectivity. Houses Edge Spoke GWs with 25Gbps WAN (underlay) + 25Gbps LAN (overlay/BGPoLAN) interfaces. 2×100Gbps circuits per CSP.

Cologix Colo

Cologix colo is preferred for Azure and GCP connectivity. Same specs: Edge Spoke GWs with 25Gbps WAN + 25Gbps LAN interfaces. 2×100Gbps circuits per CSP.

Controller Topology: App Fabric Controllers manage E/W transit and app spoke GWs within each CSP region. The single Hybrid Edge Controller spans all CSPs and both colos — it manages HE Aviatrix Transit GWs (in cloud), Edge Spoke GWs (in colo), and MTT Gateways in Central regions. MTT Gateways in Central regions are managed by the Hybrid Edge Controller and connect across CSPs via Aviatrix Transit GW Attachments.

App Fabric - East/West Traffic

Same-region and cross-region E/W flows with Palo Alto firewall inspection in NGCN Account

Same-Region E/W Flow — 1-Arm Firewall Design

NGCN Account · Palo Alto FW

1-Arm Firewall Design: The Load Balancer sits BETWEEN the firewall and the E/W Aviatrix Transit GW. Traffic flows: E/W Aviatrix Transit GW → LB → FW (hairpin back through LB) → E/W Aviatrix Transit GW. AWS uses Gateway Load Balancer (GWLB); Azure and GCP use Internal Load Balancer (ILB).

AWS — GWLB

AWS uses Gateway Load Balancer (GWLB) for the 1-arm firewall design. GWLB operates at Layer 3 and distributes traffic to Palo Alto FW instances using GENEVE encapsulation. Transparent bump-in-the-wire inspection.

Azure — ILB

Azure uses Internal Load Balancer (ILB) for the 1-arm firewall design. The ILB sits between the transit GW and Palo Alto FW instances, distributing traffic for inspection before returning it through the same ILB.

GCP — ILB

GCP uses Internal Load Balancer (ILB) for the 1-arm firewall design. Same pattern as Azure — ILB distributes flows to Palo Alto FW instances for inspection before returning through the ILB to the E/W Aviatrix Transit GW.

Palo Alto FW — 1-Arm

All Palo Alto firewall instances use a 1-arm design (single interface for both ingress and egress). They sit behind the LB and inspect traffic, then return it back through the same LB. FWs and LBs live in the NGCN Account.

E/W Flow Detail — Component Roles

All regions follow this pattern

Component	Location	Role
App Spoke GW (Source)	Workload Account	Originates traffic, attached to E/W Aviatrix Transit GW
E/W Aviatrix Transit GW	NGCN Account	Aggregates spoke traffic; sends to LB for FW inspection
CSP Load Balancer	NGCN Account	AWS: GWLB · Azure: ILB · GCP: ILB — sits between TGW and FW
Palo Alto FW (1-arm)	NGCN Account	Inspects and policy-enforces, returns via same LB
App Spoke GW (Dest)	Workload Account	Receives inspected traffic from E/W Aviatrix Transit GW

Cross-Region E/W Flow (Same CSP) — FW Inspection in Source Region Only

Via HE Aviatrix Transit GWs

Firewall Inspection in Source Region Only: For cross-region flows, inspection happens ONLY at the source region. The inspected traffic then traverses HE Aviatrix Transit GWs between regions (East → Central etc.) to reach the destination region's E/W Aviatrix Transit GW and App Spoke GW.

Cross-Region Routing: HE Aviatrix Transit GWs serve dual purpose — they connect cloud to on-prem (via Edge Spoke GWs in colos) AND provide the inter-region backbone within each CSP. E/W Aviatrix Transit GWs in non-adjacent regions route via HE TGWs.

HOP

Cross-Region Path

App A Spoke GW (East)
→ E/W Aviatrix Transit GW (East, NGCN)
→ LB → FW (East) → LB (inspection only in source)
→ E/W Aviatrix TGW (East)
→ HE Aviatrix Transit GW (East)
→ HE Aviatrix Transit GW (Central)
→ E/W Aviatrix Transit GW (Central, NGCN)
→ App B Spoke GW (Central)

HE Aviatrix Transit GW Role

HE Aviatrix Transit GWs act as inter-region connectors. They are attached to both the E/W Aviatrix Transit GW in the same region and peer with HE TGWs in other regions, forming the cross-region backbone.

Hybrid Edge — Cloud to On-Premises

Edge Spoke GWs in Equinix and Cologix colos bridge cloud to on-prem via BGPoLAN

Hybrid Edge Architecture — Colo Connectivity

2 Colos · 24 ESGs total

● NGCN Team Owns

Edge Spoke GWs (in colos)
All Aviatrix cloud infrastructure
E/W Aviatrix Transit GWs + HE Aviatrix Transit GWs
MTT Gateways
App Fabric Controllers + Hybrid Edge Controller
CSP circuit-terminating accounts (cloud side)

● On-Prem Team Owns

Cages, routers, switches in colo
Physical circuits (Direct Connect, ExpressRoute, Interconnect)
Circuit-terminating cloud accounts
Colo switches (BGPoLAN peer side)
Everything from colo switches toward on-prem

Edge Spoke GW Specifications

Per ESG

Parameter	Equinix (AWS preferred)	Cologix (Azure/GCP preferred)
ESGs per CSP per colo	4	4
Total ESGs per colo	12 (4 × 3 CSPs)	12 (4 × 3 CSPs)
Total ESGs across both	24 total
WAN interface	25 Gbps (underlay)	25 Gbps (underlay)
LAN interface	25 Gbps (overlay/BGPoLAN)	25 Gbps (overlay/BGPoLAN)
Circuits per CSP per colo	2 × 100 Gbps	2 × 100 Gbps
BGPoLAN	Between ESG LAN interface and colo switches
Routes accepted via BGPoLAN	RFC 1918 only (from colo switches)

BGPoLAN Clarification: BGPoLAN operates on the LAN interface of the Edge Spoke GWs — the peering is between the ESG LAN port and the colo switches managed by the on-prem team. This is NOT between data centers and the colo. The on-prem team handles everything from the colo switches onward into their network.

WAN Interface Role: The WAN interface of each Edge Spoke GW advertises subnets back toward the CSP for underlay connectivity (Direct Connect / ExpressRoute / Interconnect circuits). The LAN interface is used for the overlay BGPoLAN peering toward on-prem.

Equinix Colo

AWS preferred. Houses 12 ESGs (4 per CSP × 3 CSPs). AWS Direct Connect circuits land here, terminating in on-prem team's cloud account. NGCN Team owns only the Edge Spoke GWs.

Cologix Colo

Azure + GCP preferred. Houses 12 ESGs (4 per CSP × 3 CSPs). Azure ExpressRoute and GCP Interconnect Direct circuits land here, terminating in on-prem team's cloud account.

HE Aviatrix Transit GW

The HE Aviatrix Transit GW sits between the E/W Aviatrix Transit GW and the Edge Spoke GWs (in colo). It's the cloud-side attachment point. All 3 CSPs have HE Transit GWs in each region, managed by the single Hybrid Edge Controller.

RFC

Route Filtering

Only RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are accepted via BGPoLAN from the colo switches. Public routes are rejected to prevent route leaks.

Cross-CSP Traffic — MTT Gateways

Multi-Tenant Transit gateways in Central regions connect across CSPs via Aviatrix Transit GW Attachments — managed by Hybrid Edge Controller

MTT Gateway Topology — Cross-CSP Aviatrix TGW Attachments

Central regions only

Unified controller, cross-CSP TGW Attachments. All MTT Gateways are managed by the single Hybrid Edge Controller — the same controller that manages HE Aviatrix Transit GWs and Edge Spoke GWs. MTT Gateways are deployed in the Central region of each CSP, attach to the local HE Aviatrix Transit GW, and connect directly with MTT GWs in other CSPs via Aviatrix Transit GW Attachments. Routes from other CSPs are propagated throughout the local CSP's regions via these attachments.

MTT

MTT Gateway Placement

MTT Gateways exist ONLY in each CSP's Central region. Each MTT GW attaches to the HE Aviatrix Transit GW in the same CSP's Central region. 3 MTT GWs total (one per CSP Central region).

TGW

TGW Attachment Model

MTT GWs from different CSPs connect via Aviatrix Transit GW Attachments (full mesh). They exchange routes for all prefixes reachable within each CSP, enabling cross-CSP path visibility.

Route Propagation

MTT GWs propagate routes from other CSPs into the local CSP's routing domain. These routes flow from the MTT GW → HE Aviatrix TGW → E/W Aviatrix TGWs → App Spoke GWs across all regions of that CSP.

CTL

Controller Management

All MTT Gateways are managed by the single Hybrid Edge Controller — the same controller that manages HE Aviatrix Transit GWs and Edge Spoke GWs in colos. Aviatrix Transit GW Attachments between CSPs are the cross-cloud integration point.

Cross-CSP Traffic Flow — AWS to Azure Example

Via MTT TGW Attachment

#	Hop	Component	Notes
1	Source App	App in AWS (any region)	Originates from AWS workload
2	E/W Transit	E/W Aviatrix TGW (AWS region, NGCN)	Routes toward HE TGW
3	HE Transit	HE Aviatrix TGW (AWS Central)	Inter-region hop if needed; connects to MTT
4	MTT GW (AWS)	MTT GW — AWS Central	Connects to Azure MTT GW via TGW Attachment
5	↔ TGW Attachment	Cross-CSP Aviatrix TGW Attachment	Hybrid Edge Controller manages both sides
6	MTT GW (Azure)	MTT GW — Azure Central	Receives traffic from AWS MTT GW
7	HE Transit	HE Aviatrix TGW (Azure Central)	Distributes into Azure regions
8	E/W Transit	E/W Aviatrix TGW (Azure target region, NGCN)	Routes to destination spoke
9	Destination App	App in Azure	Receives cross-CSP traffic

CSP Underlay Connectivity

Native CSP circuits connecting colos to cloud — managed by on-prem team's accounts

Circuit Ownership: Physical circuits (Direct Connect, ExpressRoute, Interconnect) are terminated in cloud accounts owned by the on-prem network team — NOT in the NGCN team's accounts. The cloud-side underlay path is: HE Aviatrix Transit GW (cloud VPC/VNet) → VPG/ER-GW/Cloud Router → DXGW/ExpressRoute Circuit/VLAN Attachment → physical circuit to colo → ESG WAN Interface (in colo). Edge Spoke GWs are physical appliances in the colo, not in the cloud.

Underlay Component Reference

Per CSP

CSP	Cloud Router/GW	Aggregation	Physical Layer	Preferred Colo
AWS	VPG (Virtual Private Gateway)	DXGW (Direct Connect Gateway)	Direct Connect circuit	Equinix
Azure	ER Gateway	ExpressRoute Circuit	ExpressRoute Direct	Cologix
GCP	Cloud Router	VLAN Attachment	Interconnect Direct	Cologix

WAN

ESG WAN Interface (Colo)

The WAN interface of each Edge Spoke GW (physically located in the colo) connects back to the cloud via the CSP physical circuit (Direct Connect / ExpressRoute / Interconnect). It advertises local subnets toward the HE Aviatrix Transit GW in the cloud. The WAN interface operates at Layer 3 toward the CSP underlay.

LAN

ESG LAN Interface (Colo)

The LAN interface of each Edge Spoke GW (in colo) builds the overlay — BGPoLAN peering with colo switches toward on-prem. Only RFC 1918 routes are accepted from the colo switches.

Traffic Flow Animations

Animated packet walks through the architecture — press Play to watch each flow

Trace a Path

Select source & destination

Source

→

Destination

E/W Same-Region Flow

App A → E/W Aviatrix Transit GW → LB → FW → LB → E/W Aviatrix Transit GW → App B (same region, same CSP)

Cross-Region Flow (Same CSP)

App A (East) → E/W Aviatrix TGW → FW (source only) → E/W Aviatrix TGW → HE TGW (East) → HE TGW (Central) → E/W Aviatrix TGW → App B (Central)

Hybrid Edge Flow (Cloud to On-Prem)

E/W Aviatrix TGW → HE Aviatrix TGW → Edge Spoke GW → BGPoLAN ↔ Colo Switches → On-Prem

Cross-CSP Flow (AWS → Azure)

App A (AWS East) → E/W TGW → FW → MTT GW (AWS) → MTT GW (Azure) → E/W TGW (Azure) → App B

L2 Operational Scenarios

Hop-by-hop with ops verification notes

Select a scenario above to view the operational walkthrough with verification notes per hop.

Management Fabric

Firewall management architecture — how controllers connect to and manage Palo Alto firewall infrastructure

🏗️

Under Construction

This section is being built in collaboration with the network engineering team. Firewall management architecture, controller connections, and management paths coming soon.

Alerts & Monitoring

Grafana to ServiceNow alerting pipeline — 300+ alerts across the multi-cloud environment

🏗️

Under Construction

This section is being built in collaboration with the engineering team. Grafana alerting pipeline, ServiceNow integration, and monitoring configuration coming soon.

Alert Architecture Flow

Grafana → ServiceNow

Current State: 300+ alerts configured in Grafana. The alert volume is not optimized for operator experience — signal-to-noise ratio needs improvement. This represents an optimization opportunity.

Alert Rules Configuration

Active rules from Grafana

Alert Name	Condition	Monitored Entities	Evaluation Period	Recipients	Live Status
Global Network Health	Gateway Status (Down, Keep Alive Fail, CPPS Limit Exceeded Drop (%) more than 1%	All Gateways, All Interfaces	15 min		Not Connected
Controller CPU Used (%) Minor	CPU Used (%) more than 80%	Controller	10 min	Webhook_Interlink_Alert_Minor	Not Connected
Copilot CPU Used (%) Minor	CPU Used (%) more than 80%	CoPilot	10 min	Webhook_Interlink_Alert_Minor	Not Connected
Gateways CPU Used (%) Minor	CPU Used (%) more than 80%	All Gateways	10 min	Webhook_Interlink_Alert_Minor	Not Connected
Global Control Plane Health	CPU Used (%) more than 90% Memory Used (%) more than 90%	Controller, 1 more	15 min		Not Connected
Controller Memory Used (%) Minor	Memory Used (%) more than 80%	Controller	10 min	Webhook_Interlink_Alert_Minor	Not Connected
Global Memory Swap Surge	Memory Swapped more than 0B Memory Total more than 1.07 GB	All Gateways	15 min	Webhook_Interlink_Alert_Minor	Not Connected
Copilot Memory Used (%) Minor	Memory Used (%) more than 80%	CoPilot	10 min	Webhook_Interlink_Alert_Minor	Not Connected
Gateways Memory Used (%) Minor	Memory Used (%) more than 80%	All Gateways	10 min	Webhook_Interlink_Alert_Minor	Not Connected

Adding Alert Rules: To add new alert rules, copy a table row above and modify the Name, Condition, Monitored Entities, Evaluation Period, and Recipients. Alert rules correspond to Grafana alert rule configurations. This table mirrors the actual Grafana Alert Configuration view.

Integration Endpoints

Configure dashboard and ticket integration URLs

Grafana Dashboard URL

Main Aviatrix monitoring dashboard

Grafana Alerting URL

Alert rules management page

Grafana API Key

Grafana service account token with Viewer role (for alert status polling)

ServiceNow Instance URL

ServiceNow instance for ticket creation

ServiceNow Webhook Endpoint

Webhook endpoint for automated ticket creation from Grafana alerts

Aviatrix CoPilot URL

Aviatrix CoPilot for gateway and topology management

PagerDuty / On-Call URL

On-call escalation endpoint (optional)

Grafana Dashboards

Centralized monitoring dashboards tracking infrastructure health across all 3 CSPs and 9 regions. Alert rules defined per metric with configurable thresholds.

ALT

Alert Generation

When a Grafana alert threshold is met, an alert fires and triggers the notification pipeline. 300+ alert rules covering gateway health, tunnel status, BGP sessions, and circuit utilization.

ServiceNow Integration

Grafana alerts automatically create ServiceNow tickets via webhook integration. Tickets include alert context, affected component, and recommended remediation steps.

Environment Certification

Test your knowledge across Operations, Engineering, Architecture, and Management domains — 80% required to pass

Quick Reference

Acronyms, components, and key concepts

Glossary — Alphabetical

16 entries

Acronym	Definition
AFC	App Fabric Controller. 1 per region per CSP (9 total). Manages E/W Aviatrix Transit GWs and App Spoke GWs.
BGPoLAN	BGP over LAN. Overlay protocol used on ESG LAN interfaces to exchange routes with colo switches.
CSP	Cloud Service Provider (AWS, Azure, GCP).
DC	Direct Connect. AWS's dedicated circuit service.
DXGW	Direct Connect Gateway. AWS construct that connects VPG to Direct Connect circuits.
E/W	East/West. Traffic flowing between workloads within or across regions of the same CSP.
ER	ExpressRoute. Azure's dedicated circuit service.
ESG	Edge Spoke Gateway. Physical Aviatrix appliance in colocation facilities. 25G WAN + 25G LAN.
GWLB	Gateway Load Balancer. AWS-specific LB used in the 1-arm firewall design.
HE	Hybrid Edge. The connectivity path from cloud to on-premises via colocations.
IC	Interconnect. GCP's dedicated circuit service (Interconnect Direct).
ILB	Internal Load Balancer. Used by Azure and GCP in the 1-arm firewall design.
MTT	Multi-Tenant Transit. Gateways that enable cross-CSP routing via Aviatrix TGW Attachments in Central regions.
NGCN	The centralized network account/subscription/project in each CSP. Hosts E/W Transit GWs, HE Transit GWs, and firewall infrastructure.
TGW	Transit Gateway. Aviatrix construct that aggregates and routes traffic between spokes.
VPG	Virtual Private Gateway. AWS construct in the underlay path between HE Aviatrix TGW and DXGW.

CTL

Controller Summary

9 App Fabric Controllers — 1 per region per CSP. Manage E/W TGWs + App Spoke GWs.
1 Hybrid Edge Controller — Manages all HE TGWs, MTT GWs, and Edge Spoke GWs.

MTT

Cross-CSP Connectivity

MTT Gateways in each CSP's Central region connect to each other via Aviatrix Transit GW Attachments. Full mesh: AWS ↔ Azure ↔ GCP ↔ AWS. All managed by the Hybrid Edge Controller.

ESG

Edge Spoke GW Facts

Physical Aviatrix appliances. 4 per CSP per colo = 12 per colo = 24 total. 25G WAN (underlay to cloud) + 25G LAN (BGPoLAN to on-prem). 2×100G circuits per CSP per colo.

AWS Underlay Path

HE Aviatrix TGW → VPG → DXGW → Direct Connect → On-Prem Router. NGCN team owns HE TGW + VPG. On-prem team owns DXGW onward.

Azure Underlay Path

HE Aviatrix TGW → ER Gateway → ExpressRoute Circuit → ExpressRoute Direct → On-Prem Router. NGCN team owns HE TGW + ER GW. On-prem team owns circuit onward.

GCP Underlay Path

HE Aviatrix TGW → Cloud Router → VLAN Attachment → Interconnect Direct → On-Prem Router. NGCN team owns HE TGW + Cloud Router. On-prem team owns VLAN Attachment onward.

Hybrid Edge — Underlay & BGPoLAN

Operational verification of underlay paths and BGPoLAN neighbor status via CoPilot and CSP consoles

1 Concept Overview

The Hybrid Edge path connects cloud workloads to on-premises networks via physical colocation facilities. The full chain is:

E/W Aviatrix Transit GW → HE Aviatrix Transit GW → CSP underlay → Edge Spoke GW (physical, in colo) → BGPoLAN → colo switches → on-prem

Edge Spoke GWs (ESGs) are physical appliances — they are not cloud-based VMs. They sit in Equinix (Chicago) and Cologix (Minneapolis) colocation facilities.

Three CSP Underlay Paths:

AWS → VPG → DXGW → Direct Connect

Azure → ER Gateway → ER Circuit → ExpressRoute Direct

GCP → Cloud Router → VLAN Attachment → Interconnect Direct

2 Where to Click — CoPilot Navigation

CoPilot›Cloud Fabric›Hybrid Edge›Edge Gateways›select ESG

View individual Edge Spoke GW status, including WAN/LAN interface state (Up/Down), BGP neighbor count, and route table.

CoPilot›Diagnostics›Gateway Routes›filter by HE Aviatrix Transit GW

View routing table of the HE Aviatrix Transit GW. Verify on-prem prefixes (10.x.x.x/16) are learned, and cloud prefixes (6.x.x.x/8) are present.

CoPilot›Diagnostics›Cloud Routes

Verify prefix propagation across the fabric. Ensure on-prem routes are present in the expected cloud regions.

CoPilot›Cloud Fabric›Hybrid Edge›BGPoLAN tab

Check BGP neighbor status between ESG LAN interfaces and colo switches. Expect Established state.

3 Where to Click — CSP Underlay (High Level)

AWS:

Console → VPC → Virtual Private Gateways — verify VPG is attached and active
Console → Direct Connect → Connections — verify connection state is available

Azure:

Portal → ExpressRoute circuits — verify circuit provisioning state and peering status
Portal → Virtual network gateways — verify ER Gateway is active and routes are learned

GCP:

Console → Hybrid Connectivity → Interconnect — verify attachment operational status
Console → Hybrid Connectivity → Cloud Routers — check BGP session status

4 What to Look For

BGP neighbor state: Established vs Down

Learned prefixes: cloud routes (6.x.x.x/8), on-prem routes (10.x.x.x/16)

Next hop pointing to correct ESG or HE Aviatrix Transit GW

Route count matching expected on-prem networks (10.10.0.0/16, 10.20.0.0/16, 10.30.0.0/16)

ESG WAN interface status: Up/Down (underlay to cloud)

ESG LAN interface status: Up/Down (overlay/BGPoLAN to colo switches)

Overlay Routes — CoPilot Gateway Views

Verify route presence and correctness via CoPilot Diagnostics: Gateway Routes and Cloud Routes

1 Concept Overview

All workload routing in this architecture is via the Aviatrix overlay fabric. There is no native TGW or VWAN used for routing — all routes are managed through Aviatrix transit gateways and spoke gateways.

Gateway Routes shows the per-gateway routing table: what each individual E/W Aviatrix Transit GW, HE Aviatrix Transit GW, or Edge Spoke GW knows about reachable prefixes.

Cloud Routes shows the aggregate view: all routes visible within a given VPC/VNet/VPC project, including which gateway provides the next hop.

Key IP Ranges: Cloud workloads use 6.0.0.0/8 (6.x.x.x) internally. On-prem uses RFC1918 ranges: 10.10.0.0/16, 10.20.0.0/16, 10.30.0.0/16.

2 Where to Click — CoPilot Gateway Routes

CoPilot›Diagnostics›Gateway Routes

Opens the per-gateway routing table view.

Select gateway type: E/W Aviatrix Transit GW, HE Aviatrix Transit GW, or Edge Spoke GW
Filter by prefix (e.g., 10.10.0.0/16) to narrow results
Key columns: Destination, Next Hop, Gateway, Metric/Preference, AS-Path, Status

3 Where to Click — Cloud Routes

CoPilot›Diagnostics›Cloud Routes

Aggregate route view across the fabric.

Filter by VPC/VNet/VPC to see all routes in a given network
Verify that on-prem prefixes (10.x.x.x/16) are present in cloud gateways
Verify that cloud prefixes (6.x.x.x/8) are propagated toward on-prem direction

4 What to Look For

6.x.x.x/8 routes present in HE Aviatrix Transit GW and ESG route tables

10.x.x.x/16 routes learned from on-prem via BGPoLAN on ESGs

Next hop for on-prem prefixes points to correct colo ESG

No missing routes compared to expected prefix list

AS-path length matches expected prepend (2x for active colo, 5x for backup)

CoPilot Gateway Routes — he-aws-east-1

Destination	Next Hop	Gateway	Metric	AS-Path	Status
10.10.0.0/16	192.168.1.1	edge-aws-equinix-1	200	65000 65000	Active
10.10.0.0/16	192.168.2.1	edge-aws-cologix-1	200	65000 65000 65000 65000 65000	Backup
6.10.0.0/16	10.100.1.1	ew-aws-east-1	100	—	Active
10.20.0.0/16	192.168.3.1	edge-aws-equinix-2	200	65000 65000	Active

Reading this table: The first row shows 10.10.0.0/16 learned via Equinix (AS-path length 2) — this is the active path. The second row shows the same prefix via Cologix (AS-path length 5) as backup. The third row shows cloud prefix 6.10.0.0/16 learned from the local E/W Aviatrix Transit GW with no AS-path (directly connected overlay route).

Traffic Steering — AS-Path & Colos

Primary/secondary colo selection via BGP AS-path prepend — no PBR, exclusively BGP path selection

1 Concept Overview

Each CSP has a primary and secondary colocation for on-prem connectivity. Traffic steering is achieved exclusively via BGP AS-path prepend — NOT policy-based routing (PBR).

Active colo: Shorter AS-path — 2x prepend (e.g., AS65000 AS65000)
Non-active colo: Longer AS-path — 5x prepend (e.g., AS65000 AS65000 AS65000 AS65000 AS65000)

BGP will always prefer the path with the shorter AS-path. If the primary colo withdraws its route, traffic automatically fails over to the secondary colo.

2 Colo Preference Table

CSP	Primary Colo	Primary Prepend	Secondary Colo	Secondary Prepend
AWS	Equinix (Chicago)	2x	Cologix (Minneapolis)	5x
Azure	Cologix (Minneapolis)	2x	Equinix (Chicago)	5x
GCP	Cologix (Minneapolis)	2x	Equinix (Chicago)	5x

3 AS-Path Teaching Widget

4 Troubleshooting: Wrong Colo Active

If traffic is taking a non-preferred colo path, follow this workflow:

Open CoPilot›Diagnostics›Gateway Routes for the relevant HE Aviatrix Transit GW

Filter by the on-prem prefix (e.g., 10.10.0.0/16)

Compare AS-path lengths from both colos. The active route should have the shorter AS-path (2x prepend). If both show 5x, the primary colo’s ESG may be down.

If the non-preferred colo has the shorter path, check if the preferred colo’s ESG is down or if the route has been withdrawn. Navigate to CoPilot›Cloud Fabric›Hybrid Edge›Edge Gateways and verify the ESG’s WAN/LAN status.