Border Gateway Protocol (BGP) with Windows Server 2012 R2

Border Gateway Protocol (BGP) with Windows Server 2012 R2

  • Comments 3
  • Likes

This blogs describes in detail the concepts of Border Gateway Protocol (BGP) introduced in What’s New in 2012 R2: Hybrid Networking blog and multi-tenant site-to-site VPN (S2S VPN) blog. In this blog, we’d try to analyze how multi-tenant Border Gateway Protocol (BGP) enables cloud service provider Fabrikam to manage routing between virtual networks of organizations Woodgrove Bank, Contoso Ltd hosted in Fabrikam and their respective on-premises networks.

Let’s look at the below diagram that depicts a deployment with two tenants Woodgrove and Contoso connecting to their respective virtual networks over S2S VPN from their premises. Woodgrove has two sites in New York (NY) and San Francisco (SFO) with internal subnets 10.1.0.0/24 and 10.2.0.0/24 respectively. From both these sites, Woodgrove connects to its virtual network 10.0.0.0/24 in Fabrikam through WS 2012 R2 VM viz., GW-VM via S2S VPN. Contoso connects its internal network 10.1.0.0/24 in New York to its virtual network 10.0.0.0/24 in Fabrikam through same GW-VM via S2S VPN.

clip_image002

If we consider routing between Woodgrove virtual network and its SFO & NY sites, the following routes need to be configured in Woodgrove compartment:

    • On interface IfWi1 10.0.0.0/24
    • On interface IfWe1 10.1.0.0/24
    • On interface IfWe2 10.2.0.0/24

These routes can be added statically by Fabrikam admin or via Windows Azure Pack (WAP) (Windows Azure pack for Windows Server, Windows Azure Pack - White Paper).

Whenever a new subnet say 10.3.0.0/24 is added in NY site, the corresponding new route needs to be added on interface IfWe1 so that packets from Woodgrove virtual network can reach NY site.

With the above specified routes, in case S2S VPN tunnel between NY site and Fabrikam goes down, traffic cannot be sent to NY site. There is a link between NY & SFO sites. So traffic to NY site can be routed over SFO. Which means route 10.1.0.0/24 needs to be added on interface IfWe2. When S2S VPN tunnel between NY & Fabrikam is restored, traffic to NY will be split across two paths viz., directly to NY, via SFO. To restore routing via best path, route 10.1.0.0/24 on IfWe2 needs to be removed after tunnel between SFO and Fabrikam is restored. Adding and removing routes based on tunnel states requires manual intervention and leads to connectivity loss or sub-optimal routing. One way to solve this problem is via route metrics.

The following routes with appropriate route metrics solve the problem in this example

  • On interface IfWe1 :
    • Route 10.1.0.0/24 with metric 100
    • Route 10.2.0.0/24 with metric 200
  • On interface IfWe2
    • Route 10.1.0.0/24 with metric 200
    • Route 10.2.0.0/24 with metric 100

With the above routes, traffic to NY sites is routed over interface IfWe1 since metric of route 10.1.0.0/24 is lower on interface IfWe1. Similarly, traffic to SFO is routed over interface IfWe2 as metric of route 10.2.0.0/24 is lower on interface IfWe2. When the tunnel between NY site and Fabrikam goes down, S2S VPN interface IfWe1 also goes down and traffic to NY site is routed over interface IfWe2 due to route 10.1.0.0/24 with metric 200. If the SFO tunnel is restored, interface IfWe1 come back up along with route 10.1.0.0/24 with metric 100, optimally routing traffic to NY site over interface IfWe1. While static routes with metric works for smaller set of routes sites, the combination of sites/interfaces and metric becomes unmanageable as the number of sites/routes increase.

Clearly, as the number of customers (tenants) and their sites increases, the tasks of managing routes at cloud service provider and ever-changing on premises network routes manually becomes impossible.

