Problème démarrage réseau debian jessie 8.4

Support Debian
#1

Bonjour,
Je rencontre des soucis de démarrage de cartes réseaux.
Sur un serveur supermicro,
carte mère supermicro x9dr7-tf+ avec 2 intel 10 gbps intégrées.

Sur une install de debian 8.4 toute fraîche :

  • Message LSB job “raise network interfaces” au démarrage
  • dès le login, je me connecte. Le ping ne répond pas. La carte réseau eth0 ne répond pas.
    30-40 sec après, le réseau fonctionne.
  • Une fois que le réseau fonctionne, si je débranche / rebranche le câble réseau, ça remet 30-40 sec avant de pinguer.
  • J’ai essayé de créé un fichier par carte réseau dans /etc/systemd/network,

[code][Match]
MACAddress=00:25:90:82:bf:fc

[Link]
Name=eth0
ipaddress=1.2.3.4
[/code]

pareil.

J’ai également le fichier /var/log/dmesg vide.
ça fonctionnait bien avec debian 7.

ça fait plusieurs jours que je tourne en rond. Au secours !! :grinning:

#2

Ok, mais tu tiens absolument à utiliser networkd ?

Je veux dire, avec Jessie cela ne pose aucun problème de continuer à utiliser /etc/network/interfaces ou un fichier dans /etc/network/interfaces.d/ .

Par contre, oui, systemd étant installé par défaut sous Jessie, le composant journald est imposé pour stocker les logs.
Pour voir les logs, tu peux passer par la commande journalctl pour afficher les logs ou tu peux installer un daemon syslog auquel journald transmettra les logs que tu pourras retrouver ensuite dans /var/log .

Sinon, il est possible d’installer le paquet sysvinit-core pour dégager systemd, ce qui marche assez bien sauf si tu dois utiliser un environnement graphique.
Une autre possibilité est de se mettre à devuan afin de retrouver un peu de santé mentale.

–
AnonymousCoward

#3

J’aurai dû être plus explicite aussi :smile:
Je souhaite utiliser proxmox 4.2. Distribution basée sur debian 8.4.

J’ai mis un sujet chez eux mais je n’ai rien.

Le problème est identique en instalant debian 8.4.
Je ne tien pas a utiliser networkd
Après install, le fichier /etc/network/interfaces est renseigné (voir ci après).
/etc/network/interfaces.d/ est vide.

Pas d’environnement graphique.
Je vais voir si je peux virer systemd et si une mise à jour de proxmox ne le réinstalle pas.
Je ne connaissais pas le fork devuan. je regarderai car on peut installer proxmox sur une jessie 8.4.
Mais si je trouve une solution directement sur l’installation proxmox 4.2, ça serait impec.

Je suis tombé sur une page où quelqu’un remplace dans le fichier interfaces :auto par allow-hotplug
ça ne fonctionne pas mieux.
Mais, peut être parce que eth0 est bridgé sur vmbr0 ?

[code]# network interface settings; autogenerated

Please do NOT modify this file directly, unless you know what

you’re doing.

If you want to manage part of the network configuration manually,

please utilize the ‘source’ or ‘source-directory’ directives to do

so.

PVE will preserve these directives, but will NOT its network

configuration from sourced files, so do not attempt to move any of

the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

iface eth2 inet manual

iface eth3 inet manual

iface eth4 inet manual

iface eth5 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.10.20
netmask 255.255.255.0
gateway 192.168.10.251
bridge_ports eth0
bridge_stp off
bridge_fd 0

iface vmbr1 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0

iface vmbr2 inet manual
bridge_ports eth2
bridge_stp off
bridge_fd 0

iface vmbr3 inet manual
bridge_ports eth3
bridge_stp off
bridge_fd 0

iface vmbr4 inet manual
bridge_ports eth4
bridge_stp off
bridge_fd 0

iface vmbr5 inet manual
bridge_ports eth5
bridge_stp off
bridge_fd 0
[/code]

#4

J’ai fait un apt-get install sysvinit-core.
Pareil après reboot :grin:

#5

Combien y-a-t-il de ports réseau sur ces “2 intel 10 gbps intégrées” ? Je pose la question car dans votre fichier /etc/network/interfaces vous référencez 6 ethx ce qui supposerait un nombre impair de ports par interface, très curieux.

