Comment prendre le contrôle de son infrastructure réseau. Chapitre deux. Nettoyage et documentation

Cet article est le deuxième d'une série intitulée « Comment maîtriser votre infrastructure réseau ». Vous pouvez trouver le contenu de tous les articles de cette série et les liens associés. ici.

Notre objectif à ce stade est de mettre de l'ordre dans la documentation et la configuration.
À la fin de ce processus, vous devriez disposer d'un ensemble de documents nécessaires et d'un réseau configuré en conséquence.

Nous ne parlerons pas ici de l'audit de sécurité – cela sera abordé dans le troisième volet.

La complexité de la tâche assignée à ce stade varie considérablement d'une entreprise à l'autre.

La situation idéale est celle où

• votre réseau a été créé selon un projet et vous disposez de l'ensemble des documents.
• votre entreprise a mis en œuvre un processus de contrôle et de gestion des changements pour le réseau.
• Conformément à ce processus, vous détenez des documents (y compris tous les plans nécessaires) fournissant des informations complètes sur la situation actuelle.

Dans ce cas, votre tâche est assez simple. Vous devez examiner les documents et passer en revue tous les changements qui ont été effectués.

Dans le pire des scénarios, vous aurez une

• un réseau construit sans projet, sans plan, sans approbation, par des ingénieurs sans qualifications adéquates,
• avec des changements chaotiques, non documentés, et une abondance de « déchets » et de solutions sous-optimales.

Il est évident que votre situation se situera quelque part entre les deux, mais malheureusement, sur cette échelle, il y a de fortes chances que vous soyez plus près de l'extrémité inférieure.

Dans ce cas, vous aurez également besoin d'une capacité à lire dans les pensées, car vous devrez apprendre à comprendre ce que les « concepteurs » ont voulu faire, reconstituer leur logique, terminer ce qui n'a pas été achevé et éliminer les « déchets ».
Et bien sûr, vous devrez corriger leurs erreurs, modifier (à ce stade aussi peu que possible) le design, et modifier ou recréer les schémas.

Cet article ne prétend en aucun cas à l'exhaustivité. Je vais décrire ici seulement les principes généraux et aborder certains problèmes courants qui doivent être résolus.

Ensemble de documents

Commençons par un exemple.

Voici quelques documents souvent créés chez Cisco Systems lors de la conception.

CR – Exigences client, spécifications du client (cahier des charges).
Élabore en collaboration avec le client et définit les exigences du réseau.

HLD – High Level Design, conception de haut niveau basée sur les exigences du réseau (CR). Ce document explique et justifie les décisions architecturales prises (topologie, protocoles, choix de matériel,…). Le HLD ne contient pas de détails de conception, tels que les interfaces utilisées et les adresses IP. La configuration spécifique du matériel n'est pas non plus discutée ici. Ce document est plutôt destiné à expliquer aux responsables techniques du client les principales concepts de conception.

LLD – Low Level Design, conception de bas niveau basée sur le haut niveau (HLD).
Il doit contenir tous les détails nécessaires à la réalisation du projet, tels que les informations sur la manière de raccorder et de configurer le matériel. C'est un guide complet pour la mise en œuvre de la conception. Ce document doit fournir suffisamment d'informations pour sa mise en œuvre même par un personnel peu qualifié.

