TSHOOT – Niveau 2 – Ticket 3

Troisième articles dédié au Troubleshooting de niveau 2.

Nous continuerons ici notre entrainement à la résolution d’erreur sur des switchs.

 

1) Scénario et topologie

 

Afin de réaliser des travaux dans les locaux, il a été nécessaire de débrancher les liens entre ASW1 et DSW2. De même pour ASW2 – DSW1.

Confiant en la redondance mise en place, vous autorisez les ouvriers à procéder à la coupure.

Quelques temps après, des employés viennent vous voir pour vous dire qu’ils n’ont plus accès au réseau. Ceux-ci sont connectés au switch ASW1, qui n’est d’ailleurs plus accessible.

Vous demandez alors aux ouvriers de rebrancher les câbles entre ASW1 et DSW2.
Malheureusement, les liens n’ont été totalement retirés, et il ne sera pas possible de les remettre avant plusieurs jours.

 

Alors que vous cherchez une solution, un collègue prend l’initiative de restaurer une ancienne configuration, pensant que la redondance était bonne à l’époque.

Malheureusement les sauvegardes qu’il avait à disposition n’étaient pas fiables.

Du coup, les clients connectés à ASW2 n’ont plus non plus de réseau.

 

Il faut trouver une solution rapidement.

 

La topologie est la suivante.

Dans cet article nous nous concentrerons sur les PC Client 1 et FTP Serveur.

 

2) Troubleshooting ASW1

 

Résumons la situation.

Les liens ASW1 – DSW2 ont été retirés.

Nous avons alors perdu tout contact avec ASW1.

Voyons l’état des interfaces de DSW1.

L’agrégation entre ASW1 et DSW1 semble fonctionnelle.

 

Voyons si le lien est bloqué par le Spanning Tree.

Non.

Le lien semble OK, mais le switch ASW1 est injoignable.

 

Vérifions la configuration du lien sur DSW1.

Etrangement, le lien DSW1 – ASW1 utilise l’encapsulation ISL.

Cela provient peut être des sauvegarde qui ont été restaurées.

 

Changeons l’encapsulation pour voir.

DSW1(config)#interface port-channel 13
DSW1(config-if)#switchport trunk encapsulation dot1q

Parfait, nous avons retrouvé ASW1.

 

Comme l’encapsulation n’était plus bonne, les frames tagués ne passaient plus.

Le lien ASW1 – DSW2 étant down, il n’y avait pas de chemin alternatif.

 

Après vérifications, les clients connectés sur ASW1 ont à nouveau accès au réseau.

 

3) Troubleshooting ASW2

 

A priori, les clients connectés à ASW2 n’ont plus non plus accès au réseau.

En effet.

 

N’oublions pas que le lien ASW2 – DSW1 est coupé.

 

Vérifions la configuration IP.

La configuration semble bonne.

Au passage, lors de la préparation de l’article j’avais oublié de configurer la Gateway du PC (ici 10.2.2.1).

Il n’y avait donc aucune Gateway.

Lors d’un Ping, s’il n’y a pas de passerelle configurée, le message d’erreur est le suivant :

Reprenons.

Vérifions si l’IP de passerelle (10.2.2.1) sur FTP Serveur est bonne.

Oui.

 

Vérifions l’interface sur laquelle le PC est connecté.

Elle est UP.

 

Vérifions sa configuration.

Voici le problème.

Le port est dans le VLAN 40.

 

Etant donné que l’IP correspond au VLAN 20, nous allons changer le VLAN sur le switch.

ASW2(config)#interface fastEthernet 0/10
ASW2(config-if)#switchport access vlan 20

Testons le résultat.

Nous progressons, mais le résultat n’est toujours pas bon.

 

D’après la commande « Show ip interface brief », l’interface Po 2 (ASW2 – DSW2) est UP.

 

Vérifions le Spanning Tree.

Malgré le fait que l’interface soit UP, Spanning Tree bloque Po2.

Nous pouvons voir le message PVID_Inc.

En PVST, ce message indique qu’un BPDU a été reçu sur un VLAN différent que celui sur lequel il a été émis.

Entre deux switchs, c’est typique d’une erreur sur le VLAN natif.

 

Comparons les configurations de ASW2 et DSW2.

Le VLAN natif n’est pas le même des deux côtés.

 

Procédons au changement.

DSW2(config)#interface port-channel 24
DSW2(config-if)#switchport trunk native vlan 666

 

Le diagnostic aurait pu être réalisé avec la commande suivante :

Testons.

Un Ping vers Client 1 est aussi concluant.

Parfait !

FTP Serveur a retrouvé un accès au réseau.