Similarly, at the enterprise side, keeping up-to-date route information of all the subnets hosted in the cloud is a challenge in itself. That is where dynamic routing by using multi-tenant capable BGP router eases manageability as well as faster convergence. The following sections illustrate the concepts in detail.

Dynamic Routing with BGP

With a dynamic routing protocol, routes can be exchanged between peers and obviates the need for adding static routes on each node along a path. Considering the scenario described in the above section, let’s examine what role dynamic routing plays in enterprise subnet and virtual networks in service provider communication.

The diagram below shows details of interfaces on edge routers in NY & SFO sites. Interface IfNi1 is connected to subnet 10.1.0.0/24. S2S VPN tunnel is established between interfaces IfFe1 on SFO router to IfWe1 in Woodgrove compartment on multi-tenant gateway GW-VM.

clip_image004

If a routing protocols is running between router in NY & router in Woodgrove compartment of GW-VM, then route 10.0.0.0/24 on interface IfWi1 is propagated to NY routing peer and the routing protocol adds route 10.0.0.0/24 on interface IfFe1. Similarly, route 10.1.0.0/24 is added on interface IfWe1 in Woodgrove compartment on multi-tenant gateway. The only manual configuration required for route exchanges is configuration of information required for operation of routing protocol. Once that is done, routes are learnt dynamically without any need for manual intervention. In the rest of this blog we will examine how one such routing protocol BGP is used for dynamic route learning.

Let’s examine in more detail the interfaces and routes in the above diagram. The router in NY edge has three interfaces of relevance.

    • Interface IfNi1 (with IP address 10.1.0.1) connects to subnet 10.1.0.0/24
    • Interface IfSe1 connects to SFO site over S2S VPN.
    • Interface IfFe1 connects to Woodgrove virtual network 10.0.0.0/24 over S2S VPN.

Similarly router in SFP edge has three interfaces of relevance:

    • Interface IfSi1 (with IP address 10.2.0.1) connects to subnet 10.2.0.0/24
    • Interface IfNe1 connects to NY site over S2S VPN.
    • Interface IfFe2 connects to Woodgrove virtual network 10.0.0.0/24 over S2S VPN.

In Woodgrove compartment on multi-tenant gateway, there are three interfaces

    • Interface IfWi1 (with IP address 10.0.254.249) connects to virtual network 10.0.0.0/24
    • Interface IfWe1 connects to NY site over S2S VPN.
    • Interface IfWe2 connects to SFO site over S2S VPN.

While BGP can be enabled on all the interfaces, in this example we will enable BGP on interface IfWi1 in Woodgrove compartment, interface IfSi1 in SFO site and interface ifNi1 in NY site. BGP uses the concept of Autonomous Systems (AS) and AS numbers (ASN) for routing decisions. For this example let’s assume that each site is identified by a unique ASN in private range (64512 to 65535). The subnet in Fabrikam network is identified by ASN# 65412. NY & SFO sites are assigned ASNs 65413 & 65414 respectively.

The below cmdlet enables BGP in Woodgrove compartment with ASN 65412 and IPv4 address of interface IfWi1 as BGP Identifier:

# Add a BGP Router for Woodgrove Tenant on the Cloud Service provider Gateway

Add-BgpRouter   –RoutingDomain “Woodgrove”  –BgpIdentifier 10.0.254.249”  –LocalASN “65412”

 

Next step is to enable BGP peering for NY & SFO sites.

# Add a BGP Peer for New York site of Woodgrove tenant

Add-BgpPeer –RoutingDomain “Woodgrove”  –Name NY”  –LocalIPAddress “10.0.254.249” PeerIPAddress “10.1.0.1” –PeerASN “65413”  LocalASN “65412”  OperationMode Mixed  PeeringMode Automatic

# Add a BGP Peer for SFO site of Woodgrove tenant

Add-BgpPeer –RoutingDomain “Woodgrove”  –Name SFO–LocalIPAddress “10.0.254.249” PeerIPAddress “10.2.0.1” –PeerASN “65414” LocalASN “65412” OperationMode Mixed  PeeringMode Automatic

 

