Dépannage du réseau

Chaque entrée nomme un symptôme, sa cause et ce qu'il faut faire. Les identifiants de message renvoient à l'entrée des codes d'erreur.

Aucune adresse pour un serveur

Cause. Le pool n'a plus d'adresse IPv4 libre ni de bloc IPv6 libre (error.ip_pool.exhausted). Les adresses allouées, réservées ou en quarantaine ne comptent pas comme libres. Le serveur peut aussi n'avoir aucune carte réseau sur le réseau du pool (error.ip_pool.no_nic), ou la carte a déjà une adresse principale dans ce pool (error.ip_pool.primary_exists).

Solution.

1. Lisez les adresses libres du pool : kyvernon ip-pools available <pool>.
2. Lisez ce que le serveur possède : kyvernon addresses list <vm>.
3. Libérez les adresses qui ne servent plus, ou étendez les plages du pool : kyvernon ip-pools update <pool> --range <first>-<last>.
4. Pour un serveur sans carte adaptée, ajoutez-en une sur le réseau du pool dans les paramètres matériels de la machine virtuelle.

Adresse utilisée ou en quarantaine

Cause. Un autre appelant a pris l'adresse entre la liste et l'attribution (error.ip_pool.address_in_use), ou l'adresse a été libérée récemment et reste en quarantaine pendant 14 jours, sauf si le pool définit une autre durée (error.ip_pool.address_quarantined).

Solution. Listez de nouveau les adresses libres avec kyvernon ip-pools available <pool> et choisissez-en une autre, ou attribuez sans nommer d'adresse pour prendre la première libre. kyvernon ip-pools allocations <pool> indique quand une quarantaine se termine.

Carte réseau sans pont

Cause. Une carte réseau est connectée à un réseau qui n'a pas de pont d'hôte, et ne peut donc pas être branchée sur un pont au démarrage de la machine virtuelle (error.nic_network_unwired). La console affiche un tel réseau avec le pont Non relié.

Solution.

1. Donnez un pont au réseau : kyvernon network update <id> --body-file network.json, avec un backing qui nomme le pont.
2. Ou connectez la carte à un réseau qui a un pont.
3. Mettez de nouveau la machine virtuelle sous tension.

Mode proxy refusé

Cause. Le mode de liaison montante proxy demande un pont Open vSwitch et le nom de l'interface de liaison montante. L'interface manque, porte le nom du pont, ou le réseau est un réseau de quarantaine ou un pont Linux (error.network.proxy_uplink).

Solution. Définissez "uplink": {"mode": "proxy", "interface": "eno1"} sur un réseau Open vSwitch, avec le vrai nom de l'interface de l'hôte, ou utilisez le mode bridged.

L'adresse publique ne répond pas

Cause. L'adresse est allouée, mais le trafic n'arrive pas. Raisons courantes : le pont ou le VLAN de l'hôte ne correspond pas au réseau, le fournisseur n'accepte pas l'adresse MAC de l'invité en mode pont, ou l'invité n'a pas configuré l'adresse. Seule l'adresse IPv4 principale arrive par DHCP ; les adresses supplémentaires et le bloc IPv6 se configurent dans l'invité.

Solution.

1. Vérifiez le pont, le VLAN et la MTU sur l'hôte : kyvernon host network-health <host>. Un état autre que ok nomme ce qui diffère.
2. Lisez les adresses du serveur : kyvernon addresses list <vm>, et comparez-les à la configuration dans l'invité.
3. Quand le fournisseur filtre les adresses MAC, passez la liaison montante en mode proxy comme décrit dans Pools d'adresses IP.
4. Une carte réseau qui émet depuis une adresse qui ne lui a pas été donnée est bloquée par la sécurité des ports ; allouez d'abord l'adresse à la carte.

Le réseau ne peut pas être supprimé

Cause. Une machine virtuelle a encore une carte réseau sur le réseau. La requête échoue avec une erreur de précondition et liste les machines virtuelles.

Solution. Connectez ces cartes à un autre réseau ou supprimez-les, puis supprimez de nouveau le réseau : kyvernon network delete <id>.

Le pool ne peut pas être supprimé ni modifié

Cause. Le pool a encore des allocations (error.ip_pool.in_use), une plage chevauche celle d'un autre pool du même réseau (error.ip_pool.overlap), ou le préfixe IPv6 et la longueur de bloc ne peuvent pas changer tant que des blocs sont alloués ou en quarantaine (error.ip_pool.ipv6_layout_in_use).

Solution. Libérez les adresses avec kyvernon addresses release <vm> ou kyvernon ip-pools free <pool> <address>, attendez la fin de la quarantaine, puis modifiez le pool. Comparez les plages des deux pools avec kyvernon ip-pools get <pool>.

Le DNS inverse reste demandé

Cause. En mode manuel, un nom reste enregistré comme demandé tant qu'un opérateur ne l'a pas confirmé. En mode automatique, le fournisseur DNS peut le refuser : aucune zone inverse ne contient l'adresse (error.rdns.no_zone), le nom ne se résout pas vers l'adresse (error.rdns.not_forward_confirmed), ou le fournisseur n'a pas accepté la modification (error.rdns.provider_failed).

Solution. Appliquez le nom chez le fournisseur, puis exécutez kyvernon ip-pools ptr-applied <pool> <address> ; ou rejetez-le avec un motif : kyvernon ip-pools ptr-rejected <pool> <address> --reason <text>. Pour les autres causes, créez d'abord l'enregistrement direct du nom, ou répétez la demande plus tard. Voir DNS inverse.

Courrier sortant bloqué

Cause. Le pool bloque le port TCP 25 sortant : IPv4 est autorisé et IPv6 bloqué par défaut, et un serveur peut être débloqué individuellement.

Solution. Un opérateur lit et modifie l'état : kyvernon addresses smtp <vm>, et kyvernon addresses smtp <vm> --unblock --reason <text>. La modification est enregistrée comme un événement.

Une carte sur un groupe de ports distribué n'a pas de lien

Cause. Les réseaux logiques OVN ne sont pas activés (pas de [ovn] dans controller.toml), le contrôleur a perdu sa connexion à la base OVN Northbound, ou l'hôte n'a pas lié le port logique : ovn-controller sur l'hôte n'est pas connecté à la base Southbound, ou une condition préalable de l'hôte n'est pas remplie.

Solution.

1. Lisez la réalisation avec GET /v1/network/realization. connected doit valoir true et realizedGeneration être égal à modelGeneration ; sous hosts, l'hôte de la machine virtuelle doit indiquer applied: true et compter le port dans portsInstalled. preconditions nomme ce qui manque à l'hôte.
2. Sur l'hôte, lancez sudo bash deploy/server1/ovn-doctor.sh host ; sur l'hôte du contrôleur, sudo bash deploy/server1/ovn-doctor.sh central. Chaque ligne marquée FAIL nomme l'étape à refaire.
3. Quand l'événement NetworkNorthboundLostEvent est le plus récent des événements réseau, redémarrez la base Northbound ; le contrôleur se reconnecte et réécrit chaque segment et chaque port.

Voir aussi

• Réseaux sur pont d'hôte
• Adresses publiques
• Trafic pour un serveur dont le débit est limité