Modèle OSI
Je n'ai pas mis cette page à jour depuis un moment. Aussi, les notions concernant les réseaux qui y sont présentées sont-elles naturellement toujours exactes, mais par contre, les détails spécifiques au réseau VIA, comme les adresses IPs des serveurs et les détails des subnets ne sont plus d'actualité.
"De tous temps, l'homme a voulu communiquer", disait le fameux Meuuh. Un réseau informatique est justement destiné à assurer cette fonction. La donnée élémentaire pour un ordinateur étant l'octet, le rôle du réseau est de permettre à un ordinateur de transmettre une suite d'octets (un paquet) d'un ordinateur à un autre, à l'aide d'une simple adresse, et ce, de manière transparente pour le programmeur et indépendante de l'architecture. La majorité des réseaux, Internet le premier, utilisent aujourd'hui le protocole IP (pour Internet protocol).
Pour ce faire, plusieurs couches logicielles et matérielles sont utilisées. On représente généralement cette décomposition en couches à l'aide de l'infâme modèle OSI, un schéma d'une telle généralité qu'on peut l'appliquer sans aucune difficulté à la parapsychologie des nénuphars castrés irlandais apparentés aux insectes taïwanais. C'est cependant le modèle utilisé par le monde entier dans les documents techniques (RFCs, documentations de matériels réseau, normes, ...), il convient donc de le connaître :
Modèle OSI
La couche supérieure (application), est celle des logiciels tels que nous les percevons : telnet, ftp, rlogin, etc...
La couche de présentation prend en charge la conversion des données entre le format en vigueur sur le réseau et le format spécifique à l'architecture utilisée (par exemple, elle gère les problèmes de little/big endian).
La couche session est peu importante dans les réseaux IP.
La couche transport offre différents moyens de faire transiter des paquets d'une machine à l'autre sur le réseau. Les protocoles les plus utilisés sont TCP, qui permet d'acheminer des paquets en ayant la garantie qu'ils parviennent à destination, et dans l'ordre où ils ont été envoyés, et UDP, qui offre un moyen d'envoyer des paquets sans garantie qu'ils arrivent à destination, ni qu'ils arrivent dans leur ordre d'émission.
La couche de réseau est utilisée par la couche transport, elle lui permet de faire parvenir des paquets (dans les mêmes conditions qu'UDP), d'une machine à l'autre.
La couche de liens permet à la couche supérieure d'acheminer un paquet d'un point à l'autre du réseau, de manière souvent non fiable.
Enfin, la couche physique permet à la couche réseau de faire transiter un certain nombre d'octets le long d'un câble réseau.
Il est bon de préciser l'utilité d'avoir introduit les couches de niveau 2 et 3. Il semble en effet à première vue que l'on aurait pu se contenter d'une unique couche pour remplir ce rôle. Pour expliquer l'intérêt de cette décomposition, il faut considérer un réseau comprenant de nombreuses machines. Disons Internet, par exemple. En caricaturant un peu, pour faire parvenir un paquet d'une machine à une autre, un équipement réseau de niveau 2 (ie : un switch) doit interroger tous les autres équipements réseau du même niveau en leur demandant s'ils sont reliés à la machine dont l'adresse est l'adresse de destination du paquet. Sur un réseau important, ceci engendrerait un trafic énorme et un gaspillage de bande passante. Si tous les équipements réseau du monde devaient dialoguer à chaque fois qu'une machine sur Internet essaie d'en joindre une autre, l'utilisation du réseau serait impossible. C'est pourquoi on introduit la couche de niveau 3.
L'idée derrière la couche de niveau 3 est de découper un grand réseau en plusieurs petits sous-réseaux (ou subnets). Une machine placée dans un sous-réseau dialogue directement avec les autres machines du même sous-réseau par l'intermédiaire des équipements de niveau 2, alors qu'elle dialogue avec les machines des autres sous-réseaux par l'intermédiaire des équipements de niveau 3 (ie : des routeurs), qui peuvent déterminer à quel autre équipement de niveau 3 ils doivent faire parvenir un paquet, en observant l'adresse de destination de celui-ci. Ainsi, il n'est pas nécessaire de faire dialoguer tous les équipements réseau du monde à chaque fois qu'une machine veut faire parvenir un paquet à une autre.
Pour bien comprendre le fonctionnement d'un réseau, il est important de bien garder présente à l'esprit cette décomposition en plusieurs couches.
Par exemple, la décomposition en subnets du réseau VIA est faite en trois subnets, comme l'indique la figure suivante :
Réseau VIA au niveau 3
Sur cet exemple, les deux machines asterix et obelix peuvent communiquer en passant par les équipement de niveau 2, tandis que si obelix veut communiquer avec zen, il doit envoyer son paquet au routeur par l'intermédiaire des équipements de niveau 2, et celui-ci transmettra par ces mêmes équipements le paquet à zen.
Internet est constitué d'une multitude de sous-réseaux, eux-mêmes décomposés en sous-réseaux, etc...
Un sous-réseau n'est autre qu'un ensemble d'adresses IP consécutives. L'adresse du réseau est la première de ces adresses IP. La dernière adresse du réseau est une adresse spéciale, l'adresse de broadcast. C'est celle qui est utilisée pour envoyer un paquet à tous les autres ordinateurs du réseau. Un sous-réseau est caractérisé par une adresse de sous-réseau et un masque appelé subnet mask, dont tous les bits de poids fort sont à 1 et les bits de poids faible à 0. Les bits valant 1 identifient les bits qui ne changent pas, quelle que soit l'adresse appartenant à ce sous-réseau, tandis que les bits à 0 identifient la partie propre à chaque machine. La combinaison de ces deux facteurs permet de savoir si une adresse IP donnée appartient à un sous-réseau ou non. Elle permet également de déterminer l'adresse de broadcast.
Exemple du subnet des connectés :
adresse de réseau : 138.195.136.0 soit 10001010.11000011.10001000.00000000
subnet mask : 255.255.248.0 soit 11111111.11111111.11111000.00000000
<---------------------><---------->
fixe variable
broadcast : 138.195.143.255 soit 10001010.11000011.10001111.11111111
obelix : 138.195.140.47 soit 10001010.11000011.10001100.00101111
asterix : 138.195.138.254 soit 10001010.11000011.10001010.11111110
Ainsi, les organisations comme l'ECP achètent un sous-réseau (ie : un ensemble d'adresses IP consécutives) pour se connecter à Internet. Les sous-réseaux sont répartis en différentes classes :
| classe | adresse de sous-réseau | nombre de domaines | nombre de machines par domaine |
|---|---|---|---|
| A | de 0.0.0.0 à 9.0.0.0 | 10 | seize millions |
| A | 10.0.0.0 | réservé aux réseaux privés | |
| A | de 11.0.0.0 à 126.0.0.0 | 116 | seize millions |
| A | 127.0.0.0 | loopback | |
| B | de 128.0.0.0 à 191.0.0.0 | seize mille | soixante six mille |
| A | 192.0.0.0 | réservé aux réseaux privés | |
| C | de 193.0.0.0 à 223.0.0.0 | deux millions | 256 |
| D | de 224.0.0.0 à 239.0.0.0 | groupe de multicast | |
| E | de 240.0.0.0 à 255.0.0.0 | réservé pour usage futur | |
On constate actuellement un problème de saturation des IPs : il n'y a pas assez d'adresses. Toutes les classes A et B ont été vendues. Les grandes organisations sont maintenant contraintes de prendre plusieurs classe C, malheureusement rarement consécutives, ce qui complique l'administration de leurs réseaux. Centrale a eu la chance d'être parmi les premiers à demander des IPs, et a bénéficié d'une classe B, qui s'étend de 138.195.0.0 à 138.195.255.255. Sur cette plage d'IPs, l'école a attribué à VIA le subnet 138.195.128.0 avec un netmask de 255.255.232.0, ce qui laisse 12 bits variables. Le réseau VIA a à son tour été découpé en subnets : le 138.195.128.0 pour les switchs, le 138.195.130.0 pour les serveurs et les assoces, le 138.195.132.0 qui était utilisé autrefois par le token ring et ne l'est plus aujourd'hui, et le 138.195.136.0 pour les connectés.
Voici l'allure des paquets IP tels qu'ils sont utilisés aujourd'hui, y compris leurs 20 octets d'en-tête :
| taille | nom | fonction |
|---|---|---|
| 4 bits | version | numéro de version, actuellement 4 |
| 4 bits | header length | taille de l'en-tête du paquet en bits divisée par 32 |
| 1 octet | type of service | ce champ indique s'il faut minimiser, pour ce paquet IP, le delai de transmission, les risques de pertes de données, le coût de la transmission, ou s'il faut maximiser le débit (il est cependant ignoré par la majorité des implémentations du protocole IP à l'heure actuelle) |
| 2 octets | total length | taille totale du paquet en octets, ce qui limite la taille d'un paquet IP à 65535 octets, mais la norme précise qu'une machine n'est pas contrainte d'accepter les paquets de plus de 576 octets |
| 2 octets | identification | ce champ est incrémenté de 1 part l'émetteur à chaque paquet envoyé |
| 3 bits | flags | indicateurs |
| 5 bits | fragment offset | offset de fragment |
| 1 octet | time to live (TTL) | nombre de routeurs que le paquet est autorisé à traverser avant son élimination et l'envoi à l'émetteur d'un message de contrôle, il est décrémenté de 1 à chaque franchissement de routeur |
| 1 octet | protocol | permet de démultiplexer les paquets IP, en indiquant quel protocole est à leur origine |
| 2 octets | header checksum | permet de vérifier que l'en-tête IP n'est pas corrompu |
| 4 octets | source IP | adresse IP de l'émetteur |
| 4 octets | destination IP | adresse IP du destinataire du paquet |
| variable | data | données à transmettre |
A noter que tous les entiers de plus d'un octet sont transmis avec les bits de poids fort en premier (big endian).
J'ai montré comment la couche de niveau 3 transmet les paquets d'une machine à l'autre, éventuellement en changeant de subnet, cependant, elle est incapable de faire physiquement l'opération par elle-même, elle suppose en effet qu'elle a la possibilité de faire parvenir des paquets d'une machine à une autre au sein d'un même subnet. Cette fonction est remplie par la couche de niveau 2. Je vais présenter l'une des couches de niveau 2 les plus utilisées : l'ethernet, qui est un protocole couvrant les niveaux 1 et 2, mais je ne m'attacherai qu'à l'aspect niveau 2.
Dans un réseau ethernet, chaque carte réseau est repérée par une adresse unique, son adresse MAC (Media Access Control). C'est un identificateur de six octets. Chaque fabricant de cartes dispose d'un certain nombre d'adresses MAC qu'il peut attribuer à ses cartes. On identifie ainsi une carte de manière unique au monde. Il existe une adresse spéciale, l'adresse de broadcast FF:FF:FF:FF:FF:FF. Quant elle est utilisée, toutes les machines du réseau reçoivent le paquet. Le succès de la transmission des paquets n'est pas assuré. Le paquet ethernet se présente de la manière suivante :
| champ | taille du champ en octets |
|---|---|
| MAC destination | 6 |
| MAC source | 6 |
| type (800 pour un paquet IP, 806 pour une requête ou réponse ARP, 8035 pour une requête/réponse RARP) | 2 |
| données | de 46 à 1500 |
| CRC (permet de contrôler les erreurs dans la trame) | 4 |
Les paquets IP sont encapsulés dans des paquets ethernet (ou autre protocole layer 2). Normalement, on met simplement la totalité du paquet IP dans la zone data du paquet ethernet. Mais qu'advient-il si le paquet IP est plus long que la taille maximale de la zone data (appelée MTU) ? L'émetteur est alors contraint de répartir son paquet IP sur plusieurs paquets niveau 2, c'est-à dire de les fragmenter. La fragmentation peut intervenir au niveau de l'émetteur du paquet IP ou de n'importe quel routeur sur le chemin du paquet. Un fragment peut à son tour être fragmenté ultérieurement en un autre point du réseau. Le réassemblage du paquet IP n'a lieu qu'au niveau du destinataire du paquet. Pour savoir si un paquet de niveau 2 appartient à un paquet IP donné, il suffit de regarder le champ identification, qui est propre à chaque paquet IP d'un émetteur donné et inclus dans chaque fragment. D'autre part, le champ total length d'un fragment donné indique la taille du fragment et non celle du paquet IP contenant le fragment. Enfin, parmi les flags figure un indicateur appelé more fragments qui vaut 0 si ce fragment est le dernier du paquet IP et 1 dans le cas contraire.
Le destinataire du paquet peut le reconstruire en rassemblant les fragments dans l'ordre indiqué par le champ fragment offset de l'en-tête IP.
L'inconvénient du système de fragmentation est que si l'un des fragments ne parvient pas à destination, tout le paquet IP doit être retransmis. C'est pourquoi on évite généralement d'utiliser la fragmentation en positionnant à 1 le flag don't fragment dans l'en-tête IP. Ainsi, si un routeur reçoit le paquet IP et si la taille du paquet est supérieure à son MTU, il supprime le paquet et envoie à l'émetteur un message ICMP pour l'en informer.
Il existe un autre protocole très proche d'ethernet appelé IEE 802.3. Les paquets ressemblent beaucoup aux trames ethernet, avec quelques indicateurs supplémentaires. La RFC Host Requirements (1122) précise que toute machine connectée à Internet au moyen d'un câble ethernet :
J'ai montré comment envoyer un paquet d'une machine à une autre en utilisant le protocole ethernet, ainsi que l'utilisation d'IP en s'appuyant sur ethernet. Il manque cependant une pièce au puzzle : en effet, l'émetteur d'un paquet IP ne connaît en général pas l'adresse MAC du récepteur ou du routeur avec lequel il va devoir communiquer au niveau 2. C'est pourquoi deux protocoles ont été mis au point : ARP (address resolution protocol), qui permet d'obtenir l'adresse MAC associée à une adresse IP, et RARP (reverse address resolution protocol), qui permet d'obtenir l'adresse IP associée à une adresse MAC.
Ainsi, si une machine d'IP A doit dialoguer avec une machine d'IP B, A doit obtenir l'adresse MAC de B ou celle du routeur, selon les cas. Elle envoie pour celà un paquet ethernet dont l'adresse MAC de destination est l'adresse de broadcast ethernet FF:FF:FF:FF:FF:FF. Ce paquet contient, entre autres, son adresse IP, son adresse MAC, l'adresse IP de la machine dont elle cherche l'adresse MAC et porte le nom de requête ARP. La machine concernée répond à l'émetteur, au moyen d'un paquet unicast contenant les mêmes informations plus son adresse MAC portant le nom de réponse ARP. ARP est décrit en détail par la RFC 826.
Le fonctionnement de RARP est exactement le même que celui d'ARP, à la différence près que la requête RARP contient l'adresse MAC connue et pas l'adresse IP correspondante. Les paquets utilisés sont d'ailleurs quasiment les mêmes. La requête RARP a elle aussi lieu en broadcast, et la réponse RARP en unicast. RARP est décrit en détail par la RFC 903.
L'exposé n'a pour l'instant porté que sur l'envoi de paquets d'une machine à une autre au moyen d'une adresse IP. Cependant, quand l'utilisateur lambda utilise une application réseau, comme un browser web, ou un client telnet, il spécifie un nom de machine plutôt que son adresse IP. Pour obtenir l'adresse IP correspondant au nom de la machine cible (ce nom est appelé DNS), la machine source fait une requête DNS (Domain Name System) à un serveur DNS dont il connaît l'adresse IP (celle-ci est configurable ou obtenue par DHCP) en lui indiquant la DNS de la machine cible. Le serveur lui répond en lui indiquant son adresse IP, et vogue la galère.
Là encore, existe un protocole permettant de faire l'opération inverse, à savoir obtenir une DNS à partir de son IP. Ce protocole est appelé reverse DNS, et fonctionne comme la DNS directe : le client fait une requête DNS inverse auprès du serveur DNS en lui indiquant une IP, et le serveur lui répond en lui indiquant la DNS associée.
Le service DNS est décrit en détail par les RFCs 1034 et 1035.
Il est à ce point possible de faire fonctionner un réseau, tous les éléments nécessaires étant réunis. Cependant, il serait difficile pour les administrateurs de réseaux importants et les ISP de gérer un réseau comportant de très nombreuses machines dont les adresses IP et les DNS seraient statiques, c'est-à-dire entrées une fois pour toutes dans la configuration des machines clientes ou des serveurs. C'est pourquoi a été mis au point un protocole qui donne dynamiquement une IP, une DNS, un subnet mask, une adresse de broadcast, une adresse de serveur DNS et une adresse de routeur à une machine lors de sa connexion. Ceci permet de gérer les grands réseaux de manière beaucoup plus souple. Ce protocole est appelé DHCP pour dynamic host configuration protocol et est décrit par la RFC 1541.
Lors de son initialisation, une machine utilisant DHCP (ce qui est le cas de la majorité des machines reliées au réseau VIA), envoie un paquet broadcast sur le port UDP 67 où figure son adresse MAC en demandant à un serveur DHCP de lui donner une IP, et en fournissant éventuellement une liste de paramètres de configuration à lui indiquer. Chaque serveur DHCP lui renvoie un paquet sur le port UDP 68 en lui indiquant une adresse IP disponible. Ce paquet est en principe un paquet unicast, à moins que l'implémentation IP de la station cliente ne permette pas de recevoir des paquets unicast sur une interface dont l'IP n'est pas encore connue, auquel cas elle est censée l'indiquer dans les paquets qu'elle envoie au serveur. La machine choisit parmi toutes les réponses qu'elle a reçues quelle configuration lui convient le mieux, et envoie un paquet broadcast (port UDP 67) indiquant aux serveurs quelle configuration a été retenue. Ensuite, le serveur à l'origine de la configuration retenue envoie à la machine cliente (port UDP 68) un paquet lui indiquant que l'IP lui est maintenant réservée, ou qu'elle est devenue indisponible pour une raison ou une autre, ce qui contraint la machine cliente à recommencer tout le processus. La RFC précise également que si une station se souvient de la configuration IP qu'elle avait reçu lors d'une précédente connexion, elle peut directement passer à l'étape 3, demandant aux serveurs si cette configuration est encore disponible. Enfin, il est possible de n'attribuer une configuration IP que pour un temps donné, le client a la possibilité de suggérer au serveur la durée de ce bail, mais c'est le serveur qui fait le choix définitif. La durée minimale du bail est d'une heure.
Il n'y a à VIA qu'un seul serveur DHCP ; Celui-ci se trouve dans le subnet 138.195.130.0, les requêtes DHCP ne devraient donc pas lui parvenir. Cependant, le routeur de VIA a été configuré pour lui faire parvenir les broadcasts UDP sur le port 67. Ainsi, le DHCP fonctionne quand même.
Un problème intéressant est celui posé par le projet VideoLAN, en effet, le projet sera utilisé pour faire parvenir plus de dix chaînes dans les chambres de la résidence, alors que celles-ci ne sont reliées au réseau que par des prises à 10 Mbps, c'est à dire à peine de quoi faire passer deux flux video. La solution adaptée au problème serait l'utilisation du multicast, c'est-à-dire d'envoyer chaque flux à une liste d'utilisateurs. Malheureusement, le matériel dont nous diposons actuellement ne supporte pas le multicast. Il a donc fallu trouver une autre solution.
Il existe un moyen de diviser un réseau ethernet en plusieurs réseaux virtuels indépendants appelés VLANs. Deux machines situées dans deux VLANs différents ne peuvent pas communiquer. Pour placer une machine dans un VLAN, il suffit de configurer le switch ethernet sur lequel cette machine est branchée en lui indiquant que le port relié à la machine est dans le VLAN souhaité. Dès lors, impossible pour elle d'échanger des paquets avec des machines situées dans d'autres VLANs. Ainsi, si dans chaque VLAN est envoyé en broadcast un flux video, il suffit de disposer chez l'utilisateur d'un débit de 5 Mbps pour pouvoir recevoir les différentes chaînes, à condition de changer de VLAN pour changer de chaîne. Pour ce faire, l'utilisateur adresse une requête à une machine appelée VLANserver, qui place la machine dans un autre VLAN. Elle reçoit alors une autre chaîne.
L'inconvénient de la méthode est que deux utilisateurs qui regardent deux chaînes différentes ne peuvent plus communiquer, comme le lecteur attentif l'aura remarqué. A moins d'utiliser une astuce supplémentaire : le VLANbridge. Cette machine est reliée, à l'aide d'une carte ATM (cf partie 2 de cette formation), à tous les VLANs du réseau. Elle peut ainsi émettre des paquets dans le VLAN de son choix. Ainsi, quand le VLANserver passe une machine dans le VLAN x, il prévient le VLANbridge. A ce moment là, lorsque le VLANbridge reçoit une requête ARP destinée à cette machine depuis un autre VLAN que le VLAN x (rappelez-vous, les requêtes ARP sont des broadcasts), il répond à sa place. Il va donc recevoir les paquets IPs qui lui sont destinés. Il prend ensuite soin de les lui transmettre dans le VLAN x.
Sur le réseau VIA, toutes les machines du subnet 138.195.136.0 sont dans le VLAN 2, celles du subnet 138.195.130.0 sont dans le VLAN 10, et celles du subnet 138.195.128.0 sont dans le VLAN 1, seul VLAN dans lequel on peut administrer les switchs. Ainsi, les lignes AOB (dont je parlerai au prochain paragraphe) ne voient passer que des paquets isus du VLAN 1, et les lignes ATM (dont je parlerai également au prochain paragraphe) voient passer tous les paquets des VLANs autres que 1. D'autre part, quand le projet VideoLAN diffusera des flux video, les machines du subnet 138.195.136.0 pourront se trouver dans n'importe quel VLAN autre que 1 ou 10. On dispose en tout de 16 VLANs sur le matériel actuel de VIA.
Mais, puisque un port donné est dans un VLAN donné, il est légitime de se demander comment tous les VLANs peuvent parvenir à tous les switchs d'un bâtiment autres que celui qui est relié directement au backbone par un lien ATM. Ces switchs sont reliés au premier switch du bâtiment à l'aide d'un port configuré pour utiliser le protocole VLANtrunk, qui permet à un port d'être dans tous les VLANs simultanément. Lorsqu'un port est configuré de cette manière, il indique sur chaque paquet à quel VLAN ce paquet appartient. De cette manière, le switch qui reçoit le paquet l'inscrit dans le bon VLAN. Cependant, il est impossible pour les cartes réseau courantes de comprendre cette indication de VLAN. Un utilisateur muni d'une carte réseau "classique" ne peut donc se trouver que dans un seul VLAN à la fois. Notons enfin qu'il existe deux protocoles permettant à un port d'être dans plusieurs VLANs : le protocole VLANtrunk, que nous utilisons à VIA et qui est un protocole propriétaire de la firme 3com, et le protocle 802.1Q, qui permet d'utiliser un plus grand nombre de VLANs, mais que notre matériel ne supporte pas.
Le réseau VIA au niveau 2
Les câbles ethernet 10 Mbps qui relient le PI aux bâtiments correspondent à des ports dans le VLAN 1, il est possible grâce à eux de continuer à administrer les switchs, le routeur, et les switchs ATM même quand le réseau ATM plante. Cependant, les données des connectés et des serveurs de VIA transitent par les fibres ATM qui relient les bâtiments au PI.
Je donne ici des captures d'écran d'une session de configuration d'un switch (Superstack 2 1100), lors de laquelle les parties principales du logiciel d'administration du switch apparaissent. Même si le logiciel utilisé semble très différent d'un modèle de switch à l'autre (l'interface est par exemple complètement différente sur nos switchs Superstack 1000), les principes de base sont toujours les mêmes, seule l'interface change réellement.
Bien qu'il existe différentes manières de procéder, la plus utilisée à VIA est incontestablement... telnet ! La preuve :
telnet switch-a2
Après saisie du login et du mot de passe, on a accès au menu affiché ci-dessus. Le menu snmp permet de choisir les chaînes de communauté (en quelques sortes les mots de passe) de ce protocole d'administration réseau distante. Le sous-menu system permet de définir quelques variables propres au système, les mots de passe pour l'accès interactif au système, son nom, etc... Mais l'essentiel de la configuration est contenu dans les autres menus.
Ce menu permet de donner une adresse IP, une adresse de broadcast, et un subnet mask au switch pour l'administrer entre autres par telnet. Il permet également de définir les mêmes paramètres pour le SLIP, un protocole permettant de faire de l'IP à travers le port série d'une machine.
Le menu ip
 |  |
Dans le menu features, on trouve tout ce que les switchs 1100 permettent de faire en dehors de ce que l'on pourrait attendre d'un switch ethernet minimal :
Un peu d'exotisme ne fait pas de mal
ce sous-menu du menu-principal permet de régler tous les paramètres concernant un port au niveau du protocole ethernet même : le port doit-il être actif ou non, utiliser ou non le full duplex, à une vitesse de 10 ou de 100 Mbps (sur les ports qui permettent de l'atteindre, etc.).
 |  |
Ce menu permet de paramétrer tout ce qui a trait à l'utilisatin des VLANs et des adresses MAC.
Le menu bridge
Le sous-menu port
L'affichage de la liste des adresses MAC connues par le port
La liste des ports du VLAN 2
La liste des ports du VLAN 1
Le lecteur attentif aura remarqué que les ports 25 et 26 appartiennent à la fois aux VLANs 1 et 2, ce qui n'est rendu possible que par leur passage en mode VLT (VLAN Trunk).
Protocole permettant d'obtenir l'adresse MAC d'une machine dont l'adresse IP est connue. Décrit par la RFC 826.
Paquet envoyé à toutes les machines d'un même subnet.
Ce protocole permet à une machine d'obtenir automatiquement tous les paramètres dont elle a besoin pour pouvoir utiliser un réseau IP, à partir de son adresse MAC uniquement. Il est décrit par la RFC 1541.
Ce terme a plusieurs significations : c'est le protcole par lequel on peut obtenir l'adresse IP d'une machine dont on connaît le nom. Ce nom est aussi appelé DNS. Enfin, les serveurs implémentant ce protocole sont aussi appelés DNS pour Domain Name Server. Ce protocole est décrit en détail par les RFCs 1034 et 1035.
L'un des protocoles réseau de niveau 2 les plus répandus. Son avantage principal réside dans sa simplicité, son inconvénient réside dans sa fiabilité réduite.
Machine permettant aux paquets IP de passer d'un subnet à un autre.
Adresse de 6 octets identifiant de manière unique au monde un équipement réseau de niveau 2. On adopte généralement pour une adresse ethernet la notation hexadécimale, en séparant chaque octet par un signe ":".
Taille du plus gros paquet IP que l'on peut envoyer d'un ponit à un autre sans fragmentation. Le MTU dépend naturellement du chemin suivi.
Paquet envoyé à une liste de destinataires.
Protocole utilisé pour convoyer les messages d'erreur ou les informations d'ordre général concernant la transmission de paquets IP.
Protocole utilisé pour le contrôle de la transmission des paquets IP multicast.
C'est, comme l'indique son nom, le protocole de niveau 3 utilisé sur Internet, et dans une très grande majorité des intranets.
Réseau local, c'est-à-dire d'envergure géographique arbitrairement "petite". Cependant, ce terme est parfois utilisé pour désigner un réseau comportant un nombre de machines arbitrairement petit.
Protocole permettant d'obtenir l'adresse IP d'une machine à partir de son adresse MAC. Décrit par la RFC 903.
Document donnant les recommandations à suivre lors de l'implémentation d'un protocole. Elles sont disponibles librement, par exemple sur http://www.faqs.org/rfcs.
Routeur en français. cf gateway.
Sous-réseau, séparé des autres sous-réseaux par un routeur.
Masque de sous-réseau. Tous ses bits de poids fort sont à 1 et identifient la partie propre au sous-réseau d'une adresse IP.
L'un des protocoles de niveau 2 qui a été le plus grand concurrent d'ethernet. En train de s'éteindre à petit feu, bien que de nombreuses organisations l'utilisent encore.
Moyen d'isoler des machines qui sont pourtant reliées au niveau 2. Ainsi, alors que deux machines devraient pouvoir communiquer par l'intermédiaire des équipements de niveau 2, il leur est impossible d'échanger des données sans passer par des équipements de niveau 3.
Un port en configuré en VLAN Trunk est un port par lequel un paquet, quel que soit son VLAN d'origne, pourra passer. Cependant, le port écrira dans le paquet à quel VLAN il appartient (suivant un format propriétaire de la firme 3com). A ce port ne peut être relié qu'un autre port VLT, ou alors une carte réseau spéciale, produite par 3com. C'est la manière non-standard de mettre une indication de VLAN dans un paquet. C'est la manière utilisée à VIA.