With the above cmdlets, BGP running in Woodgrove compartment uses local IP address 10.0.254.249 and ASN 65412 to peer with BGP in NY and SFO sites site with IP 10.1.0.1, ASN 65413 and IP 10.2.0.1, ASN 65414 respectively. With this configuration BGP operates in a mode where it can initiate connections to peers as well as receive connections from peers automatically (*this is the default mode of operation for Windows BGP Router).

After similar configuration on edge devices in NY & SFO sites of Woodgrove (see BGP Routing on an enterprise edge gateway section for Windows BGP Router configuration cmdlets), BGP peering configuration is completed.

Note: - The edge devices in NY & SFO sites can be 3rd party routers. In that case, the configuration of these devices will vary from vendor to vendor.

BGP peering to NY site can be established only if S2S VPN connection IfWe1 is connected. To trigger S2S VPN connections IfWe1, host specific route of remote BGP peer is added on S2S VPN interface IfWe1 with the following cmdlet.

# Add a BGP triggering route in the VPN S2S Interface for Woodgrove tenant

Set-VpnS2SInterface –Name IfWe1 -IPv4Subnet 10.1.0.1/32:100

Set-VpnS2SInterface –Name IfWe2 -IPv4Subnet 10.2.0.1/32:100

 

 

When BGP in Woodgrove compartment tries to establish peering with 10.1.0.1 in NY site, S2S VPN interface IfWe1 is dialed. Once S2S VPN interface ifWe1 is connected, BGP packets are tunneled and peering with BGP on NY edge gateway is established. Similarly BGP peering with edge gateway in SFO is established over S2S VPN interface IfWe2.

After peering is established, to enable advertisement of route 10.0.0.0/24 in Woodgrove compartment, the following cmdlet is executed.

# Configure BGP Router for Woodgrove tenant with the custom routes

Add-BgpCustomRoute  –RoutingDomain “Woodgrove” Interface IfWe1

With the above cmdlet, all the routes on interface IfWe1 are advertised to BGP peers with ASN 65412. After similar BGP configuration on edge devices in NY & SFO, advertisements for routes 10.1.0.0/24 & 10.2.0.0/24 are received by BGP in Woodgrove compartment.

Let’s examine in detail the contents of route advertisements received by BGP running in Woodgrove compartment and understand how the routes are added on S2S interfaces.

In the advertisement from NY site, BGP running in Woodgrove compartments receives the following relevant information:

image

Based on this information, BGP running in Woodgrove compartment tries to do a recursive route lookup for 10.1.0.1 and figures out that 10.1.0.1 is reachable via S2S VPN interface IfWe1 based on the route added on S2S interface. It deduces that 10.1.0.0/24 is reachable via S2S VPN interface IfWe1 and adds this route on interface IfWe1. After this route is added, packets in Woodgrove compartment with destination matching 10.1.0.0/24 are routed over interface IfWe1. Similar route updates from BGP peer in SFO results in route 10.2.0.0/24 to be added on S2S interface IfWe2.

Since NY & SFO sites of Woodgrove are connected, it is possible to configure third party BGP routers at NY edge to advertise routes learnt from SFO to the Woodgrove virtual network in Fabrikam. Similarly a 3rd party router at SFO edge can be configured to advertise routes learnt from NY to virtual network in Fabrikam

Let’s examine how BGP running in Woodgrove compartment handles these routes and makes it easy when compared to static route configuration we described in previous section.

BGP in Woodgrove compartment receives the following relevant information in update message from peers in NY & SFO:

image

