Cours de base SDN pour les programmeurs 3: Essayez de créer un hub de commutation avec Ryu

Construction de l'environnement Ryu

L'une des forces de Ryu est que le développeur, NTT Laboratories, fournit une riche documentation. Il n'y a pas beaucoup de documents organisés pour apprendre le SDN dans un environnement japonais, et même s'ils le sont, les informations sont souvent obsolètes. Le Wiki of Ryu a été traduit en japonais, et le même contenu a été converti en livre électronique. La version pdf est ouverte au public gratuitement, elle est donc facile à apprendre. C'est aussi le sort d'un framework qui fonctionne sous Linux, mais lorsque vous essayez de préparer l'environnement d'autres contrôleurs OpenFlow, l'installation ne se poursuit pas en raison de problèmes dus à une incompatibilité de version et des dépendances, ou le code source ne fonctionne pas. J'ai eu du mal. Cependant, Ryu a préparé un fichier image qui fonctionne sur VirutalBox et a terminé la construction de l'environnement de Ryu. CA aide. Téléchargez-le immédiatement depuis HP officiel.

Lors de la lecture de l'anglais sur le site officiel lors du téléchargement, la prononciation de Ryu semble être "Ryo". Cependant, le sens semble provenir du «style» japonais (= flow). Une fois téléchargé, importez-le dans Virutal Box. Si vous exécutez comme indiqué sur la page here, l'importation est terminée. L'ID utilisateur et le mot de passe sont répertoriés au début du didacticiel officiel (https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial).

Créez un hub de commutation avec Ryu

L'environnement est prêt. De là, nous étudierons en utilisant le "Ryu SDN Framework" préparé par le fonctionnaire. Commençons par créer un hub de commutation pour vérifier le fonctionnement de Ryu. J'ai expliqué à quoi ressemble un hub de commutation (commutateur) la dernière fois, mais je vais à nouveau expliquer ses "spécifications".

スイッチングハブ説明1.png À la mise sous tension, rien n'est enregistré dans la table d'adresses MAC du concentrateur de commutation. Par conséquent, si le commutateur reçoit des trames du premier hôte connecté, il enverra des trames à tous les ports connectés. (L'hôte récepteur vérifie "l'adresse MAC de destination" du paquet envoyé et l'ignore si elle est différente de sa propre adresse MAC.) En même temps, "adresse MAC source (= hôte)" est ajoutée à la table d'adresses MAC. Et "le numéro de port auquel l'hôte avec cette adresse MAC est connecté" est enregistré.

スイッチングハブ説明2.png A l'avenir, si une trame dont l'adresse MAC de destination est enregistrée dans la table d'adresses MAC circule vers le concentrateur de commutation, la trame sera acheminée uniquement vers le port écrit dans la table d'adresses MAC.

Soit dit en passant, avant la diffusion des hubs de commutation, les hubs appelés "hubs répéteurs" qui transmettent les données reçues d'un hôte à tous les autres hôtes constituaient le courant dominant. L'envoi à tous les hôtes a causé des problèmes tels qu'une augmentation du nombre de paquets circulant sur le réseau, une augmentation des collisions et une diminution de l'efficacité d'utilisation du réseau. Dans le passé, les hubs de commutation étaient chers, alors on disait qu'il fut un temps où ils étaient des hubs de répéteurs à la maison et des hubs de commutation dans les bureaux, mais maintenant ils peuvent être achetés pour 1000 yens. Les moyeux de répéteur appartiennent au passé. Pour rappel, ce hub répéteur était également connu sous le nom de «hub stupide».

S'il est implémenté avec cette fonction de base d'OpenFlow, il semble possible de programmer le fonctionnement du hub de commutation.

Le code source du contrôleur OpenFlow qui implémente le hub de commutation se trouve sous "/ home / ryu / ryu / ryu / app" dans l'environnement de développement préparé précédemment. Vérifions-le (le code source est également posté sur Web).

Initialisation de la variable de table d'adresses MAC mac_to_port dans init. Et la ligne 32 est importante pour comprendre l'application Ryu.

simple_switch_13.py(32,Ligne 33)


    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):

