DEVOIR ADMINISTRATION RESEAUX

BARTHE Aymeric ESSI 3 – SAR 01 [email protected]

DEVOIR ADMINISTRATION RESEAUX

Aymeric BARTHE SAR01 - ESSI 3

Devoir Administration Réseaux 1

I. Exercice

1. Question

Le protocole que l'on doit mettre en place doit répondre aux besoins et uniquement aux besoins des bornes. Afin d'obtenir un niveau d'efficacité maximum, chaque borne doit obtenir l'ensemble des informations avec une seule requête échangée entre le serveur et la borne.

Les besoins des bornes sont les suivants :

Voici le détail du protocole de communication réalisé en ASN1 en utilisant les macros ROSE.

module-ProtocolCarrouf DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS IdProductType, Price, Location, ProductDescription IdDepartment, Department FROM module-TypeCarrouf; getMinPrice OPERATION ::= { ARGUMENT IdProductType RESULT Price ERRORS { unknownProductType } CODE 1 } getProductLocation OPERATION ::= { ARGUMENT IdProductType RESULT Location ERRORS { unknownProductType } CODE 2 } getProductDescription OPERATION ::= { ARGUMENT IdProductType RESULT SEQUENCE OF ProductDescription ERRORS { unknownProductType } CODE 3 } getDepartmentFromTo OPERATION ::= { ARGUMENT IdDepartment RESULT SEQUENCE OF Department



ERRORS { unknownDepartment } CODE 4 } getLaneCount OPERATION ::= { ARGUMENT IdDepartment RESULT INTEGER ERRORS { unknownDepartment } CODE 5 } unknownProductType ERROR ::= { } unknownDepartment ERROR ::= { } END

Les types des différentes requêtes sont décrits ci-dessous. Ces types ne donnent que les informations minimales qui permettent à la borne d'assurer l’affichage. Seul le type Department (rayon) contient en plus un DepartmentID, qui permet à l'utilisateur d'effectuer une requête sur ce rayon, sans que la borne ait besoin de redéterminer son ID à partir du nom. Tous les autres types contiennent directement l'information telle qu'elle sera affichée.

module-TypeCarrouf DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS IdProductType, Price, Location, ProductDescription IdDepartment, Department; Price ::= SEQUENCE { currency Currency, DEFAULT euro, value REAL } Currency ::= ENUMERATED { euro(0), dollar(1), … } ProductDescription ::= SEQUENCE { trademark PrintableString, price Price, photo Picture OPTIONAL, ... } Department ::= SEQUENCE { id IdDepartment, -- pour enchaîner avec un getDepartmentFromTo ou getLaneCount name PrintableString } Location ::= SEQUENCE { departement Department, lane INTEGER } Picture ::= OCTET STRING IdProductType ::= OBJECT IDENTIFIER IdDepartment ::= OBJECT IDENTIFIER END



2. Question

Afin de repérer les types de produits (IdProductType) et les rayons (IdDepartment), il faut avoir un mécanisme qui permet d'attribuer de manière unique ces IDs. L'utilisation d'un annuaire LDAP permet ainsi de résoudre ce problème d'attribution des IDs, en utilisant les OBJECT IDENTIFIERS des différents éléments du DIT. De plus, cet arbre permet aussi d'accélérer le traitement de certaines requêtes provenant des bornes.

Architecture proposée (extrait de DIT) :

Cette architecture permet d'accélérer les requêtes de type getLaneCount ou getProductLocation. En effet, de part sa structure arborescente, l'annuaire permet de localiser rapidement le rayon et l'allée d'un type de produit, ou alors l'ensemble des produits d'un type donné. Si l'on utilisait une base de données pour cela, il faudrait faire une requête du type SELECT FROM WHERE, avec une condition WHERE sur IdProductType. Cette méthode serait beaucoup plus lente car la base de données devrait parcourir l'ensemble des tuples d'une table pour effectuer cette sélection.

En revanche, pour les attributs concernant les produits eux-mêmes, l'usage d'une base de données est plus avisé. En effet, ces attributs sont sujets à de nombreuses modifications en écriture, un domaine dans lequel les annuaires sont peu performants. On peut même imaginer que les tables de gestion des produits sont couplées à une gestion du stock du magasin, ce qui fait que l'information concernant les produits varie à chaque vente !

