Objectifs de certification

CCNA 200-301

• 1.5 Comparer TCP à UDP

• 6.3 Décrire les architectures basées contrôleur (controller-based) et software defined (overlay, underlay, et fabric)

  • 6.3.a Séparation du control plane et du data plane
  • 6.3.b APIs North-bound et south-bound

• 6.1 Expliquer comment l’automation impacte la gestion du réseau

Protocoles et modèles de communication

Les protocoles du réseau peuvent être modélisés et catégorisés selon divers critères. On trouvera dans ce premier chapitre les principes fondamentaux sur les modèles de communication et leurs protocoles : définition, catégorisation, rôles, mise en couches, encapsulation et désencapsulation. On évoquera aussi les modèles OSI et TCP/IP, les technologies LAN, WAN et dérivés sans fil ainsi que les modèles de conception.

1. Définition d’un protocole de communication

Un protocole de communication est un ensemble de règles qui rendent les communications possibles, car les intervenants sont censés les respecter.

Les protocoles définissent une sorte de langage commun que les intervenants utilisent pour se trouver, se connecter l’un à l’autre et y transporter des informations.

Les protocoles peuvent définir toute une série de paramètres utiles à une communication :

• des paramètres physiques comme des modulations, des types de supports physiques, des connecteurs …
• le comportement d’un certain type de matériel,
• des commandes,
• des machines à état,
• des types de messages,
• des en-têtes qui comportent des informations utiles au transport.

2. Standardisation, régulation et interopérabilité

2.1. Organismes de standardisation

Les protocoles sont discutés et élaborés par des organismes de standardisation.

Les protocoles TCP/IP sont formalisés par l’Internet Engineering Task Force (IETF) dans des documents publics qui prennent le nom de RFC (“Requests For Comments”). On désigne ces documents par des numéros de références. Tous les RFCs ne sont pas nécessairement des standards. Leur statut au sein du processus de standardisation peut être : Informational, Experimental, Best Current Practice, Standards Track ou Historic.¹ L’IETF dépend de l’ISOC.

Les protocoles LAN / WAN / PAN² sont par contre formalisés par d’autres organismes comme l’IEEE (IEEE 802), l’ITU, par l’ANSI,etc.

2.2. Organismes de régulation et consortiums commerciaux

On prendra garde à distinguer ces organismes de standardisation de consortiums commerciaux comme la WiFi Alliance ou des organismes étatiques nationaux et internationaux de régulation comme le FCC, l’ETSI, l’IBPT, …

Les organismes de régulation donnent les conditions d’usage des ondes sur l’espace public. Ce sont des organismes sous l’autorité des États qui s’entendent au niveau de l’Institution Internationale des Communications (ITU).

Les consortiums commerciaux tels que la “Wi-Fi Alliance” assurent que des matériels de fournisseurs respectant un standard comme IEEE 802.11 soient compatibles entre eux.

3. Nomenclature des protocoles

On peut catégoriser les protocoles sur base de différents critères comme la signalisation, la maintenance de la connexion, la fiabilité, selon les plans gestion, contrôle, donnée ou encore selon le type de technologie TCP/IP, LAN, WAN.

3.1. Signalisation

On désigne ici par “signalisation” tout message qui comprend des commandes utiles du protocole.

Un protocole à signalisation In-Band embarque la signalisation avec les données dans un même canal (HTTP).

Un protocole à signalisation Out-of-Band utilise une signalisation dans un protocole distinct (en téléphonie IP les protocoles SIP/SDP/RTP) ou un canal dédié (FTP).

En téléchargeant les livres du Guide CCNA 200-301 vous encouragez son auteur !

3.2. Maintenance de la connexion

Un protocole Orienté Connexion est celui qui établit, maintient et ferme un canal au préalable de l’envoi des données (TCP, FTP).

Un protocole Non Orienté Connexion : Ethernet, IP, UDP, TFTP sont non orientés connexion et ne proposent aucun mécanisme de maintenance.

3.3. Fiabilité

Un protocole Fiable met en oeuvre des mécanismes de fiabilité tel que la reprise sur erreur, des accusés de réception, du contrôle de flux, etc. (TCP).

