inetdoc.net

Partant de la liste des images de machines virtuelles téléchargeables à partir du serveur Web de l'infrastructure de de travaux pratiques STRI (http://www.stri/vm/), on copie 3 images disques identiques.

$ cd ~/vm
$ mkdir ospf
$ qemu-img create -b vm0-debian-i386.raw -f raw ospf/r1.raw
$ qemu-img create -b vm0-debian-i386.raw -f raw ospf/r2.raw
$ qemu-img create -b vm0-debian-i386.raw -f raw ospf/r3.raw

Ensuite, on créé un script shell de lancement des instances de «routeurs» dans lequel on fixe les paramètres d'initialisation de ces mêmes «routeurs».

Attention ! Ce script ne doit être lancé qu'après l'initialisation du commutateur virtuel pour que le brassage des routeurs sur les ports du commutateur puisse se faire correctement.

$ cd ~/vm/ospf
$ cat ospf-lab.sh

#!/bin/bash

../scripts/startup.sh r1.raw 512 2 

../scripts/startup.sh r2.raw 512 3 

../scripts/startup.sh r3.raw 512 4

Le code du script startup.sh donné ci-dessous est extrait de l'article cité plus haut.

#!/bin/bash
# $Id: startup.sh 1614 2011-03-17 22:41:04Z latu $

#RedOnBlack='\E[31;40m'
RedOnBlack='\E[31m'

vm=$1
shift
memory=$1
shift
port=$1
shift

if [[ -z "$vm" || -z "$memory" || -z "$port" ]]
then
        echo "ERREUR : paramètre manquant"
        echo "Utilisation : $0 <fichier image> <quantité mémoire en Mo> <port commutateur [2..32]>"
        exit 1
fi

if (( $memory < 128 ))
then
        echo "ERREUR : quantité de mémoire RAM insuffisante"
        echo "La quantité de mémoire en Mo doit être supérieure ou égale à 128"
        exit 1
fi

macaddress="52:54:00:12:34:$port"

echo -e "$RedOnBlack"
echo "~> Machine virtuelle : $vm"
echo "~> Mémoire RAM       : $memory"
echo "~> Port commutateur  : $port"
echo "~> Adresse MAC       : $macaddress"
tput sgr0

#  -vga vmware \
kvm \
  -daemonize \
  -name $vm \
  -m $memory \
  -rtc base=localtime,clock=host \
  -drive file=$vm,if=virtio,media=disk,boot=on \
  -k fr \
  -usb -usbdevice tablet \
  -soundhw es1370 \
  -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl,port=$port \
  -net nic,vlan=1,model=virtio,macaddr=$macaddress \
  $*

Pour que les réseaux de l'aire OSPF puissent communiquer avec le système hôte et l'Internet, il est nécessaire de compléter la table de routage du système hôte. Dans ce contexte le système hôte joue le rôle d'un routeur central et la technique usuelle employée pour répondre au besoin d'interconnexion consiste à implanter une «super route» qui rassemble tous les réseaux de l'aire en une seule entrée.

L'aire OSPF étudiée contient quatre réseaux :

L'utilisation de l'outil ipcalc permet de vérifier qu'un masque de 19 bits permet d'englober ces quatre réseaux en une seule entrée.

$ ipcalc 10.1.0.0/19
Address:   10.1.0.0             00001010.00000001.000 00000.00000000
Netmask:   255.255.224.0 = 19   11111111.11111111.111 00000.00000000
Wildcard:  0.0.31.255           00000000.00000000.000 11111.11111111
=>
Network:   10.1.0.0/19          00001010.00000001.000 00000.00000000
HostMin:   10.1.0.1             00001010.00000001.000 00000.00000001
HostMax:   10.1.31.254          00001010.00000001.000 11111.11111110
Broadcast: 10.1.31.255          00001010.00000001.000 11111.11111111
Hosts/Net: 8190                  Class A, Private Internet

On complète donc la table de routage du système hôte avec l'instruction suivante :

# ip route add 10.1.0.0/19 dev tap0

