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

> A common forwarding address does not replace each appliance's routing session with Azure Route Server.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:22:44+00:00
- Modified: 2026-09-10T02:14:30+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

A common forwarding address does not replace each appliance's routing session with Azure Route Server.

## Potentially affected

Azure Route Server designs with NVAs behind an internal load balancer.

## DSE recommendation

Document each NVA's BGP session separately from the common forwarding next hop.

## Article

## 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](https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip).

## 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](https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip). Source retrieved September 9, 2026.

## Primary reference

- Name: Next hop IP support in Azure Route Server | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep individual NVA BGP peers when advertising a shared load-balancer next hop,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.