Un protocole Non fiable : Ethernet, IP, UDP, TFTP sont non fiables et ne proposent aucun mécanisme de fiabilité.

Les caractéristiques fiabilité et maintenance sont souvent associées, mais les deux caractéristiques peuvent être dissociées.

3.4. Plans

Les quatre plans “Data”, “Control”, “Management”, “Services” sont des concepts pour identifier le “plan” des opérations sur un routeur (L3) ou un commutateur (L2) ou dans une architecture.

Le plan Donnée (Data plane) fait référence aux fonctions et processus de transfert de paquets. On y trouve des protocoles transportant des données des utilisateurs (HTTPS, FTP, RTP), l’encapsulation de données. La qualité de service (QoS), le filtrage sont aussi sur ce plan.

Le plan Contrôle (Control plane) concerne toutes les fonctions de création des chemins comme les protocoles de routage (OSPF, EIGRP, BGP) ou les protocoles LAN IEEE 802.1 (Spanning-Tree, Etherchannel, VLANs), les protocoles de redondance du premier saut FHRP (HSRP, VRRP, GLBP), etc. Ils émanent de l’infrastructure. Les protocoles de gestion d’infrastructure comme la résolution de noms (DNS), d’attributions d’adresses (DHCP, RA, DHCPv6), de voisinage (ARP/ND) peuvent être classés dans cette catégorie.

Le plan Gestion (Management plane) est le plan des fonctions de gestion et de surveillance des périphériques. On y trouve des protocoles d’accès distant (AAA, RADIUS, SSH), de supervision (NTP, SYSLOG, SNMP), de transfert de fichier (FTP, TFTP, SSH/SCP/SFTP). On pensera aussi aux interfaces “API” Rest supportées par HTTP et/ou HTTPS qui permettent de contrôler du matériel et des solutions de type NFV / SDN.

Le plan Services (Services plane) est un cas spécifique du plan Données (Data plane) pour du trafic qui demande une transformation comme par exemple l’encapsulation en tunnels GRE, MPLS VPNs, le chiffrement/déchiffrement TLS/IPsec, le mécanisme QoS, etc.

4. Modèles de communication

Un modèle de communication en couches organise les communications entre les hôtes sous forme d’enveloppement hiérarchique. Chaque couche remplit une fonction spécifique à la communication et dispose de caractéristiques propres. Chaque couche utilise un protocole, soit un ensemble de règles de communication.

La couche est enveloppée dans la couche sous-jacente. On parle alors d’encapsulation.

On utilisera principalement le modèle TCP/IP pour expliquer les communications au niveau logique. Le modèle OSI n’a plus d’intérêt que dans sa distinction entre la couche L1 et la couche L2 au niveau de la couche d’accès au réseau.

4.1. Avantages d’un modèle de communication en couches

Un modèle de communication en couches dispose de plusieurs avantages :

• Il permet de mieux comprendre le véritable fonctionnement des communications. Il est utile à l’apprentissage.
• Il est utile au diagnostic et au dépannage.
• Il permet de développer ou d’adapter de nouvelles fonctionnalités sans à revoir l’ensemble du modèle. Les modifications peuvent intervenir uniquement sur le protocole de la couche concernée.
• Il favorise l’interopérabilité entre différents matériels, technologies et constructeurs. Il favorise la croissance du marché dans le secteur des infrastructures et de services IT.

4.2. Modèles de communication utilisés dans ce document

On discutera dans ce document de quelques modèles de communication :

1. Le modèle TCP/IP qui implémente les technologies les plus courantes.
2. Le modèle OSI qui sert de référence académique et qui trouve des correspondances par rapport aux technologies TCP/IP, LAN et WAN.
3. Les technologies LAN (Ethernet, Wi-Fi) et les technologies WAN (PPP, PPPoE, GRE, VPN) qui disposent de leur propre modélisation au niveau des couches dites “basses”, soit proches du signal physique dans les couches Physique (L1) et Liaison de données (L2).

4.3 Protocoles TCP/IP