So for routes 10.1.0.0/24 and 10.2.0.0/24, two routes are advertised, one with AS path length 2 and another with AS path length 1. BGP prefers routes with shortest AS path length and hence, routes packets to 10.1.0.0/24 via ASN 65413 (NY site) & to 10.2.0.0/24 via ASN 65414 (SFO site). If the S2S VPN tunnel between NY & Fabrikam goes down, BGP peering is also torn down (after configured time-out) and all the routes learnt from NY are discarded. BGP then re-compute the best path for 10.1.0.0/24 and 10.2.0.0/24. It finds that the best path for 10.2.0.0/24 has not changed and retains the route via SFO. It finds that the old path to 10.1.0.0/24 via NY no longer exists and determines the new best path to 10.1.0.0/24 is via SFO and adds route 10.1.0.0/24 on S2S VPN interface IfWe2 so that packets are routed to NY via SFO. Note that re-routing is taken care by BGP without any manual intervention and happens in a matter of seconds.

BGP Routing for multiple tenants with Windows Server 2012 R2

The above section explained the routing details of tenant Woodgrove on a Multi-Tenant Service provider’s edge gateway. Windows Server 2012 R2 (WS 2012 R2) can be deployed for routing of traffic of multiple tenants with overlapping IP addresses. In our example the Fabrikam edge gateway is configured with two tenants Contoso & Woodgrove with overlapping IP address space. Both the tenants can enable BGP Routing with overlapping ASNs and Prefixes. Isolation of Routing information is maintained by storing routes using Windows Route Table Manager v2 (RTMv2). Previous version of RTM had the concept of RTM Instances, which was restricted to only one instance, but RTMv2 removed that restriction and enabled the use of more than one RTM instances. This has enabled the configuration of multiple virtual BGP Routers (one per Routing Domain).

To enable, and configure BGP Routing for tenant Contoso, the cmdlets will remain the same with the value of RoutingDomain parameter now changed to “Contoso” and the BgpIdentifier as the IPv4 address of IfCi1 and similarly, the values for other parameters can be substituted.

BGP Routing on an enterprise edge gateway

The scenario outlined above assumes that the enterprise Woodgrove is deploying third party BGP Routing device at the edge gateway to communicate and exchange routing information with the service provider edge gateway. However, the inbox Windows BGP Router (enabled with Windows RRAS Server) can also be configured on the non-Multitenant enterprise edge gateway and can be configured in a similar way (however, eBGP Transit routing capability is yet not available in Windows 2012 R2 BGP router). The following set of cmdlets illustrate how the Windows BGP Router is configured on Contoso enterprise’s edge gateway to setup peering with the service provider -

# Add a BGP Router at the edge gateway of Contoso enterprise

Add-BgpRouter  –BgpIdentifier  10.3.0.1 –LocalASN 65413

# Add a BGP Peer for Service Provider’s edge gateway BGP Router

Add-BgpPeer  –Name ServiceProvider –LocalIPAddress 10.3.0.1 -PeerIPAddress 10.0.254.249 –PeerASN 65412 -LocalASN 65413 -OperationMode Mixed  -PeeringMode Automatic

BGP Routing over S2S VPN interface

As discussed throughout the scenario outlined above, the primary focus of the Windows BGP Router is to enable Hybrid Cloud networking scenarios for enterprises and Service Providers. Although Windows BGP Router can be used without S2S VPN connectivity as well, but in such cases, the administrators will have to take care to introduce BGP sessions only on secure channels, as Windows BGP Router does not include TCP MD5 authentication between peers.

Windows S2S VPN and BGP complement each other – BGP triggers the corresponding S2S VPN session when peering is started and IPsec protection of the S2S VPN tunnel provides the required security to the BGP sessions. The details of how BGP routing is configured and BGP session is established over the S2S VPN interface has already been discussed above.

Windows Server 2012 R2 - Supported deployment topologies

Listed below are some scenarios where the enterprise sites are connected to Service provider datacenter via S2S VPN and are using BGP Routing protocol for dynamic routing information exchange.

The Service provider has deployed a Windows Server 2012 R2 multi-tenant gateway at the edge, which is capable of handling multiple customer connections. This edge gateway is configured with multi-tenant BGP Router to exchange enterprise and cloud subnet routes.

