Introduction

L’é­vo­lu­tion des réseaux infor­ma­tiques a connu une trans­for­ma­tion fon­da­men­tale ces der­nières années, pas­sant d’une approche prin­ci­pa­le­ment manuelle à une vision auto­ma­ti­sée et pro­gram­mable. Cette évo­lu­tion n’est pas sim­ple­ment une ten­dance tech­no­lo­gique, mais une réponse néces­saire à la com­plexi­té des infra­struc­tures réseau modernes. La ver­sion 1.1 du Cis­co CCNA recon­naît cette réa­li­té en intro­dui­sant l’au­to­ma­ti­sa­tion et de la pro­gram­ma­bi­li­té des réseaux.

Les Fondements de l’Automatisation Réseau

L’au­to­ma­ti­sa­tion réseau repré­sente la capa­ci­té à confi­gu­rer, déployer, gérer et tes­ter des dis­po­si­tifs et ser­vices réseau de manière auto­ma­ti­sée plu­tôt que manuelle. 

Fini les com­mandes pas­sées à la mano sur une console Cisco.

Modèles de Contrôleur et Architecture Centralisée

Du Contrôle Distribué au Contrôle Centralisé

Tra­di­tion­nel­le­ment, les réseaux fonc­tion­naient selon un modèle dis­tri­bué où chaque équi­pe­ment (rou­teur, com­mu­ta­teur) pre­nait ses propres déci­sions basées sur sa vision locale du réseau. Cette approche pré­sen­tait des limi­ta­tions signi­fi­ca­tives en termes de cohé­rence et d’adaptabilité.

L’ar­chi­tec­ture basée sur les contrô­leurs repré­sente une énorme évo­lu­tion chez Cis­co. Dans ce modèle, un contrô­leur cen­tral pos­sède une vision glo­bale du réseau et prend les déci­sions que les équi­pe­ments exé­cutent. Pour com­prendre cette dif­fé­rence, ima­gi­nez la dis­tinc­tion entre un orchestre sans chef (chaque musi­cien joue selon sa propre inter­pré­ta­tion) et un orchestre diri­gé (où le chef d’or­chestre assure cohé­rence et harmonie).

Architecture Contrôleur-Agent

Dans l’ar­chi­tec­ture contrô­leur-agent, deux com­po­sants prin­ci­paux interagissent :

1. Le contrô­leur : Cer­veau du réseau, il main­tient une vue com­plète de la topo­lo­gie et de l’é­tat du réseau. Il cal­cule les poli­tiques et les che­mins opti­maux, puis com­mu­nique ces déci­sions aux agents.
2. Les agents : Pré­sents sur chaque équi­pe­ment réseau, ils exé­cutent les ins­truc­tions reçues du contrô­leur et lui remontent des infor­ma­tions sur leur état et celui de leurs connexions.

Cette sépa­ra­tion entre « pen­ser » (contrô­leur) et « agir » (agents) per­met une ges­tion plus intel­li­gente et réac­tive du réseau. Par exemple, en cas de conges­tion détec­tée sur un lien, le contrô­leur peut rapi­de­ment recal­cu­ler des che­mins alter­na­tifs et ins­truire tous les équi­pe­ments concer­nés d’a­dap­ter leur com­por­te­ment de routage.

Avantages de la Centralisation

La cen­tra­li­sa­tion du contrôle réseau offre plu­sieurs béné­fices substantiels :

• Vision glo­bale : Contrai­re­ment aux équi­pe­ments tra­di­tion­nels qui ne voient que leurs voi­sins directs, le contrô­leur pos­sède une vue com­plète de la topo­lo­gie, per­met­tant des déci­sions plus éclairées.
• Cohé­rence des poli­tiques : Les règles et poli­tiques sont défi­nies une seule fois au niveau du contrô­leur et appli­quées uni­for­mé­ment à tra­vers tout le réseau.
• Sim­pli­ci­té d’o­pé­ra­tion : Les admi­nis­tra­teurs inter­agissent prin­ci­pa­le­ment avec le contrô­leur via des inter­faces uni­fiées, rédui­sant la néces­si­té de confi­gu­rer indi­vi­duel­le­ment chaque équipement.
• Agi­li­té accrue : Les chan­ge­ments de poli­tique peuvent être déployés ins­tan­ta­né­ment à l’é­chelle du réseau entier.

