BGP Service configuration

Knowledge Base

KB0066889

BGP Service configuration


Icons/System/eye-open Created with Sketch. 202 Views 31.03.2025 BGP Service

Objective

BGP Service allows you to build highly available infrastructures by running standard BGP (Border Gateway Protocol) straight from your OVHcloud hosts. It can be used with OVHcloud Additional IP or with your own IP addresses, by using Bring Your Own IP (BYOIP).

Important: BGP Service is currently in alpha phase. This product is not intended to be used in a production environment.

Requirements

Instructions

Step 1: Join the Alpha

First, you need to request to join the alpha on the following page. After we receive your application, we will contact you by email.

Step 2: Prepare your IP addresses

You need to either buy Additional IP from OVHcloud or use your own IPs with BYOIP.

If you buy Additional IPs from us, you MUST NOT associate them to any service (e.g. Bare Metal).

If you need to import your IPs, you need to use our BYOIP service. Please follow this documentation to import your IPs to OVHcloud.

Step 3: Configure your vRack

You need to have created a vRack, which is the private network where the peering between your servers and the BGP service will take place.

The vRack must contain the servers that will participate in the BGP peering.

Important: the vRack must contain only servers in one given AZ of a region. As during the alpha period, the BGP service is only available on 1-AZ regions, this simply means that the vRack must contain only servers in one given region.

Step 4: Provide configuration parameters of your BGP Service

You need to provide us with the following parameters so that we can configure the BGP service on the OVHcloud side:

ParameterValue (example)DescriptionComment
LocationRBXThe location on which to deliver the service
vRack ID937vRack ID on which the BGP sessions will run
BYOIPYIP prefix coming from the customer
IP prefix198.51.100.0/24The public IP prefix to be used.
Subsets of this prefix may be announced:
• For IPv4, any subset up to /32
• For IPv6, any subset up to /64		Allowed prefix size:
• OVHcloud IP (/24 to /30)
• BYOIP imported prefix (/24 to /30)
• IPv6 (/56)
Private prefix10.0.0.0Reserved prefix for BGP peer IPs
The 4 last addresses will be used by OVHcloud for OVHcloud side BGP peers.		IPv4: Netmask /28
IPv6: Netmask /124
Peering IP 110.0.0.1Customer IP should be explicitly specified by customer (for OVHcloud-side monitoring)
Peering IP 210.0.0.2Customer IP should be explicitly specified by customer (for OVHcloud-side monitoring)
Peering IP 310.0.0.3Customer IP should be explicitly specified by customer (for OVHcloud-side monitoring)
Peering IP 410.0.0.4Customer IP should be explicitly specified by customer (for OVHcloud-side monitoring)

Step 5: BGP Service delivery

We will then contact you back to notify you that the service is ready to use, and give you the following parameters that are needed on your side:

  • OVHcloud Edges IPs (4 IPs)
  • Customer AS and OVHcloud AS to use for the BGP peering sessions
  • BFD parameters

Important: during the alpha phase, we cannot commit on a specific delivery time. Delivery can take up to several weeks.

Step 6: Customer-side setup

You now are able to setup the BGP sessions on your side. Below is a guide that walks you through a typical setup for simple load balancing using BGP ECMP.

Important: OVHcloud is not responsible for the configuration of the BGP daemaon on the customer's hosts. It is the responsability of the customer to configure the BGP daemon on his hosts. We provide example configurations for your consideration.

Use case: Basic BGP Configuration - Load Balancing using BGP ECMP

Here is a simple architecture that allows you to perform load balancing of your traffic on 3 hosts:

BGPaaS Basic Architecture

To achieve this setup, you need to install a BGP daemon, like FRR, on each host, and configure it.

Configuration parameters

The following parameters are to be substituted in your router configuration files with those agreed on with OVHcloud during the configuration and delivery steps.

ParameterDescription
OVHcloud_ASNPrivate ASN used on OVHcloud Edges
CUSTOMER_ASNPrivate ASN given by OVHcloud.
CUSTOMER_PREFIX_V4
CUSTOMER_PREFIX_V6		Public prefixes allocated for IPv4 and IPv6 usages
RS_IPV4
RS_IPV6		Customer RS IP addresses in private/ULA range used for BGP peering and connectivity inside the vRack.
EDGE_IPV4
EDGE_IPV6		OVHcloud Edges IP addresses in private/ULA range used for BGP peering and connectivity inside the customer vRack.
HOST_IPV4
HOST_IPV6		Other Customer Hosts IP addresses in private/ULA range used as BGP Next Hop and peer inside the vRack

