Un port fibre d'un ERS 8600 est up en 1G full duplex mais le switch n'y apprend aucune MAC
Un serveur physique sur notre ERS 8600 ne parle à personne, et le switch est pourtant convaincu que tout va bien. Le port est dans cet état depuis que le serveur est passé du cuivre à la fibre.
- Avaya ERS 8600, serveur sur un port SFP 1G en slot 3, port 12
- carte réseau du serveur avec son propre SFP, brassage fibre via le panneau du bâtiment
- port laissé à 1 Gbit/s full duplex, rien d'exotique dans la config
Ce que le switch rapporte pour ce port :
Port 3/12: up, 1000 Mbps, full duplex
FCS errors: 0
Port errors: 0
MAC addresses learned on 3/12: noneDonc le port s'entraîne, reste up pendant des jours, ne compte absolument aucune erreur, et pourtant la table de commutation n'apprend jamais la moindre adresse depuis lui. Le serveur est injoignable depuis le reste du VLAN.
Ce que j'ai essayé :
- rebasculé le port plusieurs fois, rien ne change
- basculé le contrôle de flux dans les deux sens, rien non plus
- parcouru la FDB du VLAN du serveur : des adresses depuis tous les autres ports, aucune depuis 3/12
- le serveur affirme que son propre lien est up en gigabit
Où regarderiez-vous ensuite, côté switch ou côté optique dans le serveur ?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Ce motif - lien up, full duplex, compteurs propres, table de commutation vide - signifie presque toujours que l'extrémité distante met de la lumière sur la fibre mais pas de trames valides. Le module dans le serveur est votre premier suspect, pas la configuration du switch.
Écartez d'abord le côté switch pour que personne ne puisse discuter plus tard. Dans le shell de diagnostic de l'ERS 8600, lancez
dumpPortStateetpsDump(<index du port>)pour ce port. Attention à l'index : ce n'est pas le slot/port de la CLI normale, c'est slot * 64 + (numéro de port - 1). Si ça revient avec un port local sain et des compteurs propres, le switch a fait son travail et la panne se trouve de l'autre côté de la fibre.Avant d'acheter quoi que ce soit, sortez la plante de l'équation : brassez ce port directement sur lui-même via un module de rechange du même type, puis mesurez ce qui sort et ce qui revient et voyez si les deux lectures restent stables là où la spec du module dit qu'elles devraient l'être. Après ça, changez le SFP dans la carte réseau du serveur. Dans le cas documenté avec ces symptômes, c'était tout le correctif : le port du switch a tenu le lien pendant des jours, rien d'utilisable n'est jamais sorti de la fibre, et les adresses sont apparues au moment même où le module du serveur a été remplacé.
Un avertissement si un module reconnu bon ne change rien : certaines plateformes ont un défaut logiciel qui ressemble exactement à ça. L'ERS 5900 en a un documenté : remplacez les modules d'uplink 1 Gbit/s par des SFP+ 10 Gbit/s et les liens montent actifs sans que rien ne passe dessus. Une version logicielle ultérieure le liste comme corrigé, et un reset de port ou de switch vous fait avancer en attendant. Donc si l'échange n'aide pas, lisez d'abord les notes de version de votre code.
Zéro erreur associé à zéro adresse apprise est une combinaison très particulière, donc identifiez laquelle des deux directions est réellement morte. Est-ce que les compteurs du port montrent ne serait-ce qu'une trame reçue, ou littéralement rien n'arrive ? Si le côté réception est à plat pendant que le côté émission continue de grimper, le switch parle dans le vide et votre FDB vide est un symptôme plutôt que le problème.
Ça vaut aussi la peine d'extraire tout ce que le switch a réussi à récupérer du module lui-même. Sur la gamme VSP 7000 c'est
show interfaces gbic-info, qu'on peut restreindre avecport <numéro de port>si vous voulez juste celui-là, et ça vous dit quel appareil le boîtier pense avoir installé et s'il le considère comme supporté ; si votre version d'ERS a un équivalent, postez sa sortie pour 3/12. Et dites quel module se trouve dans la carte réseau du serveur, marque et type, pas juste « un SFP ».Je suis allé dans le shell de diagnostic comme suggéré. Pour le slot 3 port 12, l'index donne 3 * 64 + 11 = 203, donc
psDump(203)plusdumpPortState- port local sain, compteurs propres, rien d'anormal sur le switch, exactement comme prévu.J'ai donc retiré le SFP de la carte réseau du serveur et mis un module de rechange du même type. L'adresse MAC était dans la table de commutation avant même que je sois retourné à mon bureau, et le serveur est joignable depuis. Un module mort côté serveur qui produisait quand même assez de lumière pour faire monter le port et l'y maintenir. Merci, j'aurais passé une journée de plus à relire la config du switch.