Pratique de le gestion de réseau

Pratique de le gestion de réseau Nazim Agoulmine Omar Cherkaoui ISBN : 2-212-11259-9

5 Études de cas de la conception de solutions de gestion Objectifs généraux Appliquer une méthode de travail (proposée dans le chapitre 1) à différentes études de cas Apprendre à proposer des solutions de gestion Apprendre à spécifier une architecture de gestion efficace Apprendre à évaluer une architecture de gestion Acquérir une expérience dans la mise en pratique des concepts et des architectures de gestion IP et Télécom Objectifs spécifiques Traiter différentes technologies réseau Faire un inventaire des technologies d un réseau Identifier les architectures technologiques d un réseau Comprendre les points clés des besoins en termes de gestion Connaître les solutions à apporter Apprendre à identifier les bases d information de gestion Savoir identifier les variables pertinentes Comprendre comment mettre en œuvre une gestion de la configuration Comprendre comment mettre en œuvre une gestion des alarmes Comprendre l utilisation de mécanismes de seuil Apprendre comment configurer des traps Comprendre comment mettre en œuvre une gestion des performances Savoir évaluer une solution de gestion Savoir proposer une plate-forme de gestion

130 Pratique de la gestion de réseau Après avoir respectivement présenté, dans le chapitre 1, une approche méthodique du processus de mise en place d une gestion appropriée d un réseau d entreprise, dans les chapitres 2 et 3, les différentes architectures de gestion d Internet et des réseaux de télécommunications, et enfin dans le chapitre 4 un panorama de plusieurs plates-formes, nous allons voir dans ce chapitre des études de cas qui permettront au lecteur d appréhender l utilisation de notre méthode de mise en œuvre de la gestion dans différentes infrastructures. Ces trois études de cas ont été choisies afin de refléter des scénarios réalistes auxquels les lecteurs peuvent être confrontés. En guise de rappel succinct, voici représenté dans le diagramme suivant le processus développé dans le chapitre 1, qui comporte 7 phases «top-down» principales : La phase Description de l environnement cible à gérer Identification des besoins en gestion de cet environnement Identification des technologies utilisées dans cet environnement Choix d une architecture de gestion adaptée Choix d une ou plusieurs plates-formes technologiques Mise en place de la solution et de sa configuration Recette de la solution La démarche S imprégner de la problématique et de sa complexité. Comprendre, filtrer et synthétiser les besoins de l entreprise et identifier les fonctionnalités de gestion pertinentes. Faire un panorama des technologies utilisées dans l environnement et leurs capacités à être gérées. En fonction des technologies, faire un choix en terme d architecture de gestion qui soit le plus adapté et qui réponde au mieux aux objectifs. En fonction des technologies, des besoins de gestion, de l enveloppe budgétaire, des perspectives d évolution du réseau, faire un choix de plate-forme. Identifier les informations de gestion nécessaires, les outils complémentaires à mettre en œuvre, les points de collectes, puis configurer les équipements actifs ainsi que la plate-forme de gestion. Faire des tests de fonctionnement et ajuster les paramètres de configuration. Établir une liste de critères d évaluation de la solution, créer des scénarios de fonctionnement et de simulation de pannes, vérifier le bon fonctionnement de la plate-forme. Nous traiterons dans ce chapitre principalement des cinq premières phases, les deux dernières phases étant des phases d implémentation et de test qui en découlent directement. Les études de cas considérées sont les suivantes : la société Alafaribius qui met en place une infrastructure moyenne de communication LAN interconnectée par un réseau commuté ISDN ; la banque Albiruni qui met en place une infrastructure complexe de communication LAN/MAN/WAN utilisant les technologies Sonet et ATM ; le musée Léonard-de-Vinci qui met en place une infrastructure LAN commutée de type gigabit Ethernet avec des besoins spécifiques de fonctionnement des applications propres à ce type d organisation.

Études de cas de la conception de solutions de gestion CHAPITRE 5 131 La gestion de réseau Pourquoi a t-on besoin de la gestion? Les environnements de gestion Sélectionner un environnement de gestion adaptés aux besoins de l'entreprise Maîtriser le fonctionnement et les composantes de SNMP Maîtriser le fonctionnement et les composantes du TMN Initiation aux nouvelles technologies L'architecture SNMP L'architecture TMN Les nouvelles architectures de gestion Reconnaître et décrire les informations de gestion Configurer une sonde S'initier à une solution de gestion S'initier à une solution de gestion L'approche de gestion via les politiques Les informations de gestion MIB1 et MIB2 La sonde RMON L'environnement HPOpenView La solution INM L'approche de gestion via les annuaires Les informations de gestion des MIB privées L'environnement Optivity La solution ISM L'environnement Cisco Les limites actuelles de la gestion de réseau Figure 5-1 Processus d apprentissage au domaine de la gestion de réseau

