Cet article est le deuxième d'une série d'articles intitulée «Comment prendre l'infrastructure réseau sous votre contrôle». Le contenu de tous les articles de la série et les liens peuvent être trouvés ici .
Notre objectif à ce stade est de nettoyer la documentation et la configuration.
À la sortie de ce processus, vous devez avoir l'ensemble de documents nécessaire et un réseau configuré conformément à eux.
Nous ne parlerons pas maintenant d'audits de sécurité - la troisième partie y sera consacrée.
La difficulté de terminer la tâche à ce stade, bien sûr, varie considérablement d'une entreprise à l'autre.
La situation idéale est lorsque
- votre réseau a été créé conformément au projet et vous disposez d'un ensemble complet de documents
- votre entreprise a mis en place un processus de suivi et de gestion du changement pour le réseau
- conformément à ce processus, vous disposez de documents (y compris 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 devriez étudier les documents et regarder toutes les modifications qui ont été apportées.
Dans le pire des cas, vous aurez
- un réseau créé sans projet, sans plan, sans coordination, par des ingénieurs qui n'ont pas un niveau de qualification suffisant,
- avec des changements chaotiques et non documentés, avec beaucoup de «déchets» et des solutions sous-optimales
Il est clair que votre situation se situe quelque part entre les deux, mais, malheureusement, c'est mieux à cette échelle - pire avec une forte probabilité, vous serez plus proche de la pire fin.
Dans ce cas, vous aurez également besoin de la capacité de lire les pensées, car vous devrez apprendre à comprendre ce que les «concepteurs» voulaient faire, restaurer leur logique, terminer ce qui n'était pas terminé et supprimer les «déchets».
Et, bien sûr, vous devrez arrêter leurs erreurs, changer (à ce stade le moins possible) la conception et changer ou recréer le circuit.
Cet article n'est nullement destiné à être exhaustif. Je ne décrirai ici que des principes généraux et je m'attarderai sur certains problèmes communs qui doivent être résolus.
Ensemble de documents
Commençons par un exemple.
Voici quelques-uns des documents que Cisco Systems crée généralement lors de la conception.
CR - Exigences personnalisées, exigences du client (mission technique).
Il est créé avec le client et définit les exigences du réseau.
HLD - High Level Design, une conception de haut niveau basée sur les exigences du réseau (CR). Le document explique et justifie les décisions architecturales adoptées (topologie, protocoles, sélection des équipements, ...). HLD ne contient pas de détails de conception, par exemple sur les interfaces utilisées et les adresses IP. De plus, la configuration spécifique de l'équipement n'est pas discutée ici. Ce document est plutôt destiné à expliquer les concepts clés de la conception à la gestion technique du client.
LLD - Low Level Design, conception de bas niveau basée sur un niveau élevé (HLD).
Il doit contenir tous les détails nécessaires à la mise en œuvre du projet, tels que des informations sur la façon de connecter et de configurer l'équipement. Ceci est un guide complet pour la mise en œuvre de la conception. Ce document doit fournir des informations suffisantes pour sa mise en œuvre même par du personnel peu qualifié.
Quelque chose, par exemple, des adresses IP, des numéros AS, du câblage, peut être «retiré» dans des documents séparés, comme NIP (Network Implementation Plan).
La construction du réseau commence après la création de ces documents et se déroule en stricte conformité avec eux, puis est vérifiée par le client (tests) pour la conformité avec la conception.
Bien sûr, différents intégrateurs, différents clients, dans différents pays, les exigences pour la documentation du projet peuvent être différentes. Mais je voudrais éviter les formalités et examiner la question sur le fond. Cette étape ne concerne pas la conception, mais la mise en ordre et nous avons besoin d'un ensemble de documents (schémas, tableaux, descriptions ...) suffisants pour achever nos tâches.
Et à mon avis, il existe un certain minimum absolu, sans lequel il est impossible de contrôler efficacement le réseau.
Ce sont les documents suivants:
- schéma (log) de commutation physique (câblage)
- circuit ou circuits de réseau avec des informations L2 / L3 importantes
Schéma de commutation physique
Dans certaines petites entreprises, les travaux liés à l'installation des équipements et au câblage physique sont la responsabilité des ingénieurs réseau.
Dans ce cas, le problème est partiellement résolu par l'approche suivante.
- utiliser la description sur l'interface pour décrire ce qui y est connecté
- arrêter administrativement tous les ports non connectés de l'équipement réseau
Cela vous donnera la possibilité, même en cas de problème avec le lien (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 pour les nouveaux équipements réseau, serveurs ou postes de travail.
Mais il est clair que si vous perdez l'accès à l'équipement, vous perdrez l'accès à ces informations. De plus, de cette façon, vous ne pourrez pas enregistrer des informations importantes telles que le type d'équipement, la consommation d'énergie, le nombre de ports, le rack, les panneaux de brassage et où (à quel rack / panneau de brassage) sont-ils connectés . Par conséquent, tout de même, une documentation supplémentaire (pas seulement des descriptions de matériel) est très utile.
L'option idéale consiste à 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 les schémas L1 / L2.
Important!
Un ingénieur réseau, bien sûr, peut très bien connaître les subtilités et les normes des SCS, les types de racks, les types d'alimentations sans coupure, ce qu'est un couloir froid et chaud, faire une mise à la terre appropriée ... tout comme en principe, il peut connaître la physique des particules ou le C ++. Mais il faut comprendre, cependant, que tout cela n'est pas son domaine de connaissance.
Par conséquent, il est de bonne pratique d'avoir des départements dédiés ou des personnes dédiées pour résoudre les problèmes liés à l'installation, la connexion, la maintenance des performances des équipements, ainsi que la commutation physique. En règle générale, pour les centres de données, il s'agit des ingénieurs de centre de données et pour le bureau, du service d'assistance.
Si de telles unités sont fournies dans votre entreprise, les problèmes de maintenance d'un journal de commutation physique ne sont pas de votre ressort et vous pouvez vous limiter à décrire uniquement sur l'interface et à arrêter administrativement les ports inutilisés.
Diagrammes de réseau
Il n'y a pas d'approche universelle des schémas de dessin.
Plus important encore, les schémas doivent permettre de comprendre comment le trafic passera, par quels éléments logiques et physiques de votre réseau.
Par éléments physiques, nous entendons
- équipement actif
- interfaces / ports d'équipements actifs
Sous la logique -
- dispositifs logiques (N7K VDC, Palo Alto VSYS, ...)
- VRF
- vilanas
- sous-interfaces
- tunnels
- les zones
- ...
De plus, si votre réseau n'est pas complètement élémentaire, il sera composé de différents segments.
Par exemple
- centre de données
- l'internet
- Wan
- accès à distance
- LAN de bureau
- Dmz
- ...
Il serait raisonnable d'avoir plusieurs schémas donnant à la fois une image générale (comment le trafic passe entre tous ces segments) et une explication détaillée de chaque segment individuel.
Étant donné que les réseaux modernes peuvent avoir plusieurs niveaux logiques, il est possible qu'une bonne approche (mais non obligatoire) consiste à créer différents schémas pour différents niveaux, par exemple, dans le cas d'une approche par superposition, il peut s'agir des schémas suivants:
- superposition
- Sous-couche L1 / L2
- Sous-couche L3
Bien sûr, le schéma le plus important sans lequel il est impossible de comprendre l'idée de votre conception est un schéma de routage.
Schéma de routage
Au minimum, ce diagramme devrait refléter
- quels protocoles de routage et où sont utilisés
- informations de base sur les paramètres du protocole de routage (zone / numéro AS / id-routeur / ...)
- sur quels appareils la redistribution a lieu
- là où le filtrage et l'agrégation des routes se produisent
- informations d'itinéraire par défaut
Le circuit L2 (OSI) est également souvent utile.
Circuit L2 (OSI)
Les informations suivantes peuvent être reflétées dans ce diagramme:
- quel vlan
- quels ports sont des ports de jonction
- quels ports sont agrégés en canal éther (canal de port), canal de port virtuel
- quels protocoles STP et sur quels appareils sont utilisés
- Paramètres principaux STP: sauvegarde racine / racine, coût STP, priorité du port
- paramètres STP avancés: BPDU guard / filter, root guard ...
Erreurs de conception typiques
Un exemple d'une mauvaise approche de la construction d'un réseau.
Prenons un exemple simple de construction d'un réseau local de bureau simple.
Ayant une expérience de l'enseignement des télécommunications aux étudiants, je peux dire que pratiquement tout étudiant au milieu du deuxième semestre possède les connaissances nécessaires (dans le cadre du cours que j'ai enseigné) afin de mettre en place un réseau local de bureau simple.
Qu'est-ce qui est difficile de connecter les commutateurs entre eux, de configurer les interfaces VLAN, SVI (dans le cas des commutateurs L3) et de configurer le routage statique?
Tout fonctionnera.
Mais en même temps, les problèmes liés à
- la sécurité
- réservation
- mise à l'échelle du réseau
- performance
- largeur de bande
- la fiabilité
- ...
Parfois, j'entends la déclaration qu'un LAN de bureau est quelque chose de très simple et je l'entends généralement des ingénieurs (et des gestionnaires) qui font tout, mais pas les réseaux, et ils le disent avec une telle confiance que ne s'étonnent pas si le LAN sera faite par des personnes avec une pratique et des connaissances insuffisantes, et sera faite avec approximativement les erreurs que je décrirai ci-dessous.
Erreurs de couche L1 de conception commune (OSI)
- Si, néanmoins, vous êtes responsable, y compris pour SCS, alors l'un des héritages les plus désagréables que vous pouvez obtenir est une commutation imprudente et irréfléchie.
De plus, pour taper L1, je classerais les erreurs liées aux ressources de l'équipement utilisé, par exemple,
- bande passante insuffisante
- TCAM insuffisant sur l'équipement (ou son utilisation inefficace)
- performances insuffisantes (se réfère souvent aux pare-feu)
Erreurs de couche L2 de conception commune (OSI)
Souvent, lorsqu'il n'y a pas de bonne compréhension du fonctionnement de STP, des problèmes potentiels qu'il entraîne, les commutateurs se connectent de manière aléatoire, avec les paramètres par défaut, sans réglage supplémentaire de STP.
En conséquence, nous avons souvent les éléments suivants
- grand diamètre STP du réseau, 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 de trafic sera sous-optimal
- les ports connectés aux hôtes ne seront pas configurés en tant que périphérie (portfast), ce qui entraînera un nouveau calcul de STP lors de l'activation / désactivation des points de terminaison
- le réseau ne sera pas segmenté au niveau L1 / L2, à la suite de quoi des problèmes avec n'importe quel commutateur (par exemple, une surcharge de puissance) conduiront à recalculer la topologie STP et à arrêter le trafic dans tous les VLAN sur tous les commutateurs (y compris critiques du point de vue de la continuité) segment de service)
Exemples d'erreur de conception L3 (OSI)
Quelques erreurs de réseautage novices typiques:
- utilisation fréquente (ou utilisation uniquement) du routage statique
- utilisation de protocoles de routage qui ne sont pas optimaux pour cette conception
- segmentation du réseau logique sous-optimale
- utilisation non optimale de l'espace d'adressage, qui ne permet pas l'agrégation de routes
- manque de routes de sauvegarde
- manque de redondance 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 d'état)
- problèmes avec MTU
- lors de la reconstruction des itinéraires, le trafic passe par d'autres zones de sécurité ou même d'autres pare-feu, ce qui conduit au fait que ce trafic baisse
- mauvaise évolutivité de la topologie
Critères d'évaluation de la qualité de la conception
Lorsque nous parlons d'optimalité / non d'optimalité, nous devons comprendre en termes de critères que nous pouvons évaluer. Voici, de mon point de vue, les critères les plus importants (mais pas tous) (et le décryptage par rapport aux protocoles de routage):
- évolutivité
Par exemple, vous décidez d'ajouter un autre centre de données. Comme vous pouvez le faire facilement. - commodité de gestion (gérabilité)
Dans quelle mesure les changements opérationnels sont-ils faciles et sûrs, tels que l'annonce d'un nouveau réseau ou le filtrage des itinéraires - disponibilité
Quel pourcentage du temps votre système fournit-il le niveau de service requis - la sécurité
Quelle est la sécurité des données transmises? - 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 tout à fait d'accord avec la conception et la mise en œuvre choisie (configuration), il n'est pas toujours conseillé d'apporter des modifications. Une approche raisonnable consiste à classer tous les problèmes identifiés de deux manières:
- avec quelle facilité ce problème peut être résolu
- combien de risques porte-t-elle
Tout d'abord, il est nécessaire d'éliminer ce qui, à l'heure actuelle, réduit le niveau du service fourni en dessous des problèmes admissibles, par exemple, conduisant à une perte de paquets. Éliminez ensuite ce qui est le plus facile et le plus sûr à éliminer afin de réduire la gravité du risque (des problèmes de conception ou de configuration qui comportent des risques plus importants aux plus petits).
Le perfectionnisme à ce stade peut être nocif. Amenez la conception dans un état satisfaisant et synchronisez la configuration du réseau conformément à celle-ci.