 Hi everyone, thank you for coming. We present you Skydive and Realtime Analyzer Network Analyzer. I'm Nicolas Planel, Principal Engineer at Red Hat. Hi everyone, thanks for having us today. I'm Sylvain Auchin, Principal Software Engineer at Red Hat. I've been contributing to Winutron and Open Control. Yeah, okay. Okay, so about the agenda of this presentation, we will speak about why we started to develop Skydive, what is Skydive and a bit about the design and the implementation. And then we will finish by a little demonstration and we will of course answer to some questions. So, first of all, why we started Skydive? Skydive is a network, a Realtime Network Analyzer. It means to help people to troubleshoot networks and to help people to monitor their infrastructure. So, why we started Skydive? So, because the SDN is a complex thing and troubleshooting monitoring it is even more complex. It's quite usual to have some issues while looking for network issues like packet drops or some performance issues. It's a bit like finding or trying to find the OpenStack logo in this picture. It could be funny, but it could be also painful. So, and why we have this? Because finally we have a lot of SDN solutions on the market. Some of them are open source and some of them not. There is a different way of implementing the network or a different way of seeing what is a network. And we can have something like nested implementation or nested deployment, like having an OpenStack Neutron, for example with an OpenDelight controller or some others, with a container, SDN implementation within it, like Flannel. So, it's quite hard to understand exactly how to troubleshoot or how to find an issue. To do that you have to understand perfectly how the network is working, but also you have to understand perfectly how the SDN solution is implementing the network or is building the infrastructure. So, meaning the interfaces and so on. So, and if we look at a bit deeper inside why we have such issues, it's because we have different way or different point of view of the implementation finally for the SDN solution. We have different implementation in terms of management, meaning configuration, for example. We have the different point of view of what is a network, what is a subnet, what is a virtual router. This is the same thing for the control plane. We have a different way to implement the control plane part, meaning a different way to use protocols, like we know that we have a control plane implementation based on OpenFlow, XMPP, BGP, sometimes we have a mix of them. This is almost the same thing for the data plane. We have some solution based on VLAN, VXLAN, GRAM, PLS, and so on. And same thing for the data path finally. We have different way of implementing these kind of things. So, it's quite hard to understand exactly how to troubleshoot when we have an issue. We really need to understand perfectly how the SDN controller is finally implementing all this stuff, meaning the configuration, the control plane, and the data plane. So, when we decide to design this solution, Skydive, we like to do troubleshooting. So, we ask ourselves the question like where are the packets are dropping, or fragmented, or the problem occurred, like a chalk point on your network, so that you usually vary by things. And what's packets layer path, what's the packet layer path could be in the network at the point? We don't know, so you need to use some tools. You want to be easy to answer the screen of question. Like a number of flow on these links, what the tenants do on the network, if you have DDoS attacks, et cetera. So, today, yeah, we have Stoolbox to debug the OpenStack network, but it's like you're using IP routes over SVCTL. OTH should be associated, et cetera, et so forth. It's quite complicated, because it's like doing debugging, troubleshooting by hands, and it's quite painful when this happens on networks, especially when there's isolation, et cetera. So, what we need, we decide to select a few points, like a solution that flows centric. So, whatever packets arrive, we analyze the flow and keep it in storage. Easy to deploy, meaning not so much binaries to install and dependency, et cetera. We like to be SDN agnostic, because all the solution today is like there are a few, a lot as a Sivam present you for your SDN solution. We like to be non-intrusive or lightweight, as well to not kill your performances on the platform. And obviously, we like to open API and connect also current SDN. So, we decide to divide the solution in two parts, like the topology probe and the flow probes and the analyzer. Basically, the topologies like to record what events the viewport will be spawned somewhere on the network, like interfaces, bonding, retrieves, MTU, metadata. And the flow probes are here to get the packets. It could be sampling from different protocols. We would like to on-demand, on the network, at some point of the network, we would like to record and do some filtering to get back and overlay information on the packets. And the brain of the solution is the analyzer that we took in more details after, but it's like the mapping between the flow and the topology and to aggregate all the probe information and do post analysis. So the agent, topology of flow agents is based on the graph engine for the topology and populated by the binding, like on netlink, net-n-s, OSDB, et TH2, etc. The flow are based on the storage internally and the flow is some trick way by the flow table in memory that we do the mapping locally of the flow and topology on each agent. All the information will be further sent to the analyzer. The packet can be today supported by your S-flow so you analyze the packet from the S-flow or from pickups. So skydive analyzer, the brain, the aggregation of all the events are just all the points of the topology of the probes and do the analysis pipeline that we decide to do and store it in the database, like elasticsearch but everything is open IPI so we can change easily the storage or one components. So the skydive use case is usually what we want to do like we designed to reply to this solution is detection of command configuration events like for example on the security group you can detect that your packets are dropped by their use. It could be like detection of live network issue on the bad performances or DDoS as you can see you can have a king of attacks because you see a lot of flow on the turn. You can possibly have a capture traffic at any point of the topology of your open stack or your networking and you can have a postmortem analysis because we store all the information on the elasticsearch database so you can ask do some query on the database afterwards to maybe see what happens at 4 am on the network why my VM didn't boot correctly then didn't have the network setup correctly Detection of bad application as well you can detect the performances of the application by the RTT on treat time all the king of information that you can conclude by the analysis of the database so let jump Ok, I'm going to start the demo just few minutes c'est un demo c'est un demo récordé et on a déclaré un peu plus mais pour commencer il y a deux stacks un full stack qui signifie Neutron, Nova et etc et un compute et le second one c'est un compute et ok, let's start 1. afin d'avoir Skydive vous devez mettre deux lignes dans votre local.conf l'un est pour enlever la plug-in et l'autre est pour enlever le component de Skydive c'est-à-dire le analyzer on a le full stack le analyzer et le stack avec le compute qui est le compute, on a l'agent donc les deux ont commencé et maintenant quand votre stack est en train vous pouvez passer par ce Skydive WebUI et vous devez voir que Skydive a détecté toutes les interfaces déjà installées c'est-à-dire le cas d'un deployment Neutron le classique de BearTune et le BearX et le BearInt vous devez enlever les interfaces qui sont présentes vous devez avoir des détails sur la droite comme le MTU et le statut de l'interface donc maintenant on va créer des sources Neutron comme le Network et la subnet et quand la subnet est créée Neutron va créer les sources physiques les sources Neutron pour impliquer la subnet c'est-à-dire le DHCP et si on retourne vers le Skydive WebUI vous devez voir que les sources sont créées ou reflètes donc nous avons un espace et nous avons un interface qui est une interface internaute et nous avons depuis que nous avons évoqué le Neutron connecteur nous avons pu enlever la subnet ID et le Network ID et si oui, c'est tout donc maintenant on va créer un router et je pense qu'on va attaquer le router juste créé pour la subnet privée et quand on fait ceci Neutron va créer l'espoir associé à ce router et le Skydive détecte le changement donc nous avons un nouvel espace pour le router avec la interface classique connectée à l'intégration bridge déjà là et nous avons presque la même information que nous avons vu précédemment nous pouvons aussi voir que le VLAN est reporté le local VLAN du local OpenVay switch on peut vouloir avoir un local VLAN c'est-à-dire s'il faut s'occuper d'un nouvel espace et nous pouvons faire ça par recréditant l'url d'un espace et donc maintenant on va attaquer le VLAN et nous devons normalement utiliser une autre interface connectée à le bridge BRX et c'est ce que nous avons et probablement vous avez tous les détails sur la droite donc vous pouvez voir précisément avec une bonne précision ce qui a été implémenté par Neutron depuis que nous avons utilisé le deployment il n'y a pas de VLAN reporté dans la metadata pour cette interface donc maintenant nous allons mettre un VLAN sur le premier test-tac c'est un peu pire pour la habilité non, c'est un subnet nous allons créer un deuxième, il sera plus rapide que ceci oui, c'est créé donc en regardant la interface nous allons voir ce que Nova va faire et Neutron on dit que nous avons un tap nous avons le bridge le QBR nous avons les deux classiques connectés à la bridge un côté de la interface est reporté pour être un membre de management par Neutron juste parce que c'est seulement cette interface associée à Neutron parce que c'est la interface que Neutron a utilisé par Neutron et oui, nous avons le même VLAN pour le port, pour le port OVS donc maintenant avant de commencer le second VM, nous commençons une capture sur le bridge sur les deux sur les deux côtés, sur le Nord 1 et sur le Nord 2 et maintenant nous sommes prêts à commencer le second VM donc comme précédemment, nous pouvons voir ce qui s'occupe sur le côté Skydive la même chose, nous avons tous les détails sur la droite, pour le tap, pour le bridge pour le VATH et pour le port donc maintenant, nous allons utiliser le client Skydive pour vérifier que nous avons le probe pour la capture déjà donc nous sommes juste exportés deux variables pour le Craydon Should nous avons un connecteur à Keystone donc c'est la même Craydon Should que la Keystone est utilisée nous pouvons voir que nous avons seulement un binary pour le client pour les analyseurs et pour l'agent donc oui, je suis juste obtenu le résultat de la capture list et nous verrons que nous avons deux propres à commencer et maintenant, si nous allons voir que nous nous avons capturé quelques flows et nous pouvons voir que nous avons le propres, qui est où les flows ont été capturées et où les flows ont été générées et où les flows vont et nous avons toutes les métriques selon les laitres, par exemple pour Ethernet IPv4, UDP et chaque fois, nous pouvons voir où les packets ont été capturés donc nous avons finalement, nous pouvons voir que l'un d'autres packets ont été capturés du Node 2 et d'autres du Node 1 depuis que nous avons commencé deux propres et si nous retournons à la web UI, vous pouvez avoir la même information pointant votre mouse et vous avez commencé la capture donc c'est exactement la même information donc maintenant avant de générer des autres trafics nous allons commencer une autre capture mais pas sur le bridge OVS mais sur le bridge l'utilisation de Node 1 pour connecter le VM donc nous nous sommes connectés à un VM et nous sommes connectés à la deuxième capture et après quelques secondes la table de flow devrait avoir été updates sur le database de l'élastique et nous devrions trouver nos flows sur le database de l'élastique donc nous allons spécifiquement chercher des packets ICMP et nous pouvons voir que nous avons trois flows pour la capture pour les bridges OVS et une pour les captures pour le bridge Linux et comme précédemment nous pouvons voir que nous avons le propas donc où l'élastique a été capturé et si nous voulons avoir un autre point de vue nous pouvons aller à l'interface avec la conversation et nous pouvons voir comment l'élastique l'élastique et où les packets sont allés nous avons un connecteur pour deux dockers en commençant un container pour un container nous pouvons voir que nous avons le container détecté avec un petit pic pour le docker et depuis que c'est un connecteur nous avons des informations du docker comme l'idée de l'image et je pense que c'est pour le demo je vais parler un peu du roadmap c'est un roadmap très short nous voulons adresser beaucoup de choses et plus que ce que nous avons listé sur ce slide dans les prochains mois nous voulons ajouter plus de connecteurs plus de façon pour capturer la topologie et plus de façon pour filtrer la topologie maintenant il n'y a pas de mécanismes pour filtrer la topologie sur le côté adjoint mais nous voulons ajouter ceci pour avoir un impact sur les performances bien sûr nous voulons ajouter plus de protocoles sur le côté analysé et nous voulons l'improver un peu la sécurité nous avons maintenant un connecteur à Keystone et nous voulons avoir un mécanisme d'authentication entre les analyseurs et les agents mais nous voulons ajouter un mécanisme d'airbag pour avoir différents types de utilisateurs sur le slide et nous voulons ajouter un layer entre la communication surtout pour les packets entre les agents et les analyseurs et nous voulons donner un moyen d'anonymiser les IPs pour la sécurité et bien sûr je ne pouvais pas arrêter cette présentation sans dire que nous sommes un projet d'open source nous avons été apportés pour aucune contribution c'est peut-être un code de reportage ou quelque chose vous pouvez le faire et je pense que c'est tout si vous avez des questions il y a deux mics a-t-il des plans pour tests en demandant pour exemple des choses comme Ping, TraceRoute ou IPerf aujourd'hui nous n'avons pas de sélection, mais nous pouvons avoir des probés de flow sur la solution IPerf c'est juste des outils pour générer les connections pour les clients donc vous pouvez voir les packets comme TCP ou UDP session sur la table de flow et bien sûr nous verrons que dans la recherche vous voulez générer l'idée c'est de générer la trafication oui exactement j'aimerais générer la trafication pour mesurer la trafication donc vous voulez pouvoir générer la trafication et capture la trafication pour voir si il y a de l'attentif ou quelque chose ou peut-être avoir des statistiques avec IPerf c'est tout à fait oui ça fait du sens ça pourrait être un bon test j'ai une question sur le test de performance comme vous l'avez mentionné vous avez utilisé le P-CAP ou quelque chose en tant que je sais que P-CAP est vraiment une bonne performance en Linux et l'autre chose c'est la performance d'un plan data l'autre chose c'est la performance de contrôle j'ai vu les graphes, le UI est très parfait mais si si nous avons un millier de namespaces dans notre déploiement les nodes network et le namespace d'automne il y aura beaucoup d'autres nodes network qu'est-ce qu'il y a d'input sur le UI qu'est-ce que c'est la performance pour les performances nous avons deux types de props nous avons P-CAP pour les bonnes performances nous allons travailler en plus comme je l'ai dit nous allons travailler en plus pour capture la trafic seulement l'agent est en train de voir la trafication pas le analyzer, seulement la partie de la trafication seulement les flows sont pour les analyzers pas toute la trafication qu'est-ce que c'est la seconde partie nous avons une seconde façon de capture la trafication qui est le S-flow c'est un moyen simple pour rappeler la trafication donc c'est moins nous allons l'improver nous allons probablement ajouter un moyen pour filtrer ce qu'il y a sur le web UI je veux juste voir les interfaces pour cette trafication ou cette trafication avec cette trafication je pense que c'est une question relative qu'est-ce que vous avez testé cette trafication nous sommes très intéressés en utilisant la trafication c'est intéressant de voir quelle scale vous avez testé ceci la trafication c'est un projet ce n'est pas un projet aujourd'hui on n'a pas testé la trafication de la trafication de la trafication on préfère ajouter tous les features qu'on préfère et voir ce que la trafication va être après mais nous l'avons designé en pensant où peut-être la trafication par exemple, nous n'avons pas envoyé les paquets de l'agence directement c'est comme si nous l'avons analysé comme si nous avions des tables et évidemment la trafication est envoyée à l'analyseur donc beaucoup de paquets c'était la question merci beaucoup