 I'll try to cover today basic principles behind the virtual networking, which is a thing that is not entirely new, but I would say it's one of the most interesting topics of current days in networking and connection world. So with that said, let's look at some history and how networks became virtual. So, traditional networking, we have a company, the company has servers. Oh, okay, sorry. So if, okay, I hear there are some issues with my microphone. Sorry for that. I can try to fix it very quickly. No, I cannot. Sorry. My mic is on the lowest level. I will try not to be so loud. So we have a company that has its own data center or server room if you want with a lot of servers. And on those servers, there are of course applications running. And those applications are talking with each another over, as you guessed, a network. Usually that would be an internet. And there's a local network or LAN. And the servers are just visible to each other on the network. IP address is a sign and all of that and talking to each other or the applications that are now. This is not something that most or many companies do nowadays because it has some disadvantages. So what's happening or what has been happening for some time is migrating to cloud. So all of those servers are virtualized, they become virtual machines and are put to Amazon cloud or Google or whatever. And now there's a problem. They are still the same applications running. And they want to communicate over a local network, except in cloud, in that third party data center, the virtual machines are not running actually on the same machine and the same, even not in the same data center. What's worse, those virtual machines can migrate from single physical machine to another. They can be even in different countries. And those legacy apps that want to communicate over a virtual, over a local network, they still should continue working. Well, now imagine that this is not just a single company migrating to cloud. That's actually multiple companies or many companies even migrating to the same cloud, sharing the same virtual machines, meaning, sharing the same physical machines, meaning virtual machines from several different customers of the cloud vendor can coexist on the same physical machines. All those should be somehow connected by a local network. So how to do that? We need somehow the same way that we present it, or that we pretend to the customers of the cloud, that their physical machines are running somewhere, but they are in fact virtual machines. We need to present to them a network that appears to those virtual servers, virtual machines as a physical network, but in effect, it's virtualized on top of the physical infrastructure of the cloud. So we need some kind of virtual local networks, virtual links between machines and virtual switches, of course. So this is the motivation. And now let's look how can we address this problem? Virtual LAN, obviously. One of the oldest attempts at virtual LAN is IEEE 802.1Q, which is called VLAN most often. It's quite old standard. It's from 1998 already. And what it does is that it adds a special field, or have a special subheader, I would say, into Ethernet header, adding, among other things, a VLAN DAC, which is a 12-bit number identifying a virtual network. So this is a number, just a number of network. Well, that means we have like 496 different values, two of them are reserved. So that leaves us with 494 different VLANs. Now support for this is quite common. The hardware switches are, I mean, what you can buy in your favorite computer shop, the switches usually can't understand VLANs. You can set up VLANs there. If you haven't seen that, this is how this works. You can set up some switch ports, access ports, some strong ports. To access ports, you plug in your machine. Now speaking about physical machines, we'll get to virtual machines a bit later. So you can plug in physical machines, set up the ports, access ports, and the switch will automatically add a VLAN tag on all packets that it receives on that port, and it strips packets that it is sending to the port. Of course, it's sending only the packet with appropriate VLAN tag there. It's kind of partitioning of the switch. So those different access ports for different groups, they cannot dock with each other. And the track ports are kind of like thing that aggregates or can aggregate traffic from several different VLANs, and the VLAN tags are kept in those. Now this is not that important. I'm just saying that for completeness, if you're interested in, then just look it up somewhere on the internet. What's important to us here is that it allows different machines on single switch to have several groups of machines that cannot communicate between those groups, only inside a single group. Which is what we wanted. If we somehow maybe switch virtual and plug in all our virtual machines into this virtual switch or software switch, as it is traditionally called. Indeed, there is a software switch, actually several different solutions. In Linux, there's a bridge module that comes out of box. It is beyond capable, so it can do everything I said. So yeah, we can set up network utilization with this. And indeed, there are solutions based on that. Now, this is not that easy, because VLAN has several problems. First of that, if we take a data center and migrate it to a cloud, it might appear, or it might happen, that that customer is actually already using VLANs. And in fact, it happens quite often. That's bad. How can we solve that? Well, there's a newer standard called IEEE 802.1 AD, which is informally called queuing queue, which solved it in a way that it adds another VLAN tag to the Internet header, or even more than one. So instead of a single VLAN tag, it becomes the stack of VLAN tags. That means that you can take or the switch can take the traffic from the virtual or physical machine that already has VLAN tag and slap another VLAN tag on top. Okay, next problem. There is a limited number of IDs in the VLAN tag, and having only 4,000 customers might be quite limited if you want to grow your cloud business. How to solve that? Well, you can use queuing queue again and combine those tags to offer more combinations, which by the way is quite madness, not at least because not that many hardware and software switches support queuing queue. Third problem, VLAN does not work over the Internet, obviously. Internet is a one layer above. That's IP, not Ethernet. Well, bad luck. You cannot solve this using VLAN. So we need something other. And that's something other is tunneling. How did it, or IP tunneling for the Internet? How does it work? We have a packet. So this is a packet that came from the customer, from the virtual machine. It contains some headers. It would be most of an Internet header, IP header, and then some TCP, UDP, whatever and data. Now, if this packet is to be forwarded to another data center over the Internet, what happens is that it is put as a payload, as data, to every packet, and that one is sent over the Internet. So when your packet is from the VN is to leave the cloud or leave the data center, it is encapsulated in this way, send over the Internet to the other data center. Then when it is received there, it is decapsulated, meaning the outer headers are removed, and then it's switched inside that other data center. So yeah, that works. Respectively, actually. It looks so well that there are at least dozen or several dozen of standards. I will mention all the three of them. That's GRE, Genetic Road and Capsulation. This is one of the oldest actually, Pythonic protocols. It is an IT protocol, so it's on the same level as TCP and UDP. Then, which has some problems because it cannot pass some rotors and so on on the Internet. So a new standard was born called VXLAN, which is really similar except it's encapsulated inside an UDP header. So it's actually UDP packet, which contains the original packet. Generally, really similar to VXLAN, but more advanced, more features, and so on. Now, I said that the packets, when they are leaving the data center, that they are encapsulated. Yeah, but there's a problem. How can we decide what packets should be forwarded to the other data centers, and which should be switched inside the data center? So remember, the virtual machines can be located on different physical machines, so the data center or infrastructure must be clever enough to know what is switched between the virtual machines on a single machine, physical machine, what should be forwarded between different physical machines in the data center, what should go out to a different data center. So how can we decide? Well, we have the obvious two options. We can use either routing or switching for decision. Well, there's nothing more we can use. So let's look at them, and let's get into more details. Routing. So let's say that we set up routing tables that will decide based on the IP address, we will know or somehow infrastructure will know whether a machine, a virtual machine with this IP address is located in this data center or the one that's far away. And based on the IP addresses, it's either routed in a single data center or encapsulated and routed in the other data center. Okay, that should work. The problem here is that routing decisions happen inside the customer local RAN network. That means if we would like to route that, we would have to configure routing inside the customer's infrastructure. So it would not be transparent to the customer. Well, it is doable. We have VPNs after which are basically the same principle. We can use BGP or something like that to configure that automatically even. Still the problem is it needs cooperation from the customer. So the customer cannot just take his infrastructure and just put it into the cloud and be done with it. That wouldn't be possible. Another problem with migration, when VPNs are migrated, all of that would have, all the routes would have to be changed. As I said, we can use BGP or something like that. Solvable but not pleasant. Let's look at switching. Switching has the nice advantage that it's completely transparent to the virtual machines because the switching, those are connected to virtual switches which are at the control of the data center or of the cloud vendor. So those could be, I mean, sorry, the physical switches between those machines and also software switches on those physical machines that the virtual machines are connected to will cover it a bit later. So all of those switches are in the control of the cloud vendor. So there's nothing the customers must configure on their side, which is nice. The disadvantage is that those switches need to look inside the IP headers to find out, okay, yeah, this is going to another data center. Yeah. And that's kind of layering violation because switches are true, it should not be looking through the upper layers. On the other hand, switches are already doing that. So yeah, whatever. There are some problems with this. There are actually some even unsolved problems with this, but it mostly works surprisingly. So this is what is actually used. Now, the problem is the migration, of course. So if you migrate a single machine or a single virtual machine to another physical machine or even to a data center, we need to reconfigure all the switches that are between the communication path. Now, how can we do that? So for the fine networking, it comes to rescue. First, let's look what the switch is. The typical switch serves two different functions. If you think about it, the first function is moving packets around, moving from one port to another, adding VLAN tags, removing VLAN tags, so in short, modifying the packets. And the second function is the management. So there's something, some configuration interface that allows the administrators to configure the switch, set the VLANs, partition the switch. And so the first function boils down to looking up some tables of rules inside the switch. And the second function boils down to configuration of those rules. Yes, switch contains some kind of rule tables chained together. So especially the modern switches. So the switch is locking into that while switching. And those tables need to be configured somehow. The first thing, the movement of packets, the lookup in the rule tables is called data plane. The second function, the configuration is called control plane. Remember those terms. So let's look at the control plane. If you have some experience with top of the red switches, traditional top of the red switches, those physical boxes that you can buy, those are usually configured using some vendor specific tool or web page, connect to that, to that switch using this IP address and so on. So this is not much friendly. This cannot be automated. So imagine if we had some kind of control API, it would be common for all vendors of all switches. If you're familiar with routing with BGP, yeah, think of BGP for routers. Sorry, think of BGP for switches. And indeed, there's a standard for that core of OpenFlow and some other pro standards. Of course, there's never only one standard. So, but OpenFlow is what will, what I base my later examples on, examples like more, like talking on. So what's, now we can explain what software we find it working. Well, that's just a fancy name for having a common API to switch control plane. That's it. It's traditionally assigned with OpenFlow protocol, but nowadays used more broadly. So, yeah, that's SDN. We have what there is a software implementation of SDN switch called OpenV switch. So OpenV switch is actually a switch that is configurable using OpenFlow. It's quite advanced switch. It can do a lot more than just adding and removing the land tax. And of course, moving packets around. It's fully programmable. There's a lot you can configure there. And one of the things that you can do is actually encapsulate packets and encapsulate them. So we get tunnel encapsulation in OpenV switch directly in the switch. Yeah, if you think, okay, yeah, that's quite cross sliding validation. Yeah, it is. It works though, at least good enough. So that's what is actually used. Now, we have an, we can think of OpenV switch or some hardware switch. Those are as capable, some of them are as capable as OpenV switch. So we have some switches that decide on a set of rules that, as we explained, can be configured remotely. So based on this configurable center rules, they decide that certain packets should be switched inside the data center and so that packets should be encapsulated and sent out to the Internet. Nice. And we can use VLANs for partitioning of virtual machines inside the single data center. Yeah, this will work somehow. Yeah, except of course, the problems I mentioned, like 4,000 limit for the customer and queuing queue necessity and so on. Yeah, but there's another problem I did not mention and that is important. If we use this solution, there's no clean separation between the virtual, between the customer's virtual network, sorry, local network and between the physical network as deployed in the data center. If you think about it, if the VM sends a packet, it's like internal header, IP header and so on. The switch puts a VLAN tag on top of the internal header. The internal header is still the same. And it traverses the physical network of the cloud vendor with the same internal header that the customer's virtual machines have. That brings several problems. First, megadresist must be unique across all customers. Oops, this. There's no way we can achieve that. Those are virtual machines. The customers can set the megadresist whatever way they like. Yeah, we can play some game with the switches, like take the VLAN tag into a canvas switching. It's probably solvable with some substantial price. But it is a problem, it is a problem to solve. Another problem is that we said we have nice SDN solution on the switches. We can configure those switches like from a central place. But this traffic is intermingled with a traffic from the customers. So if we're not really, really, really careful, the customers might be able to influence or to configure our data center switch or the cloud vendor switches, which is something that's not at all the start. And so on and so on. So there are more problems like that. How we solve this? Well, if you think what we deployed, what we have configured so far, we have, we have switches that are clever, smart switches configured remotely everywhere. They are capable of tunneling. We need tunneling between data centers anyway. So what if we just tunnel everything, including the traffic in the same data center? This idea is called overlay network. Basically, you take the physical network and you create a network on top, fully completely virtual. No mingling between packets of the overlay, the virtual network and the physical network. How does it work? So let's take this example. We have a cloud. We have a few physical machines in there and each of them is running several virtual machines. Those virtual machines on the physical machine are connected to a virtual switch and then physical machines are connected by physical switch. Now, when two virtual machines are talking with each other on the same physical host over the switch, it's just switched because the virtual switch receives the packet and it just sends it to another port. That works. Rather, we want or the virtual machines are located on different physical machines then the virtual switch encapsulates the packet in an epitome and sends it to the IP address of the destination physical machine which in its virtual switch decapsulates that packet and sends it to the target virtual machine. And of course, if the traffic goes to different data center, it works the same way. It's encapsulated, sent to the and sent from the switch or the virtual switch to directly to the other physical machine at the other cloud at the other location. So from the point of view of the virtual machines, there's really no difference between traffic to another physical machine in the same data center or a different data center. And as I said, the advantage of this, one of the advantages of this is that the control traffic can share the same physical network. It's just not encapsulated. The traffic that's not encapsulated is directly addressed to the physical machine, resets there and yeah, we're done. That's easy. Now, you may think, okay, I'm talking about all about the virtual machines, but that's so outdated. Everything is Kubernetes now and containers. How does this match to containers? Well, you may be surprised, it's really the same. Network namespaces, sorry, container in Linux are implemented using so-called namespaces, among other things. And for networking, that's network namespace. Network namespace, that's basically a new instance of the cloud networking stack. So when the container is launched, a new network namespace is created. And it's like its own networking step for that single container. Now there is a virtual, now it can be a virtual link established between the container and the root namespace, meaning the host. It's called virtual Ethernet link in Linux, VTH, you could see that. And that's it. So from the part of the host, of the switch, of the virtual switch, yeah, it's just an interface, Ethernet interface that it can put packets to and receive from. And that's it. So it's really similar to a virtual machine. There are some differences, of course, virtual machine is completely transparent to the host. Network namespace can be influenced. So in theory, the management system on the host, on the machine, can look into the container, do some configuration there, and so on. But it's probably not a good idea to do that anyway. Yeah, but that's what it said to me. Let's create more an advantage. So now we expand the basics. But there are still some problems that we did not cover. Let's take this example, the same as before. Yeah, we have data center and so virtual switches, virtual machines. Now, in the picture, you see a server, a virtual machine, communicated with another machine. Now they are located on the same physical machines by chance. They are just communicated the virtual switches, switching the traffic between those. Now, that target virtual machine gets more resource hungry. So the cloud, the cloud control software decides to migrate that virtual machine to a different physical machine. And it does that. The problem is that now the traffic needs to follow the new location. It needs to be tunneled, which means that all the virtual switches need to be reconfigured. And by saying all, I really mean all, at least all those that are part or all of the switches that are running on machines or connecting machines where a virtual machine for this particular customer can be on. So yeah, we have the, we have SDN for that, right? Problem solved. Well, not really because that's too low level. I mean, generating all of those open flow rows to all of the switches, that's not an easy task. What we really want to do is somehow describe what the, what the infrastructure is, what the physical setup looks like. And we want to define logical networks saying, okay, yeah, those virtual machines are part of this network. And then just like have some API, some comment, okay, yeah, now please put this virtual machine on this physical machine or migrate it or just tear it down. Or just tear it down. And this solution just calculate the, all the open flow rows by itself and configure all the switches by itself. So we want something high level. Yes, there are of course such solution, multiple of those, obviously of course. One quite commonly used is OVN, Open Virtual Network. It can do, so it's a slightly this high level solution with nice API. It can do more than this, more than describe. It can also set some policies, security policies, it can do load balancing and more. Yeah, so it's like very good candidate to use for Kubernetes, CNI, and it is indeed used, for example, you know, let it open, let it open shit. Yeah. So with that, I think I covered all the essentials. There's a lot, of course, a lot more to it. But I guess that's something for some other talk. Now it's time for the questions. If you have some. So, Mikhail, could you read it? We have a question from Jantluka. So what's the cost of having multiple Q in Q in V line solution for network virtualization? Is it resource intensive for switches? Yeah. So, yes, of course, it's okay. It's not that much resource intensive, intensive because I mean switches can look into higher level headers. So it's more like quite a bit more difficult configuration. You have to deal somehow with the fact that there can be multiple VLintech stack and it can be made to circumvent some security measures in the cloud and so on. The more problem is it's not that widely supported. I mean OpenVitch does support it, some hardware switches do support it, but it's not universal. And also there's one with MTU, of course, because adding another VLAN header that adds four bytes, I think, to the packet. So you quite easy can go over the MTU. Yeah. Any more questions in QAA that I don't see? So I can continue. I have two more slides if anyone, okay. So I think I still have two minutes. So let's go through that. I put the BBF in the annotation. So I should talk a bit about it. It's related somehow to what I talk about, but not directly. So it's more like future, same thing for future, an interesting thing for future. So if you didn't hear about it, it's, the BBF is a bytecode that you can compile your program into and upload it to the kernel. And now your program is actually run by the kernel and the kernel in space as a response to certain events to attach your program to some event, some predefined event, not like any event, of course. And I'm sorry, it's just that we have one more question if you want to answer it in the chat. Yeah. Okay. So let me. So do we need to choose switches depending on which protocol we want to use as we implement it? This nice question. Yes. Basically, yes. You need to, you need to choose a switch according to what you need to use. Yeah. For example, if you want to use DXLine for tunneling, yeah, you absolutely have to buy a switch. If you want to have an Xeco switch that can support DXLine or support a software switch or like take a software switch or deploy a switch that supports this topic. Okay. Yeah. Back to EVPF. So if you can attach a program to some event like a packet reception, you could, in theory, use that to build your own virtual switch. You can program that. So you can like look at whatever feels in that packet you want, decide on that, modify the packet and send it out to different interfaces we want, including virtual interface. So yeah, this doesn't work that nicely yet. There are still missing features, but still there are solutions trying to do that, at least with combination with some other features in the kernel. Thank you and we're out of time.