Le fait de désigner la destination par l'interface tap0 optimise le traitement dans la mesure où le processus de commutation de paquet connaît directement l'interface sur laquelle placer les paquets IP sans passer par un examen de la table de routage ou plus exactement les hashes de la Forwarding Information Base (FIB).

Une fois cette nouvelle entrée de la table de routage du système hôte en place, on peut valider l'accessibilité des réseaux de l'aire en testant le service Web factice implanté sur le routeur R3 depuis le système hôte.

# nmap -A -p80 10.1.3.3

Starting Nmap 5.21 ( http://nmap.org ) at 2010-11-18 22:44 CET
Nmap scan report for 10.1.3.3
Host is up (0.0019s latency).
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.16 ((Debian))
|_html-title: Site doesn't have a title (text/html)
<snipped/>

Comme indiqué dans l'article cité en référence ci-dessus, le lancement du commutateur virtuel Virtual Distributed Ethernet est intégré à la configuration du système hôte. Voici un extrait du fichier /etc/network/interfaces relatif à la configuration de l'interface tap0.

# The tap0 network interface
iface tap0 inet static
        address 192.200.0.1
        netmask 255.255.255.224
        network 192.200.0.0
        broadcast 192.200.0.31
        vde2-switch -
        post-up /etc/init.d/isc-dhcp-server restart
        post-up /etc/init.d/ntp restart
        post-up /etc/init.d/bind9 reload

Dans cette configuration, l'interface tap0 est automatiquement brassée sur le port 1 du commutateur et elle utilise le VLAN numéro 0 par défaut.

Une fois que l'on a lancé le script de lancement des instances de machines virtuelles à l'aide de la commande : $ sh ./ospf-lab.sh, on obtient les informations suivantes à partir de l'interface de configuration du commutateur.

Avant la mise en place des VLANs sur les routeurs et le commutateur, on visualise les connexions sur les 4 ports occupés.

$ unixterm /var/run/vde2/tap0.mgmt
VDE switch V.2.2.3
(C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2

vde$ port/print
0000 DATA END WITH '.'
Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
 Current User: NONE Access Control: (User: NONE - Group: NONE)
 IN:  pkts       2288          bytes              1288845
 OUT: pkts       1239          bytes               221354
  -- endpoint ID 0007 module tuntap      : tap0
Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
 Current User: ph1l Access Control: (User: NONE - Group: NONE)
 IN:  pkts       1870          bytes               275892
 OUT: pkts       2831          bytes              1328457
  -- endpoint ID 0011 module unix prog   : QEMU user=ph1l PID=2982 \
     SOCK=/var/run/vde2/tap0.ctl/.02982-00000
Port 0003 untagged_vlan=0099 ACTIVE - Unnamed Allocatable
 Current User: ph1l Access Control: (User: NONE - Group: NONE)
 IN:  pkts        639          bytes                55474
 OUT: pkts        645          bytes                57546
  -- endpoint ID 0003 module unix prog   : QEMU user=ph1l PID=2986 \
     SOCK=/var/run/vde2/tap0.ctl/.02986-00000
Port 0004 untagged_vlan=0099 ACTIVE - Unnamed Allocatable
 Current User: ph1l Access Control: (User: NONE - Group: NONE)
 IN:  pkts        642          bytes                55372
 OUT: pkts        638          bytes                57080
  -- endpoint ID 0009 module unix prog   : QEMU user=ph1l PID=2989 \
     SOCK=/var/run/vde2/tap0.ctl/.02989-00000
.
1000 Success

On valide ainsi le brassage des routeurs.

Une fois le brassage en place, on peut passer à la configuration des VLANs ; toujours via l'interface de configuration du commutateur virtuel. Il est possible d'utiliser un fichier de sauvegarde de la liste des instructions de configuration du commutateur : vde.conf dans notre exemple. On charge ces instructions dans le commutateur virtuel via la commande vde$ load /home/ph1l/vm/opsf/vde.conf.

vde$ load /home/ph1l/vm/ospf/vde.conf

vde[/home/ph1l/vm/ospf/vde.conf]: vlan/create 12
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/create 13
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/create 23
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 12 2
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 13 2
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 12 3
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 23 3
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 13 4
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/addport 23 4
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: plugin/add /usr/lib/vde2/plugins/pdump.so
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: vlan/create 99
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: port/setvlan 3 99
1000 Success
vde[/home/ph1l/vm/ospf/vde.conf]: port/setvlan 4 99
1000 Success
1000 Success

Cette syntaxe s'approche plus du mode Hewlett Packard™ que du mode Cisco™. Les trois premières lignes servent à créer les VLANs suivant la dénomination :

Ensuite, les six lignes suivantes servent à désigner les VLANs ou les trames étiquetées à véhiculer vers les ports. Par exemple, le port numéro 2 reçoit les trames avec les balises des VLANs 12 et 13.

Comme dans les cas précédents, on retrouve ces affectations via l'interface de configuration du commutateur virtuel.

vde$ vlan/print
0000 DATA END WITH '.'
VLAN 0000
 -- Port 0001 tagged=0 active=1 status=Forwarding
 -- Port 0002 tagged=0 active=1 status=Forwarding
VLAN 0012
 -- Port 0002 tagged=1 active=1 status=Forwarding
 -- Port 0003 tagged=1 active=1 status=Forwarding
VLAN 0013
 -- Port 0002 tagged=1 active=1 status=Forwarding
 -- Port 0004 tagged=1 active=1 status=Forwarding
VLAN 0023
 -- Port 0003 tagged=1 active=1 status=Forwarding
 -- Port 0004 tagged=1 active=1 status=Forwarding
VLAN 0099
 -- Port 0003 tagged=0 active=1 status=Forwarding
 -- Port 0004 tagged=0 active=1 status=Forwarding
.
1000 Success

Pour accéder à des débits réseau plus élevés sur les instances de machines virtuelles, on utilise l'interface virtio du noyau Linux. Il s'agit de mettre en place une paravirtualisation dans laquelle le noyau de l'instance de machine virtuelle est «modifié» pour accéder directement aux ressources du système hôte.

Pour utiliser cette interface de paravirtualisation, il n'est pas nécessaire d'intervenir sur la configuration système des routeurs R1, R2 et R3. Les paquets de noyaux fournis par la distribution Debian GNU/Linux possèdent toutes les fonctions nécessaires.

Une fois la configuration de la paravirtualisation en place, on peut utiliser l'outil iperf pour mesurer la capacité réseau entre les routeurs R1 et R2. Voici un échantillon de résultat obtenu.

Sur le routeur R2, on lance la partie serveur de l'outil iperf.

etu@r2:~$ iperf -s -w 65536
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:   128 KByte (WARNING: requested 64.0 KByte)
------------------------------------------------------------

Sur le routeur R1, on lance la partie cliente du même outil. On fixe le temps de transmission à 180 secondes avec 4 threads en parallèle.

etu@r1:~$ iperf -c 10.1.12.2 -w 65536 -t 180 -P 4
------------------------------------------------------------
Client connecting to 10.1.12.2, TCP port 5001
TCP window size:   128 KByte (WARNING: requested 64.0 KByte)
------------------------------------------------------------
[  4] local 10.1.12.1 port 35103 connected with 10.1.12.2 port 5001
[  5] local 10.1.12.1 port 35104 connected with 10.1.12.2 port 5001
[  3] local 10.1.12.1 port 35102 connected with 10.1.12.2 port 5001
[  6] local 10.1.12.1 port 35105 connected with 10.1.12.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-180.0 sec  7.88 GBytes    376 Mbits/sec
[  5]  0.0-180.0 sec  7.94 GBytes    379 Mbits/sec
[  3]  0.0-180.0 sec  7.67 GBytes    366 Mbits/sec
[  6]  0.0-180.0 sec  7.72 GBytes    369 Mbits/sec
[SUM]  0.0-180.0 sec  31.2 GBytes  1.49 Gbits/sec

Avec un débit total de 1.49 Gbits/sec, on peut dire que les conditions de transmission réseau entre deux instances de systèmes virtualisés sont très bonnes.