Azure Route Server

Regional routing design

The unified root pins f5-sales-demo/xcsh v15.0.3, built from api-specs-enriched v12.0.0. Azure US has three Customer Edges (CEs), two Terraform-managed FRR routers, and one Azure Route Server. A CE peers directly with both FRRs on the management subnet. Each FRR peers with both Route Server endpoints using eBGP multihop. Route Server peers with the FRRs at management addresses .20 and .21; it does not peer directly with the CEs.

The FRR import and export policy permits only the regional application VIP /32 learned from a CE. Each FRR enables packet forwarding. The expected client route for that VIP has two FRR next hops. The VIP, peers, and route server remain in the Azure US VNet.

The Azure marketplace image is the certified f5-networks:f5xc_customer_edge:f5xc-ce-crt-20260201:20260201.0178.1 tuple. Terraform handles its agreement through AzAPI before creating the hub. It then creates each CE with management/SLO, external, and internal/SLI NICs. The management NIC is the CE BGP source; the internal NIC belongs to the ILB backend. Do not infer an appliance interface name from Azure NIC order: use the provider’s realized interface and registration data.

Two application paths and Site Console

Each regional ILB has an inside-subnet application frontend at .10 and a Site Console frontend at .11. The application rule uses floating IP and the XC load balancer advertises that exact inside VIP on the CE’s specified inside network. This gives the backend a direct server return path. The console rule uses TCP/65500 without floating IP. The ILB backend pool attaches the CE internal NICs. A separate private application domain matches the inside VIP; the existing external application domain and VIP remain the BGP path.

Canadian hosting, Toronto/Montreal public advertisement, and Canada-only GeoIP access control are demonstrated independently by Canada Topology.

Deployment and acceptance

Use the deployment lifecycle from a reviewed commit on merged main. The configured subscription must be passed explicitly to every Azure CLI command because it may differ from the CLI default. The lifecycle uses saved plans bound to the source commit, backend key, provider artifact, action scope, and digest. It applies the AWS and KVM stages first, then the Azure stage, verifies each region, destroys the owned stack, and repeats the build.

For each Azure region, retain sanitized receipts proving:

1. Three registered ONLINE CEs, six direct CE–FRR sessions, and four FRR–Route Server sessions.
2. The regional VIP /32 at both FRRs and two FRR next hops at the client.
3. HTTP origin responses through the external BGP VIP and inside ILB VIP, plus healthy Site Console TCP/65500 reachability.
4. Continuity and expected route withdrawal after stopping one CE and, separately, one FRR; full session and next-hop recovery after starting each VM.

A successful apply does not establish those results. Stop on a failed live gate, fix the source, and repeat a reviewed iteration. The final state requires a refresh-enabled zero-change plan with all showcase paths enabled.

The historical observations dated 2026-08-03 and 2026-08-08 describe an earlier Azure shape. They do not prove this relay and inside-VIP design. The former schema-invalid direct CE multihop gate is no longer part of the deployment.

Cleanup

Review the full destroy plan’s ownership and action scope before applying its exact digest. The app namespace and the shared KVM bridge/uplink remain outside Terraform ownership. Use the saved teardown absence receipt to confirm Azure resource groups and XC sites are gone.

The Canadian regional deployment is maintained independently in Canada Topology.