Configuring a BGP Daemon (FRR)

To configure the BGP sessions using FRR, follow these next steps.

Step 1: Install FRR

On a Debian-based system, install FRR with:

sudo apt update && sudo apt install frr frr-pythontools

Step 2: Configure FRR

All of the following parameters should be present in the /etc/frr/frr.conf configuration file of the hosts.

Prefix list and Route Map Configuration

The configuration below is a suggested setup to prevent any unexpected announcement between BGP peers.

In the following example:

  • Hosts only accept default routes from OVHcloud Edges.
  • Hosts advertise customer's prefixes to OVHcloud Edges.

Related prefix lists and route maps to filter routes:

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
... <other sequences may be added depending of the customer setup>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
... <other sequences may be added depending of the customer setup>


route-map RM_EDGE_V4_OUT permit 10
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4
route-map RM_EDGE_V4_IN permit 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_EDGE_V6_OUT permit 10
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6
route-map RM_EDGE_V6_IN permit 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
BFD Configuration

The configuration below is a suggested setup to improve BGP convergence time between Host and Edges over vRack.

bfd
 profile edge
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <EDGE_IPV4>
  profile edge
  no shutdown
...
 peer <EDGE_IPV6>
  profile edge
  no shutdown
...
BGP Configuration

Global configuration:

router bgp <CUSTOMER_ASN>
 bgp router-id <HOST_IPV4>
 no bgp default ipv4-unicast
 maximum-paths 16
 maximum-paths ibgp 16

BGP peering with OVHcloud Edge:

router bgp <CUSTOMER_ASN>
 neighbor PG_EDGE_V4 peer-group
 neighbor PG_EDGE_V4 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V4 bfd
 neighbor PG_EDGE_V6 peer-group
 neighbor PG_EDGE_V6 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V6 bfd
 neighbor <EDGE_IPV4> peer-group PG_EDGE_V4
...
 neighbor <EDGE_IPV6> peer-group PG_EDGE_V6
 ...

 address-family ipv4 unicast
  neighbor PG_EDGE_V4 activate
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_IN in
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_EDGE_V6 activate
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_IN in
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_OUT out

Step 3: Restart FRR

After editing the configuration, restart FRR to apply changes:

sudo systemctl restart frr

Step 4: Verify BGP Session

Check the status of your BGP session with:

show protocols all

Step 5: Verify Ingress and Egress Connectivity

To ensure your BGP session is functioning correctly, test both inbound and outbound traffic:

  • Check Ingress Traffic (Incoming)

Use a remote server to ping or traceroute to your advertised IP prefix:

ping YOUR_ADVERTISED_IP
traceroute YOUR_ADVERTISED_IP

Verify that traffic reaches your network via the expected BGP paths.

  • Check Egress Traffic (Outgoing)

From your server, check the routing table and ensure your BGP routes are in use:

ip route show
vtysh -c 'show ip route bgp'

Confirm that outbound traffic is following the correct BGP paths.

Step 6: Verify connectivity with the OVHcloud team

When your setup is done and after conducting basic tests, you should notify us via email at this address: bgp_alpha@ovh.net.

We'll make sure the BGP connectivity and IP announcements are OK from our side.

Use Case: Advanced BGP configuration using Route Servers (RS)

If you want to use more than 4 hosts with BGP Service, you need to deploy and manage a Route Server (RS). The RS must deployed on a dedicated host. An RS peers with Edges and Hosts, establishing two sessions per peer (one for IPv4 and one for IPv6).

Here is an overview of the system:

BGPaaS RS Peering

And here is a detailed view of the BGP sessions between Edges, RS and Hosts:

BGPaaS sessions detail

To achieve this setup, you need to install a BGP daemon, like FRR, on each host, and configure it.

Configuration parameters

The following parameters are to be substituted in your router configuration files with those agreed on with OVHcloud during the configuration and delivery steps.

ParameterDescription
OVHcloud_ASNPrivate ASN used on OVHcloud Edges
CUSTOMER_ASNPrivate ASN given by OVHcloud
CUSTOMER_PREFIX_V4
CUSTOMER_PREFIX_V6		Public prefixes allocated for IPv4 and IPv6 usages
RS_IPV4
RS_IPV6		Customer RS IP addresses in private/ULA range used for BGP peering and connectivity inside the vRack
EDGE_IPV4
EDGE_IPV6		OVHcloud Edges IP addresses in private/ULA range used for BGP peering and connectivity inside the customer vRack
HOST_IPV4
HOST_IPV6		Other Customer Hosts IP addresses in private/ULA range used as BGP Next Hop and peer inside the vRack

