 OK. So hi, everybody. My name is Julien Fortin. I'm a French software engineer, and I work for Cumulus Networks. I work on, if I'm down to, a Python project that we have streamed last fall. And I'm the new Debian maintainer of this project. So the goal of this talk is to introduce you to the project if you don't already know about it. And to give you an update on the progress we've made since the last release in October. So the outline of the talk. So I'm going to give you a little bit of a background of who we are, and that sets the context of why we developed if up down to. I'm going to tell you what's the problem with if up down and give you a general overview of the capability of if up down to, what we added since last October, a few words about where we're going, and how to contribute. And I will answer some questions. So a little bit more about me. I'm not a networking engineer. I'm not a networking specialist. I'm a software engineer interested into operating system development. I did my undergrad internship at Cumulus Networks in 2014. And after that, I took a few networking classes. Now I was hired four months ago by Cumulus Networks, and I joined the if up down to team. And I will graduate sometimes these four. So the ones who already know about if up down to may know Rupa, she is the author of if up down to. So the project started in late 2014. And the first commit was about 2,000 lines of Python. And as of yesterday night, we had 618 commits for about 18,000 lines of Python. So what is Cumulus? Cumulus is a software company. We designed Cumulus Linux, a Debian-based Linux distribution for networking switches. Our latest version, Cumulus 3.0, is based on Debian Jessie. And so our philosophy, we really want to let you manage your networking switches just like you do with your own servers. You can write your own app or install your own app just like you would do in Debian or use standard Linux tools. Cumulus is also contributing back to the community. We upstreamed a lot of patches. Kernel patches mostly related to networking. So we try, for example, to add more support to a netlink when it comes to configuring network interfaces. Or we also contribute to some user space packages like STP. So you may know about if-up-down. So it's the default network manager for Debian. You can configure your network in a static file, ATC network interfaces. And the networking faces are represented by iFace sections. So what is wrong about it? So first, it's written in C. So it's really hard to maintain or to extend. Second, if-up-down doesn't understand interface dependencies, the complexity increase with a large number of interfaces. If you have a large number of interfaces in your file, you have to keep it order so that the dependencies are respected. And so let's say you have 52 switch ports, 2,000 VLANs, 100,000 bridges, and a few more 1,000 VXLANs. You can do it by hand. I mean, good luck, yeah. Good luck doing it by hand. And if-up-down doesn't have support for incremental changes on life configuration, you have to bring down the interface, make a modification, and bring it up again. There's also a lack of tools to query and validate the running configuration. So it's super hard to troubleshoot your network. So our solution is a backward-compatible re-implementation of if-up-down in Python. With a pluggable architecture with Python add-on modules, you can add your own support or extend the if-up-down to-behavior to support your own protocol. We also generate a graph of all the interfaces to resolve dependencies and handle the relationship between them. We also added a few capability to add support to incremental changes and query life configurations. I'm going to give you examples in the following slides. So how does it works? We have a core containing the parser, a graph generator, and some other things. Then the interfaces are scheduled in order. And the add-on takes care of the configuration of each specific attributes. In this case, you can see a small example with a bridge. On the right, you see the iface object inside if-up-down too. And then you see which add-ons takes care of what. And so each module is able to tell what are their dependencies. And then we build this graph of all the interfaces, and we schedule them in order. So here you have an example of a small topology with a bridge on top with three bridge ports, so three VLANs. So we sort this graph, and it gives us this list of interfaces to schedule in order. So we also have built-in device supports. So I have done two implicitly recognize VLAN and physical interfaces that appear as dependents. And so we do the minimal requirements to bring them up, even if you don't specify them in your configuration. So here, for example, in your interface file, there's no need to specify SWP 1, 2, 3, 4. Or even the VLANs. This is another example. I hope you can see it. Now showing the capability that we added to IF query. So we added an option to let you query the dependencies of a specific interface. And you can see the results in plain text, JSON format, or dot format. IF query is now able to check the running state of the interfaces and to tell you if everything is OK or not. So in this example, I wrote the configuration from the previous side into the ETC network interfaces file. And then I executed IF reload, which is a new command that we added. I'm going to talk about it a little bit after. And then you can use IF query dash dash check to validate, to check the validation of your applied state against the user configuration. Yeah, you can see here that there's some failures because of the address attribute. Yeah, just don't ask me why. Another practical use case of the new IF query is the running option. So you can create a live topology using, for example, IP route 2. So here I create a bound and a bridge. And then you can use IF query to see the live configuration of these interfaces. And then you can cut the result of IF query to your ETC network file. So I have done two works on already up or down interfaces. We query the running state of the interface and we only apply the difference between the user configuration and the running configuration. So let's say you have a bridge with two ports and you want to add a new port. You can just run EF up on your bridge and it will add it automatically. So here is the example. So at the beginning I have a bridge. If I run IF query check on the bridge, it will tell me that it failed because the bridge is not up yet. Then I do IF up, then check again, everything passes. Then I remove one of the bridge ports with IP route 2 and run check again so it fails. It tells me what is wrong. But if I do IF up again, it will apply the delta between the user configuration and the running configuration and add the missing bridge ports. Can you remove stuff as well? Yes, you can remove, add, modify, whatever you want. So IF reload is a new command that we introduced. So basically it runs IF down on all the interfaces you removed from your configuration and it will run IF up on the interfaces that you changed from your configuration. So it's pretty convenient rather than using service networking restart for example. We also added support for JSON format for input and output commands. So you can provide a configuration written in JSON. So this is super good for automation and orchestration tools. Templating. Or IF I have done two commands, support micro-style templates. So the goal was to reduce the size of the configuration file which is easily can get to several thousand lines. So here's a quick example how to create 100 bridges in a few lines. So here is the list of the various add-ons that we currently have within IF updown 2 package. So what's new since October 2015? So we've added support for VLAN filtering in IF updown 2. Two new add-ons. VXLAN, VRF. We increased performances with Netlink and we introduced a policy manager which lets you... Yeah. So Ed, earlier question about the general architecture. You are using IP and VRCTL commands to configure stuff? Yes. Both. In the beginning we started by a full use of Linux commands but now we are moving towards a full Netlink back-end to increase performances. I'm going to talk about it in a later slide. So the new bridge driver. So the Linux channel now supports VLAN-aware bridges also called VLAN filtering mode. And IF updown 2 supports both traditional and the bridge VLAN-aware mode. So it helps with scale and... Yeah, it's cool. So I have an example here. So here's a quick example of how you would configure in both the traditional model and the new VLAN-aware mode for 200 VLANs. VXLAN. So VXLAN is a networking overlay. It encapsulates layer 2 frames into layer 3 UDP packets. It kind of solves the VLAN limits where you can only have 4,000 VLANs. Now you can have 16 million VXLANs. I have an example here of a small topology with the configuration that you would use in IF updown 2 to configure it. So very light. Practical. VRF. So virtual routing and forwarding is an IP technology that provides traffic isolation at layer 3 for routing. It was developed by Cumulus Networks and upstream inside Linux. It's now available in kernel 4.3 and higher. So this is a small example of how you would configure a VRF called Red with two slaves, SWP1 and SWP2, sharing a forwarding table ID 10.01. So if you specify VRF table auto, IF updown 2 will pick an unavailable table ID for you. So the new policy infrastructure lets our users define default values for add-ons. It also lets the users define values to override system default. And set specific behavior for each add-ons. So right now, most of the add-ons supports it. We are working on moving all of them complying to this new policy infrastructure and it was written by Sam Tellus from Cumulus. And have a small example of the policy file. So it's written in JSON. So you can specify that the default empty empty you will always be 1,500 if you don't specify it. Bridges tp will always be on, et cetera, et cetera. So when it comes to performances, I would say so far so good. IF updown 2 scales, scales okay, but we think we can do better. So for example right now, I would say that it takes about 3 to 2 to 3 minutes to configure 1,000 bridges, 1,000 VLAN, and 1,000 VXLAN. Something like that, yeah, 3 minutes. So what costs us time is to execute IP and subcommands. So we really believe that the net link is the answer. And so net link is an IPC mechanism mainly for kernel and user space communication. For example, IPro2 uses net link. But we want to move out from the use of IPro2 and have a pure net link backend in the case that our user don't use a kernel that have all the capabilities that we're looking for, we'll use IPro2 commands for some cases. For the net link work, we are using an in-house Python library written by Daniel, Daniel Walton. So it's called Python NL Manager. So it's not yet on Debian. It should be soon. So right now we are including the sources within IF-Updown 2. I hope you can see that. So this is an example of like a random topology. On your left there's the IF-Updown configuration. And on the right, the IF-Updown 2 configuration for the same topology. And we are not even using templates here. So thanks to our sponsor, IF-Updown 2 is available on Debian Seed and JC Backport since October 2015. So we pushed a few minor fixes. But we plan to do a more major release before the freeze. I'm going to talk about it after. So you can download the sources and build the dev or just add the seed repository to your source list. So what's next? So we plan on releasing a version 2.0 before the code freeze in December. It should really increase performances. And there are some features that we might add. But we have to talk about it internally. It's not 100% decided yet. And we keep fixing bugs reported by the community and the Cumulus clients. So how to get started with us? So IF-Updown 2 is available on GitHub as well as the documentation even though we need to update it. IF-Updown 2 ships by default as the default networking manager since Cumulus Linux 2.1. And you can get in touch with me or Rupa. That's her emails. And I want to take a second to show you an example of contribution. So this contribution was made three weeks ago. It was about 200 lines of code. And it adds support for Batman which is a layer 2 protocol for mesh networking. I didn't know about it before. That's pretty cool. And finally I want to conclude with some numbers. So 1.5 million plus switch ports are powered by Cumulus Linux. All of them use IF-Updown 2 to be up or down basically. And this tool is used in production by more than 400 companies all over the world. If you have questions, thank you so much for your attention. Hello. I would like more information about the vague slants implementation on the configuration you thought. Can you put the slide back please? This one? No, this one. So are you using some... You have overlay but is there anything in the configuration to communicate about the states of vague slant between two switches or do you have a controller in this configuration? Or is it... I'm not super familiar with the implementation details within Linux but IF-Updown 2 just configured... Just static vague slants. There's no controller or anything. You can do it without a controller, yes. And you can do it with a controller? But I'm not 100% sure on that. And how is it compatible with the bridge error mode? Because last time I checked it was a bit difficult to mix the bridge error mode and the vague slant setups. Has that changed or...? In IF-Updown 2 you mean? Or in Cumulus Linux in general. I would have to double check on that but I don't think that there should be an issue. We are trying to make the configuration very easy for our users especially since Cumulus 3.0. So we're introducing a lot of new things to let you do it more easily. But yeah, I'm not 100% sure. First of all, thanks for your great work because lots of things you described is basically what I, as previous maintainer of IF-Updown, always wanted to do and never found enough time to implement that. Actually I also wanted to pause IF-Updown 2 or some scripted language though it was something else than Python. Anyways, I wanted to tell you a couple of things I noticed. First of all, let me start from the end, from the last slide. You mentioned you've got this Python ML Manager package almost prepared and I noticed you have actually uploaded it to your private Dev&Package repository. Just one thing, please always publish the source packages you use to generate Devs because otherwise I could have just downloaded it and uploaded it to Debian in like five minutes. I see there's only a Dev file there and no sources for it and otherwise I could have sponsored it during the talk. Did you see? Yes, I did see. Okay, one more thing. You mentioned that you're going to have some discussions within the company about some certain features. Could you please also not do a discussion only within your company but basically ages ago I have created a mailing list for IF-Updown related discussions which nobody used ever, including me because I was the only person maintaining it so I had basically no one to discuss things with. But now when there's a certain group of people interested in this technology related I think it would be really great if you personally and as a company could coordinate with the current maintainer of IF-Updown which is a good sleeping, I'm not sure how it's pronounced but I think so because he's really actively developing IF-Updown now and there are certain features which are obviously not revolutionary as in your product but still I think it would be cool if you could coordinate so that features don't get implemented differently. Okay, sure. I will come to you after and you will give me the email of the mailing list and I'll make sure we talk. Thanks again for your work. You're welcome. So the question is what do we plan to do next with IF-Updown too if we want to replace IF-Updown or WhatsApp. So to answer your question I would say that the original goal was maybe to replace IF-Updown but now it's not anymore because there is all the system D, network D thing but our use case requires a scriptable and templatable network manager where you can plug your own add-ons so that's why we did it basically. I think our goal is just to keep adding features and let it available as an option for everybody but we'll keep using it as the main, as the default network manager in Cumulus Linux but we probably don't want to replace IF-Updown anymore because IF-Updown is dying and it's going to be replaced by system D, network D and everything else. I'm not entirely sure that there's a wide agreement about that. I asked a question during the system D talk about system D, network D and it's not clear that it's going to be, well, what are the plans for it? Yeah, the thing is this is Python and there is no Python in the Debian Essential on the Milimau build so this is a problem. Yeah, so Piero said, OK. Python would have to be promoted to Essential or something like that in Debian which I would be very happy to do but that probably will not happen so that's the main reason probably why IF-Updown too could not be in the default. But if ever, yeah, Python is in Debian Essential, we would maybe become the default networking manager. Yeah, I also planned to put in, when I mentioned I planned to put in IF-Updown to some script language but I made some resistance from some people because, well, basically there were not many options regarding the script language and most of ideas I had were really opposed to because like, OK, you're not going to include one more script language into the base system just because you want to use it, just stick with it and that's it. Yeah, so yeah, I guess we'll see. Another question I had about the general strategy was do you see it as a free software project with a real open development model? Kind of secos what you asked earlier. Or do you see it as an internal project from Cumulus that happens to be released as free software? Or do you grade it? So the license is GPR V2. I think it will, as long as this is not in Debian Essential, I think Cumulus will be the main contributor but we will accept any external help. How many external contributors do you have? As far as I know there's this one, the Batman thing, I'm not aware about anything else but it's because the project was only upstreamed in October and I would say we need to make some improvements on maybe the documentation and the add-on modules maybe a little bit and the version is eight months old or something like that and the internal version is much more advanced. So that's what we plan to upstream before... So you have an internal version that is in public? So we upstream most of the commits a few... Do you have the upstream? I don't understand why you... We pushed on GitHub most of the commits on the master branch We have a Debian prep branch which is for Debian but this one is like a few months behind because the tool internally is made for Cumulus Linux so we have to make some changes and backport it to Debian There's not a lot of work to do it's just that we don't have that much cycle to spend on that We need to fix bugs for customers and stuff like that so I would say the upstream work comes after The internal repository isn't it published as well? No, it's a Cumulus Linux private... a Cumulus Linux network repository but most of the code is on the master branch on GitHub Is there some support for a network new space? Not yet But that's one of the features that we are thinking about So actually I had another question Mostly technical one You said that you plan to use to port it to Netlink for performance reasons but still to use IPv2 when the kernel doesn't have all the capabilities but I understood that IPv2 adjusts the client side that uses Netlink for everything So I guess I'm wrong So can you give an example of capabilities that... I don't have an example in mind but just in case that the kernel you might use maybe it will be 3 or 4.0 something and the newest version will be 4.08, 9 or 5 someday So if of them two we'll try to keep up with the kernel API but if you're using an old kernel I get your question I would say just in case and we also want to let the user the choice Netlink or IPv2 That's also one reason No more question? How do you find... I'm switching context to the Debian Derivative thing that you have in Cumulus So how do you find Debian interaction or do you have any notes or comments about being a Debian Derivative or how could Debian help your derivative? So yeah, we are Debian based but we also contribute a lot back to the community We upstream most of the kernel packages that we are doing Otherwise I'm not really aware of specific comments on Cumulus Linux I think our customer like it The Debian community is fine with us as long as we upstream what we do Yeah, I don't know So we have a really great relationship as you see Yeah, I would say yes Why not? Any more questions? Is there any progress in Python 3 port? No Maybe sometime next year It's mostly because Cumulus Linux ships with Python 2 So if Cumulus Linux would switch to Python 3 we would work on that That somehow concerns me a little bit because in Debian there are plans to switch to Python 3 and also with the private repository thing which is a little bit like the Witterbox story which you have in public not really Witterbox but other projects So this is something which concerns me if you want to have that in Debian Okay Yeah, we are keeping a private repo because most of the work is for Cumulus Linux first kind of and the repo might contain some information about clients or bugs that are not public, I would say I don't know if we are going to change that Yeah, I can ask internally to see what's the plan but I'm not sure what we're going to do about it Yes I see concerns on that one because that calls for troubles if upstream is not it's basically closed and that's what you're telling me you have more commits upstream which is closed and you say now you will commit them back to a free version but I do not see any guarantees here if the development is not done in open Okay, I understand your concerns but I will relay the question and if there is compilation data available they should be maybe not in the repository Yeah, we'll try not to Actually, I'm just curious about Cumulus Network's business model What does it sell licenses for the operating system? Is it like the Red Hat model where everything is free and you will you provide that? No, so basically we sell licenses and supports and we sell different types of licenses depending on the hardware using 10GB, 40GB, 100GB But everything is free inside Cumulus? Inside Cumulus Linux? I would say that pretty much everything is open source except one main private driver that is basically the value of Cumulus Linux Cumulus Networks Oh, the private driver is not from the network switch vendor? No, that's a Cumulus Network thing Any other questions? Okay, thanks So my dad is watching live from France so hi dad but he doesn't understand English So, hi