Problème de communication réseau entre plusieurs régions

[JoelP15]

Bonjour à toutes et à tous,

J'utilise l'offre : https://www.ovhcloud.com/fr/public-cloud/

Je rencontre la problématique suivante :

J'ai monté une infrastructure Web sous Terraform et OpenStack composée de plusieurs serveurs situés sur deux régions. Chaque région est composée de son propre réseau privé (192.168.10.0/24 et 192.168.20.0/24). Les deux régions sont reliées avec un réseau privé (172.16.0.0/16) ayant plusieurs subnets sur chaque région (172.16.10.0/24 et 172.16.20.0/24). Les routeurs sont gérés par les service https://www.ovhcloud.com/fr/public-cloud/gateway/ d'OVH.

Chaque routeur a une route statique :

SBG5 : 
Destination CIDR = 192.168.20.0/24
Next Hop = 172.16.20.1

GRA11
Destination CIDR = 192.168.10.0/24
Next Hop = 172.16.10.1

Mon infrastructure marchait très bien en Février. Et depuis début mars, je n'ai plus de communication entre mes deux régions.

Voici les quelques tests effectués :

ubuntu@bastion:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:34:72:39 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.10.48/24 metric 100 brd 192.168.10.255 scope global dynamic ens3
       valid_lft 84028sec preferred_lft 84028sec
    inet6 fe80::f816:3eff:fe34:7239/64 scope link 
       valid_lft forever preferred_lft forever

ubuntu@bastion:~$ ip r
default via 192.168.10.1 dev ens3 proto dhcp src 192.168.10.48 metric 100 
1.0.0.1 via 192.168.10.1 dev ens3 proto dhcp src 192.168.10.48 metric 100 
1.1.1.1 via 192.168.10.1 dev ens3 proto dhcp src 192.168.10.48 metric 100 
8.8.8.8 via 192.168.10.1 dev ens3 proto dhcp src 192.168.10.48 metric 100 
169.254.169.254 via 192.168.10.2 dev ens3 proto dhcp src 192.168.10.48 metric 100 
192.168.10.0/24 dev ens3 proto kernel scope link src 192.168.10.48 metric 100 
192.168.10.1 dev ens3 proto dhcp scope link src 192.168.10.48 metric 100 
192.168.10.2 dev ens3 proto dhcp scope link src 192.168.10.48 metric 100 

ubuntu@bastion:~$ date && mtr -rbwz 192.168.20.100 -r -c 10
Mon Mar 13 10:35:20 UTC 2023
Start: 2023-03-13T10:35:21+0000
HOST: bastion                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    _gateway (192.168.10.1)   0.0%    10    0.2   0.2   0.2   0.5   0.1
  2. AS???    _gateway (192.168.10.1)  90.0%    10  3078. 3078. 3078. 3078.   0.0

ubuntu@bastion:~$ traceroute 192.168.20.100
traceroute to 192.168.20.100 (192.168.20.100), 30 hops max, 60 byte packets
 1  _gateway (192.168.10.1)  0.615 ms  0.593 ms  0.578 ms
 2  _gateway (192.168.10.1)  3070.530 ms !H  3070.517 ms !H  3070.478 ms !H

Mon projet a été créé à partir de terraform en me basant sur ce repo : https://github.com/ovh/public-cloud-examples/tree/main/networking/private-networks-multi-region

Merci d'avance pour votre aide.

[FabL]

Hello @JoelP15,

@EricD76, as-tu de la visibilité sur ce type de demande ? (Merci d'avance pour ton retour 🙏)

Vous pouvez également poser votre question sur le salon suivant :

Discord - A New Way to Chat with Friends & Communities

^FabL

[EricD76]

Salut.

Assez dur de dire comme ça d'où proviens l'erreur.
Par défaut, vu que tout fonctionnais jusqu’à présent et que, depuis début mars, ça ne marche plus, j'ai tendance a dire que ce serait un soucis coté Openstack / Infra.

Donc par défaut, j'ai tendance à dire qu'il faudrait ouvrir un ticket pour s'en assurer.

Après, d'un point de purement infra et client, un delete du port coté vRouter et un recreate peut parfois aider... un peu la politique de la terre brulée, mais ça fonctionne souvent sous Openstack x)

Eric

[FabL]

Merci Eric pour ces pistes à explorer !

@JoelP15, n'hésitez pas à revenir sur ce thread pour indiquer la solution qui aura fonctionné.

^FabL

[JoelP15]

Bonjour à tous,
J'ai déjà créer un ticket. Mais sans résultat sur ce point là.

En solution proposée, j'ai créé un réseau en 192.168.0.0/16 sur plusieurs régions, et sur chacune des régions un subnet avec un cidr en 192.168.0.0/16 et un gateway en 192.168.0.1. J'ai rajouté pour chaque région un dhcp respectivement en 192.168.10.0/24 et 192.168.20.0/24.

De cette façon, les serveurs peuvent communiquer entre eux sur plusieurs régions.

Le lien Github que j'ai utilisé était un projet en Work In Progress. Je pense que je suis tombé au moment où la fonctionnalité était en test et a dû être modifiée au mois de mars. J'ai testé de recréé l'architecture sous un autre projet et l'échange entre les deux régions ne se faisait pas.