Scenario 1 - Windows Server 2012 R2 deployed at Enterprise site edge

clip_image006

Above topology illustrates the deployment where a customer site is connecting to a cloud service provider via Windows 2012 R2 gateway (behind the edge firewall device), which terminates the S2S VPN and BGP connections.

  • These two sites are connecting via eBGP, which requires that these two sides have distinct Autonomous System Numbers (ASN), a parameter integral to the protocol.
  • The customer site edge device learns the virtualized subnet routes (10.2.1.0/24) hosted in the cloud via BGP. It also advertises the on-premises subnet routes (10.1.1.0/24) to the service provider S2S gateway.
  • The customer edge router learns on-premises internal routes through one of the following mechanisms:
    1. The edge device runs BGP with an internal router and learns internal routes (in this case, 10.1.1.0/24), or
    2. The edge device can be configured with static routes or Interfaces to pick routes for advertisement via BGP.

In the former case, the internal router learns external routes (10.2.1.0/24) from the edge device, and it must distribute these routes to other on-premises routers using an IGP. In the latter case, the edge device itself must distribute the external routes to other on-premises routers using the IGP it runs.

Scenario 2 - 3rd party edge device deployed at Enterprise site

clip_image008

Above topology illustrates the deployment where a customer site is connecting to a cloud service provider through a 3rd party edge, which also serves as a S2S gateway.

  • The customer edge router learns on-premises internal routes through one of the following mechanisms:
    1. The edge device runs BGP with an internal router and learns internal routes (in this case, 10.1.1.0/24), or
    2. The edge device implements an Interior Gateway Protocol (IGP) such as OSPF, IS-IS, EIGRP, RIP, etc., and participates directly in internal routing.

Scenario 3 - Multiple Enterprise sites connecting to service provider cloud

clip_image010

Above topology illustrates the deployment where multiple customer sites are connecting to the cloud service provider via 3rd party edge devices, which also serves as a S2S gateway and BGP router.

  • The customer edge routers learns on-premises internal routes through one of the following mechanisms:
    1. The edge device runs BGP with an internal router and learns internal routes (in this case, 10.1.1.0/24), or
    2. The edge device implements an Interior Gateway Protocol (IGP) such as OSPF, IS-IS, EIGRP, RIP, etc., and participates directly in internal routing.
  • Each enterprise site learns the routes from the other site over the direct eBGP connectivity.
  • Each enterprise site learns the hosted network routes directly and via the other enterprise site, but selects the best route based on the cost attached.
  • If connectivity of one of the enterprise sites (Site1) with cloud fails, it starts learning the routes for the hosted network via the other enterprise site (Site2) and the traffic seamlessly transitions from direct Site1 <-> Cloud to Site1 <-> Site2 <-> Cloud.

Note: - Windows BGP router does not support eBGP <-> eBGP transit routing, so above scenario is only supported with enterprise edge deploying 3rd party BGP solutions.

Windows BGP supports iBGP <-> iBGP, iBGP <-> eBGP and eBGP <-> iBGP transit routing.

Scenario 4 - Enterprise edge BGP router and VPN S2S gateway are not co-located, Windows Server 2012 R2 terminates VPN S2S while internal BGP Router (3rd party) terminates BGP

clip_image012

In the above deployment, S2S VPN is terminated on Windows Server 2012 R2 gateway while BGP peering is between internal enterprise router and customer virtual network in cloud service provider. The internal router learns enterprise routes through one of the following mechanisms:

  • BGP
  • Interior Gateway Protocol (IGP) such as OSPF, IS-IS, EIGRP, RIP.
  • Static route configuration

When any IGP is used at the enterprise site, the internal router needs to redistribute IGP routes into BGP and vice-versa for maintaining the subnet reachability between vNet(s) and enterprise subnet(s) (the assumption here is that the 3rd party internal router is capable of redistributing IGP learned routes to BGP peers and vice-versa).

