Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update scenario-bgp-peering-hub.md #125642

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update scenario-bgp-peering-hub.md #125642

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion articles/virtual-wan/scenario-bgp-peering-hub.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,8 @@ The virtual hub router now also exposes the ability to peer with it, thereby exc

* When configuring BGP peering with the hub, you'll see two IP addresses. Peering with both these addresses is required. Not peering with both addresses can cause routing issues. The same routes must be advertised to both of these addresses. Advertising different routes will cause routing issues.

* The next hop IP address on the routes being advertised from the NVA to the virtual HUB route server has to be the same as the IP address of the NVA, the IP address configured on the BGP peer. Having a different IP address advertised as next hop IS NOT supported for Virtual WAN at the moment.
* The next hop IP address on the routes being advertised from the NVA to the virtual HUB route server has to be the same as the IP address of the NVA, the IP address configured on the BGP peer. Having a different IP address advertised as next hop IS NOT supported for Virtual WAN at the moment. For this reason, you cannot use Azure Firewall as NVA in this scenario, as it does not support BGP peering.

## BGP peering scenarios

This section describes scenarios where BGP peering feature can be utilized to configure routing.
Expand All @@ -86,6 +87,9 @@ Virtual network configuration

* On VNET5, set up a user-defined route (UDR) to point to VNET2 NVA IP.

See [Scenario: Route traffic through an NVA](../virtual-wan/scenario-route-through-nva.md) for more details on static routing scenario.


### Configuration steps with BGP peering

In the previous configuration, the maintenance of the static routes and UDR can become complex if the VNET5 configuration changes frequently. To address this challenge, the BGP peering with a virtual hub feature can be used and the routing configuration must be changed to the following steps:
Expand All @@ -99,6 +103,10 @@ Virtual network configuration

* On VNET5, set up a user-defined route (UDR) to point to VNET2 NVA IP.


As this scenario does not use static routes, you may use BGP peering together with Routing Intent, as [Routing Intent limitations regarding static routes](../virtual-wan/how-to-routing-policies.md#knownlimitations) are not applicable here.


#### Effective routes

The following table shows few entries from Hub 1's effective routes in the defaultRouteTable. Notice that the route for VNET5 (subnet 10.2.1.0/24) and this confirms VNET1 and VNET5 will be able to communicate with each other.
Expand Down