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

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: 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: 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.

Hello @JoelP15,

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

Vous pouvez également poser votre question sur le salon suivant :
https://discord.com/channels/850031577277792286/850031577840746592

^FabL

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

Merci Eric pour ces pistes à explorer !

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

^FabL

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.