Journal de bord

• 🛠️ Migration Cisco → Allied Telesis

  📅 État d’avancement : terminé ✅

  La migration est complètement finalisée. Beaucoup de choses ont avancé — avec et sans moi — mais globalement, tout est en place.

  J’ai passé beaucoup de temps à approfondir la QoS, afin de bien comprendre son fonctionnement, notamment sur les switchs Allied Telesis, qui gèrent la QoS de manière similaire aux anciens Cisco 3560. C’était parfois un peu fastidieux, mais formateur.

  📁 Un fichier Excel de correspondances Cisco ⇄ Allied Telesis a été créé, partagé dans un dossier accessible à toute l’équipe. (📸 Voir capture).

  🔄 Exemples de correspondance de commandes

  
  

  🔹 VLANs

  
  

  Cisco :

  
  

  CopierModifier
  vlan 99
  int vlan 99
  ip address X.X.X.X 255.255.255.0 
  no shut
  

  
  

  Allied Telesis :

  
  

  CopierModifier
  vlan database
  vlan 99 name management
  vlan 99 state enable
  interface vlan99
   description #LAN#VLAN UTILISATEURS
   ip address X.X.X.X/24
  

  
  

  🔹 Pool d’interfaces

  
  

  Cisco :

  
  

  CopierModifier
  interface range gi 1/0/1-24
  switchport mode access
  switchport access vlan 5
  switchport voice vlan 205
  switchport port-security
  switchport port-security maximum 3 
  switchport port-security aging time 1
  switchport port-security violation shutdown
  switchport port-security aging type inactivity
  no cdp enable
  no snmp trap link-status
  no logging event link-status
  spanning-tree portfast
  spanning-tree bpduguard enable
  snmp trap mac-notification change added
  snmp trap mac-notification change removed
  ip arp inspection limit rate 30 burst interval 2
  ip dhcp snooping limit rate 50
  srr-queue bandwidth share 1 70 25 5
  priority-queue out
  lldp receive
  lldp transmit
  lldp med-tlv-select network-policy
  

  
  

  Allied Telesis :

  
  

  CopierModifier
  switchport
  switchport mode access
  switchport access vlan 5
  switchport port-security
  switchport port-security aging
  switchport port-security maximum 3
  switchport port-security violation shutdown
  ip dhcp snooping max-bindings 3
  service-policy input QOS-INPUT
  wrr-queue queue-limit 20 15 15 15 20 5 5 5
  snmp trap link-status
  snmp trap mac-change add remove
  spanning-tree portfast
  spanning-tree portfast bpdu-guard enable
  switchport voice vlan 205
  ip dhcp snooping violation log trap link-down
  arp security violation log trap link-down
  arp security drop link-local-arps
  

  
  

  🔹 QoS (Quality of Service) – Focus principal 🎯

  
  

  Cisco :

  
  

  CopierModifier
  mls qos map policed-dscp  0 24 32 34 40 46 to 8
  mls qos map cos-dscp 0 8 16 24 32 46 48 56
  ...
  mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14
  mls qos queue-set output 1 threshold 1 100 100 100 2000
  mls qos queue-set output 1 buffers 15 30 35 20
  mls qos
  

  
  

  Allied Telesis :

  
  

  CopierModifier
  mls qos enable
  mls qos map premark-dscp 34 to new-cos 4
  mls qos map premark-dscp 34 to new-queue 4
  ...
  mls qos map premark-dscp 56 to new-cos 7
  mls qos map premark-dscp 56 to new-queue 7
  

  
  

  ➡️ Allied utilise aussi des access-lists hardware et des class-map / policy-map pour faire de la correspondance fine sur les VLANs, les DSCP, ou encore des ports/services (TCP/UDP).

  Voici un extrait des configs avancées pour Teams, Web, MGT, Streaming, etc.

  Exemple :

  
  

  CopierModifier
  class-map CM_VOICE
   match dscp 46
   match vlan 205
  
  policy-map QOS-INPUT
   class CM_VOICE
    set dscp 46
    set queue 5
  

  
  

  ✅ Résultat final :

  
  

  Quasiment toute la config Cisco a pu être migrée sur Allied Telesis.

  Les fonctionnalités sont là, seule la syntaxe change.

  La logique de QoS, plus ancienne, demande une autre approche mais est maîtrisée.

  Un gros travail de traduction et de documentation a été réalisé, ce qui facilitera les futures migrations.

  
  

  

  Publié le 2025-05-26 09:44:46

