Set up a resilient OVHcloud Connect architecture

View as Markdown

Connect your infrastructure to OVHcloud through two redundant OVHcloud Connect links for high availability and automatic failover.

Objective

This tutorial guides you through connecting your infrastructure to OVHcloud using two independent OVHcloud Connect links for high availability. If one link fails, traffic automatically switches to the other.

Instructions

Below are prerequisites and instructions for five use cases; choose the one matching your desired architecture.

On-Premises
WAN
AWS
Azure
GCP

Prerequisites

  • Two OVHcloud Connect services (Direct, Provider, or a mix) terminating at different PoPs
  • A router (or two routers) capable of running multiple BGP sessions with failover
  • An IP plan covering two AZs in OVHcloud
  • A vRack with resources in both AZs

Architecture

On-Premises resilient architecture diagram

When to use this architecture

✅ Recommended forDetails
Business-critical productionWorkloads that cannot tolerate downtime
Regulated environmentsCompliance frameworks requiring high availability
SLA requirements ≥ 99.99%Multi-path architecture needed for premium SLA
Disaster recoveryAutomatic failover without manual intervention

Order two separate OVHcloud Connect services at different PoPs for physical diversity:

  • Link 1 (Primary): Order at PoP A — See Order Direct or Order Provider.
  • Link 2 (Backup): Order at PoP B — Same process, different PoP.

Diversity tip: Use different data centres or at minimum different physical paths to avoid a shared failure point.

2. Install both physical connections

For each link:

  • Direct: Install cross-connects at each PoP. See Cross Connect LOA.
  • Provider: Share the respective pairing keys with your provider(s).

3. Configure BGP with failover

Set up two BGP sessions — one per link — with routing policies that define which path is preferred.

Active/Standby example (Cisco IOS)
router bgp 65001
 ! Primary link via PoP A
 neighbor 192.0.2.1 remote-as 35540
 neighbor 192.0.2.1 description OVHcloud-Primary
 neighbor 192.0.2.1 route-map PRIMARY-IN in
 neighbor 192.0.2.1 route-map PRIMARY-OUT out

 ! Backup link via PoP B
 neighbor 198.51.100.1 remote-as 35540
 neighbor 198.51.100.1 description OVHcloud-Backup
 neighbor 198.51.100.1 route-map BACKUP-IN in
 neighbor 198.51.100.1 route-map BACKUP-OUT out

! Prefer primary path using Local Preference
route-map PRIMARY-IN permit 10
 set local-preference 200

route-map BACKUP-IN permit 10
 set local-preference 100

! Influence OVHcloud's return traffic using AS-path prepending on backup
route-map PRIMARY-OUT permit 10

route-map BACKUP-OUT permit 10
 set as-path prepend 65001 65001
Key BGP attributes for failover
AttributeEffectUse case
Local PreferenceControls outbound path preference (higher = preferred)Make primary path preferred for traffic leaving your network
AS-path prependingMakes a path look longer (less preferred)Influence OVHcloud's choice of return path
MEDSuggests preference to the remote sideMay not be honoured in all OVHcloud configurations

Associate both OVHcloud Connect services with the same vRack. See Associate with vRack.

5. Configure subnets in both AZs

Set up private subnets in both Availability Zones. See Set up your vRack network.

6. Test failover

This is critical. Do not skip failover testing.

  1. Verify normal operation:

    • Both BGP sessions are Established.
    • Traffic flows through the primary link.

  2. Simulate primary failure:

    • Shut down the primary BGP session or physically disconnect the primary link.
    • Verify traffic switches to the backup link within the BGP convergence time (typically 30–90 seconds; can be faster with BFD).
    • Confirm no packet loss beyond the convergence window.

  3. Restore primary:

    • Bring the primary link back up.
    • Verify traffic returns to the primary path.

  4. Test the reverse:

    • Simulate failure of the backup link while the primary is up. This confirms both links work independently.

7. Set up monitoring

Monitor both links independently. Set alerts for:

  • BGP session drops on either link
  • Traffic imbalance (all traffic on one link may indicate a failure on the other)
  • Bandwidth approaching capacity on either link

See Monitor.

Advanced: Active/Active configuration

For maximum throughput and faster failover, you can run both links in Active/Active mode:

  • Set equal Local Preference on both paths.
  • Use ECMP (Equal-Cost Multi-Path) if supported.
  • Traffic is load-balanced across both links.
  • If one link fails, all traffic immediately flows through the surviving link.

Active/Active provides higher aggregate bandwidth but requires careful capacity planning — each link must be able to handle the full traffic load alone during a failure.

What's next?

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.

Was this page helpful?