Initially when only the S2S VPN connectivity exists between Windows Server 2012 R2 on the customer premises and service provider edge, the internal router does not have the route to the BGP router on the service provider edge; however, it learns those routes via the Windows BGP router on the on-prem Windows Server 2012 R2 via the iBGP peering. This allows the internal router to establish the eBGP peering with the service provider BGP router. Similarly, the on-prem Windows BGP router learns the customer routes (both on-prem and in cloud/vNet) via the iBGP peering it has with the internal router. This is necessary to help the Windows BGP router in routing the ingress and egress data packets correctly.

Here is a small illustration of the scenario discussed above à the internal router advertises the 10.1.1.0/24 (on-prem) and 10.2.1.0/24 (vNet) subnets to Windows BGP router (on-prem) via iBGP. The routing table at on-prem Windows BGP Router looks like this -

image

When a data packet from hosted vNet lands at the Windows box, it checks the routing table and finds the next routing peer that the data packet needs to go to for the subnet is the “internal router”. It was able to determine the next-hop because of the route update from its iBGP peer as shown above.

In the opposite direction, the data packet originating from premises subnet and destined for the vNet (10.2.1.0/24) will reach the internal router (via S2S VPN tunnel), which forwards the packet to the on-prem Windows box. Thereafter, because of the route update it had received from iBGP peer (as shown above), it can forward the data packet to the edge gateway (10.2.1.1).

Windows Server 2012 R2 - BGP capabilities

The above section gives an overview of the type of deployments supported by Windows BGP Router. These deployments however require the support of various BGP capabilities to work effectively. Following section lists all such capabilities that are presently supported in Windows BGP Router –

Internal BGP / External BGP support – Both iBGP and eBGP peering session supports are available. To configure either, the administrator has to make sure the appropriate AS Numbers have been assigned to the local and remote BGP Routers. Scenarios 1-4 employ the eBGP peering whereas scenario 4 uses iBGP peering as well.

Mixed / Passive Peering – Windows BGP Peering sessions can be configured as mixed or passive, i.e. it can act as either both Initiator and responder or as responder to incoming requests. The recommendation is to use the Mixed mode (default mode) for BGP peering unless it is being used for debugging / diagnostic purposes. All of the scenarios above are supposed to have Mixed mode peering to enable automatic restarts in case of failure events.

IPv4 and IPv6 transport peering support – Windows BGP Router supports both IPv4 and IPv6 peering. However, the BGP Identifier has to be configured as the IPv4 address of the BGP Router. The above scenarios can have any of the two peering types (IPV4 / IPv6).

IPv4 / IPv6 unicast route learning and advertisement capability (Multiprotocol NLRI) – Irrespective of the transport, Windows BGP Router is capable of exchanging IPv4 and IPv6 routes if the appropriate capability is announced while establishing the session. To configure IPv6 routing, parameter IPv6Routing has to be enabled and Local Global IPv6 address has to be configured at the router level.

Transit routing support – Windows BGP Router supports iBGP <-> iBGP and iBGP <-> eBGP transit routing. However, eBGP <-> eBGP transit routing support is not available as of yet. iBGP <-> eBGP transit routing is evident in all of the scenarios discussed in previous section.

Static route configuration support – Custom / static routes or interfaces can be configured on the Windows BGP Router via the available Add-BgpCustomRoute cmdlets. The routes being configured can be the prefixes or the name if the interfaces from which the routes have to be picked. However, only the routes with resolvable next-hops will be plumbed into the BGP routing tables and advertised to peers.

Equal Cost Multi Path Routing support – Windows BGP Router supports ECMP and can have more than one equal cost routes plumbed into the BGP routing table / stack. The decision to select the route for transmitting data packets in such cases is taken randomly in such cases.

Route filtering – Windows BGP router supports filtering ingress or egress route advertisements based on multiple route attributes such as

    • Prefix,
    • ASN-Range,
    • Community,
    • Next-Hop