La 32e ligne est le décorateur et la 33e ligne est le gestionnaire d'événements. "Decorator" est un élément que j'ai omis dans le cours de base sur Python que j'ai écrit dans le passé. La page suivante peut être utile.

Dans Ryu, lorsqu'un message OpenFlow est reçu, l'événement correspondant au message se produit. L'application Ryu implémente un gestionnaire d'événements pour le message que vous souhaitez recevoir. Vous pouvez déclarer un gestionnaire d'événements en écrivant le décorateur set_ev_cls. Le premier argument de set_ev_cls donne l'événement que l'application Ryu veut recevoir. Le deuxième argument donne un ou une liste d'états entre le commutateur OpenFlow et le contrôleur OpenFlow.

Statut La description
ryu.controller.handler.HANDSHAKE_DISPATCHER Échange de messages BONJOUR
ryu.controller.handler.CONFIG_DISPATCHER Envoyer une demande de fonctionnalités
ryu.controller.handler.MAIN_DISPATCHER État normal
ryu.controller.handler.DEAD_DISPATCHER Coupure

Le premier argument de set_ev_cls est EventOFP ** SwitchFeatures **. Le nom de la classe d'événements est ryu.controller.ofp_event.EventOFP + ** Nom du message OpenFlow **. (Par exemple, dans le cas d'un message Packet In, ce sera EventOFPPacketIn.) Dans ce cas, nous coderons le switch_features_handler en tant qu'événement lorsque le commutateur établit une connexion. Je pense que set_ev_cls est déjà implémenté dans le framework Ryu, dans lequel certaines étapes telles que la poignée de main requise pour que le commutateur et le contrôleur OpenFlow communiquent avec le protocole OpenFlow le gèrent. Je vais. Par conséquent, vous pouvez vous concentrer uniquement sur le comportement spécifique à l'application lors de la réception d'un événement.

simple_switch_13.py(switch_features_méthode du gestionnaire)


    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

La bibliothèque ofproto est une bibliothèque pour créer et analyser des messages du protocole OpenFlow. Ofproto_parser est-il un analyseur de messages par nom?

Dans le concentrateur de commutation, aucun événement n'est décrit lorsque le commutateur établit une connexion. Table-miss Traité comme un événement pour obtenir le timing pour ajouter une entrée de flux. Une entrée de flux Table-miss est une entrée qui a la priorité la plus basse (0) et correspond à tous les paquets. Correspond à la valeur par défaut dans l'instruction case.

simple_switch_13.py(Lignes 45-48)


        #Correspond à toutes les conditions de paquet
        match = parser.OFPMatch() 
        #Envoyez le paquet entier au contrôleur sans mise en mémoire tampon
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)] 
        #Ajouter une entrée de flux à la table de flux avec la priorité 0
        self.add_flow(datapath, 0, match, actions)

La condition (correspondance) est vide, c'est-à-dire toutes les conditions. L'action de transfert vers le port du contrôleur spécifie le contrôleur comme destination de sortie, et OFPCML_NO_BUFFER est spécifié pour que max_len envoie le paquet entier au contrôleur.

Remarque:Le début du paquet sur le contrôleur(En-tête Ethernet)Il est préférable d'envoyer uniquement et de tamponner le reste dans le commutateur pour plus d'efficacité, mais pour éviter le bogue Open vSwitch, envoyons le paquet entier ici. Ce bogue est Open vSwitch 2.1.Fixé avec 0(De Ryu officiel)

Dans cette description, en spécifiant l'action de sortie vers le port du contrôleur OpenFlow pour traiter cette entrée, Packet-In sera émis si le paquet reçu ne correspond pas à toutes les entrées de flux normales. .. La raison pour laquelle une telle description est nécessaire est que le commutateur OpenFlow supprime ou supprime les paquets qui ne correspondent pas à l'entrée de flux par défaut.

Ensuite, créez un gestionnaire pour l'événement Packet In afin d'accepter les paquets entrants provenant de destinations inconnues.

simple_switch_13.py(Lignes 61-62)


    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):