Un exemple concret de cette approche est Cis­co DNA Cen­ter, qui fonc­tionne comme un contrô­leur cen­tra­li­sé pour l’en­semble du réseau d’entreprise.

Protocoles de Programmabilité Réseau

Pour per­mettre la com­mu­ni­ca­tion entre contrô­leurs et équi­pe­ments réseau, plu­sieurs pro­to­coles stan­dar­di­sés ont été déve­lop­pés. Ces pro­to­coles consti­tuent la colonne ver­té­brale de l’au­to­ma­ti­sa­tion réseau.

NETCONF (Network Configuration Protocol)

NETCONF est un pro­to­cole qui per­met d’ins­tal­ler, mani­pu­ler et sup­pri­mer la confi­gu­ra­tion des équi­pe­ments réseau. Déve­lop­pé par l’IETF, il uti­lise un modèle client-ser­veur où le contrô­leur agit comme client et l’é­qui­pe­ment réseau comme serveur.

Contrai­re­ment aux méthodes tra­di­tion­nelles comme Tel­net ou SSH qui traitent les confi­gu­ra­tions comme du texte brut, NETCONF struc­ture les don­nées de confi­gu­ra­tion, offrant plu­sieurs avantages :

• Tran­sac­tions ato­miques : Les modi­fi­ca­tions de confi­gu­ra­tion sont appli­quées dans leur inté­gra­li­té ou pas du tout, évi­tant les états inconsistants.
• Vali­da­tion inté­grée : NETCONF véri­fie la vali­di­té des confi­gu­ra­tions avant leur application.
• Roll­back auto­ma­tique : En cas d’er­reur, le sys­tème peut reve­nir auto­ma­ti­que­ment à l’é­tat précédent.

Un exemple sim­pli­fié d’o­pé­ra­tion NETCONF serait :

Cette com­mande confi­gu­re­rait l’in­ter­face GigabitEthernet1 avec une des­crip­tion spé­ci­fique et l’activerait.

RESTCONF

RESTCONF est une exten­sion de NETCONF qui uti­lise les prin­cipes REST (Repre­sen­ta­tio­nal State Trans­fer) et le for­mat JSON, plus léger et plus facile à mani­pu­ler pour les déve­lop­peurs. Il expose les don­nées et opé­ra­tions NETCONF via une API HTTP/HTTPS.

La même confi­gu­ra­tion que ci-des­sus pour­rait s’ex­pri­mer en RESTCONF via une requête HTTP PUT :

RESTCONF sim­pli­fie l’in­té­gra­tion avec les outils de déve­lop­pe­ment modernes et faci­lite l’au­to­ma­ti­sa­tion via des scripts ou des pla­te­formes d’orchestration.

gRPC

gRPC (Google Remote Pro­ce­dure Call) est un fra­me­work RPC open source déve­lop­pé par Google qui per­met des com­mu­ni­ca­tions client-ser­veur hau­te­ment effi­caces. Il uti­lise HTTP/2 pour le trans­port et Pro­to­col Buf­fers pour le séria­li­sa­tion des don­nées, offrant des per­for­mances supé­rieures aux approches REST traditionnelles.

Dans le contexte des réseaux Cis­co, gRPC est uti­li­sé notam­ment dans le modèle gNMI (gRPC Net­work Mana­ge­ment Inter­face) qui permet :

• Des com­mu­ni­ca­tions bidi­rec­tion­nelles en temps réel
• La télé­mé­trie en strea­ming pour sur­veiller l’é­tat du réseau
• Des opé­ra­tions de confi­gu­ra­tion à haute performance

