 Hello, and good morning, everyone. Welcome to this session about OpenStack Networking with Notron. It's going to be kind of a bird's-eye view. It's much too less time to try to dig deep into all the components and how they work and so on. But I'm going to try to give you a feel of what the different components do and how you can use them. And to kind of spur your interest to find more information about the different components and so on. Who am I? I'm Unix Networking for 20-plus years. I've been playing with OpenStack for around three years. And right now doing DevOps-y stuff for a public private cloud provider. And I've been doing that for quite some time, and I still have fun doing it. Just a very few words about the service that I daily work with, just to get a feel where I'm coming from. As I said, it's a public OpenStack cloud, classic infrastructure as a service, multiple sites in different countries, 10 gigabit connections between sites, and mostly built on standard OpenStack components. We try to keep vendor neutral and try to keep away from too much vendor lock-in products. The thing we do is that we develop our own control panel, mostly to integrate with our other services and so on. And on the technical side, it's OpenStack. It's currently mostly Metaka release, a few Liberties still around. Standard Neutron, ML2 OpenV-Switch, kind of the reference implementation. We're doing dedicated network nodes instead of DVR. I'm going to get in more into that later on. We do layer three high availability to prevent single network node going down, affecting customer networks. Uses VxLam for overlay networking and some other services like load balancer service and VPN service and so on. What is Neutron? The OpenStack documentation basically says that Neutron is an OpenStack project to provide network connectivity as a service. Between interface devices, virtual NICs, managed by other OpenStack services, for example, Nova. And it implements the Neutron API. That's basically what Neutron is, according to the source itself. A few words about the history of Neutron. Historically, networking in OpenStack was handled by Nova Network. In Falsen, something called Quantum was released. And basically, after a few years in Havana, after a while in Havana, rather, it was renamed Neutron due to trademark dispute of some kind. Also in Havana, the initial monolithic Linux bridge and the OpenV switch was replaced by ML2, Modularly Day 2 plugins. And those monolithic drivers were replaced by mechanism drivers, so-called mechanism drivers. And the thing about that was to make it easier to implement new Layer 2 types without having to rewrite the whole plugins. There are some basic parts of OpenStack networking. Maybe the most basic are networks and subnets. And the networks are basically Layer 2 broadcast domains. It's kind of like a physical network or a VLAN or something like that if you compare it to the physical world. And then the subnet, it's basically a Layer 3 object. It can be of IPv4 or IPv6 types. You can connect one or more subnets to one network. And it contains also information about network configuration like the sitter and IP address allocation pools and the name servers and so on. Some networking terminology in OpenStack. You talk about something called provider networks. And those are created by the administrator. And the reason for that is that it maps to physical networks. And hopefully the administrator has the knowledge to about the underlying physical network so they can configure it while a user probably doesn't have that information. And it can map to different kinds of physical networks. It could be just a normal network or it could be a VLAN or it could be other types of networks. A tenant network, on the other hand, is created by the user. And the user can create them by themselves. And they usually pick their own IP addresses and can set the configuration on network itself. It's an isolated network just within the project. And it can be used for virtual machines to talk to each other. And you can connect it to other things through routers. I'm going to get more into that as well a bit later. When we come to different network types, there are local networks which are basically only used for single box testing, not in production. But the more interesting is flat networking, where all instances share the same network, no segregation. It's just a single network, no VLANs, nothing like that. You could, it doesn't have any knowledge for VLANs. You could connect it theoretically to a VLAN through a bridge or something like that, of course. Then you have the VLANs, VLAN type of networks. They are separated by VLAN tags. And you can configure OpenStack with the segmentation ID to connect it to different VLANs depending on the segmentation ID if you have a VLAN trunk to the network node. Then you have the GRE networks. I'm going to get a little bit more into GRE and VXLAN later on. But basically, there are tunnel networks, overlay networks that are used for communications between virtual machines on different network nodes. Another basic part of the OpenStack network architecture is port. It's basically a connection of a network interface to a network. And you can use it to connect many different things to the network. It could be a virtual machine. It could be a DHTP server, a router. It could also be some kind of load balancer, as a service instance, or things like that. It also contains some network configuration information, like MAC address and IP address of the port. Then you have the router component. Those are virtual instances that routes traffic between different networks. And of course, that is used to route between different subnets that are not in the same broad-cost domain, just like a normal router. You can route between tenant networks. And you could, of course, route between tenant networks and provider networks. And also, in that case, provide the NAT that is usually required to get to the right IP address translation between the private networks, the internal networks, and provider networks. There are also something called HA routers. High availability. It basically adds high availability to the router concept. And it's a standard VRRP instance that will be in active passive mode normally. And if the active one goes down, it will switch over to the passive one. Of course, to prevent a single network node going down from affecting your customer networks and so on. In our test, it usually takes like eight to 10 seconds or something like that to switch over. You can probably tune that a bit if you want to. Sorry. And it basically makes the router live in different, in more than one network node. There is also something called DVR, Distributed Virtual Routing. And that's a way to distribute routing and make it happen on the compute nodes instead of network nodes. And it's basically done to have another way of scaling your network, the handling of the network. If you can have them scale independently, you scale network nodes and compute nodes individually, or you scale compute nodes and they also handle the networking. In some ways, you still have to do some, in some architectures, you have to do some netting on the network node even though you're using DVR. OK, a little bit further down in the OpenStack network architecture, you have the agents that kind of make those things we talked about earlier happen and realizes the routers and networks and subnets and so on. And we can begin with the L2 agent, which in this case I'm going to talk about the OpenVswitch agent. There are other agents that can use other technologies as well. And it basically handles provisioning of the Layer 2 networks and connectivity for the virtual machines. It communicates with OpenVswitch, provisioning all this and basically configuring OpenVswitch to do everything you have configured the network, the configuration you have done in OpenStack through the APIs, of course. And it also provisions a security group IP tables to realize them. And it also handles the overlay network that you talked a little bit about earlier and we'll get into a little bit more detail in a few minutes. As I said, it communicates with something called OpenVswitch. And OpenVswitch is basically a virtual switch. It's not in itself an OpenStack component. It's more of a generic component that OpenStack uses. And it's a generic virtual switch you could use it for other other usages as well. It handles the L2 connectivity and basically works like a normal physical switch and has support for lots of the same protocols and stuff like NetFlow and so on. But only a subset of what it supports is used in OpenStack. It basically consists of three components. You have a kernel module that makes the data plane and where the magic happens. And there you have a Vswitch daemon that handles configuration programming of the kernel module and inserts the configuration you want and make the kernel module do what you want it to do. Then you have the OVS database, which is basically a configuration database. It has all the configuration stored that is needed for the OpenVswitch to work. Speaking about overlay networking, OpenStack support mainly a VxLanning GRE. Those are the most commonly used. Those are basically tunnel protocols that encapsulates the IP packets in another packet basically. And it's used to be able to forward traffic between compute nodes. If you have a virtual machine on one compute node and another on the other one, they want to communicate independently of the physical network and how that looks, you just tunnel it as long as there is IP connectivity, you can set up such a tunnel. And it will also separate the different networks that might exist on the compute nodes. Also, it encapsulates traffic going to the network nodes and going out, that is supposed to go out to an external network or something like that. And that's, of course, a good thing that you don't have to do any reconfiguration of the underlying network when you provision new networks and it's an easy way to accomplish that without having to have special vendor modules to actually configure a network all the time when you provision stuff. Security groups are basically IP table rules that are implemented by the L2 agent on the compute nodes very close to the virtual machine. And it basically filters traffic, it limits what traffic may go in and out on the interfaces on the virtual machine. There do exist other implementations, not only the IP tables implementation, there is, for example, an OVS open V-switch that is flow-based implementation and the really good thing about that one is that it has much better performance than the IP tables one. Also, there is a little esoteric thing about it that when you do IP tables, you have to flow the traffic between through a bridge, a Linux bridge, and with OVS flow-based implementation, you don't have to do that and that also helps performance. Then we have the L3 agent and as you can probably guess, it handles the L3 provisioning. And it provisions routers, it sets up namespaces and everything around that. I'm gonna get into what namespaces are in a few moments and it handles NAT provisioning and also the floating IPs which utilizes NAT to work. Network namespaces, this is basically a Linux function that creates multiple instances of parts of the IP stack and it's there to be able to separate different routers from each other as the customers create the tenant networks. It might be overlapping network IP spaces. Two customers can easily pick the same IP network especially as it's private networks with private IP addresses. So it wouldn't work if it was in the same instance. Each namespace has its own routing table and IP tables and that's how the separation works. And there are lots of different demons in the OpenStack network architecture that runs in different namespaces. You have DHCP servers, metadata proxies and also the different services if you're running VPN as a service or load balancer as a service and so on. And the floating IPs. Publicly, routable IP addresses are of course, IPv4 addresses are of course, a scarce resource nowadays. It's getting less and less easy to get any new addresses and more and more costly. And that was basically one of the main points behind the floating IP address function. Floating IP space is basically based on NAT and instead of NAT, IPv6 is of course the way to go but I guess we still need some IPv4 addressing for a while longer. When it comes to IPv4, you don't want to provision the tenant networks with public IPv4 addresses for this reason and instead use private addresses inside the private networks. And instead you have private RFC1980 addresses there and then you connect the floating IPs to the instances where you need it. And this is realized by the L3 agent on the network nodes or in partly in the compute nodes if you use DVR and it will basically take care of doing the network address translation between the internal addresses of the tenant network and the addresses of the provider network. Over to a bit about IPv6. There is extensive support in OpenStack for IPv6. Not every feature is there and there are no floating IPs and this is, it's probably not supposed to be any time soon either, probably not at all as it's expected that you're using global IPv6 addresses for the tenant networks and have no overlap. And I'm gonna get into that a little bit more later on how that works when I said earlier that you usually set your own IP addresses for the tenant networks. You have support both for a stateless address out of configuration, Slack, and that is a way for the virtual machines to obtain the IP addresses and they get to know what IP addresses they're gonna use without necessarily using DHCP. But you can also use DHCPv6 and there are a couple of issues there when only using SLAAC you don't normally get any DNS addresses, DNS information for example, but there are two kinds of DHCPv6 flavors, one that is stateless and one stateful and the stateless basically, then you basically get your address from with the stateless address out of configuration and then you get the DNS information from and other information from the DHCPv6 service. When it comes to DHCPv6 stateful, it's pretty much like an ordinary DHCP server for IPv4, not very much of a difference. You also have support for prefix delegation, which means that you can provide whole prefixes, network prefixes to networks in OpenStack, not just specific addresses. Okay, the DHCP addresses, the DHCP agents, those are basically, they handle provisioning of the DHCP for the tenant networks and they realize this by using DNS mask to provide the DHCP service. And it does that of course within the specific namespaces to be able to for the virtual machines to request IP addresses. It also handles RA-DVD for IPv6 which is needed for Slack that we talked about a few minutes ago. Then we have Metadata agents, a couple of different agents that are used there, a couple of different demons. Metadata is basically called used to provide cloud in it and use the data information for the virtual machines. And this are basically configuration details. It could for example be the public and private IP addresses of an instance. It can be, you can even insert through user data specific scripts and stuff that is supposed to run on the virtual machine when it's started and so on. So it's both a way for you to push information and push things that you want the virtual machine to do on startup. It could be for example to provision it as a puppet client or do some ansible stuff on it or whatever. And it's also a way for the cloud in it demon in the virtual machine to be able to get some information about the environment it lives in, like stuff like hostname, IP addresses and so on. Sorry about that. There is also, there is the metadata proxy that is run, first of all, there is an IP table rule in the router namespace that redirects a specific address. Basically I forgot to say that the cloud in it works by the demon asking basically for a URL for a specific IP address and a specific URL and it gets a response back for the different kinds of information you might need. And the IP table rule in the router namespace redirects that request to a proxy, the metadata proxy which in this case rewrites the request, adds some more information to it. For example, which router namespace it's belonging to and some stuff about that to be able to, for the metadata agent that it then forwards the request to and enables the metadata agent to actually know which virtual machine has asked a question. And then the metadata agent will respond with an answer to request and give the virtual machine the data that it needs. There are also some other services that you can use and provide for the users of your opens stack installation. One of those is load balancer service. And there are two versions, version one and version two and there are a number of limitations with version one. For example, you don't have TLS termination, you can only listen and kind of the main one is that you can only listen to one port on each load balancer IP, which means that you have to pick if you want to answer port 80 or port 443 for web server, which pretty much for many use cases, it's pretty hard to use it in a useful way. Load balancer service version two is a lot better, lots of more configuration possibilities and it solves those problems I mentioned here. And other problems as well. One problem there though is that there is no clear migration path. The thing, the main recommendation is basically to remove all that load balancers and then recreate them as V2 load balancers, which can of course be a pain if you have lots of load balancer already deployed. In the reference implementation, load balancers are in as a service implements the load balancers with the HAProxy and well sets up an HAProxy in the right namespace and just goes away with it. Then you have the VPN as a service. It's a way to connect tenant networks through IPsec tunnels to other networks. Those other networks could either be another open stack, a network in another open stack, region or installation, or it could be just a tunnel back to your office or another data center or anything basically that can speak IPsec. There are several backends. There are some commercial backends for proprietary network solutions and there are also free ones like Libre Swan and Strong Swan. It's used by configuring in a little other way, the load balancer service as we talked about earlier, it has its own agent that you start if you want to use load balancers as a service. VPN as a service on the other hand, it doesn't have its own separate daemon. It's rather that you instead of using the L3 daemon that you normally use to do all the L3 stuff, you instead start the open stack VPN agent which does both the L3 stuff and the VPN as a service stuff. Firewall as a service is another interesting service. It's perimeter security. That it can help you with. The difference between security groups and firewall as a service is basically that as I mentioned earlier, security groups are implemented right next to the virtual machine and prevents traffic from entering. It's almost like a host firewall. It's only used basically for one virtual machine. While the firewall as a service is rather like more like a traditional firewall that you implement at the router levels and you can use it to limit traffic between networks. And those are applied in the standard implementation with the IP tables and are applied on the network node. Another interesting feature are subnet pools and address scopes. And this is about what I talked about earlier that you might have the thing that you want to use. IP addresses that are globally routable on even on the tenant networks, especially with IPv6. In that case, you can set up subnet pools which basically makes you be able to pick a network from a pool that has been defined by the administrator when the user creates subnets. And of course, this is especially important for networks with public IP addresses. It could also be useful if you have a strict IP policy within the company, for example, and you want it to be routable within the company even if it's private addresses that are used. So it's usable both with IPv4 and IPv6. Combined with address scopes, that is a very powerful thing as with address scope, you can control which address basis on the tenant networks need to be routed or and which needs to be knitted to be able to reach a provider network or external network. That combined with the fact that Neutron can act as a BDP speaker is also very powerful as you can actually have Neutron announce the networks that you have provided to the tenant networks to any other equipment that can speak BDP in your network. And you basically announce the tenant prefixes and host routes for floating IPs, whichever or both. And some links to some further learning when you can get more into detailing all those components. And I would recommend the networking guides and the admin guide, of course. There are lots of details there. And they're also a very good source of information is summit presentations. Nevermind which topic or subject you're mostly interested in, you can definitely find more information if you search for summit presentations to watch about it. Keep in mind though that it's pretty important to try to keep to the more recent presentations as things move really fast in Neutron as in the rest of OpenStack. So things quickly can get out of date and then you miss critical features and so on. Okay, we have a few minutes for questions as well. Let's see, so you talked about the subnet pools and also on a previous slide you mentioned prefix delegation. So some relationship between those two things that are going on and if so could you kind of discuss how it works? Yeah, you can use prefix delegation. It has that association, but you can also use set up kind of internal pools without doing prefix delegation in that case. And it works both for IPv4 and IPv6 so it's not just for IPv6 as well. Okay, so if you were using prefix delegation would that manifest itself as subnet pools or are they two separate concepts? There are two separate concepts. Question there? Thanks. Your IP net function for IPv4 is that balanced in high availability so in the event of a state control will it then be able to fail over without disconnecting the connectivity? Did I understand the question correct that if you're using high availability routers if you can switch over to another node? So if you're doing an overlay netting in between the overlay to the outbound so from an overlay in the virtual in the hypervisor to the external IP net? Yes, yes it can. The router is actually moved from one or rather activated on the other network node. And that makes, well that moves all the functionality of the router that is used for connectivity between the external network. As long of course as both network node has the same access to networks and so on physical, yeah. What about the V2 of the balancer? Sorry? The V2 version of the balancer will that do the same or be able to do the same? Yes it's also, wait a second. I'm not actually sure if the V2 load balancers moved with it, let me think for a moment. Oh, we can take it later. Yeah, we can discuss it later, I'm not quite sure. Okay. A few years ago I know that the performance and stability of these routers that is included in OpenStack were not so good. What is your view of them today? What's the kind of performance in packets? Routing per second. Well that depends of course on the hardware, it depends on things like what network interface cards you have. There are some technologies to actually offload, for example some of the VXLAM parts to network interfaces and that can do miracles with performance. So I mean it's really hard question to answer kind of an exact number of packets per second but with the right configuration I've seen networks basically reach pretty much line speed at least when it comes to Neutron. Also there have been lots of modifications of Neutron lately that has been focused on performance and also those things that you for example be able to use the OVS plugins for firewalling with help performance as well as you don't have to go through the bridge that I talked about earlier. But it's a hard question to ask and you probably have to really think about the architecture and how you what hardware you use and so on to be able to answer that question as it varies widely. I actually saw a presentation yesterday, I think it was yesterday or the day before that I can recommend about Neutron and its performance and some testing they had done on it and benchmarking. That would probably be useful for you to watch. We have a few seconds more. So I think it's last question. Okay, thanks for the overview. It was very useful for me. So I have a question about provider networks right from the beginning of your talk. So you mentioned it can only be created by admins. Is that something that can be changed with the roles mechanism and have you looked at it? Yeah, you could probably change it with the roles mechanism. Of course that depends on your use case, what kind of users you have, but you could probably change it and have a user be able to create provider networks. And yeah, I can see that could be useful in some places when basically the users are a network engineers and have the knowledge of the underlying network to be able to do that. Thanks. Welcome.