Lundi 5 Mars 2001

TP de Téléinformatique 1

Configuration des machines

Mise en place du réseau :

Raccordement du matériel :

PC1

PC2

PC3

PC4

Paire Torsadée

Commande de configuration d’interface  (spwr0 dans notre cas):

Ø Ifconfig spwr0 plumb Initialisation de l'interface.

Ø Ifconfig spwr0 195.0.0.1 Connexion de l’interface au réseau et attribution

de son adresse Internet.

Ø Ifconfig spwr0 up Activation de l'interface.

Vérification de l’état des interfaces :

Commande : Ifconfig spwr0

Nom Officiels	Adresses Internet (Classe C)	Adresses Ethernet
Sparc1	195.0.0.1	00 :e0 :29 :2b :78 :de
Sparc2	195.0.0.2	00 :e0 :29 :2b :78 :dd
Sparc3	195.0.0.3	00 :b0 :d0 :5c :5a :d8
Sparc4	195.0.0.4	00 :b0 :d0 :5c :59 :d8

Contenu du fichier /etc/hosts  :

La configuration des interfaces réalisée ci-dessus est temporaire et limitée à la séance mais si nous la voulons permanente il faut créer un fichier /etc/hostname.spwr0 dans lequel nous mettons l’adresse Internet de l’interface que la machine lira automatiquement au moment du boot.

La machine réalisera alors les mêmes opérations que celle de la configuration manuelle que nous avons effectuée.

On peut également associer un nom symbolique à chaque machine du réseau (nom qu’elle prendront dans chaque communication sur le réseau) en complétant le fichier etc/hosts pour y mettre son adresse Internet et le nom officiel de chaque machine correspondant.

Contenu du fichier :

195.0.0.1 Sparc1

195.0.0.2 Sparc2

195.0.0.3 Sparc3

195.0.0.4 Sparc4

Pour vérifier que toutes les machine sont bien connectées on ‘lance’ des pings vers les autres machine (via leur nom symbolique) qui doivent nous renvoyer un <nom symbolique> is alive

Observation de l’activité du réseau (Fonctionnement de ping)

Explication sommaire :

Quand une machine lance un ping pour savoir si une autre machine est sur le réseau elle lui envoie un paquet (par son adresse Ethernet) et reçoit un paquet de réponse de la machine concernée si elle est bien connectée.

Une machine A lance un ping vers une machine B : ping sparc2

Messages captés par le capt lancé sur une machine C  (4 paquets):

- Un paquet de type ARP C de A vers toutes les machines du réseau (broadcast) pour connaître l’adresse Ethernet de la machine B car A ne connaît que son nom officiel et son adresse Internet (contenu du fichier Hosts).

Who is 195.0.02, sparc2

- Un paquet de type ARP R de B vers A qui envoie son adresse Ethernet c’est à dire celle qui correspond au nom officiel mis sur le réseau.

195.0.0.2 ,sparc2 is 00 :e0 :29 :2b :78 :dd

- Un paquet de type ICMP Echo request de A vers B qui connaît maintenant l’adresse Ethernet de la machine B et peut vérifier qu’elle est bien connectée et configurée.

(rmq la machine A ne sait pas que c’est B qui a répondu au paquet ARP C car une autre machine peu également répondre à cette requête).

ICMP Echo request

- Un paquet de type ICMP Echo reply de B vers A qui répond qu’elle est connectée par le message ‘Sparc2 is alive’.

ICMP Echo reply

Interprétation de la présence des paquets de type ARP :

La machine A possède une table des entrées correspondances entre les adresses Internet et nom officiels des machines et leur adresses Ethernet qui permet de communiquer sur le réseau.

Quand dans la table de A il y a une entrée pour B l’exécution du ping vers B depuis A ne donne lieu qu’a l’ envoie des 2 paquet de type ICMP alors que quand elle n’y est pas on peut également capturer les 2 paquets de type ARP (une entrée pour B dans la table de A est alors créée).

On observe également que si A possède une entrée pour B dans sa table mais que l’on attend un certain temps avant de lancer un ping de A vers B l’exécution du ping donne lieu quand même aux paquets de type ARP car l’entré B à disparu de la table (le timer de la table est d’environ 3 minutes) et donc A à d’abord du retrouver l’adresse Ethernet de B en envoyant un paquet ARP C.

On peut alors comparer la table des correspondances d’une machine comme une mémoire à durée limitée.

Observation du protocoles CSMA/CD (commande netstat)

Description du mécanisme :

Avant d’émettre sur le réseau, une machine ‘écoute’ le câble et attends qu’aucune autre machine ne soit en train d’envoyer de message (rmq :une machine ne regarde pas le réseau quand elle ne veut pas émettre).

Si deux machines émettent en même temps, il y a alors collision et les deux paquets (trames) émis sont perdues.

