Ticketing CUB
Traitement d'incidents et de demandes sur la maquette CUB: diagnostic, correction, validation et formalisation de tickets de support technique.
Cette AP prolonge le projet CUB dans une logique d'exploitation. Au lieu de construire la maquette depuis zéro, il s'agissait ici de traiter des tickets d'incident ou de demande comme dans un contexte de support.
Les consignes imposaient de documenter tous les tests utiles, même infructueux, puis d'expliquer clairement la correction et la validation finale.
- Travail individuel sur la maquette CUB sous Packet Tracer.
- Progression par niveau de difficulté selon les tickets.
- Livrables: fichier ticket complété + maquette associée.
Dans mon dossier, les tickets exploitables et réellement documentés sont les tickets 00, 12, 23 et 33. Je me suis concentré sur des incidents réseau concrets touchant le VLAN, la connectivité serveur et la publication vers l'extérieur.
- Ticket 00: remise en conformité d'un port d'accès non affecté au bon VLAN.
- Ticket 12: correction de l'inaccessibilité du serveur INTRALAB par ajout du
default-gateway. - Ticket 23: transfert du serveur VALDOR vers le switch de la ferme de serveurs avec conservation du VLAN 230.
- Ticket 33: correction d'une redirection NAT statique vers la bonne adresse du serveur INTRALAB.
Comprendre si le cas relève d'un incident ou d'une demande d'évolution.
Tests de communication, lecture de la configuration et localisation de la cause.
Application des commandes Cisco ou des ajustements réseau nécessaires.
Nouveaux tests pour prouver le retour au fonctionnement attendu.
Captures extraites des tickets complétés. Elles montrent la logique de diagnostic et de correction sur plusieurs familles d'incidents.
Cette AP complète bien le projet CUB de maquettage, car elle montre la phase d'exploitation: je ne conçois plus seulement le réseau, j'interviens dessus pour diagnostiquer un incident ou appliquer une demande sans casser le reste de l'architecture.
- Lire et comprendre un ticket d'exploitation.
- Isoler la cause d'une panne réseau.
- Choisir une correction ciblée sans surcorriger.
- Prouver la résolution par des tests et une documentation associée.
Cette AP est intéressante pour l'oral car elle montre une posture de technicien SISR en exploitation: lecture d'un besoin, diagnostic, correction précise et validation. Elle est complémentaire des AP de conception car elle fait ressortir ma méthode de dépannage.
Contexte et Enjeux
L'enjeu de cette séance était de traiter des tickets de support sur une maquette déjà existante. Il fallait donc raisonner comme en exploitation: comprendre l'incident, identifier rapidement la zone de panne, corriger avec le minimum de changements puis vérifier que l'objectif demandé était atteint.
Démarche Technique
- Lecture des symptômes : prise en compte du ticket et formulation d'hypothèses.
- Contrôle des flux : tests ping, vérification des passerelles, lecture des VLAN, de la NAT et des ports concernés.
- Correction : ajout ou modification de commandes ciblées sur le bon équipement.
- Recette : reprise des tests pour confirmer la résolution ou la conformité de la demande.
Bilan et Validation E5
Cette AP valide ma capacité à exploiter une maquette réseau en mode support, à formaliser un diagnostic et à intervenir proprement sur des équipements Cisco dans un contexte de ticketing.
⚙️ Exemples de corrections
Les tickets traités illustrent plusieurs types d'intervention: correction de port VLAN, ajout de passerelle par défaut, transfert d'un serveur dans un autre segment physique et ajustement d'une règle NAT statique.
Extrait de commande
interface FastEthernet0/8
switchport access vlan 69
switchport mode access
no shut
Routeur-CUB#no ip nat inside source static tcp 172.31.9.130 80 172.30.9.9 80
ip nat inside source static tcp 172.31.9.140 80 172.30.9.9 80