• 
  

  

  Publié le 2025-05-26 09:25:26

• 
  

  

  Publié le 2025-05-26 09:25:03

• 
  

  

  Publié le 2025-05-26 09:24:41

• Test Migration CISCO --> Allied Telesis

  📅 Contexte

  Le responsable a décidé de lancer un test en commandant des switchs Allied Telesis, pour voir s’ils peuvent remplacer nos équipements Cisco, qui sont actuellement en place sur toute notre infra.

  👉 Le but est de réduire les coûts, car les switchs Cisco, en plus d’être chers à l’achat, nécessitent des licences coûteuses, pouvant atteindre plusieurs centaines de milliers d’euros par an.

  🧪 Matériel testé

  Le modèle choisi pour les tests est le AT-X530L-28GTX.

  On a récupéré la configuration complète d’un switch Cisco déjà en production, et l’objectif est de reproduire le comportement à l’identique (ou aussi proche que possible) sur le switch Allied.

  ⚙️ Problèmes rencontrés

  
  

  Les commandes diffèrent fortement entre Cisco et Allied.

  
  

  Parfois, ce n’est qu’une variation de syntaxe (ex : noms d’interfaces, séparateurs, etc.)

  
  

  D’autres fois, c’est la philosophie de configuration qui change complètement.

  
  

  La documentation Allied est moins accessible et souvent plus lourde à parcourir que celle de Cisco 📚.

  
  

  🎯 Cas spécifique : la QoS

  La QoS est une partie critique dans nos configs Cisco : beaucoup de classes, de policies, de maps, de priorité.

  Mais sur les switchs Allied Telesis, la logique est différente :

  
  

  Les concepts de classification, de marquage et de scheduling ne s’appliquent pas de la même manière.

  
  

  Il est parfois difficile de trouver une équivalence directe, surtout quand la doc n’est pas claire ou que le protocole est un peu abstrait.

  
  

  🔄 Travail en cours

  
  

  Je continue à traduire la configuration ligne par ligne pour qu’elle soit compatible avec les switchs Allied.

  
  

  ➡️ Je m’appuie sur :

  
  

  Les docs officielles (quand elles sont compréhensibles 😅)

  
  

  Des exemples de configuration

  
  

  De la lecture croisée entre les guides Cisco et Allied

  
  

  Beaucoup de tests en CLI pour valider chaque étape

  
  

  
  

  🧭 Prochaine étape : finaliser la traduction QoS + tests de charge et de comportement en conditions réelles.

  Publié le 2025-05-20 13:49:35

