Configurer OVHcloud Connect L3 avec des routes statiques

Voir en Markdown

Configurez OVHcloud Connect L3 avec des routes IP statiques pour un routage prévisible entre votre réseau et OVHcloud

Objectif

Ce guide explique comment configurer OVHcloud Connect en mode L3 avec routage statique. Cela implique deux niveaux de configuration :

  1. Configuration PoP — La session L3 entre votre routeur et OVHcloud au niveau du Point de présence.
  2. Configuration supplémentaire AZ (network) — Des routes statiques au sein de l’Availability Zone OVHcloud pour la distribution des routes.
Info

Si vous préférez le routage dynamique avec BGP, consultez Configurer OVHcloud Connect L3 avec BGP.

Quand utiliser le routage statique plutôt que BGP

CritèreRoutage statiqueBGP
Nombre de préfixesFaible (1 à 5 routes)Élevé ou en croissance
Topologie réseauSimple, chemin uniqueComplexe, multi-chemins, multi-AZ
BasculeManuelle — vous devez mettre à jour les routes vous-mêmeAutomatique — BGP reconverge
MaintenanceLes routes doivent être mises à jour manuellement lorsque les sous-réseaux changentLes routes sont mises à jour dynamiquement
ComplexitéFaible — aucun protocole de routage à gérerPlus élevée — nécessite la configuration de BGP

Utilisez le routage statique lorsque vous disposez d’une configuration simple avec un faible nombre de préfixes stables et que vous n’avez pas besoin d’une bascule automatique.

Prérequis

Connectez-vous à votre puis accédez à Network > OVHcloud Connect.

En pratique

Vue d’ensemble

Votre routeur ── [ L3 au PoP ] ── Routeur PoP OVHcloud ── [ Routes statiques au DC ] ── Routeur vRack ── Services
                  peering /30                                next-hop + sous-réseau         (172.16.x.x)
  • Niveau PoP : une session L3 avec un sous-réseau de peering /30 entre votre routeur et OVHcloud.
  • Niveau AZ : des routes statiques définies par une IP next-hop et un sous-réseau de destination.

Étape 1 — Identifier l’ID de votre interface

Étape 2 — Créer la configuration PoP (L3)

La configuration PoP établit la session L3 au niveau du Point de présence. Cette étape est identique que vous utilisiez BGP ou le routage statique au niveau de l’AZ.

Paramètres de la requête :

ParamètreTypeRequisDescription
interfaceIdlongOuiID de l’interface OVHcloud Connect
typestringOuil3 pour le mode Layer 3
customerBgpArealongNonVotre numéro d’AS (toujours requis pour le L3 — utilisé pour le peering au niveau du PoP)
subnetipv4BlockNonSous-réseau de peering /30. La première IP est OVHcloud, la seconde est la vôtre.

Exemple de requête :

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

Étape 3 — Vérifier la configuration PoP

Exemple de réponse :

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

À partir de cette réponse :

ParamètreValeurSignification
IP du pair OVHcloud192.0.2.1Première IP du /30
Votre IP de pair192.0.2.2Deuxième IP du /30

Étape 4 — Créer la configuration supplémentaire AZ (statique)

Après la configuration PoP et une configuration AZ, créez une configuration supplémentaire network pour définir des routes statiques au sein de l’AZ.

Info

Avec le routage statique, VRRP reste actif sur le point de terminaison de l’AZ. Les équipements OVHcloud A et B partagent une IP virtuelle (la deuxième adresse du sous-réseau de l’AZ, par exemple 172.16.1.1). Pointez la passerelle par défaut de vos services vers cette IP virtuelle VRRP pour une bascule automatique entre les équipements.

Paramètres de la requête :

ParamètreTypeRequisDescription
typestringOuinetwork pour le routage statique
nextHopipv4NonAdresse IP next-hop pour la route statique
subnetipv4BlockNonSous-réseau de destination pour la route statique

Exemple de requête — router votre sous-réseau on-premises via le lien OVHcloud Connect :

{
  "type": "network",
  "nextHop": "172.16.1.1",
  "subnet": "10.0.0.0/16"
}

Ajouter plusieurs routes statiques

Créez une configuration supplémentaire par sous-réseau de destination. Répétez l’appel POST .../extra avec un subnet différent à chaque fois :

{
  "type": "network",
  "nextHop": "172.16.1.1",
  "subnet": "10.1.0.0/16"
}

Vérifier la configuration supplémentaire

Exemple de réponse :

{
  "id": 4568,
  "type": "network",
  "bgpNeighborArea": null,
  "bgpNeighborIp": null,
  "nextHop": "172.16.1.1",
  "subnet": "10.0.0.0/16",
  "status": "active"
}

Lister toutes les configurations supplémentaires d’une AZ

Étape 5 — Configurer les routes statiques sur votre routeur

Configurez votre routeur physique avec des routes statiques pointant les sous-réseaux d’AZ OVHcloud vers l’IP de peering OVHcloud Connect.

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

! Static routes to OVHcloud AZ subnets
ip route 172.16.1.0 255.255.255.0 192.0.2.1 name OVH-DC1-Production
ip route 172.16.2.0 255.255.255.0 192.0.2.1 name OVH-DC2-Production
ip route 172.16.10.0 255.255.255.0 192.0.2.1 name OVH-DC1-Management

Juniper JunOS

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

routing-options {
    static {
        route 172.16.1.0/24 next-hop 192.0.2.1;
        route 172.16.2.0/24 next-hop 192.0.2.1;
        route 172.16.10.0/24 next-hop 192.0.2.1;
    }
}

Étape 6 — Vérifier la connectivité

Depuis votre routeur

Cisco :

show ip route static
ping 172.16.1.1 source 192.0.2.2
traceroute 172.16.1.1 source 192.0.2.2

Juniper :

show route protocol static
ping 172.16.1.1 source 192.0.2.2
traceroute 172.16.1.1 source 192.0.2.2

Résultats attendus :

VérificationSortie attendue
Routes statiques présentesRoutes vers 172.16.x.x via 192.0.2.1 dans la table de routage
Le ping aboutitRéponse depuis la passerelle du sous-réseau d’AZ OVHcloud
TracerouteLe trafic passe par 192.0.2.1 (PoP OVHcloud)

Depuis l’API OVHcloud

Vérifiez l’état de l’interface :

Vérifiez le statut de la configuration PoP :

Lancer un diagnostic

Noms de diagnostics disponibles : diagPeering, diagPeeringExtra, diagRoutes, diagMacs.

Limites du routage statique

Warning

Le routage statique présente des limites importantes par rapport à BGP :

  • Pas de bascule automatique. Si un lien tombe, le trafic est blackholé jusqu’à ce que vous mettiez manuellement à jour les routes. Pour une bascule automatique, utilisez BGP.
  • Mises à jour manuelles requises. Lorsque vous ajoutez ou modifiez des sous-réseaux, vous devez mettre à jour à la fois la configuration supplémentaire OVHcloud et la configuration de votre routeur.
  • Pas de répartition de charge. Les routes statiques ne prennent pas en charge ECMP ni le traffic engineering. Le trafic suit un chemin unique.
  • Non recommandé pour le multi-AZ. Pour les configurations multi-AZ résilientes, BGP est fortement recommandé — voir Multi-AZ.

Supprimer les configurations

Supprimez dans l’ordre inverse :

Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d’utilisateurs.

Cette page vous a-t-elle aidé ?