est décrit par le fichier de configuration :
Ce document est accessible et régulièrement mis à jour à partir de l'URL http://igm.univ-mlv.fr/~duris.
Dernière modification le 30/01/2004.
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 :
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 deux 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 2 2 1 4
+------+-----+-----+-----+-----+---+--------------------------+---------+
| Dest | Src | Lgr | SAP | SAP | C | Message STP + padding | CRC |
+------+-----+-----+-----+-----+---+--------------------------+---------+
Afin de pouvoir utiliser et tester ces ponts virtuels, il faudra aussi implémenter des hôtes (DTE) virtuels, capables d'envoyer et de reçevoir 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 celui de 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 dans lequel chaque équipement est décrit, l'un après l'autre.
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.
Par ailleurs, 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 partieAdministration.
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 TCP du serveur d'administration priority: priorité MAC-address: adresse MAC du pont 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 du pont. La première ligne d'un bloc correspondant à un 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 UDP des directives port-i sont exprimés 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, et le domaine de collision sur lequel il est branché.
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
link: (optionnel) adresse IP et port du domaine de collision auquel
est connecté le ième port sur 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 pas 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 link: 225.0.0.2:1223 [host host2] admin-port: 8012 MAC-address: a0:15:65:3a:fa:15 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 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 telnet localhost 8001 (ou utiliser la commande netcat). 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 quatre programmes :
Les trois 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] name
ce 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] name
ce qui émule l'hôte name défini dans le fichier de configuration.
Ce programme permet de faire envoyer une requête ping Ethernet (cf ping) vers une adresse MAC par un hôte. Le programme doit afficher, une fois la réponse reçue, le temps mis entre l'envoi de la requête et la réception de la réponse. On le lance ainsi :
ping [-conf file] name MAC-address
ce qui provoque l'émission d'une requête ping de la part de l'hôte name défini dans le fichier de configuration, à destination de l'adresse MAC MAC-address.
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:port
ce 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 monômes sont interdits ; au plus, un seul trinôme est autorisé. Tout groupe ne respectant pas ces consignes verra son projet noté 0. Il doit être rendu au plus tard le vendredi 13 février, sous la forme d'un fichier d'archive zip qui devra contenir les fichiers et répertoires suivants :
Le fichier d'archive compressé contenant ces différents documents sera envoyé par un mail convivial, indiquant les noms et prénoms des deux membres du binôme, avec comme sujet projet EoU, aux deux chargés de TD et au chargé de cours, c'est-à-dire Nicolas.Bedon[at]univ-mlv.fr, gloyaute[at]etudiant.univ-mlv.fr et Etienne.Duris[at]univ-mlv.fr
Afin d'avoir des points, votre projet devra au moins fonctionner sur le premier des deux exemples suivants, représentatif du filtrage. Pour espérer avoir la moyenne, il devra également fonctionner sur le deuxième exemple, représentatif de l'application du spanning tree algorithm.
On réalise le réseau virtuel :
dont le fichier de configuration, mort-subite-filtering.conf,
est le suivant :
[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 link: 225.0.0.1:1236 [host host2] admin-port: 8012 MAC-address: 10:10:10:aa:10:12 link: 225.0.0.1:1234 [host host3] admin-port: 8013 MAC-address: 10:10:10:aa:10:13 link: 225.0.0.1:1235
Le test de mort subite sera le lancement les commandes suivantes :
$ switch -conf mort-subite-filtering.conf switch &
$ host -conf mort-subite-filtering.conf host1 &
$ host -conf mort-subite-filtering.conf host2 &
$ host -conf mort-subite-filtering.conf host3 &
$ while true ; do
ping -conf mort-subite-filtering.conf host2 10:10:10:aa:10:13
sleep 1
done
et dans un autre terminal, en même temps,
sniff 225.0.0.1:1236
qui ne devra voir que quelques paquets de la communication entre les hôtes host2 et host3 (filtrage).
On réalise le réseau virtuel :
dont le fichier de configuration, mort-subite-STA.conf,
est le suivant :
[switch switch1] admin-port: 10001 priority: 32768 MAC-address: 00:12:ab:34:cd:56 port-1: 228.10.20.12:1212 port-6: 228.10.30.13:1313 port-10: 228.10.10.11:1111 [host host1] admin-port: 20001 MAC-address: 00:12:34:56:ab:cd link: 228.10.10.11:1111 [switch switch2] admin-port: 10002 priority: 32768 MAC-address: 00:12:ab:34:cd:78 port-2: 228.10.20.12:1212 port-3: 228.20.30.23:2323 [switch switch3] admin-port: 10003 priority: 32768 MAC-address: 00:12:ab:34:cd:90 port-4: 228.20.30.23:2323 port-5: 228.10.30.13:1313 port-20: 228.30.20.32:3232 [host host2] admin-port: 20002 MAC-address: 00:12:34:ab:cd:ef link: 228.30.20.32:3232
Le test de mort subite sera le lancement les commandes suivantes :
$ switch -conf mort-subite-STA.conf switch1 & $ switch -conf mort-subite-STA.conf switch2 & $ switch -conf mort-subite-STA.conf switch3 & $ telnet localhost 10001 > sta on Spanning Tree Protocol enabled on switch1 > quit Connection closed by foreign host. $ telnet localhost 10002 > sta on Spanning Tree Protocol enabled on switch2 > quit Connection closed by foreign host. $ telnet localhost 10003 > sta on Spanning Tree Protocol enabled on switch3 > quit Connection closed by foreign host. $ host -conf mort-subite-STA.conf host1 & $ host -conf mort-subite-STA.conf host2 & $ telnet localhost 10003 > root root bridge MAC address 00:12:ab:34:cd:56 > info port state STA state 4 up forwarding 5 up blocking 20 up forwarding > quit Connection closed by foreign host.
© Université de Marne-La-Vallée - Janvier 2004