Le premier argument de set_ev_cls est EventOFP ** PacketIn **. Le deuxième argument est également MAIN_DISPATCHER, ce qui signifie l'état normal.

simple_switch_13.py(Lignes 67-81)


    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        in_port = msg.match['in_port'] #Obtenir le numéro de port

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocols(ethernet.ethernet)[0] #Obtenir un en-tête Ethernet

        dst = eth.dst #Adresse MAC de destination
        src = eth.src #Adresse MAC source

        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

        self.mac_to_port[dpid][src] = in_port

Le tableau mac_to_port définit le numéro de port correspondant à «l'adresse MAC source» du chemin de données «ID (OpenFlow switch identification ID)». Le programme fait la même chose que l'enregistrement de la table d'adresses MAC décrite au début de ce chapitre.

simple_switch_13.py(Lignes 82-93)



        if dst in self.mac_to_port[dpid]:
            out_port = self.mac_to_port[dpid][dst]
        else:
            out_port = ofproto.OFPP_FLOOD

        actions = [parser.OFPActionOutput(out_port)]

        #Si l'adresse MAC de destination est trouvée
        if out_port != ofproto.OFPP_FLOOD:
            match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
            #Table-miss Set 1 avec une priorité plus élevée que l'entrée de flux
            self.add_flow(datapath, 1, match, actions)

Si l '"adresse MAC de destination" correspondant à l'ID de chemin de données de la baie mac_to_port existe, spécifiez ce numéro de port, et s'il n'existe pas, envoyez une trame à tous les ports. Le processus est spécifié comme "Sortie (port)".

Si l'adresse MAC de destination est trouvée, ajoutez une entrée à la table de flux du commutateur OpenFlow. Contrairement à l'entrée de flux Table-miss, cette fois, OFPMatch spécifie le port de réception (in_port) et l'adresse MAC de destination (eth_dst) comme conditions.

La méthode add_flow qui ajoute une entrée de flux à la table de flux est: Indique au commutateur OpenFlow de mettre à jour la table de flux avec la méthode parser.OFPFlowMod.

simple_switch_13.py(Lignes 50-59)


    def add_flow(self, datapath, priority, match, actions):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             actions)]

        mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
                                match=match, instructions=inst)
        datapath.send_msg(mod)

simple_switch_13.py(Lignes 95-101)


        data = None
        if msg.buffer_id == ofproto.OFP_NO_BUFFER:
            data = msg.data

        out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                  in_port=in_port, actions=actions, data=data)
        datapath.send_msg(out)

Enfin, émettez un message PacketOut pour transférer le paquet reçu.

Exécutez l'application Ryu

Utilisez le contrôleur OpenFlow que vous avez créé pour transformer votre commutateur OpenFlow en un hub de commutation. Mais cela nécessite un commutateur et un hôte OpenFlow. Pas dans la maison d'une personne normale. (Il semble que certaines personnes ont un rack de serveur à la maison, mais w) Celui qui est préparé pour cela est "Mininet". Mininet a une fonction pour configurer un réseau virtuel à l'aide d'OpenFlow. Mininet est également installé sur la VM officiellement préparée.

Avant de lancer Mininet, essayez de taper ifconfig sur la console. ifconfig est une commande pour vérifier l'adresse IP, le masque de réseau, etc. assignés à l'interface réseau de ce PC (bien qu'il s'agisse en fait d'une machine virtuelle). Vous verrez une interface réseau pour ce PC appelée "eth0" et une interface spéciale appelée "local loopback" appelée "lo". Après cela, avec la commande Mininet (mn) écrite ci-dessous, une topologie de réseau dans laquelle un total de trois hôtes sont connectés à chaque port d'un commutateur (sous quelle forme un ordinateur est connecté sur le réseau de communication) Peut être émulé.

ryu@ryu-vm:~$ sudo mn --topo single,3 --mac --switch ovsk --controller remote -x
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6633
*** Adding hosts:
h1 h2 h3
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1) (h3, s1)
*** Configuring hosts
h1 h2 h3
Error starting terms: Cannot connect to display ←
*** Starting controller
*** Starting 1 switches
s1
*** Starting CLI:
mininet>

