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.
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 :
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.
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.
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.
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.
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.
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.
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.
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.
[UCL]
[AC]
[ADST]
[SRI]
[Pointeurs utiles]
![]()
Dernière mise à jour : 24 novembre 2001 -
Responsable : Jean-Pierre
Kuypers