FALL Mourtalla

JUPITER Julien

TP RESEAUX ET
QOS
Problématique et mise en œuvre de solution
FALL Mourtalla
JUPITER Julien

SOMMAIRE
1°) Mise en place de la maquette.........................................................................3
2°) Visualisation de l'incidence du multiplexage de différents flux :......................4
3°) Interprétation des résultats..............................................................................6
4°) Conséquences sur un trafic............................................................................9
5°) QoS Absolue de Niveau IP (IntServ/RSVP)..................................................12
FALL Mourtalla
JUPITER Julien

1°) Mise en place de la maquette

● Réalisons le câblage suivant :

Configuration des interfaces et vérifications de connectivité avec PC

● Les interfaces ETH1 de nos machines conformément au plan ci-dessus

● L’interface FA0/0 de notre routeur et vérifiez la connectivité avec votre PC

● L’interface Serial0/0/0 de votre routeur en encapsulation HDLC, à 128000b/s et

vérifiez la connectivité avec l'autre routeur
FALL Mourtalla
JUPITER Julien

● Ajoutons sur le pc et le routeur une route statique pour pouvoir joindre l'autre binôme

Route PC

Route routeur

A ce point les 2 PCs sont censés pouvoir se joindre…

2°) Visualisation de l'incidence du multiplexage de différents flux :

Le temps moyen mesuré par le ping est de 9ms avec une gigue estimée à 3ms.

Le débit moyen de ce traffic en Ethernet et HDLC est 91 octets/s.

FALL Mourtalla
JUPITER Julien

Tout en laissant le ping précédent tourner entre les 2 PCs, dans un second terminal lançons
un ping 1000 octets et un intervalle de 0.3 seconde.

Le débit moyen de ce trafic est de 597 octets par secondes, avec une bande passante de
128kbits/s.
FALL Mourtalla
JUPITER Julien

On laisse tourner une bonne minute, en fonction des instants de démarrage des deux
processus ping pour voir comment évolue la gigue sur le premier ping on peut observer
qu’elle est légèrement plus présente, d’environ 6ms.

3°) Interprétation des résultats

On décomposer le temps de réponse du ping en 3 parties :

- Le temps de réponse : il s'agit du temps écoulé entre l'envoi d'un paquet de données
et la réception de sa réponse. Cette information nous indique la latence ou le délai
de transmission entre les 2 PCs.

- Le nombre de paquets envoyés et reçus : cela nous donne une idée du taux de perte
de paquets, c'est-à-dire le nombre de paquets qui ont été envoyés mais n'ont pas été
reçus par l'adresse IP cible.

- La taille des paquets : cela nous donne des informations sur la taille des paquets de
données qui ont été envoyés et reçus. Cette information peut être utile pour
déterminer si des paquets sont perdus en raison de leur taille.

● Calculons les durées d'émission suivantes :

Interface Ethernet 100Mb/s Serial 128 kb/s

Longueur Message ICMP

64 octets 64 octets * 8 bits/octet = 4 ms

512 bits / 100 Mbps =
0,00000512 secondes
=5.12 µs

1008 octets 1008 octets * 8 bits/octet 63 ms

= 8064 bits / 100 Mbps =
0,00008064 s = 80.64 µs

Les valeurs de temps de réponse des pings effectués précédemment peuvent être
comparées aux durées d'émission que nous avons calculées. Si le temps de réponse est
plus élevé que la durée d'émission calculée, cela peut indiquer une certaine latence dans le
réseau, telle que des retards de traitement ou des congestions de trafic. D'un autre côté, si
le temps de réponse est inférieur à la durée d'émission calculée, cela peut indiquer que le
réseau est en bon état de fonctionnement.
La gigue, quant à elle, est une mesure de la variation de la latence d'un réseau. Elle peut
être calculée en prenant l'écart-type des temps de réponse des pings effectués. Si la gigue
est élevée, cela peut indiquer une instabilité du réseau, qui peut être causée par une
congestion de trafic ou d'autres problèmes de performance du réseau. En revanche, si la
FALL Mourtalla
JUPITER Julien

gigue est faible, cela indique que le réseau est relativement stable et peut offrir des
performances plus constantes.

Le fait de prioriser le trafic aura une influence importante sur la gigue parce que les paquets
prioritaires seront envoyés en premier qui va permettre d’éviter la saturation du réseau.

L'interface série du Cisco étant limitée à 128 Kb/s on va se contenter d'une gigue max A/R
d'environ 130 ms soit ~65 ms dans un sens (si on se limite à des datagrammes de 500
octets on la fait même tomber en dessous de 25 ms).

On va maintenant utiliser un outil plus précis pour mesurer les performances de notre
réseau : IPERF"

