Le but de ce projet est de fournir une implantation en Java du mécanisme mis en œuvre au niveau des ponts Ethernet (IEEE 802.1D). L'envoi de trames Ethernet sera émulé au niveau UDP par l'envoi de datagrammes multicast spécifiques. Les ponts "virtuels" devront effectuer les travaux suivants :
mise en œuvre du Spanning Tree Algorithm. Cet algorithme et son protocole (STP) permettent, à partir de l'interconnexion de ponts (ou commutateurs) par des liens redondants dans un réseau local Ethernet, d'obtenir un arbre couvrant minimum du graphe cyclique correspondant à cette interconnexion. La spécificité de cet algorithme est que son calcul est réparti sur chacun des ponts, qui n'a connaissance que de l'existence de ses voisins directs, et non de l'ensemble du graphe.
On rappelle que l'adresse multicast MAC utilisée par les ponts pour s'échanger les Bridge Protocol Data Unit (BPDU) est 01:80:C2:00:00:00. Par ailleurs, les trames Ethernet qui transportent ces BPDU doivent être envoyées avec un champ Type/Longueur qui indique la longueur des données dans la trame (format LLC). Dans ce cas, les Service Access Point (SAP) source et destination, sur un octets chacun, doivent avoir la valeur 0x42 (01000010 en binaire) et doivent être suivis d'un octet de contrôle (C) que l'on utilisera pas dans ce projet (sa valeur ne sera pas prise en compte). Ensuite, la trame contiendra le message de configuration ou de notification de changement de topologie du protocole du spanning tree, plus un éventuel bourrage pour atteindre la taille de trame minimale. Voici donc le format de cette trame schématisée:
6 6 2 1 1 1 4
+------+-----+-----+-----+-----+---+--------------------------+---------+
| Dest | Src | Lgr | SAP | SAP | C | Message STP + padding | CRC |
+------+-----+-----+-----+-----+---+--------------------------+---------+
Afin de pouvoir interagir avec ces ponts virtuels, il faudra aussi implémenter des hôtes (DTE) virtuels, capables d'émettre et de répondre à des requêtes ARP, et d'envoyer des requêtes "ping" de couche OSI 2 inventées pour ce projet, cf ping.
L'implantation qui vous est demandée est donc une simulation au dessus du protocole UDP de ce qui se passe en temps normal au niveau du réseau local Ethernet.
Un pont est un équipement qui effectue le lien entre différents domaines de collision, chaque domaine étant relié à l'un de ses ports. Plusieurs équipements (hôtes ou ponts) sont reliés à un même domaine de collision.
L'émission d'une trame sur un domaine de collision sera donc émulée par l'envoi d'un datagramme UDP à destination d'une adresse IP multicast sur un port UDP donné. Ainsi, un domaine de collision correspond à une adresse multicast IP et un port UDP.
Important Certaines adresses IP multicast ont une signification particulière (vous pouvez consulter http://www.iana.org/assignments/multicast-addresses). Il vous est donc très vivement conseillé de ne pas les utiliser (n'utilisez en particulier aucune adresse de 224.0.0.0/8, mais commencez plutôt à 225.0.0.0). Par ailleurs, vous pourrez vous arranger, entre les différents binômes, pour utiliser chacun une plage d'adresses IP multicast qui vous est propre, afin d'éviter des effets de bords parasites entre groupes.
Pour émettre une trame sur un domaine de collision, le pont ou l'hôte émettra un datagramme UDP contenant l'intégralité de la trame Ethernet, sans le préambule, à destination de l'adresse multicast IP et du port UDP correspondant au domaine de collision.
La modélisation et la simulation qui vous sont demandées doivent être les plus proches possible de la réalité, dans les mécanismes et dans les algorithmes mis en œuvre. De plus, ce projet doit vous permettre d'approfondir votre connaissance de la mise en oeuvre des ponts. Pour ces raisons, votre document de référence sera la norme officielle qui décrit le fonctionnement du Spanning Tree Protocol. Voici quelques documents utiles:
Pour pouvoir tester simplement le réseau virtuel, il convient de définir un protocole "ping" au niveau Ethernet. Les trames de ce protocole sont identifiées comme ayant un champ Type de valeur 0x0E11. Le premier octet de données est identifié comme un code d'opération (OpCode) qui vaut 1 pour une requête et 2 pour une réponse. Le récepteur d'une requête ping doit renvoyer une réponse ping à l'émetteur, dont le message est le même que la requête. Ce message doit faire entre 45 et 1499 octets.
6 octets 6 octets 2 octets 1 octet 4 octets +-----------+----------+--------+--------+-----------------+---------+ | Dest Mac@ | Src Mac@ | Type | OpCode | Message | CRC | +-----------+----------+--------+--------+-----------------+---------+
Pour connaître les configurations des ponts et des hôtes, les programmes devront lire un fichier de configuration contenant les informations de chaque équipement, les unes à la suite des autres.
Dans ce fichier, les lignes vides et les lignes qui commencent par # sont ignorées.
Outre son adresse MAC, un pont virtuel doit tout d'abord savoir à quels domaines de collision il est connecté, et sur quels ports. De plus, il faut lui spécifier une priorité, qui servira dans l'implémentation du spanning tree algorithm.
En plus, la configuration d'un pont doit pouvoir être consultée et modifiée pendant l'exécution du programme, par connexion TCP avec le programme. L'interface de configuration est définie dans la partie Administration.
Au lancement du programme d'émulation des ponts (switch, voir partie Programmes) , on indique un fichier de configuration et le nom du pont à émuler. Le format du fichier est le suivant :
[switch nom-du-pont] admin-port: port du serveur d'administration priority: priorité MAC-address: adresse MAC des ports port-i: adresse IP et port du domaine de collision auquel est connecté le ième port port-j: ..................................................................jème..... . . .L'adresse MAC indiquée par MAC-address correspond à l'adresse MAC de tous les ports. La première ligne de bloc correspondant au pont doit être la directive donnant le nom du pont, qui ne doit pas comporter d'espaces, l'ordre des directives suivantes n'a pas d'importance. Il y a une directive port-i par port "câblé". Si aucun port n'est initialement connecté, aucune directive port-i n'est spécifiée. L'adresse multicast IP et le port des directives port-i sont exprimées sous la forme a.b.c.d:port.
Ainsi, le réseau suivant :
est décrit par le fichier de configuration :
# configuration for switch1 # its name [switch switch1] # TCP connection port to configure switch1 admin-port: 8001 # its MAC address MAC-address: 10:aa:ac:10:12:ac # the list of its plugged-in ports # port 3 is connected to collision domain 225.0.0.2:1222 port-3: 225.0.0.2:1222 [switch switch2] admin-port: 8002 MAC-address: 12:aa:ac:25:af:0d port-6: 225.0.0.2:1222 port-8: 225.0.0.1:1456 [switch switch3] admin-port: 8003 MAC-address: 12:aa:ac:ef:f4:45 port-1: 225.0.0.1:1456 [switch switch4] admin-port: 8004 MAC-address: 12:aa:ac:ab:67:7f port-1: 225.0.0.1:1456
Le programme qui émule un hôte doit connaître son adresse MAC, le domaine de collision sur lequel il est branché et son adresse IP.
Comme pour les ponts, la configuration d'un hôte doit pouvoir être consultée et modifiée pendant l'exécution du programme, par connexion TCP avec le programme. L'interface de configuration est définie dans la partieAdministration
Au lancement des programmes d'émulation des hôtes (host voir partie Programmes), on indique un fichier de configuration et le nom de l'hôte à émuler. Le format du fichier est le suivant :
[host nom-de-l'hôte]
admin-port: port du serveur d'administration
MAC-address: adresse MAC de l'hôte
IP-address: adresse IP de l'hôte
link: (optionnel) adresse IP et port du domaine de collision auquel est
connecté l'hôte sous la forme x.y.z.a:port
La première ligne de bloc
doit être la directive donnant le nom de l'hôte,
qui ne doit pas comporter d'espaces,
l'ordre des directives suivantes n'a pas d'importance. Quand on ne
spécifie par de directive link, l'interface Ethernet virtuelle de
l'hôte n'est pas activée. On peut l'activer pendant l'exécution grâce à
l'interface d'administration.
Ainsi, la configuration complète (hôte et ponts) du réseau
suivant :
est donnée par le fichier de configuration suivant :
[switch switch1] admin-port: 8001 MAC-address: 10:aa:ac:10:12:ac port-3: 225.0.0.2:1222 port-12: 225.0.0.2:1223 [host host1] admin-port: 8011 MAC-address: a0:15:65:ae:ef:a2 IP-address: 10.1.0.1 link: 225.0.0.2:1223 [host host2] admin-port: 8012 MAC-address: a0:15:65:3a:fa:15 IP-address: 10.1.0.2 link: 225.0.0.2:1222 [switch switch2] admin-port: 8002 MAC-address: 12:aa:ac:25:af:0d port-6: 225.0.0.2:1222 port-8: 225.0.0.1:1456 [switch switch3] admin-port: 8003 MAC-address: 12:aa:ac:ef:f4:45 port-1: 225.0.0.1:1456 [switch switch4] admin-port: 8004 MAC-address: 12:aa:ac:ab:67:7f port-1: 225.0.0.1:1456 port-5: 225.0.1.2:1228 [host host3] admin-port: 8013 MAC-address: a0:15:65:45:12:a5 IP-address: 10.1.0.3 link: 225.0.1.2:1228
En se connectant en TCP sur le port d'administration d'un des équipements virtuels (pont ou hôte), on peut le configurer dynamiquement pendant son exécution. Par exemple, pour configurer le pont switch1 de l'exemple précédent, on peut taper netcat localhost 8001. Une fois la connexion établie, on envoie des commandes auxquelles répond le serveur. Pour simplifier, si deux personnes se connectent, le seconde est mise en attente.
Pour les ponts, les commandes sont les suivantes (les réponses du serveur doivent être en anglais, les crochets indiquent un paramètre optionel) :
Pour les hôtes, les commandes sont les suivantes (les réponses du serveur doivent être en anglais, les crochets indiquent un paramètre optionel) :
Le projet contient cinq programmes :
Les quatre premiers programmes nécessitent la fourniture d'un fichier de configuration, stipulé par l'option -conf. En l'absence de cette option, le fichier network.conf situé dans le répertoire courant sera choisi.
Ce programme permet de lancer le serveur qui émulera un pont. On le lance ainsi :
switch [-conf file] namece qui émule le pont name défini dans le fichier de configuration.
Ce programme permet de lancer le serveur qui émulera un hôte. On le lance ainsi :
host [-conf file] namece qui émule l'hôte name défini dans le fichier de configuration.
Ce programme permet de consulter ou d'effacer la table ARP d'un hôte. On le lance ainsi :
arp [-conf file] name [flush]ce qui affiche ou efface la table ARP de l'hôte name défini dans le fichier de configuration.
Ce programme permet de faire envoyer une requête ping vers une adresse MAC ou une adresse IP IP (cf là) par un hôte et de dire quand il reçoit la réponse. Avant de lancer le paquet, le programme doit afficher l'adresse MAC du destinataire, puis, une fois la réponse reçue, le temps mis entre l'envoi de la requête et la réponse. On le lance ainsi :
ping [-conf file] [-ip address] name mac ping [-conf file] [-ip address] name ipce qui provoque l'émission d'une requête ping de la part de l'hôte name défini dans le fichier de configuration file, à destination de l'adresse MAC mac ou de l'adresse IP ip. Le programme suppose que le programme émulant la machine est lancé sur localhost, sauf si la directive -ip est présente. Dans ce cas, le programme se connecte sur le port d'administration correspondant à l'hôte virtuel name, sur la machine (réelle) dont l'adresse est address.
Vous êtes libre, une fois le projet terminé et parfaitement opérationnel, d'ajouter des options au programme ping.
Ce programme se comporte comme tcpdump. Il affiche toutes les trames qui transitent sur un domaine de collision donné. L'affichage doit être agréable, et séparer les différents champs de la trame Ethernet. On le lance ainsi :
sniff ip:portce qui affiche les trames qui circulent sur le domaine de collision représenté par l'adresse multicast ip et le port port.
Ce projet est à réaliser en binôme, les deux personnes faisant partie du même groupe de TD. Les monômes sont interdits ; un seul trinôme par groupe de TD est autorisé. Tout groupe ne respectant pas ces consignes verra son projet noté 0. Il doit être rendu au plus tard le lundi 15 mars, sous la forme d'un fichier d'archive zip qui devra contenir les fichiers et répertoires suivants :
Afin d'avoir des points, votre projet devra au moins fonctionner sur
l'exemple suivant. On réalise le réseau virtuel :
dont le fichier de configuration, mort-subite.conf, est :
[switch switch] admin-port: 8001 priority: 12 MAC-address: 10:10:10:10:10:10 port-1: 225.0.0.1:1236 port-6: 225.0.0.1:1235 port-8: 225.0.0.1:1234 [host host1] admin-port: 8011 MAC-address: 10:10:10:aa:10:11 IP-address: 169.254.1.1 link: 225.0.0.1:1236 [host host2] admin-port: 8012 MAC-address: 10:10:10:aa:10:12 IP-address: 169.254.1.2 link: 225.0.0.1:1234 [host host3] admin-port: 8013 MAC-address: 10:10:10:aa:10:13 IP-address: 169.254.1.3 link: 225.0.0.1:1235
Le test sera le lancement les commandes suivantes :
switch -conf mort-subite.conf switch & host -conf mort-subite.conf host1 & host -conf mort-subite.conf host2 & host -conf mort-subite.conf host3 & while true ; do ping -conf mort-subite.conf host2