Dans le cas d’une collision chaque machine stoppe son émission et attends pendant un laps de temps aléatoire avant de re-émettre toute la trame.

Observation sur le nombre de collisions :

La commande netperf lancée par la machine A génère un trafic à destination de la machine B . En plus la machine C génère un trafic à destination de la machine D.

Notons le nombre de collisions sur le câble (en fonction du nombre de netperfs) grâce à la commande netstat :

Ø Le nombre de collisions augmente en fonction du nombre de netperf lancés sur le réseau.

Explication : Netperf envoie des trames de taille constante pour mesurer le débit du réseau et donc plus il y a de paquets émis plus la probabilité d'avoir une collision est importante donc leur nombre augmente logiquement.

De plus les machine qui n’envoient pas de trames pas ne regardent pas le câble et donc un netstat lancé sur ces machine ne repère pas les collisions.

Notons le nombre de collisions sur le câble (en fonction de la taille des paquets envoyés) :

Ø Plus les paquets envoyés sont petits plus le nombre de collisions augmente .

Explication : Comme les paquets sont petits les machines en envoient plus dans un même laps de temps et donc le nombre de collisions en est d’autant plus grand.

Vient aussi s’ajouter le fait que si les paquets émis sont grands les machines qui veulent émettre attendent plus longtemps avant d’émettre et donc dans une même période de temps le nombre de collisions est plus bas.

Notons le nombre d’erreurs détectées :

Ce nombre est faible et varie de 0 à 2.

Analyse des performances du réseau (utilitaire netperf)

Débit réel : débit observé par l’utilisateur .

Débit effectif : débit caractéristique de la ligne (10 Mb/s).

Pour calculer le débit réel nous envoyons des paquets de taille connue sur le réseau de A vers B et nous observons le temps que le paquet met pour arriver à sa cible.

Commande : netperf host [taille en octets] [nb de paquets]

Nombre de paquets (octets)	Taille des paquets	Temps (s)	Débit réel (Mb /s) (donné par netperf)
100	60	0.002	2.9
100	1500	0.116	9.6

Exemple d’ envoi de paquets

- 100 paquets de 100 octets à 10 000 octets de données 

- réception de 22 paquets pour un taille de 11 310 octets

-11 310 –22*(60) = 9 900 octets.

Explications : on enlève à chaque paquets reçu la taille des 3 entêtes et on retrouve bien la quantité de données envoyées (les erreurs proviennent de l’approximation faite sur la taille des entêtes qui peuvent n’être que de 50 octets pour certains paquets).

Différences entre débit effectif et réel :

Le débit réel est inférieur au débit effectif car des octets sont ajoutés aux paquets avant d’être envoyés.

En effet le protocole TCP utilisé pour envoyer les messages rajoute des octets de contrôle en entête de la trame à envoyer puis passe le message au protocole IP qui fait de même et fait passer le message « grossit » au protocole Ethernet qui met aussi une entête.

En lançant la commande capt sur la machine C pendant l’exécution de netperf on peut observer la nature et la taille des messages circulant sur le câble :

Ø La tailles des trois entêtes est constante et égale à 20 octets par entêtes.

Ø Les paquets sont regroupés afin d’en envoyer moins de petits et diminuer ainsi le risque de collision et le ratio(nb d’octets de données/nb d’octets d’entêtes).

Ø On observe également un paquet d’acquittement de B vers A de taille de donnés de 0 octets mais avec les trois entêtes (fréquence environ 1 pour 4 paquets envoyés).

Explications :

Comme des octets sont rajoutés, la taille de paquet utilisé pour le calcul est inférieur à la taille réelle des trames envoyées, le débit chute.

Comme la taille des entêtes est constante, plus les paquets sont petits (même si ils sont regroupés) plus le ratio est petit et donc le débit est réduit.

Les messages d’acquittement sans données réduisent également ce débit en occupant le réseau.

Cas de plusieurs trafics :

Protocole : A et C lancent un netperf respectivement vers B et D.

Observations :

En observant la colonne Avg de la commande netperf on note que le débit de chaque machines est équitable et correspond à la moitié de celui d’une seule machine générant un netperf pour la même taille de paquet.

Le protocole CSMA/CD gère cette répartition de l’envoie des messages car chaque machine attend que le réseau soit libre, et donc que l'autre machine est envoyé sont paquet, pour émettre le sien.

De plus en cas de collision, le délai avant de re-émettre est aléatoire donc le nombre de fois où chaque machine à ré-émis en premier est le même pour les deux ordinateurs (si nous considérons un grand nombre de paquets envoyés).

Conclusion :

On observe que plus le nombre de netperf générés est important plus le débit diminue jusqu’a effondrement pour un nombre de netperf >5 .

En effet le nombre de collisions devient trop important car le réseau est constamment occupé et chaque machine ne fait qu’attendre sans pouvoir émettre.