132 Pratique de la gestion de réseau La société Alafaribius Le profil de la compagnie La compagnie Alafaribius est une société canadienne spécialisée dans la fabrication, le montage et la distribution de matériel électronique (ordinateurs, téléviseurs, magnétoscopes, radios et divers autres produits). Elle est composée de plusieurs unités distribuées géographiquement dans la province du Québec. Les principaux établissements de la compagnie La compagnie comprend les unités suivantes : un siège social à Montréal ; 5 centres de vente dans un rayon de 200 km à vol d oiseau autour de Montréal ; un bureau de conception et d ingénierie à Sherbrooke. Les besoins de communication existants et futurs en communication Les échanges entre les différents sites sont importants et englobent différents types d applications. Ils sont en augmentation croissante d année en année et la compagnie a décidé de considérablement développer son réseau de données dans les cinq prochaines années. Outre l augmentation en capacité du réseau, elle compte intégrer son réseau voix et son réseau données. Les principales applications Les employés de l entreprise utilisent un ensemble d applications critiques décrites ciaprès : checkout (mise au point) contrôle des stocks inventaire local traitement des commandes Le réseau existant L architecture du réseau de la compagnie Alafaribius est disposée en étoile. Tous les sites périphériques convergent vers un site principal (siège social) qui contient un ordinateur central. Les sites périphériques (principalement, les sites de ventes) sont dotés d ordinateurs AS400. De plus, elle dispose de 10 serveurs NT et de 3 serveurs Unix à Sherbrooke. Chaque site dispose de son propre serveur de fichiers.

Études de cas de la conception de solutions de gestion CHAPITRE 5 133 Les protocoles existants Les protocoles utilisés sont Ethernet en réseau local, TCP/IP, NetBUI, SNA. Une passerelle SNA-TCP/IP a été installée en amont de l ordinateur central, de façon à supporter le protocole SNA sur le réseau local et à donner un accès TCP/IP aux sites périphériques. Les équipements déployés Les postes de travail sont reliés à des commutateurs Catalyst Cisco 1900 et 2900. À Montréal et à Sherbrooke, deux niveaux de concentrateurs sont connectés au routeur. Firewall Internet Centre de Montréal Centre de vente Catalyst 2900 Catalyst 2900 10 7 CISCO 4700 Router ISDN PRI CISCO 2611 Router Catalyst 2900 ISDN PRI ISDN PRI Centre de Sherbrooke Catalyst 2900 Centre de vente Catalyst 2900 Figure 5-2 Schéma du réseau WAN 7 CISCO Router Baynetworks Router Catalyst 2900 10

134 Pratique de la gestion de réseau L objectif de la gestion : cahier des charges Au vu de la croissance de son réseau, la compagnie Alafaribius souhaite mettre en œuvre une solution d administration globale. Pour ce faire, elle souhaite se doter d une infrastructure de gestion de réseau lui permettant de gérer à distance ces équipements. Un administrateur de serveurs est disponible à Montréal et à Sherbrooke. Un administrateur réseau veillera quant à lui sur le réseau qui connaît certains problèmes actuellement. Le temps de réponse des serveurs NT est très variable durant la journée. À 10 h et à 15 h, l accès au réseau est très lent. Lorsqu une panne survient, ce sont les usagers qui avisent les techniciens. Dans la suite de ce chapitre, nous allons développer les différentes étapes de la méthode que nous préconisons et identifier les éléments pertinents qui permettront au lecteur de mieux comprendre le processus et sa mise en œuvre. Leçon 1 : spécification des besoins Quelles sont les fonctionnalités de gestion requises par cette société? Comme nous l avons souligné dans les chapitres précédents, il est nécessaire avant de commencer de bien identifier les besoins de gestion de la compagnie Alafaribius. En nous basant sur la méthode décrite dans le chapitre 1, les besoins en matière de gestion de l entreprise Alafaribius peuvent être exprimés selon les quatre perspectives suivantes : La configuration : elle va nécessiter la maîtrise des systèmes d exploitation qui permettent de configurer les éléments actifs du réseau. Ces systèmes sont généralement hétérogènes (un ou plusieurs systèmes par constructeur) mais il est possible de retrouver globalement les mêmes fonctionnalités de base. Dans le cas des équipements Cisco, le système d exploitation est nommé IOS (Cisco internet operating system). La surveillance : elle consiste à superviser le réseau de la compagnie Alafaribius à travers des vues cartographiques qui vont permettre à l administrateur réseau de visualiser les états de tous les équipements du réseau de manière intuitive. Dans ce cas, il convient de disposer d outils pour créer ces cartes et les mettre à jour régulièrement. Les alarmes : cette perspective de la gestion consiste à mettre en œuvre les fonctionnalités qui permettront de faire rapidement remonter au niveau du réseau toutes les pannes qui peuvent survenir au niveau des équipements ou provenant d arrêts de service en général. Il est nécessaire dans ce cas de bien connaître les équipements actifs du réseau afin de vérifier les possibilités de récupération de ces alarmes. Les performances : cela consiste à vérifier que l infrastructure réseau répond bien aux objectifs qui lui ont été assignés. Il ne s agit pas simplement de vérifier que la connectivité est assurée mais aussi de s assurer des conditions de réalisation de cette connectivité. La société Alafaribius met en place des bases de données au niveau du siège auxquelles on accède à distance par les sites de ventes. Il faut vérifier les temps de réponse d accès à ces bases de données et qu ils sont bien compatibles avec les time-out généralement

