Pratique de le gestion de réseau - eyrolles.com · • Acquérir une expérience dans la mise en...

Pratique de le gestion de réseau

Nazim Agoulmine Omar Cherkaoui

© Groupe Eyrolles, 2003ISBN : 2-212-11259-9

AgoulmineTDM.fm Page XIV Lundi, 10. mars 2003 11:40 11

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 degestion 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

Agoulmine.Livre Page 129 Dimanche, 16. février 2003 6:27 18

© G

roup

e E

yrol

les,

200

3

Pratique de la gestion de réseau130

Après avoir respectivement présenté, dans le chapitre 1, une approche méthodique duprocessus de mise en place d’une gestion appropriée d’un réseau d’entreprise, dans leschapitres 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éhen-der l’utilisation de notre méthode de mise en œuvre de la gestion dans différentes infra-structures. Ces trois études de cas ont été choisies afin de refléter des scénarios réalistesauxquels les lecteurs peuvent être confrontés.

En guise de rappel succinct, voici représenté dans le diagramme suivant le processusdéveloppé dans le chapitre 1, qui comporte 7 phases « top-down » principales :

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 communicationLAN interconnectée par un réseau commuté ISDN ;

• la banque Albiruni qui met en place une infrastructure complexe de communicationLAN/MAN/WAN utilisant les technologies Sonet et ATM ;

• le musée Léonard-de-Vinci qui met en place une infrastructure LAN commutée detype gigabit Ethernet avec des besoins spécifiques de fonctionnement des applicationspropres à ce type d’organisation.

La phase La démarche

Description de l’environnement cible à gérer S’imprégner de la problématique et de sa complexité.

Identification des besoins en gestion de cet environnement

Comprendre, filtrer et synthétiser les besoins de l’entrepr ise et iden-tifier les fonctionnalités de gestion pertinentes.

Identification des technologies utilisées dans cet environnement

Faire un panorama des technologies utilisées dans l’environnementet leurs capacités à être gérées.

Choix d’une architecture de gestion adaptée En fonction des technologies, faire un choix en terme d’architecturede gestion qui soit le plus adapté et qui réponde au mieux auxobjectifs.

Choix d’une ou plusieurs plates-formes technologiques

En fonction des technologies, des besoins de gestion, de l’enveloppebudgétaire, des perspectives d’évolution du réseau, faire un choix deplate-forme.

Mise en place de la solution et de sa configuration

Identifier les informations de gestion nécessaires, les outils complé-mentaires à mettre en œuvre, les points de collectes, puis configurerles équipements actifs ainsi que la plate-forme de gestion. Faire destests de fonctionnement et ajuster les paramètres de configuration.

Recette de la solution É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 bonfonctionnement de la plate-forme.


© G

roup

e E

yrol

les,

200

3

Études de cas de la conception de solutions de gestionCHAPITRE 5

131

Figure 5-1

Processus d’apprentissage au domaine de la gestion de réseau

Sélectionner unenvironnement de gestionadaptés aux besoins de

l'entreprise

L'architecture TMNLes nouvelles architectures

de gestionL'architecture SNMP

S'initier à une solution degestion

Configurer une sondeS'initier à une solution de

gestionReconnaître et décrire lesinformations de gestion

La sonde RMONL'environnement

HPOpenView

L'environnementOptivity

L'environnementCisco

Les limites actuelles de lagestion de réseau

Les informations de gestionMIB1 et MIB2

La solution INM

Les informations de gestiondes MIB privées

L'approche de gestion via lespolitiques

L'approche de gestion via lesannuaires

La solution ISM

Maîtriser lefonctionnement et les

composantes de SNMP

Maîtriser lefonctionnement et lescomposantes du TMN

Initiation aux nouvellestechnologies

Les environnements degestion

Pourquoi a t-onbesoin de la

gestion ?

La gestion de réseau


© G

roup

e E

yrol

les,

200

3


La société AlafaribiusLe profil de la compagnie