Mininetの構成.png

Le manuel dit que "5 xterms démarreront sur votre ordinateur de bureau" mais xterm ne démarrera pas. Je reçois un message d'erreur.

Error starting terms: Cannot connect to display

Je n'ai pas pu résoudre ce problème (veuillez aider quelqu'un >>), alors j'ai honnêtement décidé de lancer et d'exploiter des consoles séparées.

Connectez-vous à ubuntu avec ssh Veuillez consulter ici pour savoir comment vous connecter à la VM sur VirtualBox avec Teraterm.

Depuis une autre console, rendez le pont créé par Mininet compatible avec OpenFlow 1.3.

sudo ovs-vsctl set Bridge s1 protocols=OpenFlow13

Exécutez ensuite la commande suivante.

ryu-manager --verbose ryu.app.simple_switch_13

Il se connecte à OVS comme indiqué ci-dessous, une prise de contact est effectuée, une entrée de flux Table-miss est ajoutée et il attend le paquet entrant.

connected socket:<eventlet.greenio.GreenSocket object at 0x26aac50> address:('127.0.0.1', 42601)
hello ev <ryu.controller.ofp_event.EventOFPHello object at 0x26aa750>
move onto config mode
EVENT ofp_event->SimpleSwitch13 EventOFPSwitchFeatures
switch features ev version: 0x4 msg_type 0x6 xid 0x50c38af1 OFPSwitchFeatures(auxiliary_id=0,capabilities=71,datapath_id=1,n_buffers=256,n_tables=254)
move onto main mode

Lancez encore une autre console et exécutez la commande suivante: Cette commande est une commande pour vider la table de flux du commutateur OpenFlow s1.

sudo ovs-ofctl -O openflow13 dump-flows s1

OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=287.127s, table=0, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535

La table de flux définie dans switch_features_handler (priorité 0, inconditionnel, action CONTROLLER, transmettre la taille des données 65535 (0xffff = OFPCML_NO_BUFFER)) est spécifiée.

Confirmation du fonctionnement du hub de commutation

C'est finalement la confirmation du fonctionnement. Ping de l'hôte 1 connecté à l'hôte 2. Même les programmeurs connaissent le ping. Vous l'utilisez pour vérifier la communication avec une autre machine sur le réseau ou une URL sur Internet. Tout d'abord, examinons brièvement ce que fait le ping. Si vous ne le savez pas, vous ne saurez pas ce que devrait être la table de flux ou si le contenu du vidage est correct. Lors du ping de l'hôte 1 à l'hôte 2, le traitement suivant est effectué en interne.

paquet La description
1 ARP request ARP est un protocole qui obtient une adresse MAC à partir d'une adresse IP. L'hôte 1 demande à tous les hôtes sur le même réseau, "Je veux communiquer avec l'hôte avec cette adresse IP, veuillez donc me dire l'adresse MAC de la machine avec l'adresse IP." La raison de la demande à tous les hôtes est que l'hôte 1 ne sait pas à quel port l'hôte 2 est connecté.
2 ARP reply L'hôte avec la même adresse IP qui a reçu la demande ARP répond "Je suis ici, l'adresse MAC est celle-ci" à l'hôte 1.
3 ICMP echo request Puisque 2 permet à l'hôte 1 de connaître l'adresse MAC de l'hôte 2, il envoie un paquet ICMP à l'hôte 2.
4 ICMP echo reply L'hôte 2 connaît l'adresse MAC de l'hôte 1 et renvoie donc un paquet ICMP à l'hôte 1.

L'échange entre 3 et 4 est appelé ping. Les hôtes et les serveurs avec des adresses IP ont une table appelée la table ARP à l'intérieur. Il est similaire à la table d'adresses MAC, mais la table d'adresses MAC a une combinaison «d'adresse MAC et de numéro de port», tandis que la table d'adresses ARP a une combinaison «d'adresse MAC et d'adresse IP». L'hôte 1 a besoin de connaître l'existence de l'hôte 2 pour traiter 3 ou envoyer un paquet ICMP pour confirmation de communication. Normalement, 1 et 2 sont exécutés lorsque l'hôte est connecté au réseau et la table ARP est créée, donc lorsque la commande ping est lancée depuis la console, 3 et 4 sont exécutées immédiatement.

