How to Set Up BGP Routing on Windows Server 2025

How to Set Up BGP Routing on Windows Server 2025

Border Gateway Protocol (BGP) is the routing protocol that underpins the global internet, and Windows Server 2025 ships with a capable software BGP implementation built directly into the Routing and Remote Access Service (RRAS). While Windows BGP is not a replacement for enterprise-grade hardware routers in carrier environments, it is a practical and cost-effective choice for small-to-medium organizations, Software-Defined Networking (SDN) deployments, branch office edge routing, and multi-homed servers that need to advertise specific prefixes to upstream providers. This tutorial covers the complete process: installing RRAS in routing-only mode, initializing a BGP router instance, adding peers, inspecting route information, writing routing policies, advertising custom routes, and understanding where Windows BGP fits in modern network architectures.

Prerequisites

• Windows Server 2025 Standard or Datacenter with at least two network adapters (one for each BGP peer path)
• A valid Autonomous System Number (ASN) assigned to your organization, or a private ASN in the range 64512–65534 for lab/internal use
• IP addresses and ASNs for all BGP peers you plan to configure
• Administrator credentials on the server
• Outbound TCP port 179 open on any intervening firewalls between BGP peers
• PowerShell 5.1 or later running as Administrator
• Basic understanding of BGP concepts: ASN, eBGP vs iBGP, route advertisements, and routing policies

Step 1 — Install RRAS in Routing-Only Mode

Windows Server BGP runs inside the Routing and Remote Access Service. You can install RRAS in a routing-only configuration that does not enable VPN or dial-up features, keeping the attack surface minimal. If RRAS is already installed for VPN purposes, skip the installation step and proceed directly to the BGP router initialization.

# Install RRAS with only the routing components (no VPN)
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Install-WindowsFeature RSAT-RemoteAccess-PowerShell

# Initialize RRAS in routing-only mode (no VPN tunnel types)
Install-RemoteAccess -VpnType RoutingOnly

# Verify RRAS is running
Get-Service RemoteAccess | Select-Object Name, Status, StartType

The Install-RemoteAccess -VpnType RoutingOnly command starts the RRAS service in a lean configuration that enables the IP routing engine and BGP subsystem without activating VPN listeners. If you need both VPN and BGP, use -VpnType Vpn instead and configure BGP separately afterward.

Step 2 — Initialize the BGP Router Instance

With RRAS running, create the local BGP router instance. You need your BGP Router ID (typically the IPv4 address of the primary interface) and your local ASN. The Router ID must be unique within your BGP domain and is used to identify this router in BGP OPEN messages.

# Add the local BGP router instance
Add-BgpRouter `
    -BgpIdentifier "192.168.10.1" `
    -LocalASN 65001

# Confirm the router is initialized
Get-BgpRouter

The output of Get-BgpRouter shows the Router ID, local ASN, client-to-client reflection settings, and the number of configured peers. If you are running BGP on a Hyper-V host as part of an SDN topology, the Router ID is typically the host’s management IP address. For iBGP (same ASN peers within your own network), the same Add-BgpRouter command applies — the distinction between iBGP and eBGP is determined by whether the peer’s ASN matches your local ASN.

Step 3 — Add BGP Peers

A BGP peer (also called a BGP neighbor) is a remote router with which this server exchanges routing information. Use Add-BgpPeer for each peer, specifying the peer’s IP address, its ASN, and the local IP address from which the session should originate (important on multi-homed servers).

# Add an eBGP peer (different ASN = external BGP)
Add-BgpPeer `
    -PeerName "ISP-Upstream-1" `
    -PeerIPAddress "203.0.113.1" `
    -PeerASN 64999 `
    -LocalIPAddress "203.0.113.2" `
    -LocalASN 65001

# Add a second peer for redundancy (multi-homed)
Add-BgpPeer `
    -PeerName "ISP-Upstream-2" `
    -PeerIPAddress "198.51.100.1" `
    -PeerASN 64998 `
    -LocalIPAddress "198.51.100.2" `
    -LocalASN 65001