L’ef­fi­ca­ci­té de gRPC en fait un choix pri­vi­lé­gié pour les envi­ron­ne­ments néces­si­tant des mises à jour fré­quentes ou un moni­to­ring en temps réel.

Formats de Données pour l’Automatisation

L’un des piliers de l’au­to­ma­ti­sa­tion réseau est l’u­ti­li­sa­tion de for­mats de don­nées struc­tu­rées qui peuvent être faci­le­ment trai­tés par des machines tout en res­tant lisibles par les humains.

YANG (Yet Another Next Generation)

YANG est un modèle de don­nées essen­tiel qui sous-tend NETCONF et RESTCONF. Il défi­nit la struc­ture, la syn­taxe et la séman­tique des don­nées de confi­gu­ra­tion et d’é­tat des équi­pe­ments réseau. Les modèles YANG stan­dar­disent la repré­sen­ta­tion des fonc­tion­na­li­tés réseau, faci­li­tant l’in­te­ro­pé­ra­bi­li­té entre équi­pe­ments et sys­tèmes d’automatisation.

XML (eXtensible Markup Language)

XML est un for­mat de bali­sage flexible uti­li­sé depuis long­temps dans les sys­tèmes infor­ma­tiques. Dans le contexte réseau, il est le for­mat natif de NETCONF. Ses carac­té­ris­tiques prin­ci­pales sont :

• Struc­ture hié­rar­chique : Per­met de repré­sen­ter des rela­tions com­plexes entre éléments
• Sché­mas de vali­da­tion : Via DTD ou XSD, assu­rant l’in­té­gri­té des données
• Par­seurs lar­ge­ment dis­po­nibles : Faci­li­tant le trai­te­ment dans presque tous les langages

XML est ver­beux mais com­plet, ce qui le rend par­ti­cu­liè­re­ment adap­té aux sys­tèmes néces­si­tant une docu­men­ta­tion exhaus­tive des struc­tures de données.

JSON (JavaScript Object Notation)

JSON est deve­nu le for­mat d’é­change de don­nées domi­nant pour les appli­ca­tions web et les API modernes, y com­pris RESTCONF. Plus com­pact que XML, il pré­sente plu­sieurs avantages :

• Syn­taxe légère : Moins de carac­tères pour repré­sen­ter les mêmes informations
• Par­sing plus rapide : Trai­te­ment plus effi­cace par les applications
• Cor­res­pon­dance directe avec les struc­tures de don­nées dans de nom­breux lan­gages de programmation
• Lisi­bi­li­té natu­relle pour les humains

Un exemple de confi­gu­ra­tion réseau en JSON :

YAML (YAML Ain’t Markup Language)

YAML est sou­vent pri­vi­lé­gié pour les fichiers de confi­gu­ra­tion humai­ne­ment lisibles et édi­tables. Sa syn­taxe mini­ma­liste faci­lite la créa­tion et la modi­fi­ca­tion manuelles :

• Inden­ta­tion signi­fi­ca­tive au lieu de déli­mi­teurs explicites
• Réfé­rences et ancres per­met­tant de réuti­li­ser des éléments
• Sup­port natif des types sca­laires (nombres, boo­léens, etc.)

La même confi­gu­ra­tion en YAML s’écrirait :

YAML est par­ti­cu­liè­re­ment appré­cié dans les outils d’au­to­ma­ti­sa­tion comme Ansible, où les play­books sont écrits dans ce format.

Conversion entre Formats

L’in­te­ro­pé­ra­bi­li­té entre ces for­mats est cru­ciale dans les envi­ron­ne­ments hété­ro­gènes. Des biblio­thèques comme PyYAML, json, et xml­to­dict en Python per­mettent de conver­tir faci­le­ment les don­nées entre ces formats :

Cette flexi­bi­li­té per­met d’adap­ter les for­mats aux besoins spé­ci­fiques de chaque com­po­sant de l’é­co­sys­tème d’automatisation.