Études de cas de la conception de solutions de gestion CHAPITRE 5 135 définis. Des erreurs d accès aux bases de données peuvent, dans certains cas, n être provoquées que par des problèmes de temps de réponse trop longs qui déclenchent des procédures de recouvrement automatique dans ces bases de données, alors qu en réalité, il n y a pas d erreurs de transmission ni de pertes de connectivité. Pour mettre en place ce processus de vérification, il est nécessaire d identifier les outils logiciels ou matériels qui permettent d effectuer une surveillance passive et de faire remonter des alarmes à l administrateur réseau. Ces activités sont résumées dans le tableau suivant : Activité Configuration Surveillance Gestion des alarmes Gestion des performances Besoins Rendre opérationnels les éléments actifs du réseau. Établir des historiques, tableaux de bord. Connaître los de Cisco. Rendre active la gestion des équipements réseau. Visualisation de l état des équipements distants. Surveillance des liens. Besoins d outils permettant de découvrir et d afficher automatiquement la cartographie du réseau. Traitement des pannes et des arrêts de service. Besoins d outils permettant de définir des seuils de déclenchement des alertes, de capturer les alarmes issues des équipements actifs et de contrôler des équipements. Assurer une disponibilité permanente du réseau et des temps de réponse compatibles avec les SLA (Service level agreements). Trouver une méthodologie et des outils permettant de contrôler les temps de réponse et la Qos du réseau. Configurer les paramètres de polling en vue de l établissement de statistiques. Leçon 2 : spécification de l environnement de gestion requis Quelles sont les architectures technologiques disponibles? À ce stade, nous essayons d analyser l environnement technologique du réseau Alafaribius afin de déterminer par la suite les outils adaptés à sa gestion selon les besoins identifiés dans la section précédente. Les applications mises en place au niveau de chaque site utilisent différents protocoles sous-jacents. On retrouvera au niveau global une architecture intranet basée sur la famille de protocoles TCP/IP. Au niveau de la communication locale, le réseau s appuie sur une infrastructure basée sur Ethernet. Au niveau de la communication interne de chaque site, les éléments actifs reposent sur le protocole Ethernet. Au niveau des communications intersites, le réseau utilise un service PRI synchrone de ISDN. Les protocoles utilisés sont synthétisés dans le réseau. Perspective Bout en bout Cœur du réseau WAN Cœur des réseaux LAN Protocoles IP ISDN IP Ethernet, NetBUI, IP, SNA