La compagnie Alafaribius est une société canadienne spécialisée dans la fabrication, lemontage et la distribution de matériel électronique (ordinateurs, téléviseurs, magnéto-scopes, radios et divers autres produits). Elle est composée de plusieurs unités distribuéesgé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 typesd’applications. Ils sont en augmentation croissante d’année en année et la compagnie adécidé de considérablement développer son réseau de données dans les cinq prochainesannées. Outre l’augmentation en capacité du réseau, elle compte intégrer son réseau voixet son réseau données.

Les principales applications

Les employés de l’entreprise utilisent un ensemble d’applications critiques décrites ci-aprè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 sitespériphériques convergent vers un site principal (siège social) qui contient un ordinateurcentral. Les sites périphériques (principalement, les sites de ventes) sont dotés d’ordina-teurs AS400. De plus, elle dispose de 10 serveurs NT et de 3 serveurs Unix à Sherbrooke.Chaque site dispose de son propre serveur de fichiers.


© G

roup

e E

yrol

les,

200

3


133

Les protocoles existants

Les protocoles utilisés sont Ethernet en réseau local, TCP/IP, NetBUI, SNA. Une passe-relle SNA-TCP/IP a été installée en amont de l’ordinateur central, de façon à supporter leprotocole 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.

Figure 5-2

Schéma du réseau WAN

Centre de Montréal

CISCO 4700Router

Catalyst 2900

Catalyst 2900

7

Centre de Sherbrooke

CISCORouter

Catalyst 2900

Catalyst 2900

7

Centre de vente

BaynetworksRouter

Catalyst 2900 10

ISDN PRI

Centre de vente

CISCO 2611Router

Catalyst 2900 10

Firewall Internet

ISDN PRI

ISDN PRI


© G

roup

e E

yrol

les,

200

3


L’objectif de la gestion : cahier des charges

Au vu de la croissance de son réseau, la compagnie Alafaribius souhaite mettre en œuvreune solution d’administration globale. Pour ce faire, elle souhaite se doter d’une infra-structure de gestion de réseau lui permettant de gérer à distance ces équipements. Unadministrateur de serveurs est disponible à Montréal et à Sherbrooke. Un administrateurré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éthodeque nous préconisons et identifier les éléments pertinents qui permettront au lecteur demieux 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 decommencer 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 gestionde 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 quipermettent de configurer les éléments actifs du réseau. Ces systèmes sont générale-ment hétérogènes (un ou plusieurs systèmes par constructeur) mais il est possible deretrouver globalement les mêmes fonctionnalités de base. Dans le cas des équipementsCisco, 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 visua-liser les états de tous les équipements du réseau de manière intuitive. Dans ce cas, ilconvient 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 fonction-nalités qui permettront de faire rapidement remonter au niveau du réseau toutes lespannes qui peuvent survenir au niveau des équipements ou provenant d’arrêts deservice en général. Il est nécessaire dans ce cas de bien connaître les équipementsactifs 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 auxobjectifs qui lui ont été assignés. Il ne s’agit pas simplement de vérifier que la connecti-vité 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 auxquelleson 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


© G

roup

e E

yrol

les,

200

3


135

définis. Des erreurs d’accès aux bases de données peuvent, dans certains cas, n’êtreprovoquées que par des problèmes de temps de réponse trop longs qui déclenchent desprocédures de recouvrement automatique dans ces bases de données, alors qu’enréalité, il n’y a pas d’erreurs de transmission ni de pertes de connectivité. Pour mettreen place ce processus de vérification, il est nécessaire d’identifier les outils logiciels oumatériels qui permettent d’effectuer une surveillance passive et de faire remonter desalarmes à l’administrateur réseau.

Ces activités sont résumées dans le tableau suivant :

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 Alafaribiusafin de déterminer par la suite les outils adaptés à sa gestion selon les besoins identifiésdans la section précédente.

Les applications mises en place au niveau de chaque site utilisent différents protocolessous-jacents. On retrouvera au niveau global une architecture intranet basée sur la famillede protocoles TCP/IP. Au niveau de la communication locale, le réseau s’appuie sur uneinfrastructure 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 communicationsintersites, le réseau utilise un service PRI synchrone de ISDN.

Les protocoles utilisés sont synthétisés dans le réseau.