Par ailleurs, si l'on stocke le RowID des produits dans l'annuaire, l'accès à la base de données se trouve grandement accéléré, et le couplage de cette base avec l'annuaire introduit une grande souplesse.



Enfin, il faut réaliser que cette base de données de gestion des produits existe nécessairement pour le magasin. Il ne s’agit pas d’une contrainte supplémentaire. De plus le stockage des informations concernant les produits à la fois dans l'annuaire et dans la base introduit donc des doublons et pose ainsi des problèmes de synchronisation.

Voici la DIT proposé

( 1.3.6.1.4.1.111057.2000.0 NAME 'top' ABSTRACT MUST objectClass ) ( 1.3.6.1.4.1.111057.2000.3 NAME 'Location' SUP top STRUCTURAL DESC 'object class' MAY ( address $ zipcode) MUST (cn) ) ( 1.3.6.1.4.1.111057.2000.6 NAME 'Department' SUP top STRUCTURAL DESC 'object class' MAY ( nb_of_lanes) MUST (cn) ) ( 1.3.6.1.4.1.111057.2000.9 NAME 'Lane' SUP top STRUCTURAL DESC 'object class' MUST ( cn ) ) ( 1.3.6.1.4.1.111057.2000.12 NAME 'ProductType' SUP top STRUCTURAL DESC 'object class' MUST ( cn & id ) ) ( 1.3.6.1.4.1.111057.2000.12 NAME 'Product' SUP top STRUCTURAL DESC 'object class' MUST ( cn & id ) ) attributetype ( 1.3.6.1.4.1.111057.2001.1 NAME 'address' DESC 'address of mall' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.111057.2001.2 NAME 'zipcode' DESC 'address of mall' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.111057.2001.3 NAME 'nb_of_lanes' DESC 'address of mall' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.111057.2001.4 NAME 'nb_of_lanes' DESC 'address of mall' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )



II. Exercice

1. Question

La MIB doit fournir les informations suivantes : - Localisation dans le magasin (location) - Nb de connexions (connexionsCount) - Date de la dernière mise en activité (lastStart) - État actuel (status)

Voici le détail de la MIB :

CARROUF-TERMINAL-AGENT-MIB DEFINITIONS ::= BEGIN IMPORTS Location FROM module-TypeCarrouf; carrouf OBJECT IDENTIFIER ::= { enterprises 111076 } terminal_agent OBJECT IDENTIFIER ::= { carrouf 1000 } location OBJECT-TYPE SYNTAX Location ACCESS read-write STATUS mandatory DESCRIPTION "Position of the terminal inside the mall" ::= { terminal_agent 1 } connexionsCount OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Nb of connexions to the terminal" ::= { terminal_agent 2 } lastStart OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "Time of the last power up" ::= { terminal_agent 3 } status OBJECT-TYPE SYNTAX INTEGER { ok (1), malfunction (2), } ACCESS read-only STATUS mandatory DESCRIPTION "Status of the terminal" ::= { terminal_agent 4 } id OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Id of the terminal. Must be unique" ::= { terminal_agent 5 } END



Afin d'être informé d'une éventuelle défaillance de la borne, ou de sa déconnexion du réseau, il est judicieux d'implémenter un mécanisme de trap. La borne émettra à intervalles réguliers des messages pour informer le manager sur son état de fonctionnement. Si le gestionnaire ne reçoit pas de message pendant un laps de temps plusieur fois supérieur à celui d’émission, on pourra en déduire que le terminal est en panne ou déconnecté du réseau. De la même manière, si le manager reçoit un message indiquant une panne, il en déduira que la borne bien que connectée, ne fonctionne pas correctement.

statusTrap TRAP-TYPE ENTERPRISE carrouf VARIABLES {status} DESCRIPTION "Message sent regularly to check whether the terminal is working or not" ::= 5

Architecture proposée :

