Service des réseaux d'information

Le réseau UCL : aspects de gestion

Contenu


Préambule

En avril 1998, le Conseil d'administration a décidé la rénovation et l'extension du réseau informatique de l'UCL. Une période de trois ans était prévue pour la réalisation. Au fur et à mesure de l'achèvement des travaux de câblage dans les bâtiments, le nouveau réseau UCL y est mis en service. Le réseau UCL est de la responsabilité du Service des réseaux d'information (SRI). Celui-ci en assure la gestion de manière à fournir le service IP (Internet Protocol) jusqu'à la prise dans le local de l'utilisateur. Cela se fait en bonne intelligence avec les équipes locales.

Afin de passer en revue différents aspects liés à la gestion du réseau UCL, après ses rénovation et extension, le SRI organise des rencontres avec les responsables et équipes informatiques facultaires et locales. Les notes ci-après reprennent la synthèse de l'ensemble des réflexions qui voient le jour au fur et à mesure de ces rencontres.

Les modalités de la gestion assurée par le SRI évoluent encore et se précisent au cours du temps. Il est opportun de les diffuser plus largement et de permettre aux utilisateurs de les connaître.

Mise en service d'un raccordement au réseau

La mise en service se fait au fur et à mesure des demandes et sous le contrôle du SRI. Les demandes de raccordement au réseau UCL se font au moyen d'un formulaire prévu à cet effet. Ce formulaire est sans doute disponible auprès du gestionnaire informatique local. Il est possible aussi de s'en procurer une copie PDF (Portable Document Format) à imprimer localement. Le nom de domaine (DNS) est à proposer par le demandeur, avec l'aide de son équipe informatique facultaire, le cas échéant.

Selon la demande de plusieurs équipes informatiques facultaires (EIF), le formulaire transite par l'EIF avant d'arriver au SRI. L'EIF peut ainsi être le partenaire unique vis-à-vis du SRI.

Selon les cas, l'opération comprend :

Du point de vue de l'utilisateur, la problématique doit se résoudre à la mise en service du raccordement demandé. Les moyens nécessaires et les difficultés éventuelles ne doivent pas lui incomber, ni à l'EIF. La mise en oeuvre est du ressort de l'Administration des services techniques (ADST).

Le délai de réponse est un point sensible. Certaines EIF assuraient l'installation d'une nouvelle prise en une semaine environ. Pour la mise en service d'une prise déjà installée et l'attribution d'une adresse IP, un délai de 2-3 jours est considéré comme acceptable, délai à compter après réception du formulaire au SRI.

Normalement, ce genre d'opération devrait être d'autant plus prévisible qu'elle est d'une certaine ampleur et concerne plus ou moins de raccordements. Le déplacement d'une machine d'un local à un autre se fait sans doute avec moins de prévision, que le déménagement de toute une entité.

Concernant la disponibilité d'une prise, le SRI peut fournir à la demande des gestionnaires locaux, la liste des prises en service. De plus, le SRI examine la possibilité de permettre l'accès à cette information directement à partir de la base de données.

Lorsque le raccordement est mis en service, une copie du formulaire est envoyée au demandeur et une autre à l'EIF.

En cas de changement de raccordement, un nouveau formulaire n'est pas nécessairement requis. Certaines modifications peuvent être communiquées par courrier électronique, par exemple. Il est admis que le formulaire ne reste pas en concordance avec l'évolution de la situation. L'information à jour est reprise ailleurs, selon les différents éléments qu'elle comporte.

Dans le cas où plusieurs adresses IP sont attribuées à une prise, on considère qu'il s'agit de plusieurs raccordements. Le même critère s'applique dans le cas d'une adresse IP allouée à plusieurs prises.

Alternative 10-100 Mbps

L'équipement du réseau UCL permet d'offrir des raccordements de fréquence 10 ou 100 Mbps (mégabits par seconde). La question se pose de savoir quelle fréquence demander.

D'abord, il y a lieu de ne demander qu'une fréquence possible sur l'interface disponible actuellement. Ensuite il n'est sans doute pas fort utile de demander la fréquence élevée pour des machines dont l'architecture ne permet pas d'en tirer parti. Il faut garder à l'esprit aussi que le débit effectif lors d'une connexion est influencé par chacune des extrémités client-serveur. À moins de justification objective pour la fréquence 100 Mbps, la fréquence de 10 Mbps serait à conseiller pour les postes de travail personnels.

Le réseau UCL étant entièrement commuté, et non plus répété comme en maints endroits de l'interréseau UCL, la bande passante est entièrement disponible pour un raccordement donné, et non plus partagée avec les autres postes raccordés au même moyeu. Les performances s'en retrouvent significativement améliorées.

Le demandeur sera attentif aussi au coût qui diffère selon la fréquence prévue par le raccordement. Ce coût est répercuté en partie dans l'abonnement réseau, dont le tarif est fixé actuellement à 0,75 €/mois pour les raccordements à 10 Mbps et 3 €/mois pour les raccordements à 100 Mbps.

Mode d'attribution d'adresse IP

Plusieurs manières d'attribuer et de contrôler les adresses IP peuvent être envisagées : Tout n'est pas encore possible aujourd'hui.

L'association prise et adresse IP n'est pas contrôlable directement. Elle se fait par configuration statique des machines, en configurant une machine donnée pour utiliser toujours la même adresse IP. Un dispositif d'attribution dynamique d'adresse, tel que DHCP (Dynamic Host Configuration Protocol) par exemple, peut permettre d'associer une adresse IP déterminée à une adresse Ethernet donnée.

Le SRI envisage la possibilité de fournir le service DHCP sur l'ensemble du réseau UCL, lorsque le niveau du logiciel disponible sera tel qu'il puisse garantir un service fiable. D'ici là, il revient aux EIF intéressées de le mettre en oeuvre selon leur besoin. Lorsque plusieurs réseaux dans un (groupe de) bâtiment(s) doivent bénéficier du service, le SRI peut assurer la transmission des requêtes d'un réseau à l'autre, et un serveur suffit alors.

Il semble que pour les endroits semi-publics (bibliothèque, salles didactiques), l'association prise et adresse Ethernet permettrait de prévenir le remplacement d'une machine par une autre, à l'insu des gestionnaires.

Se posent aussi les questions : à quoi associer l'adresse IP ? et à quoi associer le nom de domaine (DNS) ?

L'association d'une adresse IP avec une personne ne semble pas opportune. L'association à un poste raccordé (en fait une adresse Ethernet) offre des avantages, mais demande à gérer des modifications en cas de déplacement. L'association à une prise semble le plus facile à gérer. Cela aboutit à une situation plutôt stable et le poste à y raccorder peut être configuré sans demander de coordination externe.

Pour les noms de domaine, le SRI constate dans la pratique qu'ils sont tantôt liés à la personne - le patronyme restant réservé aux noms de domaine dans le cadre des connexions PPP (Point to Point Protocol) - tantôt liés au type de machine, tantôt au local et tantôt encore absolument quelconque.

Types de réseau

Outre les réseaux à caractère général, i.e. ceux sur lesquels se raccordent les ordinateurs personnels, d'autres types de réseau peuvent être réservés à des fonctions plus particulières ou spécialisées. Dans cette catégorie, on peut distinguer différents groupes de postes de travail ou d'autres ordinateurs, comme par exemple : Pour les salles machines, la situation IP y est normalement très stable. L'EIF doit pouvoir y disposer de toute la souplesse nécessaire à sa gestion et pouvoir y intervenir très rapidement en cas d'urgence. Dans ce cadre, le problème d'une machine s'appropriant l'adresse IP attribuée à une autre, un serveur facultaire par exemple, pourra aussi être évité en partie.

Dans les bibliothèques, il y a des grappes de machines, plus ou moins dédicacées à certaines tâches (consultation par exemple). Certaines de ces grappes ne sont clientes que d'un seul et même serveur. Par ailleurs, les responsables des bases de données documentaires désirent contrôler l'accès à leur information.

Pour ces raisons et d'autres encore, économie d'adresses [130.104.0.0], isolement vis-à-vis de l'Internet, confinement d'accès (cf. ci-dessus), on pourrait réfléchir à mettre certaines machines sur des réseaux privés. Cela peut convenir à des périphériques tels que numériseur et imprimante, et aussi pour certaines machines d'acquisition. Définis dans le RFC 1918 (RFC : Request For Comment), ces réseaux comprennent les trois plages d'adresses 10.0.0.0 - 10.255.255.255 (1 de classe A), 172.16.0.0 - 172.31.255.255 (16 de classe B) et 192.168.0.0 - 192.168.255.255 (256 de classe C). Le SRI peut garantir le routage de ces réseaux, au sein du réseau UCL ou au seul routeur de quartier, le cas échéant.

Il est fait remarquer que les ordinateurs d'une même grappe ou réseau ne doivent pas nécessairement se trouver dans le même local, ni même dans la même aile du bâtiment. Il reste cependant raisonnable de considérer qu'ils doivent se trouver dans le même bâtiment.

Réseaux de salle didactique

Pour les réseaux réservés au didactique, certaines EIF souhaitent en contrôler l'accès à l'Internet et n'en permettre qu'une ouverture plus ou moins grande, selon les heures, les services à atteindre et leur localisation. À certains endroits de l'interréseau UCL, cela se fait via un coupe-feu, en y contrôlant les adresses IP routées et les ports TCP (Transfer Control Protocol) ouverts ou non. Selon les activités prévues, l'ouverture est plus ou moins large et varie dans le temps.

Le SRI est réticent à jouer sur le routage, notamment dans la mesure où cela va à l'encontre du service dont il a la responsabilité, à savoir la fourniture du service IP jusqu'à la prise dans le local de l'utilisateur.

Une solution peut parfois être trouvée dans l'utilisation de serveurs mandatés et sur lequel l'EIF peut avoir l'entier contrôle. Plus strict encore de ce point de vue, est l'usage de réseau privé qui oblige le passage par le serveur mandaté.

Ce type de dispositif ne semble pas de nature à donner satisfaction partout. En effet il n'y a sans doute pas de serveur mandaté pour chacun des services à envisager. L'accès à l'Internet étant nécessaire à certains moments, un réseau privé ne convient pas. Sauf à intervenir sur chaque poste de travail, le passage par le serveur mandaté ne peut être rendu incontournable.

Le SRI est disposé à envisager et à convenir au cas par cas qu'une EIF installe un coupe-feu entre un réseau de salle didactique et le reste du réseau UCL. Elle en assumera alors toute la gestion, sous sa responsabilité et son contrôle. Le SRI n'y fournira plus le service IP, mais seulement Ethernet jusqu'à la prise dans la salle didactique concernée.

Endroits publics

Pour les endroits publics comme les auditoires et salles de séminaire, certaines EIF demandent que les prises puissent être (dés)activées à la demande. Dans l'interréseau UCL, les prises sont bien souvent en service en permanence, sans que cela ne semble poser trop de problèmes. Avec le nouveau réseau, une telle situation est encore moins risquée, vu la présence de commutateurs en lieu et place de moyeux. Cependant, le SRI va mettre au point un dispositif permettant de désactiver et de réactiver certaines prises pour lesquelles cela aura été expressément convenu. Dans ce cas, le service IP jusqu'à la prise ne pourra être garanti par le SRI.

Protocoles non IP

Les protocoles non IP tels que AppleTalk, IPX, NetBEUI, sont utilisés ça et là. Certains sont utilisés sans grand contrôle, pour ne pas dire à l'insu des utilisateurs eux-mêmes. Vu les problèmes que cela suscite, certaines EIF ne demandent pas la généralisation du transport de ce protocole dans ces conditions.

Le protocole AppleTalk sur DDP (Data Delivery Protocol) est pratiqué par les utilisateurs de Macintosh. La tendance est cependant de les voir utiliser IP. En effet, pratiquement tous les services AppleTalk sont désormais disponibles sur IP, à condition de disposer du logiciel de version adéquate. Pendant la période de transition, le service actuel doit être maintenu. La localisation judicieuse de Gatorbox ou autres permet d'assurer la fonction de tunnel entre les différents réseaux. Malgré que ce type d'équipement est d'âge certain, il devrait pouvoir encore remplir sa fonction durant le temps nécessaire à la reconversion. Mais les utilisateurs peuvent être informés que le passage aux services AppleTalk sur IP est inévitable, à terme.

Il est opportun d'envisager de libérer les réseaux de classe 3 LocalTalk. En effet, pour les imprimantes une simple fonction de pont AppleTalk est suffisante. D'autre part, elles peuvent efficacement être raccordées via une interface Ethernet-LocalTalk. Par ailleurs, pour les quelques Macintosh qui resteraient sur LocalTalk, le Gatorbox peut être configuré comme pont (bridge), et non plus comme routeur. Tout cela permet de récupérer des plages d'adresses IP, fort précieuses en général, mais plus particulièrement encore dans la phase de coexistence temporaire des deux infrastructures de réseau.

Le protocole IPX est peu utilisé, et l'est de moins en moins. Cependant, on peut s'attendre à ce qu'un groupe peu étendu, mais plus ou moins dispersé, continue à l'utiliser pendant un temps certain.

Pour les protocoles non IP, les VLAN (Virtual LAN, Local Area Network) sont prévus pour en assurer le transport. Les VLAN ne sont pas la panacée, mais permettent d'avoir des ensembles plus larges que ceux que délimitent naturellement les routeurs. Le besoin en est réduit d'autant que certains réseaux anciens, de 128 adresses maximum, se retrouvent intégrés maintenant dans un ensemble plus grand.

Migration et libération de l'équipement ancien

La migration des réseaux de l'interréseau UCL vers le réseau UCL peut se faire au meilleur gré des utilisateurs et de leur équipe informatique. Les deux infrastructures seront disponibles et, après la mise en service d'une prise du réseau UCL, l'opération essentielle consiste à déplacer le raccordement du poste de travail et à changer des paramètres de son logiciel de réseau.

Au fur et à mesure que l'équipement des réseaux anciens est mis hors service, le SRI est demandeur de pouvoir en disposer, afin de pouvoir le placer ailleurs dans les facultés, en attendant que le nouveau câblage y soit placé. Cet équipement pourra servir aussi pour des installations temporaires lors de manifestations (congrès, etc.).

Une manière de suivre la migration - et d'y aider, le cas échéant - peut être d'ôter des moyeux, les fiches correspondant à des liaisons non utilisées (lampe témoin éteinte). Lorsque toutes les fiches d'un moyeu sont finalement retirées, celui-ci peut être éteint et désaffecté. On peut aussi regrouper les liaisons actives et libérer peut-être encore plus de moyeux.

Gestion des problèmes

L'équipement actif et le logiciel de télégestion prévu permettent de disposer de beaucoup plus d'information sur l'état des éléments du réseau, que précédemment. Le SRI ayant la maîtrise de l'ensemble, le contrôle et la responsabilité du bon fonctionnement, il peut fournir aussi toute l'information souhaitée.

Cette information est mise à disposition des EIF, de manière plutôt large qu'étroite. Normalement l'information concernant le trafic général, i.e. non lié à l'activité propre d'une personne, est disponible sans grande restriction. Les renseignements de nature plus particulière ne devraient être accessibles qu'aux seules personnes habilitées, par exemple le responsable informatique et les personnes sous sa responsabilité.

De l'information est disponible sur les serveurs microNOC et MRTG. Ce dernier serveur n'est accessible qu'à partir de poste enregistré dans le DNS. Présentée de façon quelque peu fruste encore, l'information est fournie telle quelle, en supposant que le consultant dispose des connaissances lui permettant d'en tirer le parti qu'il souhaite. Aucun autre support n'est disponible actuellement dans ce domaine-là.

Le SRI examine la possibilité de permettre la désactivation d'une prise. Cela pourra servir en cas de nécessité impérieuse, par exemple dans le cas d'une machine perturbant très gravement un équipement local et se trouvant dans un local inaccessible. Via une page Web, il devrait être précisé la référence du port de commutateur concerné et, après fourniture d'un mot de passe, la commande à effectuer (désactivation, dans le cas envisagé). La réactivation ne pourra se faire que par le SRI, après vérification avec toutes les parties concernées (utilisateur, équipe informatique locale, SRI, etc.), que la situation est bien rentrée dans l'ordre et que le risque de perturbation a disparu.

Concernant la connaissance de l'adresse IP normalement associée à une prise donnée, l'EIF dispose de tous les formulaires de raccordement, mais leur information n'est pas nécessairement disponible à l'endroit et au moment du problème. Une base de données consultable est à envisager. Son accès devrait être réservé à des personnes habilitées. Un formulaire HTML (HyperText Markup Language) ferait bien l'affaire.

À la question plus particulière d'un utilisateur qui désire savoir ce qui se passe entre son équipement et une autre machine de l'Internet, on répond que la fonction traceroute est l'outil incontournable pour connaître l'état du réseau à un moment donné pour un trajet donné. Il faut rester attentif dans les délais de réponse constatés, qu'un équipement de routage peut donner priorité à sa fonction première, et répondre d'autant plus tard aux requêtes d'écho engendrées par traceroute.

Activités exceptionnelles (congrès, etc.)

En cas de congrès, colloques, etc., il pourrait être demandé une garantie supplémentaire de continuité du service réseau. Prévenu suffisamment à l'avance, le SRI mettra tout en oeuvre pour satisfaire à ce genre de demande, à examiner au cas par cas.

[UCL] [AC] [ADST] [SRI] [Pointeurs utiles]

Dernière mise à jour : 24 novembre 2001 - Responsable : Jean-Pierre Kuypers