Des éléments tels que les adresses IP, les numéros AS, le schéma de câblage peuvent être « externés » dans des documents séparés, tels que NIP (Plan d'Implémentation du Réseau).

La construction du réseau commence après l'élaboration de ces documents et se déroule strictement conformément à ceux-ci, puis est vérifiée par le client (tests) pour assurer la conformité avec le design.

Bien sûr, les exigences en matière de documentation de projet peuvent varier d'un intégrateur à l'autre, d'un client à l'autre, et d'un pays à l'autre. Mais nous aimerions éviter les formalités et considérer la question de fond. Cette étape ne concerne pas la conception, mais l'organisation, et nous avons besoin d'un ensemble de documents suffisant (schémas, tableaux, descriptions…) pour accomplir nos tâches.

À mon avis, il existe un minimum absolu, sans lequel il est impossible de contrôler efficacement le réseau.

Ces documents sont les suivants :

• schéma (journal) de câblage
• schéma ou schémas réseau avec des informations L2/L3 pertinentes

Schéma de câblage

Dans certaines petites entreprises, les travaux liés à l'installation de matériel et au câblage sont sous la responsabilité des ingénieurs réseau.

Dans ce cas, le problème est en partie résolu par l'approche suivante.

• utilisez la description sur l'interface pour décrire ce qui y est connecté.
• Désactivez administrativement (shutdown) tous les ports non connectés du matériel réseau

Cela vous permettra, même en cas de problème de lien (lorsqu'il n'y a pas de cdp ou de lldp sur cette interface), de déterminer rapidement ce qui est connecté à ce port.
Vous pourrez également facilement voir quels ports sont occupés et lesquels sont libres, ce qui est nécessaire pour planifier les connexions de nouveau matériel réseau, de serveurs ou de stations de travail.

Cependant, il est évident que si vous perdez l'accès au matériel, vous perdrez aussi l'accès à ces informations. De plus, de cette manière, vous ne pourrez pas consigner des informations aussi importantes que le type de matériel, la puissance consommée, le nombre de ports, l'emplacement dans le rack, quelles sont les panneaux de brassage et vers où (dans quel rack/panneau de brassage) ils sont connectés. C'est pourquoi une documentation supplémentaire (pas seulement les descriptions sur le matériel) est très utile.

L'idéal serait d'utiliser des applications créées pour travailler avec ce type d'informations. Mais vous pouvez également vous contenter de simples tableaux (par exemple, dans Excel) ou afficher les informations que vous jugez nécessaires dans des schémas L1/L2.

Attention !

L'ingénieur réseau peut bien connaître les subtilités et les normes de la SCSI, les types de racks, les types d'onduleurs, ce qu'est un couloir froid et un couloir chaud, réaliser une mise à la terre correcte,… tout comme il peut connaître la physique des particules élémentaires ou le C++. Mais il faut néanmoins comprendre que cela ne fait pas partie de son domaine de compétence.

C'est pourquoi il est recommandé d'avoir des départements ou des personnes dédiées pour résoudre les tâches liées à l'installation, à la connexion, au maintien du bon fonctionnement du matériel, ainsi qu'à la commutation physique. En général, pour les centres de données, ce sont des ingénieurs de centre de données, et pour un bureau, un help-desk.

Si de tels départements sont prévus dans votre entreprise, alors la tenue de journaux de commutation physique n'est pas votre tâche, et vous pouvez vous limiter à la description sur l'interface et à la désactivation administrative des ports non utilisés.

Schémas de réseau

Il n'existe pas d'approche universelle pour dessiner des schémas.

Le plus important est que les schémas doivent donner une compréhension de la manière dont le trafic circulera, à travers quels éléments logiques et physiques de votre réseau.

Par éléments physiques, nous entendons

• équipements actifs
• interfaces/ports des équipements actifs

Par logiques —

• appareils logiques (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLANs
• sous-interfaces
• tunnels
• zones
• …

Ainsi, si votre réseau n'est pas complètement élémentaire, il se composera de différents segments.
Par exemple

• data center
• internet
• WAN
• accès à distance
• LAN de bureau
• DMZ
• …

Il serait raisonnable d'avoir plusieurs schémas qui donnent à la fois une vue d'ensemble (comment le trafic circule entre tous ces segments) et une explication détaillée de chaque segment individuel.

Étant donné qu'il peut y avoir de nombreux niveaux logiques dans les réseaux modernes, il peut être judicieux (mais pas obligatoire) de créer différents schémas pour différents niveaux, par exemple, dans le cas d'une approche de superposition, cela pourrait être les schémas suivants :

• overlay
• L1/L2 sous-jacent
• L3 sous-jacent

Bien sûr, le schéma le plus important, sans lequel il est impossible de comprendre l'idée de votre conception, est le schéma de routage.

Schéma de routage

Au minimum, ce schéma doit refléter

• quels protocoles de routage et où ils sont utilisés
• informations principales sur les paramètres de routage (zone/numéro AS/id de routeur/…)
• sur quels appareils se produit la redistribution
• où a lieu le filtrage et l'agrégation des routes
• informations sur la route par défaut

De plus, un schéma L2 (OSI) est souvent utile.

Schéma L2 (OSI)

Ce schéma peut refléter les informations suivantes :

• quels VLANs
• quels ports sont des ports trunk
• quels ports sont agrégés en ether-channel (port channel), port channel virtuel
• quels protocoles STP et sur quels appareils ils sont utilisés
• paramètres principaux de STP : root/root backup, coût STP, priorité de port
• paramètres supplémentaires de STP : protection/filtering BPDU, protection d'arbre…

Erreurs typiques en conception

Exemple d'une mauvaise approche pour la construction d'un réseau.

Prenons un exemple simple de construction d'un réseau local de bureau simple.

Avec de l'expérience dans l'enseignement des télécommunications aux étudiants, je peux dire qu'en fait, n'importe quel étudiant, au milieu du deuxième semestre, possède les connaissances nécessaires (dans le cadre de mon cours) pour configurer un LAN de bureau simple.

Qu'est-ce qui est compliqué pour connecter des commutateurs entre eux, configurer les VLAN, les interfaces SVI (dans le cas des commutateurs L3) et définir le routage statique ?

Tout fonctionnera.

Mais il reste des questions liées à

• la sécurité
• la redondance
• l'évolutivité du réseau
• la performance
• la bande passante
• la fiabilité
• …

De temps en temps, j'entends l'affirmation selon laquelle un LAN de bureau est quelque chose de très simple, et cela provient généralement d'ingénieurs (et de gestionnaires) qui s'occupent de tout sauf des réseaux, et ils le disent avec une telle assurance que ne soyez pas surpris si le LAN est réalisé par des personnes avec une pratique et des connaissances insuffisantes, et qu'il est réalisé avec des erreurs que je décrirai un peu plus bas.

Erreurs caractéristiques de conception de niveau L1 (OSI)

• Si vous êtes également responsable de la Système de câblage structuré (SKS), l'un des legs les plus désagréables que vous pourriez hériter est la commutation négligente et mal pensée.

De plus, pour le type L1, je inclurais des erreurs liées aux ressources du matériel utilisé, par exemple,

• une bande passante insuffisante
• une TCAM insuffisante sur le matériel (ou son utilisation inefficace)
• une performance insuffisante (se réfère souvent aux pare-feu)

Erreurs caractéristiques de conception de niveau L2 (OSI)

Souvent, lorsqu'il n'y a pas de bonne compréhension de comment fonctionne le STP, quels problèmes potentiels il peut poser, les commutateurs sont connectés de manière chaotique, avec des paramètres par défaut, sans réglage supplémentaire du STP.

En conséquence, nous avons souvent ce qui suit

• un grand diamètre STP du réseau, ce qui peut conduire à des tempêtes de diffusion
• la racine STP sera déterminée de manière aléatoire (sur la base de l'adresse MAC) et le chemin du trafic ne sera pas optimal
• les ports connectés aux hôtes ne seront pas configurés comme edge (portfast), ce qui entraînera un recalcul de STP lors de l'allumage/de l'extinction des stations terminales
• le réseau ne sera pas segmenté au niveau L1/L2, ce qui entraînera des problèmes avec n'importe quel commutateur (par exemple, surcharge d'alimentation) entraînant un recalcul de la topologie STP et l'arrêt du trafic dans tous les VLAN sur tous les commutateurs (y compris dans le segment critique du point de vue de la continuité des services)

Exemples d'erreurs dans la conception L3 (OSI)

Quelques erreurs caractéristiques des débutants en réseau :

• utilisation fréquente (ou utilisation exclusive) du routage statique
• utilisation de protocoles de routage non optimaux pour ce design
• segmentation logique non optimale du réseau
• utilisation non optimale de l'espace d'adressage, empêchant l'agrégation des routes
• absence de routes de secours
• absence de redondance pour la passerelle par défaut
• routage asymétrique lors de la reconstruction des routes (peut être critique en cas de NAT/PAT, pare-feux stateful)
• problèmes de MTU
• lors de la reconstruction des routes, le trafic passe par d'autres zones de sécurité ou même d'autres pare-feux, ce qui entraîne un rejet de ce trafic
• mauvaise évolutivité de la topologie

Critères d'évaluation de la qualité du design

Lorsque nous parlons d'optimalité/non optimalité, nous devons comprendre selon quels critères nous pouvons évaluer cela. Voici, selon moi, les critères les plus significatifs (mais pas tous) et leur explication par rapport aux protocoles de routage :

• évolutivité (scalability)
  Par exemple, vous avez décidé d'ajouter un autre centre de données. À quel point cela peut-il être fait facilement ?
• la facilité de gestion (manageability)
  À quel point les modifications opérationnelles sont-elles faciles et sécurisées, par exemple, l'annonce d'un nouveau réseau ou le filtrage des routes
• la disponibilité (availability)
  Quel pourcentage du temps votre système fournit-il le niveau de service requis
• sécurité (security)
  À quel point les données transmises sont-elles sécurisées
• le prix

Changements

Le principe fondamental à ce stade peut être exprimé par la formule 'ne pas nuire'.
Ainsi, même si vous n'êtes pas tout à fait d'accord avec le design et la mise en œuvre (configuration) choisie, il n'est pas toujours judicieux d'apporter des modifications. Une approche raisonnable consiste à classer tous les problèmes identifiés selon deux paramètres :

• à quel point ce problème peut être facilement corrigé
• quel est le risque qu'il représente

Tout d'abord, il faut éliminer ce qui diminue actuellement le niveau de service fourni en dessous d'un seuil acceptable, par exemple, des problèmes entraînant des pertes de paquets. Ensuite, corrigez ce qui est le plus facile et le plus sûr à résoudre en ordre de gravité du risque (des problèmes dans le design ou la configuration, présentant de grands risques vers des risques moindres).

Le perfectionnisme à ce stade peut être nuisible. Amenez le design à un état satisfaisant et synchronisez la configuration du réseau en conséquence.

Source : habr.com