Configure OVHcloud Connect L3 with BGP

Ver como Markdown

Configure OVHcloud Connect L3 using BGP for dynamic route exchange between your network and OVHcloud

Objective

This guide explains how to configure OVHcloud Connect in L3 mode with BGP. This involves two levels of configuration:

  1. PoP configuration — The eBGP session between your router and OVHcloud at the Point of Presence.
  2. AZ extra configuration (BGP) — BGP peering within the OVHcloud AZ for route distribution.
Info

If you prefer static routing instead of BGP, see Configure OVHcloud Connect L3 with static routing.

Requirements

Log in to your and go to Network > OVHcloud Connect.

Instructions

Overview

Your Router ── [ eBGP at PoP ] ── OVHcloud PoP Router ── [ iBGP at DC ] ── vRack Router ── Services
   ASN 65001        /30 peering         ASN 35540           AZ        (172.16.x.x)
                                                           extra config
  • PoP level: An eBGP session between your router (your ASN) and OVHcloud (ASN 35540) over a /30 peering subnet.
  • AZ level: A BGP neighbour configured inside the AZ to distribute routes to your OVHcloud services.

Step 1 — Identify your interface ID

Retrieve the interface ID for your OVHcloud Connect service:

Step 2 — Create the PoP configuration (L3)

The PoP configuration establishes the L3 BGP session at the Point of Presence.

Request parameters:

ParameterTypeRequiredDescription
interfaceIdlongYesID of the OVHcloud Connect interface
typestringYesl3 for Layer 3 mode
customerBgpArealongNoYour private AS number (e.g. 65001)
ovhBgpArealongNoOVHcloud private AS (usually left empty — assigned automatically)
subnetipv4BlockNo/30 peering subnet (e.g. 192.0.2.0/30). First IP is OVHcloud, second is yours.

Example request:

{
  "interfaceId": 101,
  "type": "l3",
  "customerBgpArea": 65001,
  "subnet": "192.0.2.0/30"
}

The resourceId in the response is your new popId.

Step 3 — Verify the PoP configuration

Once the task completes:

Example response:

{
  "id": 5678,
  "interfaceId": 101,
  "type": "l3",
  "customerBgpArea": 65001,
  "ovhBgpArea": 35540,
  "subnet": "192.0.2.0/30",
  "status": "active"
}

From this response, note:

ParameterValueMeaning
OVHcloud peer IP192.0.2.1First IP of the /30 — OVHcloud side
Your peer IP192.0.2.2Second IP of the /30 — your router
OVHcloud ASN35540The ovhBgpArea value
Your ASN65001The customerBgpArea value

Check the BGP session state:

Step 4 — Create AZ extra configuration (BGP)

After the PoP configuration and the AZ configuration, create a BGP extra configuration to enable BGP route distribution within the AZ.

Warning

Enabling BGP at the AZ level disables VRRP on that AZ configuration. BGP handles failover instead. You must establish a BGP session with both OVHcloud device A and device B (up to 4 BGP peers per AZ). By default, BFD (Bidirectional Forwarding Detection) is activated on all AZ BGP sessions — enabling BFD on your side as well is strongly recommended for faster convergence.

Request parameters:

ParameterTypeRequiredDescription
typestringYesbgp for BGP routing
bgpNeighborArealongNoBGP AS number for the AZ neighbour
bgpNeighborIpipv4NoRouter IP for the BGP session within the AZ

Example request:

{
  "type": "bgp",
  "bgpNeighborArea": 65501,
  "bgpNeighborIp": "172.16.1.1"
}

Verify the extra configuration:

Example response:

{
  "id": 4567,
  "type": "bgp",
  "bgpNeighborArea": 65501,
  "bgpNeighborIp": "172.16.1.1",
  "nextHop": null,
  "subnet": null,
  "status": "active"
}

Step 5 — Configure BGP on your router

Configure your physical router to establish the eBGP session with OVHcloud at the PoP. Replace the example values with your actual parameters from Step 3.