● Sur le PC "M" lancons iperf en mode serveur iperf -s -u -i 1

A quoi correspondent les différents paramètres s, c, u, i, b et t ?

- s permet d’exécuter iperf en mode server.

- c permet d’exécuter iperf en mode client.
- u permet d’utiliser UDP plutôt que TCP.
- i permet d’appliquer intervalle entre chaque capture de données.
- b permet de mettre en place une bande passante en bits par seconde à utiliser par
iperf. Elle est à 1 Mbits/seconde par défaut en UDP.
- t est le temps de transmission en secondes.

A la fin de l'intervalle de test le client affiche les résultats. (Données transférées, Bande
passante, Gigue (jitter) et taux de perte)

● Sur le PC "N" lancer iperf en mode client -c 10.6.0.1 -u -i 1 -b 64K -t 10

FALL Mourtalla
JUPITER Julien

La gigue est de 0.023 ms.

Lançons maintenant un ping vers l'autre PC en mode rafale (ping -i 0 -s 500 10.X.0.1) et
regarder l'évolution de la gigue

La gigue est très impactée lorsqu’on lance un ping en continu, car cela va entraîner des
collisions/de la congestion. On peut voir que l’on passe d'une gigue de 0.023 ms à 16.119
ms. Ce qui est logique car en envoyant autant de paquets à la seconde un goulot
d’étranglement se créé.

4°) Conséquences sur un trafic

FALL Mourtalla
JUPITER Julien

● Réalisons le câblage suivant (en fait on rajoute un lien entre les fa0/0 en half
duplex/10Mb/s)

Configuration de l’interface f0/0 en half duplex /10Mb/s

● Ajoutons une seconde route statique passant maintenant par l'extrémité de fa0/0
avec une métrique de 2.

● A l'aide d'un traceroute entre les 2 machines vérifions que les paquets suivent
toujours la première route.

● Débranchons le serial et vérifions par traceroute que la route passe maintenant par
l'autre interface.

On va lancer le serveur et le client vlc en rtp/udp sur le port 9999 du client...

● Copions le fichier video "video.mp4" sur notre serveur

● Lançons le serveur : vlc -vvv video.mp4 --sout rtp:10.7.0.1:9999 -–ttl 3 --loop
FALL Mourtalla
JUPITER Julien

● Lançons le client : vlc -vvv rtp:@:9999

● A l'aide du menu... de vlc nous pouvons voir en continu la qualité du flux

On arrive à voir le contenu de la vidéo coté client.

● A l'aide de Wireshark repérons la bande passante consommée par le streaming ainsi

que les ports utilisés par celui-ci.
FALL Mourtalla
JUPITER Julien

A l’aide de wireshark on peut constater que les ports utilisés pour le streaming sont les 9999
en port destination et 55520 en port source et la bande passante est de 10 Mo/s.
FALL Mourtalla
JUPITER Julien

5°) QoS Absolue de Niveau IP (IntServ/RSVP)

Le protocole RSVP (Resource Reservation Protocol) est un protocole de communication

utilisé dans les réseaux IP pour permettre aux utilisateurs de réserver des ressources de
bande passante pour des sessions de communication spécifiques.

Activons le RSVP sur l’interface fa0/0

fair queue

- ip rsvp sender 10.7.0.1 10.11.0.1 UDP 9999 0 fa0/1 64 32

- ip rsvp reservation 10.10.10.2 10.3.0.1 UDP 9999 0 10.3.0.1 fa0/1 64 32

Activation du debugging de l'activité RSVP : "debug ip rsvp"

Testons successivement les commandes suivantes et expliquer leur rôle :

show ip rsvp interfaces

Affiche les informations sur les interfaces configurées pour le protocole RSVP.

show ip rsvp installed

Affiche les informations suivantes pour chaque session RSVP enregistrée sur
l’équipement :

- Tunnel ID: identifiant du tunnel RSVP

- Sender IP: adresse IP de l'expéditeur
- Receiver IP: adresse IP du destinataire
- RSVP Class: classe de service RSVP

show ip rsvp neighbor

FALL Mourtalla
JUPITER Julien

La commande "show ip rsvp neighbor" est utilisée pour afficher les informations sur
les voisins RSVP sur le réseau.

show ip rsvp sender

La commande "show ip rsvp sender" est utilisée pour afficher les informations sur les
expéditeurs RSVP enregistrés sur le réseau.

show ip rsvp request

La commande "show ip rsvp request" est utilisée pour afficher les informations sur
les demandes RSVP enregistrées sur notre réseau.

show ip rsvp reservation

La commande "show ip rsvp reservation" affiche les informations sur les sessions de
réservation RSVP actives, y compris l'adresse IP du destinataire, l'identifiant du
tunnel RSVP, la classe de service RSVP…