Impact sur l’Architecture et l’Exploitation des Réseaux

L’a­dop­tion de ces tech­no­lo­gies d’au­to­ma­ti­sa­tion et de pro­gram­ma­bi­li­té trans­forme fon­da­men­ta­le­ment la concep­tion et l’ex­ploi­ta­tion des réseaux. Cis­co l’a bien com­pris et a déve­lop­pé des outils et ses tech­no­lo­gies depuis de nom­breuses années pour aller dans cette direction.

Passage d’un Paradigme Impératif à Déclaratif

Tra­di­tion­nel­le­ment, les réseaux étaient confi­gu­rés de manière impé­ra­tive : les admi­nis­tra­teurs spé­ci­fiaient exac­te­ment com­ment effec­tuer chaque tâche (les fameuses séquences pré­cises de com­mandes CLI). L’au­to­ma­ti­sa­tion favo­rise une approche décla­ra­tive où l’on spé­ci­fie ce qui doit être accom­pli, lais­sant au sys­tème le soin de déter­mi­ner com­ment y parvenir.

Cette tran­si­tion est com­pa­rable au pas­sage de l’as­sem­bleur à des lan­gages de haut niveau en pro­gram­ma­tion : on gagne en abs­trac­tion, en lisi­bi­li­té et en main­te­na­bi­li­té. Mais j’a­voue ce fut un beau chan­ge­ment pour les tech­ni­ciens et ingé­nieurs reseau car il y a une forte com­po­sante de déve­lop­pe­ment informatique.

Infrastructure as Code (IaC)

L’au­to­ma­ti­sa­tion per­met de gérer l’in­fra­struc­ture réseau comme du code source, appor­tant plu­sieurs avan­tages issus des pra­tiques de déve­lop­pe­ment logiciel :

• Ver­sion­ne­ment : Les confi­gu­ra­tions peuvent être sto­ckées dans des sys­tèmes comme Git, per­met­tant de suivre leur évo­lu­tion et de reve­nir à des ver­sions anté­rieures si nécessaire.
• Tests auto­ma­ti­sés : Les chan­ge­ments peuvent être vali­dés dans des envi­ron­ne­ments de test avant déploie­ment en production.
• Déploie­ment conti­nu : Les modi­fi­ca­tions peuvent être déployées auto­ma­ti­que­ment après vali­da­tion, rédui­sant les délais d’implémentation.
• Docu­men­ta­tion vivante : Le code d’in­fra­struc­ture sert lui-même de docu­men­ta­tion tou­jours à jour.

Nouvelles Compétences pour les Professionnels Réseau

Cette évo­lu­tion requiert une trans­for­ma­tion des com­pé­tences des ingé­nieurs réseau, qui doivent désor­mais maîtriser :

• Des lan­gages de pro­gram­ma­tion (par­ti­cu­liè­re­ment Python)
• Les prin­cipes d’A­PI et d’in­té­gra­tion
• La pen­sée algo­rith­mique et l’automatisation
• La ges­tion de don­nées structurées
• Les métho­do­lo­gies DevOps

Ces nou­velles com­pé­tences ne rem­placent pas l’ex­per­tise réseau tra­di­tion­nelle mais la com­plètent, créant un pro­fil d’in­gé­nieur réseau plus poly­va­lent et plus ali­gné avec les besoins des entre­prises numé­riques modernes.

Conclusion

L’au­to­ma­ti­sa­tion et la pro­gram­ma­bi­li­té réseau repré­sentent bien plus qu’une simple évo­lu­tion tech­no­lo­gique ; elles consti­tuent un chan­ge­ment fon­da­men­tal dans la façon dont les réseaux sont conçus, déployés et gérés. 

La maî­trise des modèles de contrô­leur, des pro­to­coles comme NETCONF, RESTCONF et gRPC, ain­si que des for­mats de don­nées struc­tu­rées (XML, JSON, YAML) est essen­tielle pour le CCNA