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?
Passerelle non fonctionelle sur instance Public Cloud
Related questions
- Dimensionnement serveur MySQL
45280 
07.11.2018 12:32
- [RESOLU] Connexion impossible en SSH
37905 05.06.2019 20:05
- Bonjour, Je n'est reçus aucun mot de passe root lors de mon achat!
33193 05.02.2018 20:47
- Gitlab private docker registry
32885 16.03.2018 13:05
- Ssh connection timed out port 22
32312 11.12.2019 08:21
- Configuration IP failover avec netplan (Ubuntu 17.10)
31743 12.01.2018 23:23
- Problème connexion ssh
31531 04.02.2018 09:46
- IP Failover sur Debian 9
31088 18.11.2016 20:40
- Instance Public Cloud en "error"
28737 15.12.2025 10:04
- Connexion OpenStack Swift Object Storage
24797 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