Les protocoles TCP/IP relèvent de la “logique”, du logiciel, où d’une part, l’Internet Protocol (IP) identifie les noeuds de communication à travers l’interréseau et les meilleurs chemins, et où d’autre part, TCP ou UDP assurent la fonction de transport de bout en bout alors qu’un protocole de couche application rend un service de communication.

C’est la technologie “Internet” qui utilise la pile des protocoles TCP/IP qui permet que des services comme Facebook, Google ou encore Amazon puissent fonctionner. C’est grâce à TCP/IP que nous pouvons tous les jours aller sur Internet.

IP pour Internet Protocol, dans sa version 4 ou sa version 6, est celui qui permet d’identifier l’interface de communication de n’importe quels ordinateurs dans le monde et d’acheminer des paquets de données d’une extrémité du globle à une autre. TCP (Transmission Control Protocol) est celui qui permet de maintenir un canal fiable entre deux points IP. Son équivalent sans fiabilité et sans connexion est UDP (User Datagram Protocol). TCP et UDP transportent des protocoles applicatifs comme HTTPS ou DNS. Ces protocoles applicatifs sont utilisés par nos logiciels pour transporter des pages Web, des images, du son, bref n’importe quel type de données.

4.4. Protocoles LAN et WAN

Les technologies et protocoles LAN/WAN relèvent du matériel/physique. Elles assurent le transport et la livraison physique des données sur les liaisons locales avec les technologies :

• LAN : Technologies au sein des réseaux locaux (confinés localement, rapides et permanents) : Ethernet, Wi-Fi, Bluetooth, WiMax, etc.
• WAN : Technologies qui interconnectent les routeurs, points intermédiaires de connectivité, plus lentes et couvrant de longues distances : xDSL/PPPoE, Metro-Ethernet, DOCSIS, LTE, 3G/4G/5G, Satelite, HDLC, Frame-Relay, ATM, … mais aussi les connexions VPN.

Ces technologies disposent de leur qualification “Wireless” avec WPAN, WLAN, WWAN.

Les technologies LAN, WAN, PAN, WLAN, WPAN, WWAN sont dites des technologies d’accès, car elles permettent d’accéder aux réseaux qui autorisent des connexions de bout en bout d’une extrémité à l’autre du globe, a priori en TCP/IP.

Si cette distinction fondamentale LAN/WAN tient essentiellement à la portée des technologies ou à leur usage, ce sont aussi d’autres critères comme l’origine de leur standardisation qui les opposent dans les rôles ou leurs objectifs.

En téléchargeant les livres du Guide CCNA 200-301 vous encouragez son auteur !

5. Modèles de conception

Cisco Systems a contribué à la popularité des modèles de conception des réseaux. Ces modèles sont des guides de déploiement des infrastructures du réseau qui permettent aux organisations de rencontrer des objectifs de performance et de disponibilité. On parle aussi d’architectures ou de topologie ou encore de design dans ce cadre. Les modèles de conception représentent la mise en oeuvre opérationnelle des protocoles du réseau dans l’infrastructure physique afin de contrôler au mieux le trafic et atteindre le niveau de service attendu par l’entreprise.

5.1. Modèles de conception traditionnels

On avait jusqu’en plus ou moins 2016 des modèles de déploiement respectant des architectures traditionnelles avec un modèle de conception hiérarchique et modulaire à trois couches : Access, Distribution et Core. Chaque couche assurant des rôles spécifiques sur l’objectif, les protocoles autorisés, les limites de la couche 2 et la couche 3, la sécurité, etc. Le chapitre ultérieur intitulé “Principes de conception LAN” évoque le sujet plus amplement.

Bien souvent, ces infrastructures sont difficiles à gérer et à faire évoluer. Elles demandent des interventions manuelles répétitives. Une vue unifiée de la surveillance et de la sécurité sont alors un véritable enjeu dans la gestion quotidienne de l’infrastructure ainsi que les reprises sur erreurs et la gestion des incidents.