Activité Besoins

Configuration 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.

Surveillance 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.

Gestion des alarmes

Traitement des pannes et des arrêts de service.• Besoins d’outils permettant de définir des seuils de déclenchement des aler tes, de capturer

les alarmes issues des équipements actifs et de contrôler des équipements .

Gestion des performances

Assurer une disponibilité permanente du réseau et des temps de réponse compatibles avec lesSLA (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.

Perspective Protocoles

Bout en bout IP

Cœur du réseau WAN ISDNIP

Cœur des réseaux LAN Ethernet, NetBUI, IP, SNA


© G

roup

e E

yrol

les,

200

3


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érentesclasses d’équipement, ainsi que de lister leur constructeur. Dans cette phase, l’objectif estd’identifier, d’une part, les capacités de gestion de ces équipements par rapport auxbesoins de gestion exprimés dans la phase précédente et, d’autre part, la technologie degestion de réseau qu’ils supportent.

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 degestion du réseau Alafaribius qui soit compatible avec les besoins exprimés et avec lesarchitectures technologiques identifiées à l’étape précédente.

L’environnement technologique du réseau de la compagnie Alafaribius reposant entière-ment 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 degestion SNMP. Comme décrit dans le chapitre précédent, il existe une panoplie de plates-formes de gestion SNMP. Le choix de la solution finale dépendra des possibilités fonction-nelles de la plate-forme, mais aussi du coût, de la mise en place et de la maintenance decette dernière. Parmi les plates-formes, on retrouvera les ténors du marché : HP OpenViewNNM, Tivoli, Computer Associates, etc. L’autre critère de choix est la capacité des plates-formes à offrir des outils complémentaires permettant de prendre en compte des besoinsspé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. À cetteplate-forme, il serait judicieux d’associer un outil de configuration propriétaire de Ciscopour la configuration des routeurs Cisco, par exemple CiscoView. Néanmoins, d’autresplates-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ésdans le réseau de la compagnie Alafaribius selon la topologie décrite précédemment.

Équipement Constructeur Protocoles compatibles Technologie de gestion compatibles

Routeur Cisco IP, NetBUI SNMP, configuration propriétaire Cisco

Switch Cisco Ethernet, ISL SNMPConfiguration propriétaire Cisco

Switch Baynetworks Ethernet SNMPConfiguration propriétaire Baynetworks


© G

roup

e E

yrol

les,

200

3


137

En plus des traps SNMP, certains équipements peuvent également envoyer des trapsSyslog. Les équipements implémentent en général une MIB privée à cet effet. Toutes lesstations de gestion peuvent recevoir ces événements sur un port UDP prédéfini. Chaquemessage 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 demanière plus précise les informations de gestion sur les équipements réseau, en fournis-sant 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 environne-ment 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 à plusieurscritè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 judi-cieux de choisir le site de Montréal comme site de déploiement de la plate-forme degestion. Ce choix a plusieurs avantages :

• La plate-forme se trouve sur le site de convergence, ce qui permet de diminuer lestemps de remontée des alarmes.

• On évite ainsi la surcharge des sites avec du trafic de gestion comme cela aurait été lecas 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 lacompagnie 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é.

É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


Serveur Centre de Montréal Serveur AS400 VMS

Centre de Sherbrooke Serveur NT Windows NT

Serveur Unix Unix


© G

roup

e E

yrol

les,

200

3


On peut résumer l’évaluation des avantages de chaque site sur le tableau suivant :

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 ; leproblème de traduction de protocoles et d’informations de gestion ne se pose donc pasdans 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 dansles équipements du réseau qui sont nécessaires à la mise en place de la solution degestion globale.

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’onsouhaite gérer dans ce réseau : les routeurs, les switchs, les hubs, mais également lesserveurs 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 nombred’informations utiles pour leur identification, localisation et maintenance telle que celaest décrit dans le deuxième chapitre concernant le protocole SNMP.

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

É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




© G

roup

e E

yrol

les,

200

3


139

Ces informations sont introduites grâce à des commandes de configuration spécifiques del’OS des équipements.

Les informations qu’il est nécessaire d’initialiser sont les suivantes :

Parmi les autres informations importantes à configurer dans les équipements réseau, il ya la spécification de l’adresse IP de la ou des stations d’administration. De manière iden-tique à la configuration précédente, une commande spécifique de l’OS permet de fixerl’adresse de la station de supervision. Dans le cas de la compagnie Alafaribius, on doitconnaître l’adresse de la station de supervision et introduire cette adresse dans chacundes équipements actifs.

La phase suivante concerne l’identification des informations de gestion nécessaires à lamise en place de la stratégie de gestion du réseau Alafaribius. Cette identification estfacilitée lorsqu’elle est abordée à travers les aires fonctionnelles de la gestion de réseautelles 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 laconfiguration ?

Il s’agit ici de récupérer des informations permettant de constituer la carte topologiquedu réseau et de visualiser des informations sur le fonctionnement du réseau telles que lestatut opérationnel des équipements, les nombres de paquets entrant ou sortant par uneinterface, etc. En général, la plupart, voire la totalité, des plates-formes sont capables dedétecter automatiquement la topologie du réseau et de construire des cartes, et même descourbes. Pour pouvoir collecter automatiquement ces informations directement au niveaudes équipements, on doit charger les MIB correspondantes dans la plate-forme de gestionet configurer cette dernière pour qu’elle soit à même d’afficher correctement ces informa-tions sur la carte topologique.

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 Localisation physique de l’équipement (par exemple : bâtiment 1, étage 3, localtechnique 213)

Mib-2.1.6

SysServices Le nom, le type et la version du système géré (par exemple : routeur-montréal,Cisco2900, IOS11.1)

Mib-2.1.7

Configuration Stations

Adresse IP de la station d’administration Admin-montréal.Alafaribius.com

Adresse IP de la station de collecte des traps Admin-montréal.Alafaribius.com


© G

roup

e E

yrol

les,

200

3


Dans le cas où l’on souhaiterait surveiller les liens entre les différents sites, l’état opéra-tionnel de ces liens est donné par l’état des interfaces qui y sont connectées. Les informa-tions de base pour ce type de configuration sont résumées dans le tableau suivant :

Ces informations doivent être capturées pour chacune des interfaces.

Avec les équipements Cisco, il est également possible d’utiliser les extensions privées dela MIB. En effet, il est possible en interrogeant les variables privées de collecter desinformations complémentaires sur les équipements Cisco, telles que la description de lacarte système, le numéro de série, la version du matériel et du logiciel, les révisions, laposition de la carte, etc. Ces informations peuvent être utiles dans le cas où l’on souhai-terait avoir, dans la société Alafaribius, une vue centralisée et détaillée des équipementsqui se trouvent dans les autres centres sans devoir se déplacer.

Quelles informations la station d’administration va-t-elle collecter pour la gestion desalarmes ?

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 derouteur, 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 desMIB 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’étatopérationnel des équipements des interfaces en entrée ou en sortie.

Pour pouvoir surveiller ces équipements, il est nécessaire de réaliser une surveillance parscrutation ou polling des variables de la MIB des équipements qui auront été sélectionnées.


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


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 pour cause d’erreurs.

.1.3.6.1.2.1.2.2.1.14

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


© G

roup

e E

yrol

les,

200

3


141

La surveillance par polling va permettre de détecter tout changement dans le réseau etde générer immédiatement une alerte. Cette dernière doit être rendue visible à l’admi-nistrateur 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 alertespeuvent être également envoyées à l’aide d’un message électronique ou SMS à lapersonne appropriée.

Cette fonctionnalité est incluse dans les principales plates-formes de gestion SNMP. Ladifficulté ici, c’est de fixer la période de scrutation pour chacun des équipements. Eneffet, si celle-ci est trop courte, elle va introduire un trafic important dans le réseau, si elleest 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. Celapeut être obtenu par surveillance du réseau sur une période donnée (en général, unesemaine). Après une semaine de collecte d’informations, nous devons analyser lesdonnées pour déterminer les seuils de référence pour ces variables. Cette collecte doitintégrer les périodes de surcharge du réseau pour pouvoir identifier au mieux les valeursde référence permettant de distinguer un état opérationnel normal du réseau d’un étatcongestionné. Le seuil pour les variables doit se situer en général à quelque 10 à 20 % au-dessus de la valeur calculée.

Ces valeurs seuils peuvent être utilisées soit pour configurer les seuils dans la plate-forme degestion, soit pour définir les seuils de déclenchement des traps dans les équipements duréseau (switchs et routeurs) si ces derniers ont la capacité de le faire. Dès lors, ces seuilsdoivent être définis de manière uniforme pour tous les équipements du même type. Certainsajustements peuvent être réalisés sur des équipements qui ont la même caractéristique (équi-pement 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éclenchementdes alarmes, et donc identifier les notifications qui sont pertinentes et appropriées pour le

Figure 5-3

Définition des seuils d’alarme

Seuil nominal

Seuil d'alarme

temps

variableMIB

envoi d'un trap

Agoulmine.Livre 1 Dimanche, 16. février 2003 6:27 18

© G

roup

e E

yrol

les,

200

3


déclenchement de ces seuils d’alarme. Les alarmes ne signalent pas obligatoirement desfautes graves. Ce sont en général des avertissements que l’administrateur doit prendre encompte s’ils se répètent trop souvent. La sauvegarde de ces alarmes dans des fichiers delogs permet à l’administrateur de mieux comprendre le fonctionnement du réseau etd’identifier la source des erreurs. Des ajustements de ces seuils peuvent être nécessairesdans 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 alar-mes en fonction de leur gravité. Le tableau suivant donne un exemple de configuration :

L’information sur la panne d’alimentation peut être cherchée dans la MIB privée deCisco 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 desperformances ?

Il s’agit ici de réaliser un certain nombre de configurations qui permettent de collecterdes données sur la station d’administration afin d’évaluer les performances réseau de lacompagnie Alafaribius et de déterminer la tendance future en termes de fonctionnementet de trafic.

De même que pour la gestion de fautes, il faut déterminer les variables de la MIB à analyserdans le temps. Les informations de performance peuvent être plus ou moins complexes etpeuvent 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) permet-tent à l’administrateur du réseau d’analyser visuellement les performances du réseau, voirede détecter certains incidents.

Les informations peuvent être sauvegardées de manière brute dans des fichiers ou encorede manière agrégée dans une base de données. Des rapports synthétiques peuvent dèslors ê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 letaux d’utilisation des connexions ISDN. Il va falloir collecter plusieurs variables de laMIB pour l’évaluer.

Le taux d’utilisation mesure l’utilisation d’une ressource dans le temps. Cette mesure estexprimée en pourcentage du maximum de capacité de la ressource. Le taux d’utilisation

Fonctionnement Source de la cause Présentation

Normal Couleur verte

Problème mineur au niveau d’un routeur. Avertissement sur taux de pertesupérieur au seuil prédéfini.

Couleur jaune

Problème important au niveau d’un routeur sansconséquence sur le fonctionnement du réseau.

Panne alimentation et basculementsur l’alimentation de secours.

Couleur orange

Problème fatal au fonctionnement du réseau. Panne d’une carte d’interface surun port WAN.

Couleur rouge clignotanteSignal sonore


© G

roup

e E

yrol

les,

200

3


143

quant à lui permet de savoir si la ressource est en sous-utilisation (problème financier) ouen sur-utilisation (problème de congestion).

Supposons que la ressource à contrôler soit la bande passante d’un lien. On procède à lamesure du taux d’utilisation au niveau des interfaces de routeurs entre les sites de lacompagnie Alafaribius. Cette mesure va dépendre de la nature half-duplex ou full-duplexdu lien.

Comme les variables de la MIB2 sont sauvegardées sous forme de compteurs, il estnécessaire de faire deux cycles de mesures pour procéder au calcul du taux d’utilisationcomme cela est décrit dans le tableau suivant :

Les variables DifInOctets et DifOutOctets sont collectées ensemble toutes les 5 minutes etsauvegardées dans une base d’informations. À partir de ces données, un taux d’utilisationpeut être calculé et l’administrateur réseau peut également fixer des seuils d’alarme surce taux d’utilisation pour prévenir d’une congestion imminente. Grâce à l’établissementde statistiques sur cette variable, il sera capable de déduire dans le temps et en fonctiondes 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 collectede données relatives au segment auquel elle est connectée, comme cela est décrit dans lepremier chapitre et dans la RFC1757. Cette sonde est capable de fonctionner de manièreautonome, 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 decollecter des statiques sur l’utilisation des ressources afin d’évaluer le trafic dans le réseauAlafaribius et de procéder aux ajustements appropriés en termes de dimensionnement pourde 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 del’endroit où on la place (taux d’utilisation, taux d’erreurs, collisions, matrice de flux,historique, dépassement de seuils préconfigurés, etc).

Variable de la MIB Signification Intervalle

DifInOctets La variation du nombre d’octets en entrée d’une interface entre deux ins-tants de collecte de l’objet. Cela représente le trafic en entrée de l’inter-face.

5 min

DifOutOctets La variation du nombre d’octets en sortie d’une interface entre deux ins-tants de collecte de l’objet. Cela représente le trafic en sortie de l’interface.

5 min

ifSpeed Le débit de l’interface reporté par l’objet snmp ifSpeed object. Cette valeurpeut être biaisée dans le cas d’interfaces WAN.

5 min

Taux d'utilisation d’uneligne full-duplex

Max(DifInOctects, DifOutOctets) × 8 × 100

Inyerval × 60 × ifSpeed

5 min


© G

roup

e E

yrol

les,

200

3


Si oui, où pensez-vous l’installer et quelles sont les informations que vous vous proposezd’aller chercher ?

Comme le problème provient des accès aux serveurs NT de Sherbrooke, il est judicieux deplacer une sonde RMON au niveau de ce site. Elle va ainsi permettre d’alléger la charge dela 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 existantesdans les routeurs et les switchs. En effet, certains de ces équipements implémentent unepartie de la MIB RMON.

Par exemple, pour les routeurs et les switchs Cisco de la compagnie Alafaribius, les grou-pes statistics, history, alarms et events de RMON sont implantés. Quant aux switchsCatalyst 2900 et routeurs Catalyst 2611 et 4700, ils concernent les segments Ethernet.

En outre, ces équipements supportent également les groupes alarms et events de laRMON. On peut configurer dans ces équipements une surveillance locale des variablesde 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é lasonde RMON envoie un trap à la station d’administration qui, à son tour, va envoyer unmessage à 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 dessousduquel 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 contenusdans les groupes qui permettent de calculer les performances entre deux machines IPS :

Variable Signification

NL Host Permet de mesurer l’usage du réseau par adresse IP

NL Host Top N Permet de calculer de manière périodique les N plus grands usages du réseau et les repor tentdans une matrice NL Matrix sauvegardée au niveau de la RMON

NL Matrix Surveille le trafic entre deux adresses IP


© G

roup

e E

yrol

les,

200

3


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 fournisseurd’é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 provenancede différents constructeurs, il faudrait prendre en compte certaines contraintes :

• Les équipements ne supportent pas la même MIB propriétaire, et certaines applica-tions 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 logicielsadaptés aux produits Cisco.

• Certaines vues dans la station d’administration ne sont pas complètes. Il est nécessairede vérifier que les logiciels particuliers au constructeur sont bien interopérables avec laplate-forme d’administration choisie.

• L’apprentissage des systèmes opératoires des différents équipements peut être unetâ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 detraitements 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 troiscentres de traitement régionaux.

• En outre, la banque dispose de plus de 300 accès de guichets automatiques avec 32 et56 Kbits/s.

Les besoins existants et futurs en communication

Le besoin de base de la compagnie est bien entendu constitué par le transactionnelbancaire utilisant SNA (System network architecture). La banque déploie actuellementun 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.


© G

roup

e E

yrol

les,

200

3

Pratique de le gestion de réseau - eyrolles.com · • Acquérir une expérience dans la mise en...

Documents

Transcript of Pratique de le gestion de réseau - eyrolles.com · • Acquérir une expérience dans la mise en...