Afin de gérer un magasin, nous allons utiliser le réseau local 192.168.7.0. A chaque borne sera associée un agent SNMP qui permet d'interroger l'état de la borne. Un manager SNMP sera chargé de gérer l'ensemble de ces bornes pour le magasin. Les adresses IP de chaque agent sont attribuées de manière statique. Le nombre de bornes étant peu susceptible de changer dans le magasin, tout système d'attribution d'IP dynamique semble être inutile. La communication s'effectuera en utilisant les ports classiques 161 et 162. Le gestionnaire SNMP quant à lui possède une table contenant les IPs de toutes les bornes du magasin.



2. Question

Pour accéder à l’état de la n-ième borne, le manager envoie une requête Get Resquest, sur la n-ième borne. Le manager reçoit ensuite une Response contenant l'information de status de la n-ième borne. S'il ne reçoit rien, soit la borne est déconnecté, soit l'IP est invalide.

Pour ajouter une borne, il convient d'abord de lui attribuer une IP libre, puis d'ajouter cette IP dans la table de correspondance du Manager. On connecte ensuite cette borne sur le réseau, en donnant à l'agent SNMP associé, l'IP du manager à qui il envoie les Traps.

Une administration GDMO n'apporterait que peu d'intérêt pour une architecture aussi simple. En effet, nous n'avons aucune relation d'héritage susceptible d'être mise en place, et notre MIB ne possède que des types scalaires et aucune table. Ce qui rend inutile l'utilisation d'un arbre d'héritage, de contenance et d'enregistrement. De plus, nos agents sont déployés une fois pour toute, donc un arbre de nommage n'apporterait rien. Dans ce contexte, la richesse GDMO n'a pas d'intérêt et ne ferait que complexifier notre architecture.

III. Exercice

Afin de gérer l'ensemble des magasins, on peut mettre en place une structure entre les réseaux locaux de l'entreprise. Chaque manager de magasin jouera aussi le rôle d'agent SNMP permettant d'accéder à l'état des bornes à partir du centre régional. Une MIB spécifique avec une table, permettra d'accéder à l'état de chaque borne dans chaque magasin. La communication entre les réseaux locaux s'effectuera par une connexion de type WAN, plus ou moins sure, et il sera peut-être nécessaire d'utiliser un protocole de type SMUX si les pertes de paquets UDP sont trop importantes.

Lorsque plus de la moitié des bornes d'un magasin tombe en panne, le manager/agent d'un magasin envoie un message d'erreur de type TRAP au central.



Voici le détail de la MIB implémenté l’agent au niveau de chaque manager SNMP de magasin.

CARROUF-TERMINAL-AGENT-MIB DEFINITIONS ::= BEGIN IMPORTS Location FROM module-TypeCarrouf; carrouf OBJECT IDENTIFIER ::= { enterprises 111076 } mall_agent OBJECT IDENTIFIER ::= { carrouf 1001 } nb_of_malfunctions OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Nb of terminals working"



::= { mall_agent 1 } statusTrap TRAP-TYPE ENTERPRISE carrouf VARIABLES {nb_of_malfunctions} DESCRIPTION "Sent when too many terminals are not working" ::= 5 terminalTable OBJECT-TYPE SYNTAX SEQUENCE OF TerminalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table of pictures" ::= { mall_agent 1 } terminalEntry OBJECT-TYPE SYNTAX TerminalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entry in the pictures table" INDEX { pictureId } ::= { terminalTable 1 } TerminalEntry ::= SEQUENCE { location Location, connexionsCount Gauge, lastStart TimeTicks, status INTEGER, id INTEGER, } location OBJECT-TYPE SYNTAX Location ACCESS read-write STATUS mandatory DESCRIPTION "Position of the terminal" ::= { terminalEntry 1 } connexionsCount OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Nb of connexions to the terminal" ::= { terminalEntry 2 } lastStart OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "Time of the last power up" ::= { terminalEntry 3 } status OBJECT-TYPE SYNTAX INTEGER { ok (1), malfunction (2), } ACCESS read-only STATUS mandatory DESCRIPTION "Status of the terminal" ::= { terminalEntry 4 }



id OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Id of the terminal. Must be unique" ::= { terminalEntry 5 } END

Documents

DEVOIR ADMINISTRATION RESEAUX