 Hello everyone, if you have a free seat next to you on your left or your right please squeeze into the middle of the room because we often have a situation that people are entering the room when the presentation starts and they don't have any seat to have a seat. So before we start I would like to encourage you to ask questions during the presentation or after the presentation. We have cool scars for you as a reward for your questions. Then I would like to ask you to evaluate sessions using the web application for schedule or the mobile application. Also please write blocks or tweets using the hashtags defconfzz or define future and also feel free to use the Telegram group for asking any even related questions. Also please don't forget about the Sunday contest that's the last thing on the program and you can win really cool stuff there like Arduino boards or Raspberry Pi. So please stay till the end. So just before we start I would like to ask you again to squeeze into the middle if you have free seat next to you please squeeze into the middle of the room so we have room for people entering the room after the presentation starts and now I would like to introduce EG Bands. We'll give you a presentation about new features in OpenVswitch so floor is yours. Yep. Hi. Since the mic is working. So OpenVswitch, okay so let's start with a question. No scar for this question, sorry. Who knows what OpenVswitch is? Raise your hands. That's good. I was a bit afraid that people here would just come and try to learn something about OpenVswitch and then I will start with something really hard and difficult. So this doesn't, doesn't work. So new features let's just first try to make sure that we know what we mean by new features so the current version of OpenVswitch is 2.4 was released in August it's like half a year ago and actually this version came after one year gap so the previous version 2.3 was a year before that and obviously during that time a lot of development happened and a lot of new features appeared so this talk will be mostly about 2.4 but also about 2.5 which is going to be released soon hopefully even this month maybe in March if everything goes well and actually I will be talking about few features that will go even beyond that 2.6 or maybe even later depending on how fast the developers are. I will be mostly the most of the most okay as you probably know OpenVswitch has several data paths, data paths can be current data path or user space data path. I will try to cover both but focus a bit more on the current data path so just for reference the current version is 4.4 there is just a few weeks ago the upcoming is 4.5 and I will cover also these kernels during this talk. I don't remember that was the current DPDK version it's not so much important now so from the high-level view the new features can be divided into like five groups. First improvement in the OpenFlow because the OpenFlow standard specifies quite a lot of things and not all of those are implemented in OpenVswitch so new things are being implemented constantly and the the committee that is responsible for the OpenFlow standards is just adding things even more quickly so there's always something to add. Next quite a big topic is tunneling. There was a lot of new stuff with tunneling that happened in the past year. The third topic is connection tracking. That's actually quite important stuff we will talk more about that and related topic is network address translation and the last point I want to cover though just briefly is oven really new shiny stuff so let's start with the OpenFlow. One of the nice things that is new in OpenVswitch 2.4 is bundling. Now we can do we can add, delete and modify flows using one command and if we specify the bundle option it creates OpenFlow bundle which means that all of those flow modifications have to happen atomically and together so if any one of those would fail all of those are not committed and not executed. Also if this is done then the changes appear automatically at once to all packets to all operations on the flow tables and so on so no more situations like when you are deleting flows and adding flows and packets keep coming in between and you are in a bit awkward situation that packets can match flow that you didn't intend to so this solved that. To make this easier to use the AddFlow and AddFlow syntax was enhanced now you can actually specify a keyword in front of the flow rule but to specify where you are deleting flow or modifying flow or adding a new flow so yeah since now new flow oh sorry since now all flows are deleted by AddFlow command but yeah of course the DelFlow and other other things that still works. There are many more features or many more new stuff with OpenFlow I don't want to cover everything most of such small things that are usable in particle scenarios so just one more and it's conjunctive match which allows a kind of matrix match like kind of match this packet only if the source address is in this particle list of IP address and destination address is in this another set of IP address at the same time right up to now this actually required to have like n times m flows setup which is quite inefficient so if you matched four source addresses and four destination addresses you would have to have 16 flows installed sucks so conjunctive match solve this solve this its usage is so bit weird but then what with OpenFlow is not weird the can it actually point I don't know I think it does yeah so what do you do is establish a rule with conjunction ID that if matched would do something like in this case it outputs the packet to to the first report and then you set up rules with a special conjunction action which first argument is the ID and second actually specifies which part of the of this set this matches so this would mean that and and the the actual action or the the conjunction it will only match if all of those parts are satisfied so yep let's move to Chananik that's more interesting so there were a few infrastructure enhancements the generic the generic enhancements the one that's quite a new or quite interesting although invisible to most users is conversion to lightweight tunnels inside kernel so up to now when you created say vxl interface in OBS it was some kind of weird internal interface if you run if config of our IPA you didn't see that tunnel interface was internal to OBS the not so nice thing about this was that was quite a lot of code application in the kernel because the BXLan kernel interface and BXLan code in the kernel module OBS sorry BXLan code in OpenVSwitch kernel module was really most many of code was was duplicated and that caused problems with implementing new features and so on so this was finally unified now when you create VXLan interface in OBS you see an actual kernel VXLan interface and the same for other tunnels it's still backwards compatible you don't have to worry about that OpenVSwitch is used exactly the same way as before so this went to kernel 4.3 and we'll be back ported to various distribution kernels we also got support for our user space tunneling over VXLan GNEV and GRE that's in OpenVSwitch 2.4 its usage is quite non-intuitive the setup of the DPDK tunneling is a bit hard but can be done and works so I spoke about GNEV GNEV I think the correct pronunciation is GNEV it stands for genetic okay networking something something I didn't write it down so I didn't remember so GNEV protocol is a protocol that's kind of specific to to OBS currently it's not much used outside of OBS it's actually designed by the OBS authors and it's really similar to VXLan but it can carry metadata so you can add quite a lot of metadata to headers which is really useful for some use cases and we get to that later so support for GNEV tunneling was added to OBS 2.4 but only the upcoming 2.5 release adds support for actually matching on the on the metadata and setting it and it's done using TLV type length value and it's really generic so using the new comment at TLVMap you can add actual or specify actual TLV attributes and then later set them using the set field action yeah that sets this value or adds this value to the GNEV header using this TLV so this class this type of this length and similar for other so this this rule actually adds two TLVs to a GNEV metadata area and the constructed encapsulated packet is sent to Vport too on Ingress we can match on metadata again as usual this is mask and this is the value so it can be masked making this more useful another thing and the new thing is tunneling over IPv6 up to now OBS did not support turning over IPv6 at all so this is new stuff again will be in upcoming 2.4 you also need the kernel 4.4 for that so that's mean that's this the current kernel the newest RIST one currently tunneling over IPv6 is supported for VXLan and GNEV and its usage is really similar to tunneling over IPv4 was actually one of the design goals so let's say that we create VXLan port and we specify that we will supply the source and destination address later using the actual open flow rules so this will be the OBS command to create the port this is the same no change here it's exactly the same as before and then we can create open flow rules that will actually do the tunneling and again it's really similar to IPv4 except we have this IPv6 keyword or IPv6 string so if we want to set the source address for tunneling we start that to turn IPv6 source variable or whatever the same for destination so it's really simple again on ingress we can match on these things as well so we match on IPv6 source address and can do the right thing direct the packet is appropriate or the second option again the same as with IPv4 this is even simple actually you may not specify the destination address using open flow rules you can just make it fixed by creating the interface so you just specify IPv6 address you're done nothing more so this is really simple there's also the order will also be support for IPv6 tunneling using user space data path for example the PDK this is going to be in either 2.5 or 2.6 OBS series it's not clear yet I don't know whether Tadeu has new info no 2.6 probably smaller actually well tunneling stuff I probably have to mention MPLS it's not so new it's exactly it went to kernel 3.19 but that's was actually after the last DEF CONF so yeah so it was it's kind of new feature in the last year anyway speaking about kernel data path only because that was supported even before for for user space data path and the example of usage is here so there's push MPLS action which push the MPLS header on front of the packet specify the ether type and then you can set fields set the MPLS label and other stuff and on ingress match that pop the MPLS header and so on so yeah again nothing nothing complex here but there's a lot of new stuff happening that's not yet merged that's is currently worked on one of these thing is NSH NSH is kind of weird stuff it's kind of similar to Genev in some kind or in some way it's kind of similar to MPLS in other way so the intention of NSH is to actually carry metadata between various switches over wire actually or even inside host in various format and the way this is done is quite often this is encapsulated in stuff like VXL and GPE or GRE and or other stuff in L3 mode which means that the tunnel does know or inside the tunnel inside the the packet in the headers there's no internet header so you take just IP packet without the internet header and encapsulate that inside VXL and GPE or GRE or whatever and then a possibly adding NSH header between VXL and GPE and the actual payload this means that now we're dealing with L3 tunnels no internet header or two headers but OBS is strictly Ethernet based so it expects that every packet has Ethernet header in front of it and it's really hardwired hardcoded in various places in OBS so this is limitation that obviously has to be lifted actually there are patches available for that so they have some issues so they are going to be recent and yeah they are not yet merged so it's likely they will go to OBS 2.6 or maybe even later it really depends on how well this goes when this is done really possible to really direct or to add more interfaces of more kinds to OBS bridge like right now you can add tap interface to OBS bridge with these patches you will be able to also attune or turn interface to OBS bridge or VXL and GPE and stuff like that so there will be new Posh most likely nothing is really certain at this point so some of these patches are not yet merged so there are likely to be two new actions push eth header and pop eth header action which will add the or remove the internet header the the first version of the patches actually pushed empty it's on the header meaning the source and destination MAC address was all all nulls or zeros and then you would use set field action to actually populate these fields also to ease switching between L3 and L2 ports added to the to the single bridge it's likely there will be some kind of implicit push and pop actions if you don't specify otherwise which will take care of this transparently so NSH I already talked about talk about that there are people really want that honestly I don't really understand why but people really do want that so this is something that will be added most most intently VXL and GPE there are patches that add VXL and GP to the kernel ready not yet merged currently in process of being reviewed and and being merged so the target is probably kernel 4.6 maybe later again you never know when you're submitting upstream and the the the earliest open-v-switch version this can go in is 2.6 because we need L3 support for this actually VXL and GP can operate in two modes L2 or L3 really this is something that needs to be chosen before or while creating the interface so either the internal hardware is excited or not this was done or this actually used lightweight tunnel infrastructure in kernel would not be able it would not be able to implement it otherwise so the effort of the conversion really pays off now so this is the this is how this will probably look like but maybe again will be maybe different so this is the syntax you see the only different differences that you specify different type an NSH will likely be implemented as new two new actions push NSH and pop NSH which will then push and pop NSH header more actions will be needed to actually support setting the payload of NSH and matching on that this is not yet clear how this will look like there are no patches that do that yet again something to be implemented it's quite likely that first we will there will be some limited support of NSH and will be extended in some later version of OBS this will be combined with those push eth and pop eth actions to support all those two combinations of NSH and the internet headers so yeah that's enough for tunneling I think we had enough tunneling so connection tracking that's the most cool features that can be to obvious two point or will come with OBS 2.5 you will need kernel 4.3 at least for that for this to work and this really adds connection tracking to OBS meaning you can do stateful fireboarding in OBS finally this is really important for things like OpenStack or OpenShift and Docker and stuff because now they will be able to do stateful fireboarding inside their integration bridge and they won't don't want they won't have to resort to various tricks as now like creating bridges with Linux bridges with two interfaces and using EB tables to do to connection tracking so this new code allows matching on connection state using open flow rules so you can match but to the particular connection or particular packet belongs to connection that is established already or is new or belongs to another another connection so called related for this to work OBS has to defragment or if defragment and defragment packets on ingress and refragment them again where they go out this is transparent you don't have to care about that this just happened so the the theory of the operation is that the packet can be in two states can be either untracked or tracked initially every packet packet is untracked and it become it becomes tracked when you execute CT action contract CT for contract or connection checking action on that packet it actually the CT action takes several parameters one of that is stable which cost the packet to be actually forked and to continue to the table is specified and also continue executing rules in the same table and at that new table that packet becomes tracked so from that point on you can match on those contract fields so untracked untracked packet does not have the contract fields populated so you don't know whether it's established or new or whatever so one packet is tracked there are two more states that are interesting and it's it can be uncommitted and committed when it's uncle when it's committed basically the state becomes new to contract and basically save the state you can set certain fields and also you commit that connection that's further packets in the same connection became established I will show the example there are different zones yeah because quite often you need to do the fragmentation and connection tracking different for different like VMs or different tenants so in this you cannot do that in the same space you cannot really mix traffic from different tenants this they kind of the same IP address so you could mix up the fragments this is something that cannot happen so you can specify actual zone zone is a number and that's kind of namespace for for connection tracking so that's independent for different zones you can also set mark or label that series custom number that you can store with the connection and later retrieve and measure that so it's like metadata stored in the connection connection table well this is an example state for firewall which allows new connections from port 1 to port 2 but only established connection the other way so we cannot initiate connection for from port 2 so let's look at this it's quite complex actually so we have table 0 we have rules so three rules they have different priorities the highest priority rule is this one matches on IP packets we yeah it's kind of bills and this is important so when the packet is not tracked it's unchecked then we execute this action we execute the contract the contact action and redirect the packet to table one we're operating in zone 2 but it's not so important in table one the packet is tracked now yeah so this again we have two rules and we have two rules one matches on new packets and one matches on packets that belong to an already established connection so maybe it's new we commit the packet and output it to port 2 and if it's established we just send it out yeah it can it's just shorter syntax it's the same see and I don't think so I wanted this to be shorter so yeah and on the other on the other other way which I think this is not complete so you would you would actually have to have this more more complex if you really want would like to for this to work so this is really just just a part of the configurable part of the rules but yep so if we got the packet from the other direction from port 2 to port 1 again table 0 yeah we match this rule again go to table one but now in port is to we go in the other way and here if the if the state is new we drop the packet is established we send it out to port one so yeah that's a simple state for firewall it doesn't deal with things like ICMP and stuff like that I said it's not really complete but yeah net network of this translation this is another thing that's that will really help open stack and docker open-shift and all those guys because that will allow to do networking network of this translation inside OBS again using open flow rules it's implemented it will be in OBS 2.6 so something like you know for months ahead or like that and in kernel 4.6 so we will have we will have we will have to wait even for the kernel with the support a bit this is implemented in actually inside the contract action so there is a new sub action sub action of the of the city action which do the net so this is highly tied to contract it's actually highly configurable you can do you can do snet dnet so you can specify IP address ranges port ranges and do other cool stuff so this is example of of snet the the syntax is not yet final it may change so don't take this syntax for granted so again we have we have this action contract we do we do commit I have commit twice here why okay so it is definitely not the final syntax no just one commit is enough that's actually it's this type of so we commit and we execute this sub action specifying that we want the source address to be replaced by an address from this range yeah so there probably will be different rules so how to to select just the the the particle is from the range or it can be random whatever whatever you need yep so that's basically it on the from the other side yeah from then from the port 2 we need to reverse the net so translate the address back to the address according to net table and that's done just by specifying not sub action without any any parameters yep so the way this is done actually is using contract zones so if you have multiple tenants and you want to net each other it's two different addresses use different zone in the in the city action yeah so that's that's it it's not your name spaces are currently spaces but this is what we really want this contract zones there's no writing this is switching this switch so we'll specify flows you insert net action somewhere in the flows and that's it you don't do any routing that's just if you configure so yeah so the question is if it happens before routing so it really depends on we configure if you configure the open we switch in the way that you have an internal internal port that goes somewhere and it's rotated yeah of course it happens before it goes out that port it's really up to you it's open flow you can space you can program it whatever we like an example of the net of course it's really similar there's nothing nothing interesting there you match on the particle IP address and translate it to to another one and on the way back you just specify net and that's it happens magically only probably an understanding maybe harness yep one of the one of the so okay so so the net net will be really interesting thing in in 2.6 with the upcoming 2.5 there there's another really new thing that's called oven open virtual network and that's resides in inside OBS project but it's kind of high level or higher than OBS it's an interface between so-called so-called cloud management systems like open stack and on open we switch and it does it takes the logical logical view of the network as those cloud management systems have yeah like open stack view of the network for logical network and 10 slides days to actual open flow rules on actual nodes yeah so basically this is some kind of generic code that will do the translation from the from the virtual networks to the low level open flow rules and profile code and control flow configuration so that makes you'll make life easier I guess for a lot of projects and the tariff operation is that there is a cloud management system plug-in that actually communicates with so so-called northbound database and through north north demon in this communicates with sound main database which communicates with OBS control over open open controls on individual nodes and during this chain the rules are translated back and forth so everything is nice and happy I don't really have time to go through that in details interesting thing about this or think word to note is that through each packet that travels the logical network has metadata appended through the whole through the throughout its whole life and its whole travels of the network so that means that to use all the features that are needed we need a protocol tonic protocol that can carry those metadata between hosts so this is why oven is based on gene if you can use the excellent to but you lose some features and there are some not so trivial not so trivial things that are limitations like you can have only one endpoint for each VXL and so so let's not like going to details there's a bunch of other features that I won't cover can either them like DP DK V host support in OBS 2.4 that's pits actually speeds up handing of the packets from OBS to VMs you no longer have to go through kernel you can directly to QEMU since 2.5 even with multi queue for V host net there is more QoS support more Q Linux Q disk support it you can set up there's Mac Mac flooding mitigation implemented multicast snooping MLD bash command line completion which is very nice finally 2.4 and so on so I'm almost out of time we have like two minutes for questions I think yeah question please so the the question was that net filter on has the concept of related connections and how this how can this be expressed in in contract in OBS so that's quite easy you see those flags here to check new established so there's flag court RL R EL so we just use that and that's it good question sorry another question yeah for IPv6 tunnel endpoints that appeared here that kernel 4.4 is required is is that the case yeah so it's kind of 4.4 it it has to put that's for for current data path obviously yes for user space data part obviously you don't you don't care about the kernel support but it will be in a canal to in in OBS 2.6 only probably probably maybe it will make 2.5 but it's not likely you want this thank you slightly tangentially but do you know what happened to contract D does this still around is it dead do people care about it or contract D I have no idea that's probably question more to net filter developers you want to answer so I don't really understand the question so contract D is basically for two things so one is for replication to multiple firewalls for redundancy and the other one is to do experimental protocol helpers in user space but I don't think anyone ever uses that except the developers so it's just about replication and should just work actually because as far as I've seen the patches and I didn't see anything that what interfere with contract D and the way it works so I'm actually not sure what was something like that could be implementing using OBS controller maybe not sure probably not not not not not now would have we would need to have some kind of notifications about new connections which I don't think it's there yet I mean there's probably no no protocol to pass this information from OBS to open flow control right now not sure okay so thank you EG for your presentation