Donc en fait, cela n’a jamais fonctionné ?

Je vous conseille de regarder du côté de

dmesg | fgrep -i eth | less

Vérifiez le pilote noyau et avec lsmod qu’il est bien chargé.
De plus avec systemd + udev on a parfois des surprises du genre

[    7.224042] systemd-udevd[338]: renamed network interface eth1 to rename3
[    7.266490] systemd-udevd[342]: renamed network interface eth2 to eth1
[    7.292232] systemd-udevd[341]: renamed network interface eth2 to eth3
[    7.312666] systemd-udevd[338]: renamed network interface eth1 to eth2

et dans mon cas (bonding) il a fallu réfléchir calmement pour savoir quoi allait avec quoi :wink:

Bon courage.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

#6

Effectivement, si c’est pour du proxmox, cela change tout.

Puisque cela veut dire qu’il y a probablement utilisation d’un bridge / switch virtuel. Soit les bridge-utils soit open vSwitch (OVS), ce dernier étant quand-même un peu plus adapté.

Et là où il y a un bridge / switch il y a souvent le Spanning Tree Protocol. Et là où on utilise STP il y a un délai qui peut aller jusqu’à 50s.
Même si STP était désactivé du coté de Debian, il peut l’être sur le switch en amont du Debian.

La seule manière de garder STP activé en évitant ce long délai est de pouvoir utiliser Rapid Spanning Tree Protocol (RSTP) et de configurer les ports en “edge port” / “portfast” AVEC utilisation de “BPDU filter” ou “BPDU guard”.
Et je ne suis pas sûr que ce soit possible à faire sous Linux, y compris avec open vSwitch.

Terminons en précisant que je déconseille fortement de désactiver STP : une boucle sur le réseau Ethernet et quasiment tout part en vrille.

–
AnonymousCoward

#7

Après quelques essais, ça ne vient pas du tout de debian.
J’ai installé windows 2008 : pareil
Je branche un ordi portable avec Windows 7 : pareil (les 30-40 sec lors du débranchement / rebranchement câble réseau)
Je branche l’ordi portable et le supermicro via un petit switch : ça marche normalement. Le réseau répond immédiatement.

Je regarde les logs du switch, un cisco sg220-50. Et là, de belles lignes :

STP port state is set to Blocking STP port state is set to Learning STP port state is set to Forwarding

C’est donc le switch qui met du temps à activer le port.
Je vais être hors sujet car non debian, mais quelqu’un aurait des pistes où chercher ?

Je n’ai pas de liaison avec d’autres switch.

merci

#8

Est-ce que tu as eu l’occasion de lire la dernière version de mon précédent post ?

Quoiqu’il arrive, une petite minute d’attente au démarrage d’un serveur, bon, ce n’est quand-même pas la mer à boire.

–
AnonymousCoward

#9

Je comprend que la minute d’attente fait “ridicule”…
Je pensais que le quorum du cluster aurait peut-être du mal à se faire à cause de ce délai.

Je ne connaissais pas du tout le STP, à part qu’il permet de brancher un switch en secours.

A la lecture du post, j’ai pensé que tu parlais du STP uniquement sur Open vSwitch. Je n’ai pas pensé au switch.
J’ai voulu tester avec un autre OS et switch ensuite pour voir.

Je vais laisser tel quel. C’est le mieux quand on ne connait pas.
Peut-être une formation sur le sujet un jour.
merci beaucoup en tout cas :wink:

#10

En fait, STP (et ses variantes) est surtout là pour empêcher la création de boucles sur le réseau Ethernet.
Cet article Wikipedia explique le problème.

Et, par exemple, 2 switchs reliés directement entre eux par 2 câbles réseau, cela forme une boucle. A moins que l’on regroupe les liens en une agrégation de liens (LAG).

S’il y a plusieurs liens différents entre deux switches, STP les désactivera tous sauf un. Si ce dernier s’interrompt, un lien précédemment désactivé sera réactivé.

–
AnonymousCoward

#11

Je connaissais le problèmes des boucles sur un réseau, mais pas le STP.
Merci pour le lien :slight_smile: