Exemples d’utilisation des agents mobiles .1 Quelques exemples simples exploitant la propriété.1Quelques exemples simples exploitant la propriété

d’autonomie

En constatant que les réseaux actuels offrent de plus en plus de bande pas-sante (LAN, WAN, WLAN), nous allons introduire des exemples concrets d’uti-lisation des agents mobiles dans un cadre d’administration système et réseau. Ces exemples permettent de justifier le choix de la technologie à agent mobile en

PC 4

PC 2

PC 1 ^{PC 3}

Serveur HTTP + Linux (SRV)

Point d’acces Wifi commutateur 10/100Mbps

Coeur du reseau 100Mbps

10Mbps

Fig. 7.13 – Schéma d’un réseau Wifi fonctionnant en mode ad hoc

fonction, non pas des performances et du gain en bande passante escompté, mais en fonction du service rendu. Des critères tels la réactivité, l’autonomie, la prise en compte de contraintes géographiques sont alors considérés.

Imaginons par exemple, qu’un administrateur veuille effectuer un inventaire automatique de tous les systèmes connectés au réseau de son entreprise. Pour cela, on met en œuvre des opérations Java et des requêtes SNMP afin de collecter le descriptif des systèmes, mais aussi sur chaque hôte (PC, serveur) ayant la MIB host implanté, toutes les ressources du système. Dans cet exemple, le temps de réponse n’est pas critique puisque la tâche est une tâche de fond, de longue haleine. Il s’agit de déployer plusieurs agents mobiles respectant l’architecture du réseau, c’est-à-dire déployés sur l’ensemble des sites. Avec l’autonomie propre de chaque agent, lorsque l’opération d’administration est menée à terme, chaque agent mobile peut ramener à la station d’administration les données collectées ou alors les transmettre à l’agent responsable de la mise en forme de celles-ci. Toutes ces opérations peuvent être effectuées indépendamment de la station d’administration.

Prenons un autre exemple : un service d’impression sur le réseau s’arrête de manière inopinée. En urgence, l’administrateur va envoyer un agent mobile dédié à la supervision de ce service afin de savoir rapidement la cause de cet arrêt. En même temps, l’agent mobile peut essayer de relancer le service défectueux, ou de rediriger toutes les impressions bloquées vers un autre service d’impression. Une solution plus autonome, consiste à utiliser des agents mobiles de supervi-sion qui n’attendraient pas d’ordre direct de l’administrateur pour réagir à toute modification des services réseaux fournis.

7.3.2 Exemple : Autoconfiguration des VLANs dans un

réseau

Imaginons un administrateur de réseau qui doit déployer une nouvelle archi-tecture de réseau, bien que notre exemple puisse s’appliquer aisément dans le cas d’une architecture réseau en exploitation. L’administrateur du réseau prépare les configurations de base des équipements actifs du réseau, en fonction de ses de-siderata : Nom logique, adresse Ip, nom de communauté SNMP V1 en lecture seule, informations sur la configuration SNMP V3 nécessaire pour les opérations d’administration, et ce pour chaque commutateur appartenant au cœur du ré-seau. Il définit aussi des réseaux virtuels (VLANs) afin de contrôler les accès entre les différents éléments qui seront connectés sur le réseau : PC, serveurs, imprimantes, dans l’optique de faire des groupes de machines par réseau virtuel. Pour réaliser cela, l’administrateur doit connaître le lien entre chacune des inter-faces sur les commutateurs, les éléments qui doivent y être connectés et le VLAN dans lequel ces éléments doivent être intégrés. Par défaut, les configurations des commutateurs associent chaque port au VLAN administratif, qui est le VLAN de gestion du commutateur. Pour changer cette valeur par défaut, l’administrateur doit donc, soit se connecter sur le commutateur pour en changer la configura-tion (en utilisant un client ssh [48], par exemple), soit utiliser pour des raisons de sécurité et de distance, le protocole SNMP V37. Dans tous les cas, l’adminis-trateur devra connaître l’adresse IP du commutateur sur lequel il doit effectuer l’assignation du VLAN sur une interface de ce commutateur.

En nous basant sur l’exemple proposé par la figure 7.14, où le VLAN 180 est déjà déclaré pour certains éléments, nous allons expliciter comment nous utilisons un agent mobile pour configurer les VLANs sur les ports des commutateurs.

Ainsi, en utilisant un itinéraire de migration dans le réseau local, ou vers un réseau local distant, et en fournissant comme information à l’agent mobile : (1) l’adresse Ethernet de l’élément concerné par l’assignation du VLAN ; (2) le nu-méro du VLAN pour configurer l’interface du commutateur, l’agent mobile peut automatiquement configurer l’interface du bon commutateur de manière complè-tement automatique. En effet, notre algorithme de construction de la topologie nous permet de détecter automatiquement l’équipement actif sur lequel l’action de l’agent mobile doit être effectuée.

7.4 Bilan

Par les tests que nous avons mis en œuvre, sur le réseau présenté par la figure 7.1, nous pouvons constater que la technologie des agents mobiles donne

7attribut de l’entrée de la MIB :

private.cisco.ciscoMgmt.ciscoVlanMembershipMib.-ciscoVlanMembershipMIBObjects.

PC 4 PC 3

Vlan 1

Vlan 180 Vlan 180 ^{Vlan 180}

PC 2 PC 1 Switch 3 Switch 2 Switch 1 Workgroup Switch Catalyst Workgroup Switch Catalyst Workgroup Switch Catalyst _CiscoSystems CiscoSystems CiscoSystems

Fig. 7.14 – Schéma du réseau pour l’autoconfiguration des VLANs

des avantages en temps d’exécution et que les résultats obtenus ne sont pas trop dépendants du débit inter-réseau. A contrario, les tests montrent effectivement que le modèle Client/Serveur exécuté à distance n’est pas adapté à la collecte d’un nombre important de variables SNMP sur plusieurs agents SNMP. La mise en œuvre de tâches longues qu’un administrateur souhaite voir exécutées est tout à fait envisageable en utilisant des agents mobiles, notamment lorsque les éléments sont situés sur un réseau distant et qu’il est possible de réaliser des opérations sur des éléments qui n’étaient pas concernés au départ grâce aux itinéraires construits dynamiquement. Il convient de constater que lorsque les fonctions sont à exécuter sur le réseau local, les deux techniques (Client/Serveur et agent mobile) sont aussi bien applicables l’une que l’autre.

Quand on travaille sur un réseau de nouvelle génération (type Wifi), il est nécessaire de prendre en compte les contraintes qui y sont associées : latence, faible bande passante, collision, mode de fonctionnement du réseau (infrastructure ou ad hoc). Ainsi nous avons pu constater par l’évaluation des performances d’agents mobiles agissant sur un réseau Wifi que des précautions doivent être prises : il faut alléger l’agent mobile pour une meilleure efficacité ; éviter les aller-retour inutiles pendant l’itinéraire, ce qui impose que l’itinéraire d’administration soit très adapté à ce type de réseau ; l’utilisation d’un agent mobile stationnaire permet sur ce type de réseau de regrouper et mettre à disposition des informations d’administration sans pour autant engorger le réseau Wifi.

Pour conclure ce chapitre, nous pensons que les agents mobiles trouvent une place dans le monde de l’administration système et réseau mais que cette techno-logie n’est pas adaptée à toutes les fonctions d’administration réseau (par exemple une fonction de courte durée sur un réseau local). Il est préférable d’utiliser les agents mobiles pour des tâches "plus longues", réalisables de manière décentralisée et autonome, et n’imposant pas une urgence particulière.

Conclusion