• Récap des dernières semaines

  Je ne tiens plus ce journal à jour quotidiennement, tout simplement parce que les missions commencent à se ressembler !

  Alors, oui et non. En réalité, je fais plein de choses. Mais ce sont souvent des missions qui, au fil des semaines, se répètent.

  J’ai quand même la chance de toucher à beaucoup d’aspects du métier. Je manipule du matériel, je découvre des outils, des environnements différents… Bref, j’ai une vision assez large du domaine.

  
  

  Les missions récurrentes (et pas toujours pertinentes à détailler) :

  Elles représentent la majorité de mon quotidien :

  
  

  Gestion des tickets reçus,

  Ouverture de flux,

  Création ou modification de règles,

  Tests de connexions,

  Identification des ports en erreur sur les switchs, exécution de commandes shut / no shut.

  
  

  Mais voici un petit florilège de missions un peu plus intéressantes réalisées récemment :

  🔄 Remplacement d’équipements suite à un changement d’opérateur

  Suite au passage de notre opérateur Free Pro (anciennement Jaguar Network) à Celeste, Free Pro nous a demandé de leur retourner leur matériel : routeurs, boîtiers opérateurs, etc. Cela concernait plusieurs marques comme Juniper, Cisco, Ciena ou RAD.

  Ces équipements permettaient de déployer leur réseau sur nos différentes infrastructures.

  J’ai donc dû :

  
  

  Identifier les équipements dans les différents datacenters,

  Les débrancher proprement,

  Les emballer et les étiqueter,

  Les expédier selon leurs consignes.

  
  

  Il y a plusieurs datacenters dans la région Sud, mais je détaillerai ça dans un autre billet.

  
  

  📶 Gestion du Wifi – Analyse de dysfonctionnements

  Nous avions trois bornes Cisco défectueuses, sans comprendre l’origine du problème.

  Nous avons :

  
  

  Débranché les bornes,

  Les avons ramenées au bureau pour les tester → aucun souci détecté.

  On a donc suspecté un problème de câblage (paire torsadée endommagée ou connectique instable).

  
  

  Nous avons ensuite fait un test simple :

  → Brancher directement la borne sur la baie de brassage de l’étage concerné (au lieu du port mural).

  Après quelques jours d’observation, tout fonctionnait.

  Conclusion : le souci venait bien du câblage mural.

  
  

  🧭 Déploiement complémentaire d’une borne au CESER (Pôle Finances)

  Lors du remplacement massif des bornes wifi, une borne de l’étage avait été retirée.

  Il ne restait plus qu’une borne pour tout l’étage, ce qui posait problème, surtout pour les intervenants externes sans accès RJ45.

  Nous avons donc :

  
  

  Préconfiguré une nouvelle borne au bureau via le DNA Center,

  Puis déployé la borne sur place au CESER.

  → Résultat : installation réussie, tout fonctionne parfaitement.

  
  

  🛠 Réunion avec un prestataire – Projet Wifi Événementiel

  La région a lancé un projet autour du wifi événementiel. Le cahier des charges :

  
  

  Le mot de passe du wifi événementiel doit changer chaque semaine.

  Il doit être affiché automatiquement (écran, autre support...).

  L’automatisation doit se faire via DNA Center, connecté à l’affichage.

  L’activation/désactivation du wifi doit être possible par des personnes hors DSI-SART.

  
  

  Nous avons eu une réunion avec Spie, un de nos prestataires, pour discuter de leur proposition.

  Le concept était intéressant, mais pas totalement abouti selon nos attentes.

  Nous avons insisté pour avoir une solution clé en main, simple à gérer et à maintenir.

  Spie doit maintenant soit développer une telle solution, soit nous rediriger vers une entreprise qui la propose déjà.

  
  

  Publié le 2025-05-12 09:04:12

• Semain 2 et 3

  Les missions commencent clairement à se dessiner : il y a moins de nouveautés, mais plus de concret.

  Avec l’aide de mon maître de stage, je réalise les missions quotidiennes suivantes :

  
  

  Effectuer la maintenance des appareils présents sur le réseau : repérer les failles, réaliser les mises à jour.

  
  

  Gérer les tickets : on reçoit des demandes de divers services, que l’on traite souvent en créant de nouvelles règles ou en modifiant certaines existantes.

  
  

  J’ai dû, seul, modifier une quinzaine de règles suite à une erreur : il a fallu les corriger en ajustant les protocoles, en supprimant ceux en trop ou en ajoutant ceux manquants.

  
  

  Harun me donne régulièrement des choses à réviser : des protocoles ou du matériel que l’on utilise, comme MPLS/VPLS, VTP, MSTP… Ce sont des notions que je connais déjà, mais qu’il est bon de revoir pour bien comprendre le réseau de l’entreprise.

  
  

  J’ai également travaillé sur un routeur 5G.

  
  

  Il y a aussi eu une plénière avec tous les élus de la région, ainsi que le président Renaud Muselier. On a dû intervenir pour tester le bon fonctionnement du Wi-Fi afin que tous les élus puissent accéder à Internet.

  Voilà voilà !

  Publié le 2025-04-24 07:02:21

