Compare the Azure application paths
Each Azure region runs three CEs and exposes two independent HTTP application paths.
The external VIP is learned through BGP; the internal ILB frontend is on the CE
inside subnet. Both paths use the region’s own origin pool and require the
matching Host domain.
| Property | BGP VIP | Internal ILB application VIP |
|---|---|---|
| Next hops | Two FRR relays at management addresses .20 and .21 | Three CE internal NICs in the backend pool |
| Route exchange | Each CE peers with both FRRs; each FRR peers with both Route Server endpoints | Azure Standard ILB probes TCP/80 and forwards TCP/80 |
| Advertised address | Regional external application VIP /32 | Inside-subnet frontend .10, configured as the CE specified inside VIP |
| Return path | FRR IP forwarding toward the client | Floating IP with direct server return |
| Domain | Existing regional external application domain | Separate private regional application domain |
| Failure behavior | One CE failure withdraws its route from both FRRs; one FRR failure removes one client next hop | Unhealthy CE inside endpoints leave the backend pool |
The same ILB also has a separate frontend at .11 for Site Console TCP/65500.
Its rule is nonfloating. The console endpoint is a health and management
path, not the application VIP.
Canadian regional access control is demonstrated independently in Canada Topology.
The AWS path has three sites, six Transit Gateway Connect peers, and twelve BGP sessions. The KVM path has one CE with a NAT SLO and physical-LAN SLI; its custom inside VIP serves an independent physical client. Neither uses Azure Route Server or the Azure ILB design.
See Azure Route Server for the relay topology and deployment verification for live acceptance.
Azure clients send the regional BGP VIP to either FRR relay. The relay translates TCP port 80 to an assigned primary address of a CE that still advertises that exact VIP. This avoids Azure dropping packets addressed to an unassigned VIP between FRR and CE. The relay preserves the VIP seen by the client and follows valid CE BGP paths every three seconds; it removes the translation when no valid CE path remains.
The inside ILB sends traffic directly to CE internal NICs. Azure health-probe responses use an exact source and destination policy route through that internal NIC, while management and metadata routing remain unchanged.