136 Pratique de la gestion de réseau Quels sont les types d équipements qu utilise cette société? Dans un deuxième temps, il est nécessaire de dresser un inventaire de toutes les différentes classes d équipement, ainsi que de lister leur constructeur. Dans cette phase, l objectif est d identifier, d une part, les capacités de gestion de ces équipements par rapport aux besoins de gestion exprimés dans la phase précédente et, d autre part, la technologie de gestion de réseau qu ils supportent. Équipement Constructeur Protocoles compatibles Technologie de gestion compatibles Routeur Cisco IP, NetBUI SNMP, configuration propriétaire Cisco Switch Cisco Ethernet, ISL SNMP Configuration propriétaire Cisco Switch Baynetworks Ethernet SNMP Configuration propriétaire Baynetworks Proposer un environnement de gestion pour cette société Dans cette dernière étape de la leçon 1, l objectif est de proposer un environnement de gestion du réseau Alafaribius qui soit compatible avec les besoins exprimés et avec les architectures technologiques identifiées à l étape précédente. L environnement technologique du réseau de la compagnie Alafaribius reposant entièrement sur IP, il est clair que le choix de l environnement de gestion va se porter sur SNMP. En conséquence, les choix en matériels et logiciels viseront à supporter le système de gestion SNMP. Comme décrit dans le chapitre précédent, il existe une panoplie de platesformes de gestion SNMP. Le choix de la solution finale dépendra des possibilités fonctionnelles de la plate-forme, mais aussi du coût, de la mise en place et de la maintenance de cette dernière. Parmi les plates-formes, on retrouvera les ténors du marché : HP OpenView NNM, Tivoli, Computer Associates, etc. L autre critère de choix est la capacité des platesformes à offrir des outils complémentaires permettant de prendre en compte des besoins spécifiques, identifiés, en termes de remontée des alarmes, des performances, et des fautes. De ce point de vue, la plate-forme HP OpenView est un bon choix technique. À cette plate-forme, il serait judicieux d associer un outil de configuration propriétaire de Cisco pour la configuration des routeurs Cisco, par exemple CiscoView. Néanmoins, d autres plates-formes pourraient également être retenues en raison de leur plus faible coût. Leçon 3 : installation et configuration Quels sont les équipements à gérer? Cette étape consiste à dresser une liste de tous les équipements actifs qui doivent être gérés dans le réseau de la compagnie Alafaribius selon la topologie décrite précédemment.

Études de cas de la conception de solutions de gestion CHAPITRE 5 137 Équipements Sites Type Système opératoire Routeur Centre de Montréal Cisco 4700 Cisco IOS 11.1 Centre de Sherbrooke Cisco 4700 Cisco IOS 11.1 Centre de vente 1 Cisco 2611 Cisco IOS 11.1 Centre de vente 2 Baynetwork (Nortel) Baynetworks ICL Switch Centre de Montréal Catalyst 2900 Cisco IOS 12 Centre Sherbrooke Catalyst 2900 Idem Centre de vente 1 Catalyst 2900 Idem Centre de vente 2 Catalyst 2900 Idem Serveur Centre de Montréal Serveur AS400 VMS Centre de Sherbrooke Serveur NT Windows NT Serveur Unix Unix En plus des traps SNMP, certains équipements peuvent également envoyer des traps Syslog. Les équipements implémentent en général une MIB privée à cet effet. Toutes les stations de gestion peuvent recevoir ces événements sur un port UDP prédéfini. Chaque message Syslog est estampillé dans le temps, identifié par niveau de gravité du problème à l origine de son émission. Ces traps sont très utiles car ils permettent de compléter de manière plus précise les informations de gestion sur les équipements réseau, en fournissant des indications sur les parties système de l équipement (CPU, mémoire, interface, etc.). Il faut toutefois rester extrêmement vigilant lorsqu on travaille dans un environnement hétérogène. Sur quel site devrait se trouver la plate-forme de gestion? Le choix du site sur lequel la plate-forme doit être mise en place répond à plusieurs critères : disponibilité, optimisation du trafic, temps de réponse, sécurité, etc. En tenant compte de la topologie du réseau de la compagnie Alafaribius, il serait judicieux de choisir le site de Montréal comme site de déploiement de la plate-forme de gestion. Ce choix a plusieurs avantages : La plate-forme se trouve sur le site de convergence, ce qui permet de diminuer les temps de remontée des alarmes. On évite ainsi la surcharge des sites avec du trafic de gestion comme cela aurait été le cas si l on avait choisi un autre site. Les aspects relatifs à la sécurité sont respectés puisque a priori le siège social de la compagnie est un lieu qui a des privilèges avancés que l on ne pourrait pas accorder, par exemple, à un administrateur sur un site délocalisé.

