How to Configure Windows Server 2016 BGP Route Reflector

Border Gateway Protocol (BGP) is the routing protocol that underpins the modern internet and is increasingly used within enterprise and cloud environments to enable dynamic routing between networks. In Windows Server 2016, the Remote Access Server role includes a fully functional BGP router implementation. A BGP Route Reflector is a specialised configuration that eliminates the need for a full mesh of internal BGP (iBGP) peers by allowing a central node to reflect routes to other peers within the same Autonomous System (AS).

This tutorial covers how to configure a BGP Route Reflector on Windows Server 2016, enabling scalable iBGP deployments without the administrative overhead of maintaining full-mesh peering between every router in your network.

Understanding BGP Route Reflection

In a standard iBGP deployment, every BGP speaker within an AS must peer with every other BGP speaker — a full mesh topology. This becomes unmanageable as the network grows. A Route Reflector breaks this requirement by acting as a hub: route reflector clients peer only with the Route Reflector, which then reflects learned routes to all other clients. This dramatically reduces the number of peering sessions required.

Prerequisites

You need Windows Server 2016 with the Remote Access role installed, including the BGP feature. The server should be running and accessible on the network. Confirm the role is available:

Get-WindowsFeature -Name RemoteAccess, Routing

If not installed, run:

Install-WindowsFeature RemoteAccess, Routing -IncludeManagementTools

Step 1 — Initialise the BGP Router

First, configure the local BGP router with your AS number and BGP Identifier (typically the loopback or management IP):

Add-BgpRouter `
  -BgpIdentifier "10.0.0.1" `
  -LocalASN 65000 `
  -CompareMEDAcrossASN $true

Verify the router was created:

Get-BgpRouter

Step 2 — Add Route Reflector Clients

In Windows Server 2016, when you add an iBGP peer (same ASN), you can designate it as a Route Reflector client. This effectively makes the current router a Route Reflector for that peer. Add peers with the route reflector client flag:

Add-BgpPeer `
  -Name "Spoke1" `
  -LocalIPAddress "10.0.0.1" `
  -PeerIPAddress "10.0.1.1" `
  -PeerASN 65000 `
  -RouteReflectorClient $true `
  -OperationMode Mixed `
  -PeeringMode Automatic
Add-BgpPeer `
  -Name "Spoke2" `
  -LocalIPAddress "10.0.0.1" `
  -PeerIPAddress "10.0.2.1" `
  -PeerASN 65000 `
  -RouteReflectorClient $true `
  -OperationMode Mixed `
  -PeeringMode Automatic

Repeat this for each spoke router that should be a client of this Route Reflector.

Step 3 — Add Non-Client iBGP Peers

If you have peer routers in the same AS that are not Route Reflector clients (for example, other Route Reflectors), add them as regular iBGP peers without the RouteReflectorClient flag:

Add-BgpPeer `
  -Name "RR2" `
  -LocalIPAddress "10.0.0.1" `
  -PeerIPAddress "10.0.0.2" `
  -PeerASN 65000 `
  -OperationMode Mixed `
  -PeeringMode Automatic

Step 4 — Verify Peering Sessions

Check that all BGP peering sessions are established:

Get-BgpPeer

The ConnectivityStatus for each peer should show Established. If peers remain in Active or Idle state, check firewall rules allow TCP port 179 between the routers.

Step 5 — Inject and Advertise Routes

Add network prefixes to be advertised by the Route Reflector:

Add-BgpCustomRoute -Network "10.100.0.0/16" -PassThru

Verify the routes are being advertised to clients:

Get-BgpRouteInformation -Type All

Step 6 — Apply Route Policies

Control which routes the Route Reflector reflects using BGP route policies. First define a policy:

Add-BgpRoutingPolicy `
  -Name "AcceptAll" `
  -PolicyType ModifyAttribute `
  -MatchPrefix "0.0.0.0/0" `
  -MatchASNRange 1,65535

Apply the policy to a peer:

Add-BgpRoutingPolicyForPeer `
  -PeerName "Spoke1" `
  -PolicyName "AcceptAll" `
  -Direction Ingress

Step 7 — Monitor BGP Route Reflection

Use these commands to monitor the operational state of your Route Reflector:

Get-BgpStatistics
Get-BgpPeer -PeerName "Spoke1" | Select-Object *

Review BGP-related events in Event Viewer under: Applications and Services Logs > Microsoft > Windows > Routing and Remote Access.

Cluster IDs and Route Reflector Groups

When deploying multiple Route Reflectors for redundancy, assign a Cluster ID to prevent routing loops. In Windows Server 2016, the BGP Identifier serves as the Cluster ID. Ensure each Route Reflector has a unique BGP Identifier while sharing the same Cluster ID if they serve the same group of clients. This prevents the same route from being reflected in a loop between the redundant reflectors.

Conclusion

Configuring a BGP Route Reflector on Windows Server 2016 provides a scalable approach to iBGP deployments. By designating a central Route Reflector and marking spoke routers as clients, you eliminate the full-mesh peering requirement and significantly reduce configuration complexity as your network grows. Combined with route policies and redundant reflector pairs, this architecture delivers both flexibility and resilience for enterprise and SDN environments.