Cet article est le deuxième d'une série d'articles « Comment prendre le contrôle de votre infrastructure réseau ». Le contenu de tous les articles de la série et les liens peuvent être trouvés .
Notre objectif à ce stade est de mettre de l'ordre dans la documentation et la configuration.
À la fin de ce processus, vous devriez disposer de l'ensemble de documents nécessaire et d'un réseau configuré conformément à ceux-ci.
Nous ne parlerons plus des audits de sécurité, ce sera le sujet de la troisième partie.
La difficulté d'accomplir la tâche assignée à ce stade varie bien entendu considérablement d'une entreprise à l'autre.
La situation idéale est celle où
- votre réseau a été créé conformément au projet et vous disposez d'un ensemble complet de documents
- a été mis en œuvre dans votre entreprise pour réseau
- conformément à ce processus, vous disposez de documents (comprenant tous les schémas nécessaires) qui fournissent des informations complètes sur l'état actuel des choses
Dans ce cas, votre tâche est assez simple. Vous devez étudier les documents et examiner toutes les modifications qui ont été apportées.
Dans le pire des cas, vous aurez
- un réseau créé sans projet, sans plan, sans agrément, par des ingénieurs ne disposant pas d'un niveau de qualification suffisant,
- avec des changements chaotiques et non documentés, avec beaucoup de « déchets » et de solutions sous-optimales
Il est clair que votre situation se situe quelque part entre les deux, mais malheureusement, sur cette échelle du meilleur au pire, il y a de fortes chances que vous soyez plus proche du pire.
Dans ce cas, vous aurez également besoin de la capacité de lire dans les pensées, car vous devrez apprendre à comprendre ce que les « concepteurs » voulaient faire, restaurer leur logique, terminer ce qui n'était pas fini et éliminer les « déchets ».
Et, bien sûr, vous devrez corriger leurs erreurs, modifier (à ce stade le moins possible) la conception et modifier ou recréer les schémas.
Cet article ne prétend en aucun cas être complet. Ici, je décrirai uniquement les principes généraux et me concentrerai sur certains problèmes courants qui doivent être résolus.
Ensemble de documents
Commençons par un exemple.
Vous trouverez ci-dessous quelques documents habituellement créés chez Cisco Systems lors de la conception.
CR – Exigences Client, exigences client (spécifications techniques).
Il est créé conjointement avec le client et détermine les besoins du réseau.HLD – High Level Design, conception de haut niveau basée sur les exigences du réseau (CR). Le document explique et justifie les décisions architecturales prises (topologie, protocoles, choix du matériel,...). HLD ne contient pas de détails de conception, tels que les interfaces et les adresses IP utilisées. De plus, la configuration matérielle spécifique n'est pas abordée ici. Ce document est plutôt destiné à expliquer les concepts de conception clés à la direction technique du client.
LLD – Low Level Design, conception de bas niveau basée sur la conception de haut niveau (HLD).
Il doit contenir tous les détails nécessaires à la mise en œuvre du projet, tels que des informations sur la manière de connecter et de configurer l'équipement. Ceci est un guide complet pour mettre en œuvre la conception. Ce document doit fournir suffisamment d'informations pour sa mise en œuvre même par du personnel moins qualifié.Quelque chose, par exemple les adresses IP, les numéros AS, le schéma de commutation physique (câblage), peut être « publié » dans des documents séparés, tels que PIN (Plan de mise en œuvre du réseau).
La construction du réseau commence après la création de ces documents et se déroule dans le strict respect de ceux-ci et est ensuite vérifiée par le client (tests) pour la conformité à la conception.
Bien entendu, différents intégrateurs, différents clients et différents pays peuvent avoir des exigences différentes en matière de documentation de projet. Mais je voudrais éviter les formalités et examiner la question selon ses mérites. Cette étape ne concerne pas la conception, mais la mise en ordre des choses, et nous avons besoin d'un ensemble suffisant de documents (schémas, tableaux, descriptions...) pour accomplir nos tâches.
Et à mon avis, il existe un certain minimum absolu, sans lequel il est impossible de contrôler efficacement le réseau.
Il s'agit des documents suivants :
- schéma (log) de commutation physique (câblage)
- schéma ou schémas de réseau avec informations essentielles L2/L3
Schéma de commutation physique
Dans certaines petites entreprises, les travaux liés à l'installation des équipements et à la commutation physique (câblage) relèvent de la responsabilité des ingénieurs réseau.
Dans ce cas, le problème est en partie résolu par l’approche suivante.
- utiliser une description sur l'interface pour décrire ce qui y est connecté
- arrêter administrativement tous les ports d'équipement réseau non connectés
Cela vous donnera la possibilité, même en cas de problème de liaison (lorsque cdp ou lldp ne fonctionne pas sur cette interface), de déterminer rapidement ce qui est connecté à ce port.
Vous pouvez également voir facilement quels ports sont occupés et lesquels sont libres, ce qui est nécessaire pour planifier les connexions de nouveaux équipements réseau, serveurs ou postes de travail.
Mais il est clair que si vous perdez l’accès à l’équipement, vous perdrez également l’accès à ces informations. De plus, de cette façon, vous ne pourrez pas enregistrer des informations aussi importantes que le type d'équipement, quelle consommation électrique, combien de ports, dans quel rack il se trouve, quels panneaux de brassage se trouvent et où (dans quel rack/panneau de brassage ) ils sont connectés . Par conséquent, une documentation supplémentaire (pas seulement des descriptions sur l’équipement) reste très utile.
L'option idéale est d'utiliser des applications conçues pour fonctionner avec ce type d'informations. Mais vous pouvez vous limiter à des tableaux simples (par exemple dans Excel) ou afficher les informations que vous jugez nécessaires dans des diagrammes L1/L2.
Important!
Un ingénieur réseau, bien sûr, peut très bien connaître les subtilités et les normes du SCS, les types de racks, les types d'alimentations sans coupure, ce qu'est une allée froide et chaude, comment effectuer une mise à la terre appropriée... tout comme en principe il peut connaître la physique des particules élémentaires ou le C++. Mais il faut quand même comprendre que tout cela n’est pas son domaine de connaissance.
Par conséquent, il est de bonne pratique d'avoir soit des services dédiés, soit des personnes dédiées pour résoudre les problèmes liés à l'installation, à la connexion, à la maintenance des équipements, ainsi qu'à la commutation physique. Habituellement, pour les centres de données, il s'agit d'ingénieurs de centre de données, et pour un bureau, il s'agit d'un service d'assistance.
Si de telles divisions sont proposées dans votre entreprise, les problèmes de journalisation de la commutation physique ne sont pas votre tâche et vous pouvez vous limiter uniquement à la description de l'interface et à l'arrêt administratif des ports inutilisés.
Diagrammes de réseau
Il n’existe pas d’approche universelle pour dessiner des diagrammes.
Le plus important est que les diagrammes doivent permettre de comprendre comment le trafic circulera, à travers quels éléments logiques et physiques de votre réseau.
Par éléments physiques, nous entendons
- équipement actif
- interfaces/ports des équipements actifs
Sous logique -
- périphériques logiques (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- sous-interfaces
- tunnels
- zone
- ...
Aussi, si votre réseau n’est pas complètement élémentaire, il sera constitué de différents segments.
Par exemple
- centre de données
- Internet
- WAN
- accès à distance
- réseau local de bureau
- DMZ
- ...
Il est judicieux d'avoir plusieurs diagrammes 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é que dans les réseaux modernes, il peut y avoir de nombreuses couches logiques, il est peut-être judicieux (mais pas nécessaire) de créer différents circuits pour différentes couches. Par exemple, dans le cas d'une approche par superposition, il pourrait s'agir des circuits suivants :
- revêtement
- Sous-couche L1/L2
- Sous-couche L3
Bien entendu, 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 diagramme doit refléter
- quels protocoles de routage sont utilisés et où
- informations de base sur les paramètres du protocole de routage (zone/numéro AS/identifiant du routeur/…)
- sur quels appareils la redistribution s'effectue-t-elle ?
- où le filtrage et l'agrégation de routes se produisent
- informations d'itinéraire par défaut
De plus, le schéma L2 (OSI) est souvent utile.
Schéma L2 (OSI)
Ce diagramme peut afficher les informations suivantes :
- quels VLAN
- quels ports sont des ports de jonction
- quels ports sont regroupés dans Ether-Channel (Port Channel), port-channel virtuel
- quels protocoles STP sont utilisés et sur quels appareils
- paramètres STP de base : sauvegarde racine/racine, coût STP, priorité du port
- paramètres STP supplémentaires : protection/filtre BPDU, protection racine…
Erreurs de conception typiques
Un exemple d’une mauvaise approche pour construire un réseau.
Prenons un exemple simple de création d'un simple réseau local de bureau.
Ayant de l'expérience dans l'enseignement des télécommunications aux étudiants, je peux dire que pratiquement tous les étudiants au milieu du deuxième semestre possèdent les connaissances nécessaires (dans le cadre du cours que j'ai enseigné) pour mettre en place un simple réseau local de bureau.
Qu'y a-t-il de si difficile à connecter les commutateurs les uns aux autres, à configurer les VLAN, les interfaces SVI (dans le cas des commutateurs L3) et à configurer le routage statique ?
Tout va marcher.
Mais en même temps, des questions liées à
- la sécurité
- réservation
- mise à l'échelle du réseau
- productivité
- débit
- la fiabilité
- ...
De temps en temps, j'entends dire qu'un réseau local de bureau est quelque chose de très simple et j'entends généralement cela de la part d'ingénieurs (et de gestionnaires) qui font tout sauf des réseaux, et ils le disent avec une telle assurance qu'il ne faut pas être surpris si le réseau local est opérationnel. fait par des personnes ayant une pratique et des connaissances insuffisantes et sera fait avec à peu près les mêmes erreurs que celles que je décrirai ci-dessous.
Erreurs courantes de conception L1 (OSI)
- Si, néanmoins, vous êtes également responsable du SCS, l'un des héritages les plus désagréables que vous puissiez recevoir est un changement imprudent et mal pensé.
Je classerais également en type L1 les erreurs liées aux ressources du matériel utilisé, par exemple,
- bande passante insuffisante
- TCAM insuffisant sur l'équipement (ou utilisation inefficace de celui-ci)
- performances insuffisantes (souvent liées aux pare-feu)
Erreurs courantes de conception L2 (OSI)
Souvent, lorsqu'on ne comprend pas bien le fonctionnement de STP et les problèmes potentiels qu'il entraîne, les commutateurs sont connectés de manière chaotique, avec les paramètres par défaut, sans réglage STP supplémentaire.
En conséquence, nous avons souvent ce qui suit
- grand diamètre de réseau STP, ce qui peut entraîner des tempêtes de diffusion
- La racine STP sera déterminée de manière aléatoire (en fonction de l'adresse Mac) et le chemin du trafic sera sous-optimal
- les ports connectés aux hôtes ne seront pas configurés comme Edge (portfast), ce qui entraînera un recalcul STP lors de l'activation/désactivation des stations d'extrémité
- le réseau ne sera pas segmenté au niveau L1/L2, de sorte que des problèmes avec n'importe quel commutateur (par exemple, surcharge de puissance) entraîneront un recalcul de la topologie STP et l'arrêt du trafic dans tous les VLAN sur tous les commutateurs (y compris le un critique du point de vue du segment de continuité de service)
Exemples d'erreurs dans la conception L3 (OSI)
Quelques erreurs typiques des réseauteurs débutants :
- Utilisation fréquente (ou utilisation uniquement) du routage statique
- utilisation de protocoles de routage sous-optimaux pour une conception donnée
- segmentation sous-optimale du réseau logique
- utilisation sous-optimale de l'espace d'adressage, qui ne permet pas l'agrégation de routes
- pas d'itinéraires de secours
- aucune réservation pour la passerelle par défaut
- routage asymétrique lors de la reconstruction des routes (peut être critique dans le cas de NAT/PAT, pare-feu avec état)
- problèmes avec MTU
- lorsque les routes sont reconstruites, le trafic passe par d'autres zones de sécurité voire d'autres pare-feux, ce qui conduit à l'abandon de ce trafic
- mauvaise évolutivité de la topologie
Critères d'évaluation de la qualité de la conception
Quand on parle d'optimalité/non-optimalité, il faut comprendre du point de vue de quels critères on peut évaluer cela. Voici, de mon point de vue, les critères les plus importants (mais pas tous) (et les explications concernant les protocoles de routage) :
- évolutivité
Par exemple, vous décidez d'ajouter un autre centre de données. À quel point pouvez-vous le faire facilement ? - facilité d'utilisation (gestion)
Dans quelle mesure les changements opérationnels, tels que l’annonce d’un nouveau réseau ou le filtrage des itinéraires, sont-ils faciles et sécurisés ? - disponibilité
Quel pourcentage du temps votre système fournit-il le niveau de service requis ? - sécurité
Dans quelle mesure les données transmises sont-elles sécurisées ? - prix
Changements
Le principe de base à ce stade peut être exprimé par la formule « ne pas nuire ».
Par conséquent, même si vous n'êtes pas entièrement d'accord avec la conception et la mise en œuvre (configuration) choisie, il n'est pas toujours conseillé d'apporter des modifications. Une approche raisonnable consiste à classer tous les problèmes identifiés selon deux paramètres :
- avec quelle facilité ce problème peut-il être résolu
- quel risque supporte-t-elle ?
Tout d'abord, il est nécessaire d'éliminer ce qui réduit actuellement le niveau de service fourni en dessous du niveau acceptable, par exemple les problèmes conduisant à des pertes de paquets. Corrigez ensuite ce qui est le plus simple et le plus sûr à résoudre par ordre décroissant de gravité des risques (des problèmes de conception ou de configuration à haut risque aux problèmes à faible risque).
Le perfectionnisme à ce stade peut être néfaste. Amenez la conception à un état satisfaisant et synchronisez la configuration du réseau en conséquence.
Source: habr.com