Hello,
Depuis quelques jours j'ai une instance Public Cloud sous CentOS 7 qui n'a plus d'accès Internet.
A priori la passerelle est injoignable (pas de réponse au ping), ça a coupé subitement et ce n'est jamais revenu depuis (test de reboot, arret du firewall...)
Lors du boot on voit bien cloud-init afficher l'IP et les routes puis juste ensuite les erreurs commence avec des échec de connexion lié à l'init OpenStack ( http://169.254.169.254/2009-04-04/meta-data/instance-id ).
Le support OVH étant aux abonnées absent (ticket ouvert et relancé depuis plus de 4 jours) que puis faire sans réinstaller complètement l'instance?
Public Cloud OVHcloud - Passerelle non fonctionelle sur instance Public Cloud
Related questions
- Dimensionnement serveur MySQL
41939 
07.11.2018 12:32
- [RESOLU] Connexion impossible en SSH
35232 05.06.2019 20:05
- Bonjour, Je n'est reçus aucun mot de passe root lors de mon achat!
30538 05.02.2018 20:47
- Gitlab private docker registry
30458 16.03.2018 13:05
- Configuration IP failover avec netplan (Ubuntu 17.10)
29282 12.01.2018 23:23
- Ssh connection timed out port 22
28390 11.12.2019 08:21
- IP Failover sur Debian 9
27937 18.11.2016 20:40
- Problème connexion ssh
27491 04.02.2018 09:46
- Instance Public Cloud en "error"
25544 15.12.2025 10:04
- Connexion OpenStack Swift Object Storage
22135 11.04.2019 10:09
Salut @CyprienD2
Est-ce que tu as tenté le reboot en rescue pour voir si tu as le même comportement ?
Met le numéro de ticket ici au cas où un des membres du staff passe une tête ;)
Jalinn
169.254.x.x c'est quand un serveur ne reçoit pas de lease DHCP et cette plage n'est pas routable.
@Jalinn
Après quelques reboot j'ai réussi a avoir du ping en rescue.
En boot normal il doit y avoir une problème de route mais je ne comprend pas lequel.
@Fritz2cat
C'est une plage réservé mais cloud-init/openstack l'utilise (sur une instance avec du réseau un "curl http://169.254.169.254/2009-04-04/meta-data/instance-id" renvoi une réponse)
Question bête @CyprienD2... :
Ce comportement me fait penser a un truc.
Est-ce que tu as une interface vRack sur ton instance ?
Si oui, est-ce que tu as définis une Gateway par défaut dans ton subnet (ex 192.168.0.1 ) ?
J'ai déjà eu un cas comme ça a cause d'un GW activé sur un subnet + thread en parlant sur la mailing list CLOUD.
Dans ce cas, la solution passe en désactivant cette GW dans le subnet Openstack si possible.
Si pas possible car réellement utilisés, il me semble (de mémoire), qu'en mettant sur la VM gérant la GW une règles de FW bloquant tout trafic in/out vers 169.254.169.254.
Ce comportement est lié au fait qu'Openstack ne sais pas gérer de réseau prioritaire.
Il ne fait la différence entre le vRack et ext-net donc, va charger la route par défaut sur la patte privée au lieu d'EXT-NEt.
Le fait de rebooter a plusieurs reprise et que ça fonctionne a tendance a me faire penser a cela.
A un moment, ton interface Ext-net réponds plus vite que le vRack et prends donc le dessus.
Jalinn