Les architectures qui existent depuis longtemps deviennent difficiles à faire évoluer en demandant beaucoup d’interventions manuelles. Il n’est pas étonnant que l’environnement aie un impact sur les mentalités des professionnels en charge des infrastructures réseau.

Ces modèles sont toutefois toujours d’application dans les réseaux d’entreprise, ne fut-ce qu’en surcouche (overlay) d’une infrastructure physique sous-jacente – qui pourrait être conçue d’une autre manière.

5.2. Intent-Based Networks

“Intent-Based Networks” (IBN) est une nouvelle perspective de la gestion des réseaux dont l’acronyme est typiquement sorti des équipes marketing de chez Cisco. Les objectifs “Business” de l’organisation devraient être traduits en “policies” du réseau par les professionnels de l’informatique de telle sorte que le réseau puisse atteindre ces objectifs de manière automatisée et à grande échelle, à titre d’“intention”.

Il s’agirait en fait de se rapprocher de plus en plus d’architectures offrant du “Network as a Service” (NaaS). IBN demande une autre approche de la gestion de l’infrastructure avec d’autres interfaces que la ligne de commande (CLI) telle que la gestion à travers d’APIs HTTP REST avec des langages de programmation comme Python et des retours présentés en format JSON. Ces technologies sont déjà disponibles grâce à des déploiements de type SDN (“Software Defined networks”) qui utilisent des contrôleurs pour centraliser la gestion de l’infrastructure.

Dans les offres des technologies WAN, on trouvera de plus en plus du “Software Defined WAN” (SD-WAN) voyant la connectivité WAN comme un service à la demande, prêt à la production et à l’évolutivité, comme par exemple commander à la demande des liaisons WAN entre deux villes d’un pays de manière “élastique”. Son équivalent dans le LAN/WLAN (réseau local filaire et sans-fil) SD Access (SDA) apparaît dans les offres des fabricants. Avec SDN, le plan de contrôle et le plan data sont clairement distingués de telle sorte que les pratiques de gestion s’en trouvent modifiées.

Cette nouvelle vision du réseau a déjà eu pour conséquence de changer les infrastructures réseau du centre de données avec les concepts de fabrique (Fabric), de topologie “Spine/Leaf” (à deux niveaux) ou encore avec l’implémentation de protocoles comme VxLAN et l’intégration des réseaux SAN (de stockage, Storage Area Network, qui se distingue du LAN).

Aussi, avec IBN, on trouvera une multitude de propositions de déploiement du plan “contrôle” : dans le nuage, en local, embarqué sur les périphériques, etc. Les accès au réseau sans-fil devraient mieux s’intégrer aux infrastructures locales filaires, le “contrôle” pouvant disposer d’une vue abstraite des accès avec des politiques de sécurité unifiées.

Enfin, une nouvelle pratique fait son apparition avec celle de “Network Assurance” dans laquelle on retrouve des exigences de surveillance en temps réel avec des protocoles traditionnels, du reporting et des réponses automatiques. Concrètement, cela signifie que de nouvelles compétences en programmation, en automation et en gestion d’infrastructures virtuelles (locales ou dans le nuage) devront s’ajouter aux compétences des équipes en charge des réseaux, en plus de la connaissance des nouvelles architectures qu’ils devront gérer (ils n’en seront pas nécessairement les concepteurs initiaux).

6. Éléments clés à retenir

Les éléments clés à retenir concernant les protocoles et modèles réseau sont les suivants :

1. le rôle d’un protocole de communication réseau
2. les critères de distinction des protocoles (signalisation, connexion, fiabilité, plans)
3. la distinction entre les plans “donnée”, “contrôle” et “gestion”
4. la distinction entre technologie d’accès et technologie Internet
5. la distinction entre technologies d’accès LAN et WAN
6. le concept de modèle en couche et d’encapsulation
7. le rôle des modèles de communication comme TCP/IP ou OSI
8. les modèles de conception de réseau
9. les concepts d’“Intent-Based Networks” (IBN) et de “Software Defined networks” (SDN)
10. le concept de topologie “Spine/Leaf”

En conclusion, un modèle de communication est une référence à maîtriser si l’on désire comprendre les technologies des réseaux.