Configuring a BGP Daemon (FRR)

To configure the BGP sessions using FRR, follow the steps below.

Step 1: Install FRR

On a Debian-based system, install FRR with:

sudo apt update && sudo apt install frr frr-pythontools

Step 2: Configure FRR

FRR configuration for Route Servers

All of the following parameters should be present in the /etc/frr/frr.conf configuration file of the route server(s).

Prefix list and Route Map Configuration

The configuration below is a suggested setup to prevent any unexpected announcement between BGP peers.

Route Servers accept default routes from LBEdges and all routes from Hosts if they match the defined prefix length (cf. OVHcloud rules for IPv4 and IPv6 prefix length). Route Servers advertise Hosts routes to LBEdges and Default routes to Hosts.

Related prefix lists and route maps to filter routes:

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
<other sequences may be added depending of the customer setup>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
<other sequences may be added depending of the customer setup>


route-map RM_EDGE_V4_OUT deny 10
 match ip address prefix-list PL_DEFAULT_ROUTE_V4
route-map RM_EDGE_V4_OUT permit 20
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4

route-map RM_EDGE_V4_IN permit 10
 match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_HOST_V4_IN deny 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4
route-map RM_HOST_V4_IN permit 20
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4

route-map RM_HOST_V4_OUT permit 10
match ip address prefix-list PL_DEFAULT_ROUTE_V4


route-map RM_EDGE_V6_OUT deny 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
route-map RM_EDGE_V6_OUT permit 20
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6

route-map RM_EDGE_V6_IN permit 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6

route-map RM_HOST_V6_IN deny 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
route-map RM_HOST_V6_IN permit 20
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6

route-map RM_HOST_V6_OUT permit 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
BFD Configuration

The configuration below is a suggested setup to improve BGP convergence time between RS and edges over vRack.

bfd
 profile edge
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <EDGE_IPV4>
  profile edge
  no shutdown
 peer <EDGE_IPV6>
  profile edge_slow
  no shutdown
 ```

##### BGP Configuration

Global configuration:

```bash
router bgp <CUSTOMER_ASN>
 bgp router-id <RS_IPV4>
 no bgp default ipv4-unicast

BGP peering with OVHcloud Edges:

router bgp <CUSTOMER_ASN>
 neighbor PG_EDGE_V4 peer-group
 neighbor PG_EDGE_V4 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V4 bfd
 neighbor PG_EDGE_V6 peer-group
 neighbor PG_EDGE_V6 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V6 bfd
 neighbor <EDGE_IPV4> peer-group PG_EDGE_V4
 neighbor <EDGE_IPV6> peer-group PG_EDGE_V6

 address-family ipv4 unicast
  neighbor PG_EDGE_V4 activate
  neighbor PG_EDGE_V4 addpath-tx-all-paths 
  neighbor PG_EDGE_V4 attribute-unchanged next-hop
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_IN in
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_EDGE_V6 activate
  neighbor PG_EDGE_V4 addpath-tx-all-paths 
  neighbor PG_EDGE_V6 attribute-unchanged next-hop
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_IN in
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_OUT out

BGP peering with Hosts:

router bgp <CUSTOMER_ASN>
 neighbor PG_HOST_V4 peer-group
 neighbor PG_HOST_V4 remote-as <CUSTOMER_ASN>
 neighbor PG_HOST_V6 peer-group
 neighbor PG_HOST_V6 remote-as <CUSTOMER_ASN>
 neighbor <HOST_IPV4> peer-group PG_HOST_V4
 neighbor <HOST_IPV6> peer-group PG_HOST_V6

 address-family ipv4 unicast
  neighbor PG_HOST_V4 activate
  neighbor PG_HOST_V4 addpath-tx-all-paths
  neighbor PG_HOST_V4 route-map RM_HOST_V4_IN in
  neighbor PG_HOST_V4 route-map RM_HOST_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_HOST_V6 activate
  neighbor PG_HOST_V6 addpath-tx-all-paths 
  neighbor PG_HOST_V6 route-map RM_HOST_V6_IN in
  neighbor PG_HOST_V6 route-map RM_HOST_V6_OUT out
FRR configuration for Hosts

All of the following parameters should be present in the /etc/frr/frr.conf configuration file of the hosts.

Prefix list and Route Map Configuration

The configuration below is a suggested setup to prevent any unexpected announcement between BGP peers.

In the following example:

  • Hosts only accept default routes from RS.
  • Hosts only advertise customer's prefixes to RS.