Cisco IOS / IOS-XE

! Interface facing OVHcloud
interface GigabitEthernet0/0
 description OVHcloud Connect
 ip address 192.0.2.2 255.255.255.252
 no shutdown

! BGP configuration
router bgp 65001
 bgp log-neighbor-changes
 neighbor 192.0.2.1 remote-as 35540
 neighbor 192.0.2.1 description OVHcloud-Peer
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  network 10.0.0.0 mask 255.255.0.0
  ! Only advertise your own prefixes
  neighbor 192.0.2.1 prefix-list MY-PREFIXES out
  neighbor 192.0.2.1 prefix-list OVH-PREFIXES in
  neighbor 192.0.2.1 maximum-prefix 100

ip prefix-list MY-PREFIXES seq 10 permit 10.0.0.0/16
ip prefix-list OVH-PREFIXES seq 10 permit 172.16.0.0/12 le 24

Juniper JunOS

interfaces {
    ge-0/0/0 {
        description "OVHcloud Connect";
        unit 0 {
            family inet {
                address 192.0.2.2/30;
            }
        }
    }
}

protocols {
    bgp {
        group OVHcloud {
            type external;
            peer-as 35540;
            local-address 192.0.2.2;
            neighbor 192.0.2.1 {
                description "OVHcloud Peer";
                import OVH-IMPORT;
                export MY-EXPORT;
            }
        }
    }
}

policy-options {
    policy-statement MY-EXPORT {
        term allow {
            from {
                route-filter 10.0.0.0/16 exact;
            }
            then accept;
        }
        term reject {
            then reject;
        }
    }
    policy-statement OVH-IMPORT {
        term accept-ovh {
            from {
                route-filter 172.16.0.0/12 orlonger;
            }
            then accept;
        }
        term reject {
            then reject;
        }
    }
}

Step 6 — Verify the BGP session

From your router

Cisco:

show ip bgp summary
show bgp ipv4 unicast neighbors 192.0.2.1
show ip route bgp

Juniper:

show bgp summary
show bgp neighbor 192.0.2.1
show route protocol bgp

Expected results:

CheckExpected output
BGP stateEstablished
Prefixes receivedAt least 1 route from OVHcloud (your AZ subnets)
Prefixes sentYour advertised prefixes visible

From the OVHcloud API

Check PoP statistics (accepted prefixes):

Run a diagnostic

If the session does not come up, run a peering diagnostic:

Available diagnostic names: diagPeering, diagPeeringExtra, diagRoutes, diagMacs.

Best practices

  • Only advertise prefixes you own. Do not leak third-party routes through OVHcloud Connect.
  • Apply prefix filters. Use prefix-lists on both import and export to prevent accidental route leaks.
  • Set maximum-prefix limits. Protect your router from receiving an unexpected number of routes.
  • Use MD5 authentication. If required, configure MD5 on the BGP session for added security.
  • Monitor the session. Set up alerts for BGP flaps and session drops — see Monitor your connection.
  • For redundant setups. Use Local Preference or AS-path prepending to control primary/backup path selection — see Multi-AZ.

Troubleshooting

IssuePossible causeSolution
BGP stuck in ActiveIncorrect peer IP or ASNVerify IP addresses and ASN on both sides. Use GET .../config/pop/{popId} to check OVHcloud-side values.
BGP stuck in IdleInterface down or firewall blocking TCP 179Check physical link and firewall rules. Use GET .../interface/{id}/status to check link status.
No routes receivedMissing network statement or prefix filter too restrictiveVerify export policy and network commands. Run diagRoutes diagnostic.
Session drops frequently (flapping)Unstable physical link or MTU mismatchCheck interface errors and MTU settings. Use GET .../interface/{id}/statistics to check error counters.
PoP config stuck in init statusTask still in progress or failedCheck GET .../task for pending tasks.

Delete configurations

To remove the BGP configuration, delete in reverse order:

Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analyzed by our experts.

Join our community of users.

Esta página foi útil?