Route Attribute re-write capability – Following attributes can be added, modified or removed from the ingress / egress route advertisements by using the BGP Routing policies

    • Next-Hop
    • MED
    • Local-Pref
    • Community

HoldTime and IdleHoldTime configuration – Windows BGP Router supports configuration of HoldTimer and IdleHoldTimer values as per the network requirements. It can be dynamically changed to accommodate interoperability with third party devices or to maintain a certain min / max time for reconnect (useful for failovers, route dampening etc.).

Route-Reflector client – Windows BGP Router can act as a Route-Reflector client, however it cannot be used to act as Route-Reflector itself. This is useful in cases where a new BGP Router needs to be introduced in complex topologies using third party BGP Routers deployed in RR mode.

Interoperability with 3rd party solutions – Windows BGP routing solution has been tested for interoperability with most of the major third party BGP routing devices (details in Interoperability with 3rd party solutions section).

Route-Refresh support – Windows BGP Router supports Route-Refresh and advertises this capability on peering by default. It is capable of sending a fresh set of route updates when requested by a peer via route-refresh message.

BGP Statistics (Message counters, Route counters) – Windows BGP Router supports displaying the message and route statistics, if required, by using the Get-BgpStatistics cmdlet.

Interoperability with 3rd party solutions

Windows Server 2012 R2 – BGP Router is based on the latest BGPv4 specifications (please refer Appendix A) and is thus interoperable with most of the commonly deployed BGP devices that conform to those standards.

Following is the list of some of the common vendors and their devices that have been tested for interoperability with Windows BGP Router –

image

Note: - The interoperability testing with the above listed hardware has been performed in Microsoft labs and by University of New Hampshire – Interoperability Lab.

Windows BGP Router configuration

BGP routing support has been newly introduced in Windows Server 2012 R2, and can be configured using the PowerShell cmdlets, which work for both multi-tenant as well as non-multitenant deployments. For the service providers with multi-tenant edge gateway deployment, BGP router can be configured via System Center Virtual Machine Manager as well, as a part of the complete edge gateway configuration as explained later in this section.

Configuration via PowerShell cmdlets

Windows Server 2012 R2 provides a set of PowerShell cmdlets to configure various aspects of BGP Routers. The prerequisite for enabling BGP Routing and its configuration cmdlets is that the system must be configured with RemoteAccess service.

For more information on all the PowerShell cmdlets, cmdlet parameters and their usage, please refer to the BGP Router configuration PowerShell cmdlet documentation on TechNet and Microsoft BGP Router configuration automation script for more information on how to configure BGP Routing using PowerShell cmdlets.

Configuration via SC-VMM

BGP Routing configuration via SC-VMM console is only available for the multi-tenant service provider gateway, and only a very limited set of configuration options are available for BGP Router (Local BGP IP Address and ASN, List of BGP Peer IP Address and ASN values).

Please refer to the sessions by Greg and Charley on “How to design and configure networking in Microsoft VMM” [Part1, Part2] for more information on how to configure BGP Routing on a Multi-tenant gateway using SC-VMM.

References

Following BGP v4 RFCs are supported in the current version of Windows BGP Router –

Ø RFC 4271 - Border Gateway Protocol 4 (BGP-4)

Ø RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

Ø RFC 4760 - Multiprotocol Extensions for BGP-4

Ø RFC 5492 - Capabilities Advertisement with BGP-4

Ø RFC 5004 - Avoid BGP Best Path Transitions from One External to Another

Ø RFC 4760 - Multiprotocol Extensions for BGP-4

Ø RFC 4486 - Sub codes for BGP Cease Notification Message

Ø RFC 2918 - Route Refresh Capability for BGP-4

Ø RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

Ø RFC 1997 - BGP Communities Attribute

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Link to "How to design and configure networking in Microsoft VMM" is not working

  • Thanks for pointing that out. Updated the links now!