38 0 2MB
TP 2 : Mininet – Créer Learning Switch I.
Installation et familiarisation avec la plate-‐forme
•
Création d’un réseau avec 3 machines, un Switch et un contrôleur :
•
Avant le lancement du contrôleur, aucune communication n’est possible entre les machines :
•
Ce comportement est normal étant donnée qu’il n’y encore aucune règle dans la table de flux. Lancer une autre fenêtre ssh et taper la commande dpctl show tcp:127.0.0.1:6634. Cette commande permet de visualizer la table des flux
•
Nous pouvons ajouter manuellement des règles de gestion de flux.
You'll use dpctl to manually install the necessary flows. In your SSH terminal: $ dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2 $ dpctl add-flow tcp:127.0.0.1:6634 in_port=2,actions=output:1
Le ping est maintenant possible :
•
NB : par défaut le délai de conservation de ces règles est défini par le paramètre idle_timeout (60 seconde). Si on veut l’augmenter à 120 secondes, cela est possible via la commande :
•
Au lancement du contrôleur avec la commande :
Les échanges OFP entre le contrôleur tracés par Wireshark sont comme suit :
•
On lance un ping de la machine h1 vers h2 et on visualise les paquets échangés tracé par Wireshark :
NB : Il s’agit dans ce qui précède de l’OpenFlow en mode réactif : les règles OpenFlow sont envoyées en réponse à des paquets individuels. Il est également possible d’envoyer des règles OpenFlow avant que des paquets n’arrivent (mode proactif) et ce pour optimiser les temps d’aller/retour et les délais d’insertion des règles de flux. Analyse des performances avec Iperf
II.
Création d’un learning Switch
Nous allons installer un contrôleur openFlow POX (développé à l’aide du langage Python). Ensuite nous allons créer un hub, constater le comportement et par après, nous allons le reprogrammer en Switch et en Switch OpenFlow pour voir la différence. •
Création du contrôleur
•
Création d’un hub
•
Vérification du comportement du hub avec tcpdump :
o
Sur les deux hots h2 et h3 on lance l’utilitaire tcpdump pour surveiller les paquets vus par les deux hosts :
o
Sur h1 on lance un ping vers h2. Le contrôleur envoi le paquet vers tous les ports à l’exception du port source :
o
En cas de ping d’une adresse inexistante, les échanges ARP sont comme suit :
•
Les performances (justifié par le fait que les paquets vont systématiquement jusqu’au contrôleur)
•
Fichier de configuration du Hub :
•
Les modifications que nous allons apporter au fichier du code, auront pour effet de passer d’un hub à un learning switch ou à un flow-‐based switch. Pour les deux derniers cas, nous allons vérifier que tcpdump n’affichera aucun trafic après les premiers broadcast ARP lors de ping des adresses auxquels elles ne sont pas destinataires
•
Lancement du tutorial d’un exemple de hub :
•
Vérification de la connectivité et du comportement du hub :
Pour ce faire, on lance un ping sur h2 à partir de h1 et on utilise l’utilitaire tcpdump pour visualiser les paquets au niveau des différents nœuds :
•
Visualisation des performances (w/iperf) :
•
Lancement d’un Switch : en invoquant POX avec le composant l2_learning (switch)
•
Visualisation des paquets par dpctl dump-‐flows :