Keep individual NVA BGP peers when advertising a shared load-balancer next hop

Source facts

In Microsoft’s documented next-hop design, each NVA maintains its own BGP sessions with Route Server. The appliances advertise matching routes with the internal load-balancer frontend as their common next hop; forwarding then uses that shared address.

The next-hop setting belongs in the NVAs’ BGP configuration and needs no special Route Server setting. The load balancer and Route Server must be in the same Azure region. Active-active operation can produce asymmetric traffic paths that the appliances and applications must handle. Microsoft Learn.

Applicability

Separate routing-session addresses, advertised next hop, load-balancer frontend and appliance backend membership in the topology record. Do not collapse them into a single endpoint because data traffic uses a common address.

DSE recommendation

DSE recommends reviewing route exchange and traffic distribution as separate acceptance items. Confirm each intended appliance has the required peer relationship and consistent advertisements, then review the load-balancer probes and rules. Have the appliance owner validate the selected active-passive or active-active design rather than inferring availability from one established peer.

Verification

Inspect each peer’s learned advertisements and the resulting forwarding next hop. In approved tests, verify traffic reaches the intended healthy appliance set and behaves correctly during failure and restoration. For active-active designs, include the agreed asymmetric-path checks. Preserve session, route and traffic evidence separately so a routing success does not conceal a forwarding failure.

Official references

Microsoft Learn: Next hop IP support in Azure Route Server. Source retrieved September 9, 2026.