138 Pratique de la gestion de réseau On peut résumer l évaluation des avantages de chaque site sur le tableau suivant : Sécurité Disponibilité Trafic Performance Centre de Montréal Correcte Bonne Bonne Bonne Centre de Sherbrooke Insuffisante Correcte Critique Critique Centre de vente 1 Critique Critique Critique Critique Centre de vente 2 Critique Critique Critique Critique Qu est-ce qui justifierait l utilisation d un proxy? Au vu de la liste des équipements qui est présentée, ils sont tous compatibles SNMP ; le problème de traduction de protocoles et d informations de gestion ne se pose donc pas dans cette étude de cas. Leçon 4 : spécification des informations de gestion requises Quelles sont les MIB disponibles avec chacun de ces agents? Il s agit ici de faire un inventaire complet des informations de gestion disponibles dans les équipements du réseau qui sont nécessaires à la mise en place de la solution de gestion globale. Équipements Sites Type MIB compatibles Routeur Centre de Montréal Cisco 4700 MIB1, MIB2, MIB privée Cisco, RMON1, RMON2 Centre de Sherbrooke Cisco 4700 MIB1, MIB2, MIB privée Cisco, RMON1, RMON2 Centre de vente 1 Cisco 2611 MIB1, MIB2, MIB privée Cisco, RMON1, RMON2 Centre de vente 2 Baynetwork (Nortel) MIB1, MIB2, MIB privée Baynetworks, RMON1, RMON2 Switch Centre de Montréal Catalyst 2900 MIB1, MIB2, MIB privée Cisco, RMON (Statistics, history, alarms et events) Centre de Sherbrooke Catalyst 2900 Idem Centre de vente 1 Catalyst 2900 Idem Centre de vente 2 Catalyst 2900 Idem Que faut-il configurer au niveau des équipements réseau? Tout d abord, il est nécessaire d activer les agents SNMP sur tous les éléments que l on souhaite gérer dans ce réseau : les routeurs, les switchs, les hubs, mais également les serveurs pour une gestion intégrée réseau et système qui n est pas traitée dans cet ouvrage. Ensuite, il convient de configurer les équipements afin de mettre à jour un certain nombre d informations utiles pour leur identification, localisation et maintenance telle que cela est décrit dans le deuxième chapitre concernant le protocole SNMP.

Études de cas de la conception de solutions de gestion CHAPITRE 5 139 Ces informations sont introduites grâce à des commandes de configuration spécifiques de l OS des équipements. Les informations qu il est nécessaire d initialiser sont les suivantes : Objets MIB II Sémantique OID SysDescr Le nom, le type et la version du système géré (par exemple : routeur-montréal, Cisco2900, IOS11) Mib-2.1.1 SysObjectID Identification du type de l objet géré en fonction de sa position dans l arbre MIT. Mib-2.1.2 SysContact Le nom et l adresse de la personne responsable de la gestion de cet équipement (par exemple : Jean Édouard, bureau 116, bâtiment Saint- Exupéry, Montréal). Mib-2.1.4 SysName Nom de l équipement géré (par exemple : routeur-montréal 192.213.45.6) Mib-2.1.5 SysLocation SysServices Localisation physique de l équipement (par exemple : bâtiment 1, étage 3, local technique 213) Le nom, le type et la version du système géré (par exemple : routeur-montréal, Cisco2900, IOS11.1) Mib-2.1.6 Mib-2.1.7 Parmi les autres informations importantes à configurer dans les équipements réseau, il y a la spécification de l adresse IP de la ou des stations d administration. De manière identique à la configuration précédente, une commande spécifique de l OS permet de fixer l adresse de la station de supervision. Dans le cas de la compagnie Alafaribius, on doit connaître l adresse de la station de supervision et introduire cette adresse dans chacun des équipements actifs. Configuration Adresse IP de la station d administration Adresse IP de la station de collecte des traps Stations Admin-montréal.Alafaribius.com Admin-montréal.Alafaribius.com La phase suivante concerne l identification des informations de gestion nécessaires à la mise en place de la stratégie de gestion du réseau Alafaribius. Cette identification est facilitée lorsqu elle est abordée à travers les aires fonctionnelles de la gestion de réseau telles qu elles ont été présentées dans le chapitre 1. Quelles informations la station d administration va-t-elle collecter pour la gestion de la configuration? Il s agit ici de récupérer des informations permettant de constituer la carte topologique du réseau et de visualiser des informations sur le fonctionnement du réseau telles que le statut opérationnel des équipements, les nombres de paquets entrant ou sortant par une interface, etc. En général, la plupart, voire la totalité, des plates-formes sont capables de détecter automatiquement la topologie du réseau et de construire des cartes, et même des courbes. Pour pouvoir collecter automatiquement ces informations directement au niveau des équipements, on doit charger les MIB correspondantes dans la plate-forme de gestion et configurer cette dernière pour qu elle soit à même d afficher correctement ces informations sur la carte topologique.

