Configurer un bloc IPv6 dans un vRack

Objectif

Le réseau vRack est un réseau privé mondial qui relie différents produits OVHcloud et permet la création de solutions réseau sophistiquées. En plus de faciliter les connexions privées, il prend également en charge le routage des adresses IP publiques.

Ce guide se concentre sur la configuration des blocs d’adresses Additional IPv6 au sein d’un réseau vRack.

Introduction

L’IPv6 révolutionne la mise en réseau au sein du vRack d’OVHcloud, en offrant une solution aux limites de l’IPv4, ainsi que des fonctionnalités adaptées à l’Internet moderne. Son déploiement est une réponse directe au besoin d'architectures Internet plus étendues, plus sécurisées et plus sophistiquées. Voici les principaux avantages de l’intégration d’IPv6 au vRack :

• Flexibilité pour les réseaux avancés : l’IPv6 augmente considérablement l’espace d’adressage, offrant la flexibilité nécessaire pour faire évoluer l’infrastructure, gérer les scénarios de basculement et prendre en charge des solutions plus importantes. Cela permet aux réseaux de se développer et de s’adapter sans les contraintes d'adressage de l’IPv4.

• Routage hiérarchique et segmentation : IPv6 permet un routage hiérarchique efficace et une segmentation de l’infrastructure logique. Cela améliore la gestion et la sécurité du réseau, idéal pour la revente de machines virtuelles avec des sous-réseaux dédiés ou encore la segmentation de l'infrastructure réseau.

• Faible latence : La connectivité IPv6 native de bout en bout peut faciliter la mise en place de services sensibles à la latence, comme le streaming multimédia, car de nombreux réseaux de fournisseurs récents sont construits en IPv6 native. Dans de tels réseaux, l’utilisation de services IPv4 crée une latence (et des coûts) supplémentaires.

En tirant parti de l’IPv6 au sein du vRack, les utilisateurs d’OVHcloud peuvent profiter d’un environnement réseau plus sécurisé, efficace et évolutif, prêt à répondre aux exigences des utilisations modernes d’Internet.

Prérequis

• Un service vRack actif sur votre compte
• Un serveur compatible vRack connecté à votre réseau vRack
• Un accès à l'espace client OVHcloud

En pratique

Obtention d’un nouveau bloc Additional IPv6

