Azure Route Server

Prerequisites

Use authorized Microsoft Azure and F5 Distributed Cloud (XC) access, marketplace image terms, and the MCN Terraform prerequisites. Allow tens of minutes for registration and potentially hours for a version-installation investigation. The current source pins f5-sales-demo/xcsh v11.0.2 and immutable api-specs-enriched v8.0.0. It intentionally does not claim current Azure Route Server convergence: the contract has no schema-valid writable eBGP-multihop control. Retain the dates below when presenting Azure observations.

Deploy the marketplace shape

The ce-node module selects the fixed certified tuple f5-networks:f5xc_customer_edge:f5xc-ce-crt-20260201:20260201.0178.1, with the matching Marketplace plan. Terraform first reads and then idempotently writes accepted = true for exactly f5-networks/offers/f5xc_customer_edge/plans/f5xc-ce-crt-20260201 through AzAPI 2.12.0; Azure foundation resources transitively depend on that agreement. Operators must not accept terms in the portal or CLI, import an agreement, edit state, taint resources, or substitute an arbitrary offer. The module attaches three network interface cards (NICs), enables IP forwarding, disables accelerated networking, and enables boot diagnostics.

Attachment order	MCN cloud role	Address and XC interpretation
First	mgmt	Static private address and public IP; explicit eth0 Site Local Outside (SLO), also the BGP source. This is not a separate management network.
Second	external	Dynamic private address; inspect the realized Site Local Inside (SLI) assignment.
Third	internal	Dynamic private address; inspect the realized SLI assignment.

Do not infer host addresses solely from cloud NIC order. On the observed appliance builds, SLO appears on vhost0, and the internal address can appear on different guest interfaces. Read the interface model and refresh ce_sli_private_ips after replacement. The source reference contains the authoritative ce-node, xc-site, and azure-hub modules.

Route Server and BGP: current stop condition

Azure Route Server requires a dedicated RouteServerSubnet. Do not associate a network security group (NSG) or user-defined route (UDR) table with that subnet. Peer every network virtual appliance with both Route Server service addresses and advertise the same routes to each. Configure multihop external Border Gateway Protocol (BGP); the service endpoints are not a directly attached neighbor pair. See Microsoft’s Route Server guidance.

MCN retains the topology code and observations, but does not permit its Route Server BGP path to apply. enable_bgp defaults to false. Setting it to true requires the immutable azure_route_server_ebgp_multihop capability and fails during planning, before Terraform, Azure, or F5 mutation, with enforcement reject_before_mutation and reason no_schema_valid_ebgp_multihop_request_control.

Do not add multihop, time-to-live, target_service, or family_inet_v6 inputs to work around this boundary. A future release must supply the precise request schema, field path, value semantics, validation, and live acceptance before this path can be enabled.

Register in phases

1. Leave enable_bgp = false while the multihop capability is unavailable.
2. Treat a plan with enable_bgp = true as the authoritative pre-mutation rejection check, not as a bootstrap or apply request.
3. Preserve existing sanitized Azure observations; do not rerun the blocked deployment.

Current Azure bootstrap uses the tenant-scoped xcsh_token.ce and Azure-specific cloud-init/ce-node.yaml. It does not implement AWS’s site-bound JWT flow. Keep this limitation visible when adapting the general lifecycle. Do not add a dependency to the plan-time registration lookup that makes approval count unknown.

Preserve replacement and version behavior

Changes to Azure VM custom_data replace the VM. MCN’s site lifecycle follows the VM instance identity, retiring stale site registrations before replacement registration can converge. A replacement also changes SSH host keys and can reassign dynamic SLI addresses. Refresh connection information instead of reusing a prior address.

Observed 2026-07-29: the tested software/operating-system pair failed on the marketplace image’s 31 GiB disk and installed at tested sizes from 33 GB upward. The module defaults to 64 GB and rejects values below 40 GB. Those results are not a universal disk minimum. Observed 2026-08-03: a clean rebuild with empty version selectors installed the then-advertised versions and reached ONLINE on all three nodes with a clean plan.

Marketplace latest selects the image at creation; empty XC version selectors select the then-advertised installation target. Editing create-time selectors is not an upgrade action. Provider v8 now exposes upgrade actions, but the final three-site upgrade acceptance was AWS. Keep Azure’s dated version and disk evidence separate.

Verify

Do not perform Route Server BGP, learned-route, VIP-traffic, failover, replacement, or upgrade acceptance while the multihop gate is unavailable. Keep the VIP outside the configured virtual-network ranges as required by the MCN guards for future supported validation.

Observed 2026-08-08: the guide records Azure route and HTTP verification. That proves the dated path, not node-failure timing, even distribution across next hops, or v8 from-zero acceptance. Finish current operations with live routing/traffic checks and a refresh-enabled no-change plan; label new results with their date and artifact identity.

Clean up

Review the stack’s destroy plan and follow Deploy cleanup. The shared app namespace is read rather than managed. Preserve unrelated Azure resources and remove private bootstrap artifacts according to the backend’s retention policy.