140 Pratique de la gestion de réseau Dans le cas où l on souhaiterait surveiller les liens entre les différents sites, l état opérationnel de ces liens est donné par l état des interfaces qui y sont connectées. Les informations de base pour ce type de configuration sont résumées dans le tableau suivant : Objets MIB II Sémantique OID ifphysaddress Adresse physique de l interface.1.3.6.1.2.1.2.2.1.6 IfType Type de l interface.1.3.6.1.2.1.2.2.1.3 IfDescr Description de l interface.1.3.6.1.2.1.2.2.1.2 IfAdminStatus Statut administratif d une interface.1.3.6.1.2.1.2.2.1.7 IfOperStatus Statut opérationnel d une interface.1.3.6.1.2.1.2.2.1.8 Ces informations doivent être capturées pour chacune des interfaces. Avec les équipements Cisco, il est également possible d utiliser les extensions privées de la MIB. En effet, il est possible en interrogeant les variables privées de collecter des informations complémentaires sur les équipements Cisco, telles que la description de la carte système, le numéro de série, la version du matériel et du logiciel, les révisions, la position de la carte, etc. Ces informations peuvent être utiles dans le cas où l on souhaiterait avoir, dans la société Alafaribius, une vue centralisée et détaillée des équipements qui se trouvent dans les autres centres sans devoir se déplacer. Quelles informations la station d administration va-t-elle collecter pour la gestion des alarmes? Dans cette perspective, il s agit d assurer l intégrité des communications entre les différents sites de l entreprise. Il faut donc pouvoir détecter toute panne d une interface de routeur, d un port d un switch, dans le réseau de la compagnie Alafaribius. On va donc choisir dans le modèle d information de SNMP, MIB1 et MIB2, voire des MIB propriétaires des objets qui contiennent les informations relativement au statut des équipements, des interfaces, des lignes, etc. Dans le tableau suivant, voici quelques exemples d objets qui permettent de vérifier l état opérationnel des équipements des interfaces en entrée ou en sortie. Objets MIB II Sémantique OID IfAdminStatus Statut administratif d une interface.1.3.6.1.2.1.2.2.1.7 IfInDiscards Nombre de paquets supprimés sur une interface..1.3.6.1.2.1.2.2.1.13 ifinerrors Nombre de paquets reçus supprimés par une interface.1.3.6.1.2.1.2.2.1.14 pour cause d erreurs. ifoutdiscards Nombre de paquets qui n ont pu être transmis par une interface pour cause d erreurs..1.3.6.1.2.1.2.2.1.20 Pour pouvoir surveiller ces équipements, il est nécessaire de réaliser une surveillance par scrutation ou polling des variables de la MIB des équipements qui auront été sélectionnées.