# Add an iBGP peer (same ASN = internal BGP, e.g., another RRAS server in your network)
Add-BgpPeer `
    -PeerName "Internal-Router-2" `
    -PeerIPAddress "192.168.10.2" `
    -PeerASN 65001 `
    -LocalIPAddress "192.168.10.1" `
    -LocalASN 65001

# Check all peer states
Get-BgpPeer | Select-Object PeerName, PeerIPAddress, PeerASN, ConnectivityStatus

The ConnectivityStatus field will show Connected once the TCP session on port 179 is established and the BGP OPEN and KEEPALIVE handshakes complete. If a peer remains in Idle or Connect state, verify firewall rules allow TCP 179 bidirectionally and that the peer’s IP address is reachable via Test-NetConnection -ComputerName 203.0.113.1 -Port 179.

Step 4 — Inspect BGP Route Information

Once peers are established, BGP begins exchanging route advertisements. Use Get-BgpRouteInformation to view routes received from peers.

# View all BGP routes in the routing table
Get-BgpRouteInformation | Format-Table Network, NextHop, Origin, LocalPref, MED -AutoSize

# Filter routes received from a specific peer
Get-BgpRouteInformation -PeerName "ISP-Upstream-1" |
    Select-Object Network, NextHop, Origin, AsPath

# View only best-path routes (routes currently active in the routing table)
Get-BgpRouteInformation -Type Local |
    Format-Table Network, NextHop, LocalPref

The -Type parameter accepts Local (routes originated by this router), Aggregate (summarized routes), and the default which shows all received routes. Use Get-BgpStatistics to see message counts per peer, which is useful for verifying that UPDATE messages are being exchanged:

# View BGP session statistics per peer
Get-BgpStatistics | Format-Table PeerName, UpdatesReceived, UpdatesSent, NotificationsReceived

Step 5 — Configure BGP Routing Policies

BGP routing policies control which routes are accepted from peers, which are advertised, and how attributes like Local Preference and MED are modified. Use Add-BgpRoutingPolicy to create match-and-action policies, then apply them to peer sessions with Add-BgpRoutingPolicyForPeer.

# Create a policy that sets Local Preference to 200 for routes from ISP-1
# (higher Local Pref = preferred path in iBGP)
Add-BgpRoutingPolicy `
    -Name "Prefer-ISP1" `
    -PolicyType ModifyAttribute `
    -MatchASNRange @(64999) `
    -NewLocalPref 200

# Create a policy that sets Local Preference to 100 for routes from ISP-2 (less preferred)
Add-BgpRoutingPolicy `
    -Name "Prefer-ISP2-Lower" `
    -PolicyType ModifyAttribute `
    -MatchASNRange @(64998) `
    -NewLocalPref 100

# Apply the policy as an ingress filter on the ISP-1 peer
Add-BgpRoutingPolicyForPeer `
    -PeerName "ISP-Upstream-1" `
    -PolicyName "Prefer-ISP1" `
    -Direction Ingress

Add-BgpRoutingPolicyForPeer `
    -PeerName "ISP-Upstream-2" `
    -PolicyName "Prefer-ISP2-Lower" `
    -Direction Ingress

# Create a policy filtering outbound advertisements (only advertise your own prefix)
Add-BgpRoutingPolicy `
    -Name "Advertise-Own-Prefix-Only" `
    -PolicyType Filter `
    -MatchPrefix @("203.0.113.0/24")

Add-BgpRoutingPolicyForPeer `
    -PeerName "ISP-Upstream-1" `
    -PolicyName "Advertise-Own-Prefix-Only" `
    -Direction Egress

Step 6 — Advertise Static Routes into BGP

In addition to routes learned dynamically from peers, you can inject static routes into the BGP table using Add-BgpCustomRoute. This is the mechanism for advertising your own IP prefixes to upstream peers.

# Add a static route to the Windows routing table first
New-NetRoute `
    -DestinationPrefix "203.0.113.0/24" `
    -InterfaceAlias "Ethernet" `
    -NextHop "0.0.0.0" `
    -RouteMetric 1

# Inject the static prefix into BGP for advertisement to peers
Add-BgpCustomRoute `
    -Network "203.0.113.0/24"

# Advertise a more specific prefix (used for traffic engineering)
Add-BgpCustomRoute `
    -Network "203.0.113.128/25"

# Verify the custom routes appear in the BGP table
Get-BgpRouteInformation -Type Local | Select-Object Network, Origin

For aggregated route advertisement (summarizing multiple /24s into a /22, for example), use Add-BgpRouteAggregate:

# Aggregate four /24 prefixes into a single /22 advertisement
Add-BgpRouteAggregate `
    -Prefix "203.0.112.0/22" `
    -SummaryOnly $true

Step 7 — Understanding Windows BGP in SDN Contexts

In Windows Server 2025 Software-Defined Networking deployments, BGP plays a key role in the RAS Gateway component. The RAS Gateway acts as a multi-tenant virtual gateway that uses BGP to exchange route information between tenant virtual networks and physical networks. Each tenant gets its own BGP router instance, and the Windows BGP implementation handles route reflection between tenant networks without requiring dedicated hardware.

# In an SDN context: view all BGP routers (one per tenant)
Get-BgpRouter -RoutingDomain All |
    Select-Object RoutingDomain, BgpIdentifier, LocalASN

# View routes for a specific routing domain (tenant)
Get-BgpRouteInformation -RoutingDomain "Tenant-A" |
    Format-Table Network, NextHop, Origin

When comparing Windows RRAS BGP against dedicated routers such as Cisco IOS or Juniper Junos, Windows BGP is appropriate for scenarios where the routing table is small (fewer than 10,000 routes), BGP policy requirements are moderate, and the organization wants to avoid additional hardware licensing costs. For full internet routing table ingestion (900,000+ routes), a hardware router or a dedicated network OS such as VyOS or FRRouting on Linux remains the better choice.

Conclusion

Windows Server 2025’s built-in BGP implementation, delivered through the RRAS framework, provides a fully functional routing solution for organizations that need dynamic path selection, multi-homing, or SDN integration without investing in dedicated routing hardware. In this tutorial, you installed RRAS in routing-only mode, initialized a BGP router with a custom ASN and Router ID, added eBGP and iBGP peers, inspected route information and session statistics, created Local Preference policies to influence path selection, advertised your own prefixes using custom and aggregate routes, and explored how Windows BGP integrates into SDN RAS Gateway deployments. Regular monitoring with Get-BgpStatistics and Get-BgpPeer will keep your routing sessions healthy, and policy-based filtering will ensure that only intended prefixes are accepted and advertised to your upstream providers.