• JOUR 5 et 6

  Durant ces deux jours, j’ai eu l’opportunité d’accompagner Haroun dans la gestion quotidienne des tickets d’intervention. Les demandes arrivent généralement par mail (la plateforme de ticketing étant peu utilisée par les utilisateurs). Chaque ticket est une enquête : on identifie le problème, on l’analyse, puis on agit.

  Parmi les actions les plus fréquentes :

  
  

  Création ou modification de règles sur les firewalls

  Vérification de l’état des switchs (ex. : port désactivé ou non)

  Résolution de problèmes de connectivité utilisateur, comme une mauvaise attribution d’IP. Dans ce cas, on remonte jusqu’au port réseau pour vérifier l’affectation VLAN

  Chaque matin, nous commençons par consulter le rapport du service d’exploitation, qui recense les vulnérabilités identifiées, notamment par le CERT. L’objectif : analyser les alertes pour déterminer si nos équipements sont concernés.

  Un exemple concret : une alerte liée à une faille de sécurité sur les firewalls Palo Alto. Après lecture de l'article technique, nous avons constaté que si notre firewall principal n'était pas affecté, nos firewalls virtuels utilisaient le VPN SSL vulnérable. Nous avons donc appliqué les correctifs préconisés sans attendre.

  Autre tâche importante : la mise à jour de notre parc de switchs via le Cisco Catalyst Center. Après avoir identifié les modèles concernés (9500, 3650, etc.), nous avons comparé les versions recommandées par le CERT et Cisco, téléchargé les firmwares adaptés, et programmé les mises à jour pendant les plages horaires de maintenance.

  Publié le 2025-04-15 07:40:06

• JOUR 4

  Des personnes en charge de la vidéosurveillance sont venues dans notre bureau car l'alarme d'une des caméras ne répondait plus.

  Elles sont venues pour nous indiquer le switch concerné, l’adresse IP et le port utilisé, afin de comprendre pourquoi cela ne fonctionnait pas.

  Nous avons identifié le bon switch, vérifié si le port était actif, et grâce à un ping, nous avons constaté que l’alarme ne répondait effectivement pas.

  Il s’est avéré que l’alarme n’était pas dans le bon VLAN. Nous avons simplement modifié le VLAN du port correspondant.

  Après avoir relancé le ping, l’alarme répondait correctement.

  Publié le 2025-04-10 13:17:52

• JOUR 4

  Ce matin, je suis allé voir Alexandre.

  Il occupe un poste dans la partie Exploitation, qui se trouve toujours dans le SART (se référer au diagramme).

  Il m’a montré un peu ce qu’il faisait.

  Premièrement, il vérifie chaque matin que les logs des serveurs de sauvegarde ont bien été poussés pendant la nuit.

  Il m’a ensuite expliqué la gestion des logiciels utilisateurs, notamment avec le logiciel Microsoft SCCM, utilisé pour la gestion des postes de travail des utilisateurs (ordinateurs fixes, portables, téléphones, etc.).

  Il m’a aussi montré le firewall Palo Alto, via l’interface web Palo Alto Panorama.

  On a pu voir les règles de filtrage ainsi que l’enregistrement de l’activité des utilisateurs.

  Par exemple, on a pu visualiser toutes les requêtes effectuées par un utilisateur grâce à son identifiant de la ville (nom).

  Dans notre cas, on a pris l’exemple d’Alexandre : après avoir effectué quelques recherches sur son poste, on a pu observer en détail chaque requête effectuée grâce au pare-feu.

  Publié le 2025-04-10 12:15:31