Une fois que vous connaissez le comportement du ping ** d'une manière ou d'une autre **, ** lancez trois consoles ** et exécutez la commande tcpdump afin de voir quels paquets ont été reçus de l'hôte 1 à l'hôte 3. Je vais. Veuillez noter que le nom d'hôte est également différent de la commande dans le PDF.

Console hôte 1

ryu@ryu-vm:~$ sudo tcpdump -en -i s1-eth1
tcpdump: WARNING: s1-eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

Console hôte 2

ryu@ryu-vm:~$ sudo tcpdump -en -i s1-eth2
tcpdump: WARNING: s1-eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

Console hôte 3

tcpdump: WARNING: s1-eth3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth3, link-type EN10MB (Ethernet), capture size 65535 bytes

Maintenant, sur la console où vous avez exécuté la commande mn pour la première fois, exécutez la commande suivante pour envoyer un ping à l'hôte 1 vers l'hôte 2.

--- 10.0.0.2 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 89.463/89.463/89.463/0.000 ms

Un paquet a été transmis sans perte. Lancez une nouvelle console et entrez à nouveau la commande pour vider la table de flux pour le commutateur OpenFlow s1.

ryu@ryu-vm:~$ sudo  ovs-ofctl -O openflow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=110.621s, table=0, n_packets=2, n_bytes=140, priority=1,in_port=2,dl_dst=00:00:00:00:00:01 actions=output:1
 cookie=0x0, duration=110.58s, table=0, n_packets=1, n_bytes=42, priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:2
 cookie=0x0, duration=2752.545s, table=0, n_packets=3, n_bytes=182, priority=0 actions=CONTROLLER:65535

En plus de l'entrée de flux Table-miss, deux entrées de flux ont été ajoutées.

(1). Port entrant (in_port): 2, Adresse MAC de destination (dl_dst): Hôte 1 → Actions: Sortie vers le port 1 (2). Port entrant (in_port): 1, adresse MAC de destination (dl_dst): Hôte 2 → Actions: Sortie vers le port 2

L'entrée dans (1) est référencée deux fois (n_packets) et l'entrée dans (2) est référencée une fois. Puisque (1) est une communication entre l'hôte 2 et l'hôte 1, la réponse ARP (2 dans le tableau précédent) et la réponse d'écho ICMP (4 dans le tableau précédent) sont mises en correspondance. (2) est la communication de l'hôte 1 à l'hôte 2 par la demande d'écho ICMP (3 dans le tableau ci-dessus). La requête ARP (1 dans le tableau ci-dessus) a été envoyée à tous les hôtes et n'est pas comptée.

Le contenu de tcpdump a été mis à jour, donc vérifions-le.

Console hôte 1

22:37:49.681949 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28
22:37:49.727635 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 28
22:37:49.727666 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1907, seq 1, length 64
22:37:49.771373 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 1907, seq 1, length 64
22:37:54.776004 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, length 28
22:37:54.776045 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, length 28

La première ligne est une requête ARP qui recherche l'hôte 2 à partir de l'hôte 1 lui-même. La deuxième ligne est la réponse ARP de l'hôte 2. La troisième ligne est une demande d'écho ICMP de l'hôte 1 lui-même à l'hôte 2. La quatrième ligne est la réponse d'écho ICMP de l'hôte 2. Les 5ème et 6ème lignes sont comme ARP Request and Reply pour mettre à jour la table ARP.

Console hôte 2

22:37:49.684703 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28
22:37:49.684727 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 28
22:37:49.771102 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1907, seq 1, length 64
22:37:49.771171 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 1907, seq 1, length 64
22:37:54.774704 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, length 28
22:37:54.777621 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, length 28

