Je deviens nerveux avant les changements majeurs du réseau, et ma méthodologie de meilleures pratiques semble disparaître lorsqu'un changement tourne mal. Des années d'expérience m'ont appris que la solution réside dans une planification approfondie, des tests précis et des procédures de restauration claires. Il y a tout simplement trop de choses à penser dans une situation de panne de réseau.
Le problème pour moi est que même si j'ai une bonne compréhension de la technologie, il est très difficile de savoir avec un degré élevé de certitude comment un changement affecte l'ensemble d'un réseau. Comprendre la sortie de commandes telles que Afficher la base de données IP OSPF, afficher l'itinéraire IP et afficher IP CEF peut fournir à un ingénieur très qualifié une idée immédiate de ce à quoi ressemble l'ensemble du graphe OSPF. Il existe certainement une classe de professionnels des réseaux qui peuvent le faire, mais comment pouvons-nous, simples mortels exploitant de grands réseaux, peindre une image mentale de la façon dont OSPF sélectionne les chemins sur l'ensemble d'un réseau ?
Ce genre de réflexion ne concerne pas seulement l'examen CCIE. D'après mon expérience, il est pertinent pour les opérations réseau quotidiennes de nombreuses grandes organisations. Pour eux, chaque configuration OSPF est essentielle à la mission.
Il y a des années, j'ai travaillé sur un réseau mondial avec des emplacements géographiques maintenus isolés avec deux points de sortie dans le réseau mondial. Dans certains cas, ces emplacements géographiques exécutant OSPF représentaient des pays entiers, chacun avec des dizaines d'emplacements et des milliers d'utilisateurs finaux.
Pour un projet, j'ai dû configurer des itinéraires via une sortie à privilégier par rapport à l'autre, car le chemin le moins préféré passait par un site en cours de désaffectation. De plus, toute la région utilisait des routeurs extrêmement anciens, et un par un, eux et leurs liens avec le FAI étaient mis à niveau. Ce à quoi j'ai dû faire face était une zone OSPF avec une variété d'anciens matériels et de liaisons à faible vitesse et plusieurs emplacements avec du nouveau matériel et des liaisons à grande vitesse.
Pendant ma fenêtre de changement, j'ai scanné la configuration OSPF, la table de routage sur les deux ASBR et la base de données LSA. J'ai codé en dur un faible coût OSPF sur un lien et ajusté la bande passante de référence afin d'influencer la façon dont ce routeur a calculé ses métriques.
Lorsqu'il s'agit de modifier les temporisateurs par défaut, le coût de la liaison et d'influencer la sélection de chemin sur plusieurs routeurs à la fois, la configuration même d'un simple changement peut devenir beaucoup plus complexe.
J'ai attendu mes différents pings persistants et traceroutes pour ressembler à ce que je voulais, mais ils ne l'ont jamais fait. En fait, il semblait que j'avais créé une petite crise.
J'ai oublié que tous les routeurs d'un domaine OSPF doivent s'accorder sur la bande passante de référence car le coût est inversement proportionnel à la bande passante d'un lien. Dans mon esprit, la diminution du coût rendait le lien plus préféré, mais en changeant la bande passante de référence de manière incorrecte, j'ai fait le lien moins préféré.
Derrière ces deux ASBR se trouvait un domaine OSPF entier géré par diverses plates-formes de routeur. Après le recalcul du SPF dans la zone, les modèles de trafic ont suffisamment changé pour que non seulement la sortie la moins préférée soit utilisée, mais que le trafic soit trombonné entre plusieurs anciens routeurs utilisant des liaisons à très faible bande passante.
En gros, je n'avais aucune idée de ce qui se passait à part le fait que tout était lent et bizarre. J'avais besoin d'une visibilité granulaire en temps réel avant et après mon changement.
NetBrain Dynamic Maps vous offrent une visibilité de bout en bout sur l'ensemble de votre configuration OSPF.
Dans un réseau très simple, il ne se passe pas grand-chose avec OSPF à part l'activer sur une interface et laisser SPF faire le reste. Mais lorsqu'il s'agit de modifier les temporisateurs par défaut, le coût de la liaison et d'influencer la sélection de chemin sur plusieurs routeurs à la fois, la configuration même d'un simple changement peut devenir beaucoup plus complexe. Se connecter à un appareil à la fois pour effectuer ce type de modifications signifie que les fenêtres de modification sont longues, que le risque d'erreur humaine est élevé et que la visibilité du réseau en temps réel est presque inexistante.
C'est pourquoi je pense que l'automatisation du réseau devient une partie normale de la façon dont les ingénieurs gèrent les réseaux. Une approche programmatique pour apporter plusieurs modifications à une configuration OSPF sur des dizaines de routeurs
Le plan de restauration pour mon changement de réseau était simple. J'ai supprimé la configuration des coûts et la bande passante de référence. Après avoir rebondi quelques interfaces pour forcer SPF à s'exécuter à nouveau, les modèles de trafic sont revenus à l'état de la fenêtre de pré-changement.
Dans ma prochaine fenêtre de changement, j'ai donné un autre coup mais avec quelques changements à ma stratégie. Cette fois, j'ai changé la bande passante de référence sur tous les routeurs de cette zone OSPF, modifié le coût de plusieurs interfaces et modifié la description de presque toutes les interfaces exécutant OSPF dans cette zone et sa zone adjacente.
La fenêtre de changement devait être plus longue car je prévoyais des temps d'arrêt plus longs et mes méthodes n'étaient pas sophistiquées. J'avais des extraits de configuration dans le Bloc-notes sur mon écran de gauche, que j'ai copiés et collés dans les fenêtres de terminal appropriées sur mon écran de droite. Heureusement, je n'ai fait que quelques erreurs en mettant la mauvaise configuration sur le mauvais routeur, et heureusement, je n'ai pas perdu la connectivité aux appareils en conséquence. Mais j'aurais dû avoir zéro erreur et une fenêtre de changement beaucoup plus courte.
NetBrainest intégré Exécutable Runbooks faire courir montrer commandes sur de nombreux appareils à la fois en un seul clic sur un bouton. De manière réaliste, un Runbook aura plus qu'un simple montrer commande, cependant.
Un exécutable Runbook vérifie l'état d'exécution OSPF actuel. La commande défini que le Runbook exécute est affiché à droite.
La puissance de NetBrain Runbooks est dans la façon dont une variété de commandes peuvent être exécutées simultanément ou déclenchées pour s'exécuter automatiquement. Dans mon cas, un exécutable Runbook aurait pu être configuré avec le bon montrer pour rassembler une quantité importante d'informations spécifiques à OSPF et de routage. En un clic, NetBrain aurait rassemblé ces informations sur de nombreux appareils sans avoir besoin de me connecter à un routeur à la fois.
La puissance de NetBrain Runbooks est dans la façon dont une variété de commandes peuvent être exécutées simultanément ou déclenchées pour s'exécuter automatiquement.
Cependant, regarder des pages de sortie n'est pas vraiment ce dont j'avais besoin. NetBrain's Cartes réseau dynamiques puis prenez cette sortie et représentez-la dans un instantané interactif en temps réel de la façon dont le routage fonctionne sur le réseau. De cette façon, j'aurais pu voir immédiatement la sélection du chemin et cliquer sur les routeurs suspects.
Votre Runbook met en évidence le nombre de voisins et les routes de l'OSPF et l'affiche directement sur le Dynamic Map.
Pousser les changements de configuration sur tous les appareils est relativement facile, mais NetBrain offre une fonctionnalité approfondie avec leur Dynamic Maps tels que la fonction Path qui présente graphiquement les modèles de trafic après chaque push de configuration. Et lorsque nous devons vérifier nos configurations, la fonction de comparaison est un outil de comparaison intégré qui fournit un mécanisme en un clic pour identifier les différences de configuration entre les appareils.
Un ingénieur peut voir immédiatement les différences de configuration OSPF entre les routeurs 2 et 4.
Je n'ai pas honte d'admettre que je deviens anxieux avant un changement majeur de réseau. Cependant, l'utilisation d'une méthode programmatique pour surveiller et configurer un réseau à la fois au niveau de l'appareil et de manière holistique m'aide à avancer en toute confiance, sachant que je comprends exactement comment chaque changement a affecté le réseau en temps réel. NetBrain's Runbook Automatisation et Dynamic Mapping Les technologies offrent aux ingénieurs ce type d'environnement programmable pour apporter des modifications au routage sans crainte.