RSX217
SDN-IP
Table des matières
1 Présentation de la topologie
2 Configurations mises en œuvre
2.1 Machine virtuelle « mininet »
2.2 Machine virtuelle « Contrôleur Onos »
2.3 Machine virtuelle « GNS3 »
Présentation du sujet
Nous avons choisi le sujet numéro 5 qui consistait en la mise en œuvre du SDN-IP proposé par le contrôleur Onos. Le sujet est le suivant : « Mettre en place une topologie pour mettre en place un SDN-IP avec Onos. SDN-IP permet à un réseau SDN de se connecter à internet à l’aide de BGP. Montrez que vous arrivez a pingez les serveurs de Google à partir de votre Host en passant par votre réseau SDN. En externe, du point de vue BGP, le réseau SDN apparaît comme un système autonome unique (AS) qui se comporte comme n'importe quel AS traditionnel. Au sein de l'AS, l'application SDN-IP fournit le mécanisme d'intégration entre BGP et ONOS. Au niveau du protocole, SDN-IP se comporte comme une communication BGP ordinaire. Du point de vue ONOS, il s'agit simplement d'une application qui utilise ses services pour installer et mettre à jour l'état de transfert approprié dans le plan de données SDN. »
Afin de pouvoir répondre au sujet, nos recherches se sont fixées sur le site cité en référence (xueguofeng, 2017) qui détail la méthodologie de mise en place d’un réseau SDN-IP avec le contrôleur Onos.
Notre objectif est de monter une architecture accueillant un contrôleur utilisant ONOS avec comme particularité, l’Appliance SDN-IP.
Figure 1 - Présentation de la topologie
Pour répondre à cette problématique, nous utiliserons le logiciel VMWare. Nous avons créé 3 machines virtuelles (VM), chacune accueillant une partie de l’architecture et tournant avec le système d’exploitation Ubuntu server 20.04. La Figure 1 présente la topologie dans son ensemble.
On décomposera cela comme suit :
- Une VM où est installée le logiciel Mininet. Ce logiciel est capable de virtualiser une configuration de switches et d’hôtes, et est compatible avec les contrôleurs ONOS ;
- Une VM où est installée le logiciel GNS3. Ce logiciel est capable de virtualiser des routeurs, des switches, des réseaux type cloud ou NAT etc …
- Une VM où est installée le logiciel ONOS. Celui-ci est notre contrôleur, métronome de notre architecture.
Afin de comprendre comment les machines vont dialoguer entre elles la Figure 2 présente un tableau récapitulatif.
Figure 2 - Présentation des interfaces des machines virtuelles
On configure une interface NAT sur chacune des VM afin qu’elles soient dans le même réseau. Dans le tableau, c’est l’interface eth0.
Par la suite, grâce au segment LAN, nous allons pouvoir diriger le flux des interfaces en nommant ces différents segments.
Le segment 102 sera utilisé pour le switch S2 de Mininet et le routeur R1 sur F0/0 dans GNS3. Le segment 103, pour S1 et R2, le segment 104 pour S3 et R3, enfin, le segment 104 pur R1 F0/1 et ONOS. La Figure 3 présente une vue schématique des connexions réalisées entre les différentes machines virtuelles de notre topologie.
Figure 3 - Présentation des interfaces reliant les machines virtuelles de notre topologie
Chacune des machines virtuelles a été configurés de façon a ce que notre topologie réponde au sujet de ce mini projet.
Pour créer les hôtes et les commutateurs de notre réseau SDN, nous avons utilisé le simulateur de réseau virtuelle « mininet ». Nous avons créé 3 commutateurs (s1, s2 et s3) avec pour chacun d’eux une machine hôte (h1, h2 et h3). La commande utilisée pour créer cette topologie est la suivante :
sudo mn --controller=remote,ip=192.168.231.133 --topo=linear,3
L’adresse IP correspond à celle de la machine virtuelle hébergeant le contrôleur Onos. L’option « topo=linear,3 » précise que nous créons une topologie de type linéaire avec 3 commutateurs et 3 hôtes.
Une fois la topologie créée, nous avons déclaré les interfaces ethernet aux différents commutateurs dans mininet :
sh ovs-vsctl add-port s1 eth2
sh ovs-vsctl add-port s2 eth1
sh ovs-vsctl add-port s3 eth3
Ces commandes nous ont permis de déclarer respectivement les interfaces eth2, eth1 et eth3 aux commutateurs s1, s2 et s3. L’interface eth2 communique avec le routeur R2, eth1 avec le routeur R1 qui est le speaker BGP et l’interface eth3 communique avec le routeur R3.
Nous avons également modifié les adresses IP des machines hôtes du réseau SDN et nous leurs avons déclaré l’adresse IP du routeur R1 comme passerelle par défaut avec les commandes suivantes :
h1 ifconfig h1-eth0 10.1.1.1 netmask 255.255.255.0
h1 ifconfig h2-eth0 10.1.1.2 netmask 255.255.255.0
h1 ifconfig h3-eth0 10.1.1.3 netmask 255.255.255.0
h1 route add default gw 10.1.1.254
h2 route add default gw 10.1.1.254
h3 route add default gw 10.1.1.254
Une fois cette configuration mise en place nous avons pu vérifier que les bridges communiquaient bien avec le contrôleur comme montré par la Figure 4.
Figure 4 - Communication mininet avec Onos
La version du contrôleur Onos utilisé est 2.0.0. Au lancement du contrôleur, nous avons activé les cinq applications suivantes :
- openflow : suite de support du protocole Openflow ;
- fwd : permet le transfert ;
- config : permet la configuration dynamique (fichier json) ;
- proxyarp : permet à Onos de répondre aux requêtes ARP entre les routeurs BGP externes et le routeur BGP interne « BGPspeaker » ;
- sdnip : installer sdn-ip sur Onos.
La Figure 5 montre l’activation de ces applications dans l’interface de paramétrage Onos.
Figure 5 – Liste des applications activées dans Onos
Seules, ces applications ne permettent pas au contrôleur de communiquer avec le routeur « SpeakerBGP » et avec les routeurs externals BGP. Le contrôleur doit connaître l’emplacement des interfaces de sortie et l’adresse MAC de l’interface du Speaker BGP qui communique avec le réseau SDN (mininet).
La Figure 6 présente le résultat de la commande netcfg dans l’interface Onos. Le fichier renvoyé est celui que nous avons créé et intégré dans le contrôleur Onos via la commande suivante :
curl --user onos:rocks -X POST -H “Content-Type:application/json” http://192.168.231.133:8181/onos/v1/network/configuration/ -d @/tmp/network-cfg.json
L’adresse IP utilisée est celle de l’interface eth0 de la machine hôte du contrôleur. Et le fichier network-cfg.json est celui que nous avons créé.
Dans le fichier netcfg, pour l’application org.onosproject.router, le numéro openflow of:0000000000000002/4 correspond à l’identifiant de l’interface physique de l’emplacement de R1 connecté à l’interface eth1 de s2. Les adresses IP 10.1.1.253 et 10.1.2.253 correspondent aux routeurs eBGP (R2 et R3).
Lors de la définition des ports :
- of:0000000000000003/3 correspond à l’identifiant de l’emplacement physique de R3 connecté à l’interface eth3 de s3 ;
- 10.1.2.254/24 : correspond est l’adresse IP secondaire de l’interface f0/0 du routeur R1 ;
- CA:01:3D:74:00:00 : adresse MAC de l’interface f0/0 du routeur R1.
- of:0000000000000001/3 correspond à l’identifiant de l’emplacement physique de R2 connecté à l’interface eth2 de s1 ;
- 10.1.1.254/24 : correspond est l’adresse IP de l’interface f0/0 du routeur R1 ;
- CA:01:3D:74:00:00 : adresse MAC de l’interface f0/0 du routeur R1.
Figure 6 - Fichier netcfg.json intégré dans Onos
Pour résumer, l’intégration du fichier de configuration nous a permis de :
-
- au SDN-IP de connaitre où se situe le routeur BGPspeaker et les routeurs BGP externes ;
- au SDN-IP de répondre aux requêtes ARP ;
- mettre en place la connectivité pour le trafic BGP.
L’application SDN-IP du contrôleur Onos écoute par défaut pour les connexions entrantes BGP sur le port TCP 2000 alors que le port standard est 179. On active donc dans « Netfilter » un transfert de port entre 2000 et 179 avec la commande suivante :
iptables -t nat -A PREROUTING -ptcp --dport 179 -j REDIRECT --to-ports 2000
Après ces différents paramétrages, la machine hôte et le contrôleur Onos sont configurés. Les routeurs et les bridges et hôtes SDN peuvent communiquer avec le contrôleur. La Figure 7 montre l’interface GLI du contrôleur et la bonne détection des différents composants de la topologie.
Figure 7 - Topologie dans l'interface graphique du contrôleur Onos
La configuration de la machine virtuelle sur laquelle le logiciel GNS3 est utilisé consiste à configurer les routeurs de type c1700 mis en place dans la topologie. Les différentes connections mises en place correspondent à la Figure 3. Les interfaces de la machine virtuelle ont été configurées comme vu dans la partie 1.
La Figure 8 présente la topologie ainsi que les connexions entre les différents éléments mis en place avec le simulateur GNS3. Pour chacun des routeurs, nous avons configuré les interfaces conformément au plan d’adressage IP en Figure 2. Puis, nous avons mis en place le protocole BGP en définissant les différents systèmes autonomes.
Pour le routeur eBGP R3, nous avons artificiellement augmenter la valeur « TTL » lors de l’annonce de ses routes afin que le routeur iBGP ou Speaker BGP privilégie le routeur R2 pour son choix de routage. Seul R2 est connecté à internet. Il annonce donc une route par défaut dans BGP.
Figure 8 - Topologie mis en place avec GNS3
Le Tableau 1 montre le détail des configurations des routeurs R1, R2 et R3 utilisés lors de ce mini-projet.
|
R1#sh run Building configuration...
Current configuration : 1556 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! no aaa new-model no ip icmp rate-limit unreachable ! ip cef no ip domain lookup ! ip tcp synwait-time 5 ! interface FastEthernet0/0 ip address 10.1.2.254 255.255.255.0 secondary ip address 10.1.1.254 255.255.255.0 duplex half ! interface Ethernet1/0 ip address 10.213.166.94 255.255.255.0 duplex half ! router bgp 65501 no synchronization bgp router-id 10.213.166.94 bgp log-neighbor-changes neighbor 10.1.1.253 remote-as 65502 neighbor 10.1.2.253 remote-as 65503 neighbor 10.1.2.253 ebgp-multihop 255 neighbor 10.1.2.253 next-hop-self neighbor 10.213.166.68 remote-as 65501 no auto-summary ! no ip http server ! no cdp log mismatch duplex ! control-plane ! gatekeeper shutdown ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line vty 0 4 login ! ! end |
R2#sh run Building configuration...
Current configuration : 1620 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R2 ! boot-start-marker boot-end-marker ! no aaa new-model no ip icmp rate-limit unreachable ! ip cef no ip domain lookup ! ip tcp synwait-time 5 ! interface Loopback0 ip address 172.18.1.1 255.255.255.0 ! interface Loopback1 ip address 172.18.2.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.1.253 255.255.255.0 duplex half ! router bgp 65502 bgp router-id 10.1.1.253 bgp log-neighbor-changes neighbor 10.1.1.254 remote-as 65501 ! address-family ipv4 neighbor 10.1.1.254 activate no auto-summary no synchronization network 0.0.0.0 network 172.18.1.0 mask 255.255.255.0 network 172.18.2.0 mask 255.255.255.0 exit-address-family ! no ip http server ! no cdp log mismatch duplex ! control-plane ! gatekeeper shutdown ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line vty 0 4 login ! end |
R3#sh run Building configuration...
Current configuration : 1614 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R3 ! boot-start-marker boot-end-marker ! no aaa new-model no ip icmp rate-limit unreachable ! ip cef no ip domain lookup ! ip tcp synwait-time 5 ! interface Loopback0 ip address 172.19.1.1 255.255.255.0 ! interface Loopback1 ip address 172.19.2.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.2.253 255.255.255.0 duplex half ! router bgp 65503 no synchronization bgp router-id 10.1.2.253 bgp log-neighbor-changes network 0.0.0.0 network 172.19.1.0 mask 255.255.255.0 network 172.19.2.0 mask 255.255.255.0 neighbor 10.1.2.254 remote-as 65501 neighbor 10.1.2.254 ebgp-multihop 255 no auto-summary ! ip route 0.0.0.0 0.0.0.0 dhcp ! no ip http server ! no cdp log mismatch duplex ! control-plane ! gatekeeper shutdown ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line vty 0 4 login ! ! end |
Tableau 1 - Configuration des routeurs iBGP et eBGP
Suite aux configurations des différents équipements, la topologie choisie est désormais configurée et opérationnelle.
Nous vérifions tout d’abord la configuration BGP du contrôleur ONOS. La commande bgp-neighbors nous indique que le routeur R1 (dont l’adresse IP termine en 94) est membre de l’AS 65501. Ensuite, la commande bgp-speakers montre que le routeur R1 est un routeur iBGP de cet AS. La commande nous informe également que R1 a deux pairs eBGP (qui sont R2 et R3 dans notre topologie). Les résultats de ces deux commandes sont présentés par la Figure 9.
Figure 9 - Résultats des commandes bgp-neighbors et bgp-speakers sur le contrôleur ONOS
Ensuite, nous vérifions que la configuration BGP du routeur R1 est fonctionnelle. La Figure 10 montre le résultat de la commande show bgp summary. Il nous indique que R1 a bien trois connexions actives : celle avec le contrôleur ONOS en iBGP et les deux connexions à R2 et R3 (les adresses 10.1.1.253 et 10.1.2.253) en eBGP.
Figure 10 - Résultat de la commandes show bgp summary sur le routeur R1
À ce stade, nous avons donc réussi à configurer l’application SDN-IP afin qu’elle fournisse le mécanisme d’intégration entre BGP et ONOS. En externe, du point de vue BGP, le réseau SDN apparaît comme un système autonome unique (AS).
Nous vérifions ensuite que les routeurs R2 et R3, qui n’ont pas de lien direct entre eux dans notre topologie, peuvent tout de même communiquer. C’est bien le cas puisque nous constatons que chacun de ces deux routeurs répond aux requêtes ICMP envoyées l’un vers l’autre, comme montré par les Figure 11 et Figure 12.
Figure 11 - Résultat de la commande ping depuis le routeur R2 vers le routeur R3
Figure 12 – Résultat de la commande ping depuis le routeur R3 vers le routeur R2
Comme nous constatons que tous les routeurs communiquent bien entre eux, nous vérifions ensuite que le contrôleur ONOS récupère bien les informations depuis ces routeurs.
La commande bgp-routes, exécutée dans ONOS, nous montre que c’est bien le cas puisque nous constatons que désormais les routes vers les réseaux 172.18 et 172.19, réseaux des routeurs R2 et R3, font désormais partie de la configuration du contrôleur. La Figure 13 montre le résultat de cette commande.
Figure 13 – Résultat de la commande bgp-routes sur le contrôleur ONOS
De plus, la commande route, en Figure 14, démontre que la source de ces routes dans le plan de contrôle sont bien issues du contrôleur puisque c’est bien son adresse IP qui est indiquée comme source dans le résultat de la commande.
Figure 14 - Résultat de la commande routes sur le contrôleur ONOS
Pour finir, nous testons le ping d’un hôte du réseau SDN vers un serveur DNS de Google. Comme le montre la Figure 15, nous constatons que le ping fonctionne et que les paquets passent par notre routeur R2, le routeur de l’AS 65502 puisque c’est son adresse IP (10.1.1.253) qui est indiquée comme prochain saut.
Figure 15 – Résultat de la commande ping depuis l’hôte h1 vers le serveur Google 8.8.8.8
Afin de confirmer que le ping de notre hôte vers le serveur DNS de Google passe bien par notre réseau SDN, nous avons effectué une capture Wireshark du lien entre le routeur R2 et la machine virtuelle Mininet depuis GNS3.
La Figure 17 montre le résultat de cette capture Wireshark, capture représentée sur la Figure 16 :
Figure 16 – Lien capturé avec Wireshark depuis GNS3
Le résultat de la capture confirme que notre hôte ping bien le serveur Google en passant par notre réseau SDN.
Figure 17 – Résultat de la capture Wireshark
Nous avons créé deux systèmes autonomes externes afin de valider la prise en compte du réseau SDN comme un système autonome indépendant. Ces deux systèmes autonomes nous ont permis de suivre le cheminement de requêtes ICMP au sein du réseau SDN. Nous avons ainsi validé la bonne communication des routes entre le routeur Speaker BGP, le contrôleur Onos et les hôtes du réseau SDN. Cette étape était nécessaire avant de passer aux tests vers Internet.
Nos tests démontrent l’efficacité de notre architecture. Notre réseau se connecte à internet à l’aide du protocole BGP grâce à SDN-IP. Les hôtes du réseau SDN parviennent à « pinguer » les serveurs de Google.
Pour améliorer notre topologie, celle-ci pourrait contenir de la redondance. À savoir 2 contrôleurs dans un conteneur Docker, en mode distribué ; ou bien un second routeur speaker BGP palliant la défaillance de R1 ou encore augmenter le nombre de systèmes autonomes.
onosproject.org. (2020). ONOS - Wiki [Wiki]. Onos Project.
https://wiki.onosproject.org/display/ONOS/ONOS
xueguofeng. (2017, septembre 18). SDN in Action : Build a mini-lab environment and practice SDN-IP/ONOS with GNS3, Mininet and VMware【图文】_xueguofeng_51CTO博客 [Blog]. https://blog.51cto.com/u_8493144/1966215
Ajouter un commentaire