La première ligne reçoit la demande ARP envoyée par l'hôte 1 partout. La deuxième ligne est une réponse ARP de l'hôte 2 lui-même. La troisième ligne est la demande d'écho ICMP reçue de l'hôte 1. La quatrième ligne est une réponse d'écho ICMP de l'hôte 2 lui-même. Les 5ème et 6ème lignes sont comme ARP Request and Reply pour mettre à jour la table ARP.

Console hôte 3

22:37:49.684694 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28

L'hôte 3 ne reçoit que la demande ARP que l'hôte 1 a initialement envoyée à l'ensemble. Il ne s'adresse pas à lui-même, donc il ne répond pas.

Résumé

L'a fait! J'ai pu implémenter un hub de commutation en utilisant OpenFlow ...! !! Jusqu'à présent, j'ai écrit jusqu'à présent, mais dans OpenFlow, un port de sortie logique appelé port NORMAL est spécifié en option, et si NORMAL est spécifié pour le port de sortie, le paquet est traité en utilisant la fonction d'origine du hub de commutation. Ce sera comme. En d'autres termes, vous pouvez le faire agir comme un concentrateur de commutation simplement en lui demandant de sortir tous les paquets sur le port NORMAL. Il n'est pas nécessaire de se soucier de mettre en œuvre un hub de commutation. Cela dit, il suffisait de comprendre certaines des choses que les frameworks SDN et Ryu peuvent faire. La création de ce hub de commutation est en ligne avec le contenu du livre électronique ou du Wiki préparé par le responsable Ryu. À l'avenir, la méthode de mise en œuvre du pare-feu et du routeur mentionnée ci-dessus sera également décrite, et non seulement l'émulation de l'équipement physique, mais également les avantages uniques du SDN seront introduits. Par exemple, Ryu a une fonction de liaison REST, et des tableaux de flux peuvent être ajoutés / mis à jour à partir d'un programme externe sans passer par un contrôleur.