Related prefix lists and route maps to filter routes:

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
... <other sequences may be added depending of the customer setup>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
... <other sequences may be added depending of the customer setup>


route-map RM_RS_V4_OUT permit 10
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4
route-map RM_RS_V4_IN permit 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_RS_V6_OUT permit 10
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6
route-map RM_RS_V6_IN permit 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
BFD Configuration

The configuration below is a suggested setup to improve BGP convergence time between RS and edges over vRack.

The values below are just an example, and you may choose other values for your RS and Hosts.

bfd
 profile rs
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <RS_IPV4>
  profile rs
  no shutdown
...
 peer <RS_IPV6>
  profile rs
  no shutdown
...
BGP Configuration

Global configuration:

router bgp <CUSTOMER_ASN>
 bgp router-id <HOST_IPV4>
 no bgp default ipv4-unicast
 maximum-paths 16
 maximum-paths ibgp 16

BGP peering with RS:

router bgp <CUSTOMER_ASN>
 neighbor PG_RS_V4 peer-group
 neighbor PG_RS_V4 remote-as <CUSTOMER_ASN>
 neighbor PG_RS_V4 bfd
 neighbor PG_RS_V6 peer-group
 neighbor PG_RS_V6 remote-as <CUSTOMER_ASN>
 neighbor PG_RS_V6 bfd
 neighbor <RS_IPV4> peer-group PG_RS_V4
...
 neighbor <RS_IPV6> peer-group PG_RS_V6
 ...

 address-family ipv4 unicast
  neighbor PG_RS_V4 activate
  neighbor PG_RS_V4 route-map RM_RS_V4_IN in
  neighbor PG_RS_V4 route-map RM_RS_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_RS_V6 activate
  neighbor PG_RS_V6 route-map RM_RS_V6_IN in
  neighbor PG_RS_V6 route-map RM_RS_V6_OUT out

Step 3: Restart FRR

On each host/RS, after editing the configuration, restart FRR to apply changes:

sudo systemctl restart frr

Step 4: Verify BGP Session

Check the status of your BGP sessions on your differents hosts/RS with:

show protocols all

Step 5: Verify Ingress and Egress Connectivity

To ensure your BGP session is functioning correctly, test both inbound and outbound traffic:

  • Check Ingress Traffic (Incoming)

Use a remote server to ping or traceroute to your advertised IP prefix:

ping YOUR_ADVERTISED_IP
traceroute YOUR_ADVERTISED_IP

Verify that traffic reaches your network via the expected BGP paths.

  • Check Egress Traffic (Outgoing)

From your server, check the routing table and ensure your BGP routes are in use:

ip route show
vtysh -c 'show ip route bgp'

Confirm that outbound traffic is following the correct BGP paths.

Step 6: Verify connectivity with the OVHcloud team

When your setup is done and after conducting basic tests, you should notify us via email at this address: bgp_alpha@ovh.net.

We'll make sure the BGP connectivity and IP announcements are OK from our side.

Limitations

The number of peers on OVHcloud side is limited to 4. If you need more than 4 peers, you will need to install a route server on your infrastructure in order to redistribute routes to your hosts.

  • BGP sessions: 4 BGP sessions per client (4 IPv4 + 4 IPv6)
  • Prefixes: up to 32 IPv4 prefixes and 32 IPv6 prefixes per client
  • Hosts: 10 hosts per client

Available Regions

The product is available in the following regions:

Region LocationRegion NameRegion Type
Europe (France - Paris) (will be available only in beta)eu-west-par3-AZ
Europe (France - Gravelines)eu-west-gra1-AZ
Europe (France - Roubaix)eu-west-rbx1-AZ
Europe (France - Strasbourg)eu-west-sbg1-AZ
Europe (Germany - Limburg)eu-west-lim1-AZ
Europe (Poland - Warsaw)eu-central-waw1-AZ
Europe (UK - Erith)eu-west-eri1-AZ
North America (Canada - East - Beauharnois)ca-east-bhs1-AZ
North America (Canada - East - Toronto)ca-east-tor1-AZ
Asia-Pacific (Singapore - Singapore)ap-southeast-sgp1-AZ
Asia-Pacific (Australia - Sydney)ap-southeast-syd1-AZ
Asia-Pacific (India - Mumbai)ap-south-mum1-AZ

Troubleshooting

If you encounter issues with your BGP session:

  • Verify that your ASN and IP prefixes are correctly configured.
  • Check for any conflicting announcements.
  • Ensure your firewall and network policies allow BGP traffic.
  • Contact our team for further assistance by email: bgp_alpha@ovh.net

Go further

Join our community of users.

Related articles