Present the demo

The claim this demo supports is narrow and worth stating precisely, because a wider one will not survive questions:

Customer Edges in Azure, AWS, and On-Premise KVM advertise the same host route by eBGP (or load balance via Azure ILB), and the native routing fabric installs all of them as equal-cost next hops. Traffic distribution and node removal are therefore properties of the routing fabric — there is no cloud load balancer required in front of the CEs for BGP/ECMP topologies.

Run the four health checks first. Everything below assumes they passed.

The one command that makes it visible

Effective routes are the strongest single artefact: they are what Azure actually programmed, not what the CEs claim.

cd terraform
az network nic show-effective-route-table \
  -g "$(terraform output -raw resource_group_name)" \
  -n "$(terraform output -raw client_nic_name)" \
  --query "value[?addressPrefix[0]=='$(terraform output -raw vip)/32'].{prefix:addressPrefix[0],nh:nextHopIpAddress,state:state}" \
  -o json

Observed 2026-08-08 on live deployment:

[
  {
    "addressPrefix": [
      "10.250.0.10/32"
    ],
    "nextHopIpAddress": [
      "10.0.1.4",
      "10.0.1.5",
      "10.0.1.6"
    ],
    "nextHopType": "VirtualNetworkGateway",
    "state": "Active"
  }
]

One prefix, three next hops, Active. That is the whole point of the demo in a single output, and it is worth pausing on: nothing in the picture is a load balancer.

Then show it serving, from inside the VNet and with the Host header:

az vm run-command invoke \
  -g "$(terraform output -raw resource_group_name)" \
  -n "$(terraform output -raw client_vm_name)" \
  --command-id RunShellScript --query "value[0].message" -o tsv \
  --scripts "curl -s -o /dev/null -w '%{http_code}\n' \
               -H 'Host: $(terraform output -raw lb_domain)' \
               http://$(terraform output -raw vip)/"

Do not demo it by typing the address into a browser

The load balancer matches on Host, so a bare-IP request returns 404 — on a completely healthy deployment. Either send the header, or resolve the domain to the VIP first. A 404 in front of an audience is hard to walk back from even though nothing is wrong.

Suggested order

1. Frame the 4-path hybrid architecture. One VIP per regional path, several CEs, and no cloud load balancer needed for BGP/ECMP:
   • ROW (eastus): Azure Route Server + eBGP/ECMP (f5-sales-demo.com)
   • Canada (canadacentral): Canadian Regional Edge Virtual Site (f5-sales-demo.ca) supporting Azure Route Server (eBGP/ECMP) or Azure Internal Load Balancer (enable_canada_ilb)
   • AWS (us-east-2): AWS VPC + EC2 CEs (m5.2xlarge) (aws.mcn-ce-ha.f5-sales-demo.com)
   • On-Premise KVM: Local libvirt bridge + FRR ToR BGP router (10.100.0.1, ASN 65515, maximum-paths 4)
2. Show the advertisement side. Loop the peerings (check 2) — each CE advertising the same prefix with its own next hop, all with the same AS path, so none is preferred.
3. Show what Azure, AWS, and FRR did with it.
   • In Azure: Effective route table showing one prefix with $N$ next hops (type: VirtualNetworkGateway).
   • In On-Premise FRR: vtysh -c "show ip bgp 10.100.0.10/32" showing multiple *= multipath entries, and ip route show 10.100.0.10/32 in Linux kernel showing ECMP multipath next hops.
4. Show regional data sovereignty & traffic localization. Demonstrate how xcsh_virtual_site.canada_re uses ves.io/city in (toronto, montreal) to restrict ingress, egress, and TLS decryption for f5-sales-demo.ca strictly within Canadian Regional Edges.
5. Show Canadian ILB Architecture Variation (when enable_canada_ilb = true). Show how Azure Standard ILB (azurerm_lb.ca_ilb) uses HA Ports (protocol = "All") and Health Probes (Tcp/65500) to distribute traffic across Canadian CE management NICs without BGP.
6. Show it serving. The curl commands, sending Host headers for mcn-ce-ha.f5-sales-demo.com, mcn-ce-ha.f5-sales-demo.ca, and aws.mcn-ce-ha.f5-sales-demo.com.
7. Show the configuration. The Terraform is published here, read from the files that deploy it — useful when someone asks whether this is reproducible.

What this demo cannot yet show

Stated here rather than discovered live. All three are absences of evidence, not known failures.

Do not rehearse a failover story from these pages

Failover has not been tested. The equal-cost next hops are verified installed; what happens to the route table when a CE is stopped or stops advertising has not been exercised against this deployment. The intended mechanism is to withdraw one CE’s advertisement and watch the next-hop count drop, but until that has actually been run and measured it is a plan, not a result — so do not promise it, and do not improvise it in front of an audience.

Testing it needs a window when nobody else is using the environment, since it changes live advertisement state. Until then, use the generic routing and failover guide to explain the intended mechanism without presenting it as an observed result from this demo.

• Traffic distribution across the next hops has not been measured. The from-zero UAT sent 160 requests to the VIP, and earlier testing sent 1,470 more. The verify page establishes that the path works and how it behaves over time. None of that shows how requests were spread across the next hops, and this topology gives no per-node HTTP listener to attribute them with. If asked “is it even?”, the honest answer is that it has not been measured here.
• The cause of the fresh-build convergence transient is not established. It is characterised — when it happens, for how long, and that the origin is clean throughout — and not explained.

If you are presenting on a freshly built stack, wait

The VIP loses a small fraction of requests for roughly the first 45 minutes after the CEs reach ONLINE. It clears completely. Build the demo well before you need it, and re-run check 4 immediately beforehand.

Prove it healthyThe four checks, and the normal-looking results that read as an outage and are not.

The TerraformThe configuration itself, for the question about whether this is reproducible.