Lors de la demande d'un nouveau bloc Additional IPv6, l'allocation est régionale. Cela signifie que le bloc IPv6 que vous recevez sera lié à une région spécifique, définissant où le trafic public entre dans votre réseau vRack (à savoir, l'emplacement de la passerelle).

Configurer l’IPv6 dans un vRack (mode simple)

Dans cette section, nous présenterons la configuration IPv6 de base de vos hôtes connectés au vRack.

L'exemple ci-dessus montre deux hôtes avec leurs interfaces côté vRack configurées avec des adresses publiques IPv6. Un hôte possède une configuration manuelle, tandis qu’un autre dispose d'une adresse IP attribuée automatiquement en SLAAC. Toutes les adresses IP appartiennent au premier sous-réseau /64 d'un bloc /56 d'Additional IPv6 publiques donné. Les deux utilisent l'interface vRack pour la connectivité IPv6 publique.

La passerelle par défaut pour le premier sous-réseau /64 (celui qui est bridgé) est la première adresse du bloc /56. Dans cet exemple, la passerelle est 2001:41d0:abcd:ef00::1. Celle-ci est distribuée via SLAAC, mais doit être configurée manuellement (en tant que route par défaut) si le SLAAC est désactivé (voir la section Configuration IP statique ci-dessous).

Commandes sur l'hôte

$ sudo ip address add 2001:41d0:abcd:ef00::2/64 dev eth1

$ sudo ip -6 route add default via 2001:41d0:abcd:ef00::1/64 dev eth1

$ sudo ip link set up dev eth1
$ ip -6 addr list dev eth1
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 2001:41d0:abcd:ef00::2/64 scope global static

$ sudo sysctl -w net.ipv6.conf.eth1.accept_ra=1

$ sudo ip link set up dev eth1
$ ip -6 addr list dev eth1
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 2001:41d0:abcd:ef00:fe34:97ff:feb0:c166/64 scope global dynamic mngtmpaddr
       valid_lft 2322122sec preferred_lft 334922sec

Vérification de l'installation

debian@host:~$ ping 2001:41d0:900:2100:fe34:97ff:feb0:c166
PING 2001:41d0:900:2100:fe34:97ff:feb0:c166(2001:41d0:900:2100:fe34:97ff:feb0:c166) 56 data bytes
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=2 ttl=64 time=0.034 ms

ubuntu@remote-test:~$ ping 2001:41d0:900:2100:fe34:97ff:feb0:c166
PING 2001:41d0:900:2100:fe34:97ff:feb0:c166(2001:41d0:900:2100:fe34:97ff:feb0:c166) 56 data bytes
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=1 ttl=55 time=7.23 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=2 ttl=55 time=6.90 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=3 ttl=55 time=6.92 ms

Configurer une IPv6 dans un vRack pour le mode routé

Dans cette section, nous présenterons une configuration IPv6 plus avancée, où vos hôtes connectés au vRack agissent comme des routeurs pour les machines virtuelles hébergées. Ces VMs disposent de sous-réseaux délégués provenant du bloc IPv6 principal (présenté avec une couleur orange dans le schéma ci-dessous).

Le chemin emprunté par le trafic est le suivant : le trafic entrant vers une VM donnée (avec le sous-réseau spécifié) est routé via le vRack du client, d'abord vers un hôte spécifié (avec une adresse de prochain saut), puis en utilisant un lien local (ou vSwitch - lien noir fd00::/64 sur le diagramme) vers la machine virtuelle particulière. Le trafic revenant d'une telle VM doit utiliser la route par défaut via la première partie du lien local (en noir sur le diagramme, fd00::1), puis la route (éventuellement par défaut) d'un hôte vers sa passerelle.

Pour la définition de sous-réseau routé, toute taille de préfixe peut être utilisée entre /57 et /64.

La passerelle par défaut de l'hôte est la première adresse du bloc /56, qui est dans cet exemple : 2001:41d0:abcd:ef00::1. Les passerelles par défaut utilisées par les VMs sont les adresses configurées de l'hôte (ici fd00::1).

Définir un sous-réseau routé

Configuration de l'hôte

$ sudo ip addr add 2001:41d0:abcd:ef00::2/64 dev eth1
$ sudo ip link set dev eth1 up
$ sudo ip -6 route add default via 2001:41d0:abcd:ef00::1 dev eth1

$ sudo sysctl -w net.ipv6.conf.all.forwarding=1

$ sudo sysctl -w net.ipv6.conf.eth1.accept_ra=2

$ sudo ip -6 route add 2001:41d0:abcd:ef10::/60 via fd00::2

debian@vm-1:~$ sudo ip address add 2001:41d0:abcd:ef10::1/60 dev lo

debian@vm-1:~$ sudo ip -6 route add default via fd00::1

Vérification de la configuration

debian@host:~$ ping fd00::2
PING fd00::2(fd00::2) 56 data bytes
64 bytes from fd00::2: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from fd00::2: icmp_seq=2 ttl=64 time=0.071 ms

debian@host:~$ ping 2001:41d0:abcd:ef10::1
PING 2001:41d0:abcd:ef10::1(2001:41d0:abcd:ef10::1) 56 data bytes
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=2 ttl=64 time=0.073 ms

debian@host:~$ ip -6 route get 2001:41d0:abcd:ef10::1
2001:41d0:abcd:ef10::1 from :: via fd00::2 dev veth1a src fd00::1 metric 1024 pref medium

debian@vm-1:~$ ip -6 route show
2001:41d0:abcd:ef10::/60 dev lo proto kernel metric 256 pref medium
fd00::/64 dev veth1b proto kernel metric 256 pref medium
default via fd00::1 dev veth1b src 2001:41d0:abcd:ef10::1 metric 1024 pref medium

debian@vm-1:~$ ping fd00::1
PING fd00::1(fd00::1) 56 data bytes
64 bytes from fd00::1: icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from fd00::1: icmp_seq=2 ttl=64 time=0.070 ms

debian@vm-1:~$ ping 2001:41d0:abcd:ef00::2
PING 2001:41d0:abcd:ef00::2(2001:41d0:abcd:ef00::2) 56 data bytes
64 bytes from 2001:41d0:abcd:ef00::2: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 2001:41d0:abcd:ef00::2: icmp_seq=2 ttl=64 time=0.080 ms

debian@vm-1:~$ ping 2001:41d0:242:d300::
PING 2001:41d0:242:d300::(2001:41d0:242:d300::) 56 data bytes
64 bytes from 2001:41d0:242:d300::: icmp_seq=1 ttl=57 time=0.388 ms
64 bytes from 2001:41d0:242:d300::: icmp_seq=2 ttl=57 time=0.417 ms

debian@vm-1:~$ ping -6 proof.ovh.net
PING proof.ovh.net(2001:41d0:242:d300:: (2001:41d0:242:d300::)) 56 data bytes
64 bytes from 2001:41d0:242:d300:: (2001:41d0:242:d300::): icmp_seq=1 ttl=57 time=0.411 ms
64 bytes from 2001:41d0:242:d300:: (2001:41d0:242:d300::): icmp_seq=2 ttl=57 time=0.415 ms

ubuntu@remote-test:~$ ping 2001:41d0:abcd:ef10::1
PING 2001:41d0:abcd:ef10::1(2001:41d0:abcd:ef10::1) 56 data bytes
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=1 ttl=55 time=5.84 ms
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=2 ttl=55 time=2.98 ms

ubuntu@remote-test:~$ mtr -rc1 2001:41d0:abcd:ef10::1
Start: 2024-03-26T09:26:45+0000
HOST: remote-test                               Loss%   Snt   Last   Avg  Best  Wrst StDev
...
...
  9.|-- 2001:41d0:abcd::2:5d                        0.0%     1    1.9   1.9   1.9   1.9   0.0
 10.|-- 2001:41d0:abcd:ef00::2                      0.0%     1    2.2   2.2   2.2   2.2   0.0
 11.|-- 2001:41d0:abcd:ef10::1                      0.0%     1    2.2   2.2   2.2   2.2   0.0

Emplacements multi-régions vs. vRack global

La technologie vRack d’OVHcloud permet aux entreprises de connecter des serveurs à différents emplacements, comme s’ils étaient situés dans le même datacenter. D’autre part, les services comme Additional IPv6 sont régionaux, ce qui signifie que leur fonctionnement est lié à un emplacement particulier.

Ci-dessous, une architecture est présentée à des fins d'apprentissage avec deux régions différentes, et des blocs Additional IPv6 différents annoncés depuis chacune des deux régions. De plus, il y a un hôte configuré avec des adresses IP des deux réseaux ainsi qu'un exemple de route sous-optimale - un hôte dans une région possédant une adresse IPv6 annoncée dans une autre région :

Veuillez noter que dans de telles configurations (avec des Additional IPv6 provenant de plus d'une région), le SLAAC doit être désactivé dans l'ensemble du vRack (car cela peut entraîner des résultats imprévisibles et une perte de connectivité aléatoire).

Avantages

• Connectivité améliorée : En tirant parti d'un réseau vRack et de blocs IP publics routés à plusieurs endroits, les entreprises peuvent bénéficier d'une communication transparente dans le monde entier, quels que soient les emplacements physiques des serveurs backend.
• Migrer vers le cloud : La technologie vRack peut grandement faciliter les premières étapes vers une stratégie organisationnelle de « migration vers le cloud », en débloquant certaines applications existantes qui nécessitent encore une communication réseau locale.

Risques et considérations

• Pas de prise en charge SLAAC dans les configurations multi-emplacements : Lorsqu'il y a plus d'un emplacement impliqué dans le routage du trafic IP public (IPv4 et IPv6) dans le même vRack, la configuration automatique d'adresses sans état (SLAAC) ne doit pas être utilisée. Prenons l'exemple d'hôtes existants utilisant des adresses IPv4. Ces hôtes sont automatiquement reconfigurés par SLAAC avec une passerelle IPv6 configurée à partir d'une autre région. Associée à la priorisation de l’IPv6 sur l’IPv4 par certains systèmes d’exploitation, cette situation peut conduire à un routage sous-optimal, voire à une perte totale de connectivité pour ces hôtes.

Limites Connues

Comprendre les contraintes liées à l'utilisation d'Additional IPv6 dans l'environnement vRack est essentiel pour une planification efficace du réseau. Voici les principales limites à prendre en compte :

• Additional IPv6 est fourni uniquement avec vRack : Veuillez noter que les adresses Additional IPv6 ne peuvent être configurées qu’avec des backends connectés au vRack.
• Limites du SLAAC dans les configurations multi-emplacements : La configuration automatique des adresses sans état (SLAAC) n'est pas prise en charge lorsqu'il y a du trafic IP public (IPv6 et IPv4) routé dans le vRack dans plusieurs régions.
• Jusqu'à 128 hôtes à l'intérieur du sous-réseau ponté : Vous pouvez utiliser jusqu'à 128 adresses IP directement sur le vRack.
• Jusqu'à 128 routes next-hop : vous pouvez utiliser jusqu'à 128 routes pour des sous-réseaux routés à l'intérieur d'un vRack.
• Plafonnement de la bande passante publique : Le trafic sortant d’OVHcloud vers Internet est plafonné à 5 Gbit/s par région.
• Limites d’allocation de blocs IPv6 : un seul bloc Additional IPv6 par vRack dans une région. Maximum de 3 blocs (/56) par emplacement de région.
• Mobilité des blocs Additional IPv6 : En raison de la conception hiérarchique de l’espace d’adressage IPv6, les blocs Additional IPv6 sont spécifiques à chaque région. Cela signifie que les blocs ne peuvent pas être transférés entre les régions, bien qu'ils puissent être réaffectés au sein de n'importe quel backend connecté au vRack.
• Pas de prise en charge directe du VLAN 802.1Q dans le vRack par Additional IPv6 : La configuration ne peut être effectuée qu'avec le VLAN natif de votre réseau vRack. Pour la transmission de paquets à l'intérieur d'un VLAN spécifique (dans un vRack), un hôte dédié côté client sera nécessaire.
• Le routage d’Additional IPv6 dans le vRack n’est actuellement pas pris en charge dans les régions APAC.

Aller plus loin

Échangez avec notre communauté d'utilisateurs.