Études de cas de la conception de solutions de gestion CHAPITRE 5 141 La surveillance par polling va permettre de détecter tout changement dans le réseau et de générer immédiatement une alerte. Cette dernière doit être rendue visible à l administrateur réseau sur la carte topologique (en mettant en rouge l icône correspondant à l équipement) et éventuellement émettre un message textuel ou sonore. Ces alertes peuvent être également envoyées à l aide d un message électronique ou SMS à la personne appropriée. Cette fonctionnalité est incluse dans les principales plates-formes de gestion SNMP. La difficulté ici, c est de fixer la période de scrutation pour chacun des équipements. En effet, si celle-ci est trop courte, elle va introduire un trafic important dans le réseau, si elle est trop longue la détection de panne peut être retardée. Une fois les variables identifiées, il convient de définir leurs valeurs de référence. Cela peut être obtenu par surveillance du réseau sur une période donnée (en général, une semaine). Après une semaine de collecte d informations, nous devons analyser les données pour déterminer les seuils de référence pour ces variables. Cette collecte doit intégrer les périodes de surcharge du réseau pour pouvoir identifier au mieux les valeurs de référence permettant de distinguer un état opérationnel normal du réseau d un état congestionné. Le seuil pour les variables doit se situer en général à quelque 10 à 20 % audessus de la valeur calculée. Figure 5-3 Définition des seuils d alarme variable MIB envoi d'un trap Seuil d'alarme Seuil nominal temps Ces valeurs seuils peuvent être utilisées soit pour configurer les seuils dans la plate-forme de gestion, soit pour définir les seuils de déclenchement des traps dans les équipements du réseau (switchs et routeurs) si ces derniers ont la capacité de le faire. Dès lors, ces seuils doivent être définis de manière uniforme pour tous les équipements du même type. Certains ajustements peuvent être réalisés sur des équipements qui ont la même caractéristique (équipement du réseau d accès, du réseau de distribution ou du réseau central (core network). Au niveau de la plate-forme d administration, il faut définir les seuils de déclenchement des alarmes, et donc identifier les notifications qui sont pertinentes et appropriées pour le

142 Pratique de la gestion de réseau déclenchement de ces seuils d alarme. Les alarmes ne signalent pas obligatoirement des fautes graves. Ce sont en général des avertissements que l administrateur doit prendre en compte s ils se répètent trop souvent. La sauvegarde de ces alarmes dans des fichiers de logs permet à l administrateur de mieux comprendre le fonctionnement du réseau et d identifier la source des erreurs. Des ajustements de ces seuils peuvent être nécessaires dans le cas où ces alarmes seraient déclenchées de manière intempestive. On peut proposer une configuration de la plate-forme afin qu elle puisse présenter les alarmes en fonction de leur gravité. Le tableau suivant donne un exemple de configuration : Fonctionnement Source de la cause Présentation Normal Problème mineur au niveau d un routeur. Problème important au niveau d un routeur sans conséquence sur le fonctionnement du réseau. Problème fatal au fonctionnement du réseau. Avertissement sur taux de perte supérieur au seuil prédéfini. Panne alimentation et basculement sur l alimentation de secours. Panne d une carte d interface sur un port WAN. Couleur verte Couleur jaune Couleur orange Couleur rouge clignotante Signal sonore L information sur la panne d alimentation peut être cherchée dans la MIB privée de Cisco comme cela est décrit dans la documentation en ligne de ce constructeur. Quelles informations la station d administration va-t-elle collecter pour la gestion des performances? Il s agit ici de réaliser un certain nombre de configurations qui permettent de collecter des données sur la station d administration afin d évaluer les performances réseau de la compagnie Alafaribius et de déterminer la tendance future en termes de fonctionnement et de trafic. De même que pour la gestion de fautes, il faut déterminer les variables de la MIB à analyser dans le temps. Les informations de performance peuvent être plus ou moins complexes et peuvent nécessiter un calcul par combinaison de données issues de plusieurs variables. Certains indicateurs sur des graphiques (sous forme de courbes ou de camemberts) permettent à l administrateur du réseau d analyser visuellement les performances du réseau, voire de détecter certains incidents. Les informations peuvent être sauvegardées de manière brute dans des fichiers ou encore de manière agrégée dans une base de données. Des rapports synthétiques peuvent dès lors être générés à partir de ces données à des fins de planification de la capacité. Par exemple, pour le réseau Alafaribius, l administrateur réseau peut souhaiter calculer le taux d utilisation des connexions ISDN. Il va falloir collecter plusieurs variables de la MIB pour l évaluer. Le taux d utilisation mesure l utilisation d une ressource dans le temps. Cette mesure est exprimée en pourcentage du maximum de capacité de la ressource. Le taux d utilisation

Études de cas de la conception de solutions de gestion CHAPITRE 5 143 quant à lui permet de savoir si la ressource est en sous-utilisation (problème financier) ou en sur-utilisation (problème de congestion). Supposons que la ressource à contrôler soit la bande passante d un lien. On procède à la mesure du taux d utilisation au niveau des interfaces de routeurs entre les sites de la compagnie Alafaribius. Cette mesure va dépendre de la nature half-duplex ou full-duplex du lien. Comme les variables de la MIB2 sont sauvegardées sous forme de compteurs, il est nécessaire de faire deux cycles de mesures pour procéder au calcul du taux d utilisation comme cela est décrit dans le tableau suivant : Variable de la MIB Signification Intervalle DifInOctets La variation du nombre d octets en entrée d une interface entre deux instants 5 min de collecte de l objet. Cela représente le trafic en entrée de l inter- face. DifOutOctets La variation du nombre d octets en sortie d une interface entre deux instants 5 min de collecte de l objet. Cela représente le trafic en sortie de l interface. ifspeed Le débit de l interface reporté par l objet snmp ifspeed object. Cette valeur 5 min peut être biaisée dans le cas d interfaces WAN. Taux d'utilisation d une ligne full-duplex Max(DifInOctects, DifOutOctets) 8 100 Inyerval 60 ifspeed 5 min Les variables DifInOctets et DifOutOctets sont collectées ensemble toutes les 5 minutes et sauvegardées dans une base d informations. À partir de ces données, un taux d utilisation peut être calculé et l administrateur réseau peut également fixer des seuils d alarme sur ce taux d utilisation pour prévenir d une congestion imminente. Grâce à l établissement de statistiques sur cette variable, il sera capable de déduire dans le temps et en fonction des activités de l entreprise les meilleures valeurs pour les seuils de déclenchement. Leçon 5 : spécification des points de collecte Afin de résoudre le problème de trafic aux heures de pointe, doit-on utiliser la sonde RMON? Une sonde RMON (Remote network monitoring) va permettre de procéder à la collecte de données relatives au segment auquel elle est connectée, comme cela est décrit dans le premier chapitre et dans la RFC1757. Cette sonde est capable de fonctionner de manière autonome, de collecter et de traiter les informations de gestion. L intérêt de l utilisation d une sonde dans le contexte de la compagnie Alafaribius serait de collecter des statiques sur l utilisation des ressources afin d évaluer le trafic dans le réseau Alafaribius et de procéder aux ajustements appropriés en termes de dimensionnement pour de résoudre le problème de dégradation de la qualité de service aux heures de pointe. Cette sonde permet d enregistrer des informations de diverses natures en fonction de l endroit où on la place (taux d utilisation, taux d erreurs, collisions, matrice de flux, historique, dépassement de seuils préconfigurés, etc).

144 Pratique de la gestion de réseau Si oui, où pensez-vous l installer et quelles sont les informations que vous vous proposez d aller chercher? Comme le problème provient des accès aux serveurs NT de Sherbrooke, il est judicieux de placer une sonde RMON au niveau de ce site. Elle va ainsi permettre d alléger la charge de la station d administration qui se trouve sur le site de Montréal et réduire le trafic qui aurait été nécessaire pour surveiller les équipements qui se trouvent à Sherbrooke. On va donc placer une sonde RMON directement sur un port libre sur le switch connecté au routeur du site de Montréal. Il est également possible d utiliser directement les fonctionnalités RMON existantes dans les routeurs et les switchs. En effet, certains de ces équipements implémentent une partie de la MIB RMON. Par exemple, pour les routeurs et les switchs Cisco de la compagnie Alafaribius, les groupes statistics, history, alarms et events de RMON sont implantés. Quant aux switchs Catalyst 2900 et routeurs Catalyst 2611 et 4700, ils concernent les segments Ethernet. En outre, ces équipements supportent également les groupes alarms et events de la RMON. On peut configurer dans ces équipements une surveillance locale des variables de la MIB avec configuration de seuils et génération de traps (voir le site de Cisco). Parmi les informations à surveiller, il y a par exemple le temps de réponse du serveur. Pour ce faire, on configure les seuils de telle sorte que lorsque ce temps est dépassé la sonde RMON envoie un trap à la station d administration qui, à son tour, va envoyer un message à l administrateur réseau. La configuration d une alarme dans la RMON va nécessiter la définition de deux seuils : un premier seuil au-dessus duquel le réseau est congestionné et un second en dessous duquel le réseau repasse dans son état normal. Pour cela, il faut définir les informations suivantes dans le groupe alarmes de la RMON : l intervalle de surveillance de la variable ; la variable à surveiller ; les seuils de déclenchement ; l événement qui est créé lorsque le seuil est dépassé. Dans la société Alafaribius, quelques exemples de variables à surveiller sont contenus dans les groupes qui permettent de calculer les performances entre deux machines IPS : Variable NL Host NL Host Top N NL Matrix Signification Permet de mesurer l usage du réseau par adresse IP Permet de calculer de manière périodique les N plus grands usages du réseau et les reportent dans une matrice NL Matrix sauvegardée au niveau de la RMON Surveille le trafic entre deux adresses IP

Études de cas de la conception de solutions de gestion CHAPITRE 5 145 Leçon 6 : prise en compte de l évolution hétérogène du réseau La compagnie a décidé de ne pas garder l exclusivité de ses équipements au fournisseur d équipements Cisco et d introduire des équipements 3COM dans son réseau. Quelle plate-forme suggéreriez-vous à l administrateur du réseau? Dans le cas où l entreprise Alafaribius déciderait de s équiper de matériels en provenance de différents constructeurs, il faudrait prendre en compte certaines contraintes : Les équipements ne supportent pas la même MIB propriétaire, et certaines applications liées à un constructeur particulier ne fonctionneront donc pas sur cet équipement. Dans le cas de la société Alafaribius, il ne sera pas possible d utiliser les logiciels adaptés aux produits Cisco. Certaines vues dans la station d administration ne sont pas complètes. Il est nécessaire de vérifier que les logiciels particuliers au constructeur sont bien interopérables avec la plate-forme d administration choisie. L apprentissage des systèmes opératoires des différents équipements peut être une tâche fastidieuse pour l ingénieur réseau. La banque Albiruni Le profil de la compagnie La banque Albiruni dispose de plus d une centaine de succursales avec trois centres de traitements situés dans trois provinces canadiennes (Québec, Ontario, Nouvelle-Écosse). Les principaux sites de la compagnie Elle se compose des entités suivantes : Un siège social à Montréal et deux centres régionaux à Toronto et Halifax. 112 succursales à travers les trois provinces. Chaque succursale dispose au minimum d un accès 128 Kbits/s (2B + D) à un des trois centres de traitement régionaux. En outre, la banque dispose de plus de 300 accès de guichets automatiques avec 32 et 56 Kbits/s. Les besoins existants et futurs en communication Le besoin de base de la compagnie est bien entendu constitué par le transactionnel bancaire utilisant SNA (System network architecture). La banque déploie actuellement un réseau TCP/IP et compte utiliser des serveurs NT/Exchange dans toutes les succursales. Elle compte dans le futur déployer des applications client-serveur en intranet.