On a dit que le SDN élimine le besoin d'ingénieurs réseau, mais c'est une révélation. J'entends aussi que la programmation fait partie des matières de l'enseignement obligatoire. Dans ce cas, le codage deviendra une formation générale et le moment viendra peut-être où des personnes connaissant la technologie des réseaux configureront, contrôleront et géreront naturellement les réseaux avec leur propre technologie de programmation. Quand j'étais programmeur, j'entendais souvent le terme «ingénieur full stack». [Glossaire informatique](http://e-words.jp/w/%E3%83%95%E3%83%AB%E3%82%B9%E3%82%BF%E3%83%83%E3 % 82% AF% E3% 82% A8% E3% 83% B3% E3% 82% B8% E3% 83% 8B% E3% 82% A2.html) dit ce qui suit.

Par exemple, dans le cas de la création et de l'exploitation de sites Web et de services Web, de l'acquisition et de la configuration de serveurs et de réseaux, de la création et de la programmation d'environnements logiciels côté serveur, de la conception de bases de données, de la conception Web, de la programmation côté client et du HTML./Des ingénieurs qui ont des connaissances et de l'expérience dans tous les domaines connexes tels que le codage CSS et peuvent créer des sites, lancer des services et fonctionner seuls.

Je ne m'en suis pas rendu compte quand je ne connaissais que le monde des logiciels, mais le véritable ingénieur full-stack est peut-être un ingénieur tridimensionnel qui connaît la couche physique de la couche OSI 7, la couche application et l'avant et l'arrière de la couche application. Absent···. Étrange. Les ordinateurs et la technologie informatique sont censés nous faciliter la tâche, mais il y a de plus en plus de choses dont nous devons nous souvenir et savoir.

Les références

Présentation de présentations, d'articles, de pages Web, etc. que j'ai utilisés comme référence lors de la rédaction de cet article.

papier

Directives SDN NTT Communications Réseau de nouvelle génération considéré par le plus grand opérateur NTT. L'avenir est présenté dans lequel le SDN permet aux administrateurs de sous-traitants réseau de modifier (dans une certaine mesure) la configuration du réseau à leur guise.

présentation

Nouvelle technologie de contrôle de réseau OpenFlow et comment l'utiliser Ce sont des informations anciennes, mais elles expliquent le concept de SDN et d'OpenFLow d'une manière facile à comprendre avec de nombreux chiffres. NEC est une entreprise qui a participé aux activités du SDN depuis le début.

Expérience Openflow En plus du fonctionnement d'OpenFlow, nous menons une expérience d'interconnexion de plusieurs commutateurs.

Problèmes opérationnels et avantages du SDN du point de vue du développement de dispositifs SDN tels que OpenFlow Switch Le SDN, qui présente de nombreux avantages, présente également des défis. Mon article ne l'a pas mentionné, alors veuillez lire cette diapositive.

Dernières tendances SDN et exemples d'application Il existe des références à des protocoles SDN autres qu'OpenFlow et à des frameworks autres que Ryu. Quand je lis cette diapositive, il semble que le texte officiel de Ryu, bien sûr, n'explique pas toutes les fonctionnalités de Ryu.

[Premier séminaire pratique parrainé par l'Open Laboratory d'Okinawa (RYU, vSwitch)](https://www.okinawaopenlabs.org/wp/wp-content/uploads/%E7%AC%AC1%E5%9B%9E%E3 % 83% 8F% E3% 83% B3% E3% 82% BA% E3% 82% AA% E3% 83% B3% E3% 82% BB% E3% 83% 9F% E3% 83% 8A% E3% 83 % BC.pdf) Séminaire pratique organisé par NTT Communications, le développeur de Ryu, en 2014 à Okinawa. Je vous envie.

SDN Study Group-Current and Future of SDN Technology- Bien que l'explication soit omise cette fois, il existe un "type saut par saut" et un "type de recouvrement" dans SDN. La méthode simple est de type saut par saut, mais les entreprises font également la promotion d'un type de superposition qui peut utiliser l'infrastructure existante. Cette diapositive décrit l'état actuel du SDN du point de vue de l'entreprise.

Articles sur Internet

SDN (1/5) que vous pouvez absolument comprendre en 5 minutes Je peux le comprendre en 5 minutes (rires)

Idéal et réalité du SDN: réflexion sur l'utilisation pratique du SDN dans le fonctionnement du réseau Suite de l'article ci-dessus, il explique les idéaux et la réalité du SDN. Le niveau est plus élevé que les autres articles.

Destiné aux ingénieurs réseau - Qu'est-ce que le SDN? Un article simple explique SDN. Nous vous encourageons à lire toute la série.

Logiciel Ryu SDN Framework-Open Source SDN Platform Cela semble être une interview du développeur Ryu dans un magazine appelé NTT Technology Journal.

Participation à un séminaire sur le contrôleur OpenFlow Ryu Impressions du séminaire de Ryu. Il n'y a pas tellement de sessions d'étude SDN, et il y a encore moins d'informations quand il s'agit de Ryu (mais Ryu étudie par rapport aux autres frameworks OpenFlow en termes de qualité et de quantité de documents japonais et de facilité de préparation d'un environnement de développement. Je pense que c'est facile). Je souhaite également participer à la session d'étude.

Tech-Circle #19 SDN_Trema Hands-on J'ai participé l'autre jour. Ryu n'a pas été mentionné, mais c'était intéressant, comme le SDN utilisé pour les entreprises et le SDDC (Software Defined Datacenter, c'est-à-dire l'idée intrépide de virtualiser l'ensemble du centre de données).

Cours de base sur le SDN pour les programmeurs 1: Qu'est-ce que le SDN Cours de base SDN pour programmeurs 2: contrôleurs et commutateurs OpenFlow Cours de base SDN pour les programmeurs 3: essayez de créer un hub de commutation avec Ryu

Recommended Posts

Cours de base SDN pour les programmeurs 3: Essayez de créer un hub de commutation avec Ryu
Essayez TensorFlow RNN avec un modèle de base
Essayez de créer un site Web simple avec responder et sqlite3
(Pour les débutants) Essayez de créer une API Web simple avec Django
Essayez de programmer avec un shell!
L'histoire de la création d'un pilote standard pour db avec python.