{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "slug": "dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop", "url": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/" }, "title": "Keep individual NVA BGP peers when advertising a shared load-balancer next hop", "summary": "A common forwarding address does not replace each appliance's routing session with Azure Route Server.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:22:44+00:00", "modified_at": "2026-09-10T02:14:30+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 237, "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.", "primary_source": { "name": "Next hop IP support in Azure Route Server | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

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

", "content_text": "Source facts\nIn 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.\nThe 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.\nApplicability\nSeparate 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.\nDSE recommendation\nDSE 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.\nVerification\nInspect 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.\nOfficial references\nMicrosoft Learn: Next hop IP support in Azure Route Server. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nIn 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.\n\nThe 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).\n\n## Applicability\n\nSeparate 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nInspect 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.\n\n## Official references\n\n[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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "url": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Keep individual NVA BGP peers when advertising a shared load-balancer next hop", "item": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "url": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/", "headline": "Keep individual NVA BGP peers when advertising a shared load-balancer next hop", "description": "A common forwarding address does not replace each appliance's routing session with Azure Route Server.", "abstract": "A common forwarding address does not replace each appliance's routing session with Azure Route Server.", "articleBody": "Source facts\nIn 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.\nThe 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.\nApplicability\nSeparate 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.\nDSE recommendation\nDSE 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.\nVerification\nInspect 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.\nOfficial references\nMicrosoft Learn: Next hop IP support in Azure Route Server. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:22:44+00:00", "dateModified": "2026-09-10T02:14:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-552-keep-individual-nva-bgp-peers-when-advertising-a-shared-load-balancer-next-hop/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep individual NVA BGP peers when advertising a shared load-balancer next hop" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 237, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Next hop IP support in Azure Route Server | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip" } } ] } }