• JOUR 3

  Aujourd’hui je suis seul dans l’équipe réseaux.

  Présentation de l’équipe admin système.

  En premier lieux j’ai rencontré une personne qui s’occuper de la bdd, Leur base de données est basée sur Oracle, un des leaders de la base de données. Avec 30ans d’ancienneté il a vu les systèmes beaucoup évoluer.

  J’ai vu on va dire le superviseur de l’équipe système. (C’est un ancien de R&T), lui m’a parler de toutes l’infra.

  Ce que j’ai retenu là-dessus, c’est qu’ils font beaucoup de virtualisation, environs 350 vm. Sur 9 serveurs de virtualisation. Il y’a trois DC de stockage donc on est sur le central dans l’hôtel de région, y’a 3 baies je crois (pas certain), un a AZURE*, et enfin un dans le bâtiment en face, celui-là c’est vraiment pour la sauvegarde.

  D’ailleurs il m’a parlé d’un projet qui devrait arriver en fin d’année. En gros ils veulent externaliser une partie du DC, pour plusieurs raisons notamment le fait qu’il n’y ait pas maintenance sure sur l’infrastructure pure du DC, notamment l’électricité et tout.

  
  

  
  

  
  

  
  

  *AZURE : c’est un bâtiment qui se situe prêt de la joliette et c’est relier en synchrone avec l’hôtel de région

  Publié le 2025-04-09 08:34:31

• JOUR 2

  Dans l’après-midi, j’ai pu accéder au firewall et voir comment ça marchait. L’interface est quand même bien différente de Stormshield mais y’a des ressemblances.

  On a fait de la gestion de ticket, globalement une personne disait un disfonctionnement dans les accès de réseaux etc... Et on allait vérifier sur le firewall si y’avait bien une règle de filtrage si oui est ce qu’elle était bien faite s'il n'y en avait pas on en crée une etc...

  

  Publié le 2025-04-09 08:22:36

• JOUR 2

  On peut trouver aussi des audits de sécurisé passé chaque année.

  
  

  J’ai fait la visite du DC. Ce que l’on observe déjà c’est que leur DC est en réalité géré par Schneider. Il y’a à 2 baies qui sont exclusivement à eu, et enfin trois autres avec les équipements “classique” donc on y retrouve des router, les firewalls, des boitiers fibres etc...

  Publié le 2025-04-09 08:14:53

• JOUR 2

  le service informatique au complet : 

  

  Publié le 2025-04-09 08:10:23

• JOUR 2

  J’ai réceptionné mon ordinateur.

  Le 2ème firewall est un Palo alto.

  J’ai accès au serveur de fichier de la DSIPN, ce groupe comporte plusieurs Service.

  Publié le 2025-04-09 07:59:41

• JOUR 1

  Présentation du bâtiment, des bureaux ainsi que de l’équipe notamment réseau et systèmes.

  J’ai vu très rapidement comment faire une maj d’un switch avec l’outils Cisco Catalyst Center. De ce que j’ai vu on a des Catalyst de séries 3000 et des 9500, (à vérif mais le routage se fait seulement sur les 9500)

  Y’a aussi un autre panel cette voici via une VM (connexion à distance via Windows mstsc..). Y’a tous les switches présents dans le réseau avec une connexion direct pour les config. On est directement en {#en}. [J’ai pas le nom du soft pour le moment]

  
  

  Ce que j’ai appris aujourd’hui :

  (Marque CISCO)                      - Une centaine de switch dans le réseau

  (Marque CISCO)                      - Plusieurs centaines de modem wifi dans le réseau

  Je n’ai pas encore vu le DC.

  Je sais déjà que le FW est de la marque Fortinet et qu’ils le config en mode graphiques accès HTTPS.

  Le 2ème FW je ne connais pas la marque pour le moment.

  Concernant le théorique je n’ai rien appris de nouveau. Mais c’est le premier jour.

  Feeling : Début calme mais c’est normal.

  Effectif : Emmanuelle et Moi

  Publié le 2025-04-09 07:58:16