 Hello. I'm Nijin Ashok. So I'm basically from Redact. I work as a senior software maintenance engineer in Redact. I worked in virtualization domain for almost last five years. So I will be talking about Overt and OVN here. So what is OVN? We can say OVN in simple terms is a series of elements that translates a virtual network configuration into open flow. And installs them into open usage. So basically it adds STN capability to the open usage. Before OVN was born, there was other STN solutions which was already available in the market. However, all of these solutions were cloud dependent. One of the biggest benefits of OVN is it's independent of cloud. Any cloud provider can integrate their cloud with OVN by developing a plugin that has to talk with OVN. The features I will be talking about here will be logical switches, logical router, ACL or security groups, DHCP, ARP responder. These features will be I will be talking in integration with Overt. So first of all, I will talk about OVN architecture. So from the top, it starts with OVN provider. This is the CMS plugin which talks with the OVN. This is the only cloud dependent plugin which is available in the follow architecture. So if I have to create a logical switch, or if I have to create a logical router, the first request will be sent to the OVN provider. The OVN provider will talk with the northbound database and create whatever, if it's a request to create a logical switch, it will create logical switch. So these information are stored in the northbound database. So northbound database contains all virtual network configuration. So for example, Desin contains any information about the hypolysis. It contains all the information about virtual network configuration. It contains the information of logical switches. It contains the information about logical routers, ACLs, et cetera. So northbound database is having another client, OVN Northby. OVN Northby basically translates or converts whatever information is in the northbound database and converts into low level concepts, which is easier for the hypolysis to understand. This southbound database contains the information about the hypolysis, and it contains the logical flows. Every hypolyser is a client of southbound database. So there is a distributed OVN controller, which is run on every hypolyser. It gets this information from the southbound database, and one of the major functions of the controller is to convert this logical flow into open flow. For example, logical flow is similar to open flow. However, if the logical flow reference to a logical switch, which is a logical v-nick, which is a v-nick, which is running in a different hypolyser, it will convert that information into, in the open flow, it will be a reference to the tunnel, because the package has to move through the tunnel to reach another hypolyser. So OVN provider, as I said, all requests will be first forwarded to the OVN provider, which will do the task. So it acts as a proxy between engine and OVN database. It exposes API to the user and manager. So API is similar to Neutron Network API. It is the subset of networking API. One of the examples which I have shown in the image is it's calling the API directly to get the information of the network. So when I call the API directly, I will get the information about all the logical networks in the infrastructure. We can also interact with the OVN directly. OVN, if an NBCDL comment, you can interact directly with the northbound database. For example, if I have to create a logical switch, I can use OVN, NBCDL, LSIPHON, or if I have to add a logical port, I can use LSPIHON. So you can interact with the databases directly. Similarly, SBCTL is to interact with the southbound database. And the OVN trace comments you can use to simulate how the packet will be going through the logical flow. So if I have to understand, if there is a network drop in the environment, and if I have to understand how the packet will go through the complete infrastructure, I can use OVN iPhone trace and get the information how in which tables it will be going or in which tables it's getting dropped. Integrating OVN with OVT is, in the user point of view, it's pretty simple. So engine setup is the command to install the OVT manager. So it's an interactive command. And it has to install provider or OVT provider OVN. If you give years, it will automatically install or automatically configures all packages. And it will be added as an external provider. So OVT is having a concept of external provider where you can use the external providers. So OVT provider OVN will be added as an external provider in the OVT. So once it's added as a provider, the user has to create a logical switch to use this particular provider or use the oven in the infrastructure. So in order to create logicals, it's similar to that of you create a logical network. So I just have to tell the OVT manager that I have to create it in the external provider. So I will click the checkbox of external provider and I will select the particular external provider. If I have to attach the VNIC to this logical switch, I will create a while creating the virtual NIC, I have to tell that I have to use this particular logical switch, then I have to use a profile as this particular, the one which I have just created. So OVN I could unvisited command is used to interact with the northbound database. And if you use, and we can see the logical switches and logical ports just created. So it is showing the logical switches and one port attached to it. The port is ideally the VNIC. And it will also show the MAC address and dynamic means it will be using the DHCP. So I can have multiple OVN logical networks in the environment. So to connect these networks together, I need a router. So OVN also supports logical router to connect multiple OVN networks. However, it's not possible to create it from the GUI. You have to either use API or you have to use Ansible. So there are a set of Ansible modules you can use here. I am using OS underscore router to create this particular router named router word. So it is having two networks interfaces. So the network interface are 192.16.1.0 network and 0.0 network. So these are the two networks which I already have in this environment. And the router can be used to connect these networks together. Also, if I need an external communication, external communication may be a network outside the environment or it can be even an internet connection which is required for the virtual machine. So for that, I have to tell that I am using an external fixed IP. Then I will provide an IP. This particular IP will be the interface. It will be the package will be forwarding through this IP address. And I will be getting the external connection. So the IP address which I will be providing to the interfaces of router will be ideally the gateway IP address of whatever I am configuring for the subnets which I create using the OVEN provider from the GUI. So this is ideally if I create a flowchart of this particular network. So I have two networks 0.0 and 1.0 and connected using the router. So if 0.1 asks for a request to suppose I am trying to contact redhat.com. So the first the package will go to this gateway 0.254 then to the router. Then it will go to the 122.100 and to this gateway which is 122.1. So this gateway is not an entity which is in the OVEN network. It will be a server which will be outside the network. And this particular gateway will decides where the network has to go. So it can be through internet or it can be a network outside this particular OVEN network. So when you create a network in the OVEN, so this is how you will create a subnet. So I have the option to provide the gateway, provide the DNS. So DHCP will be automatically configured. So conceptually it's a DHCP in principle is very simple. So suppose I am having a server which asks for its IP address. The DHCP server provides the IP address to the client telling you can use this IP address and give set of options. So the implementation of DHCP in OVEN is almost as simple as this. So there will be a open-float rules which will be created for this DHCP purpose. So when the packet leaves the virtual machine and reaches the hypervisor, this package will match us in the open-float tables and the reply will be automatically given to the virtual machine. So ideally the packets will never leave the hypervisor. So it also supports DHCP options like gateway, the DNS, even the PXC related options. These are the set of tables which corresponds to DHCP. So I'm having a logical switch table which have the information about all the logical switches in the environment. There is logical port table which have information about all the, basically all the VNICs in the environment. So DHCP, it will be having a pointer to the what DHCP options it is having. So DHCP options table will be having the all options supported. For example, if you have options of DNS server, lease time, MTU, the router is the gateway. Server ID and server map is, if I capture the DHCP reply within the virtual machines, it will looks like the packet is coming from this particular IP and this particular map. So even though these options or even though these servers doesn't exist, the reply looks like it's coming from this particular IP address and this particular map. This is the logical flow which corresponds to DHCP. So as you can see the DHCP port is automatically matched and the first two tables, the DHCP options is added and the third table is the actual replay. So you can see that the sources, at eth.sources convert to zero to MAC address and IP both sources changed into zero to zero. So the packets will looks like it's coming from this particular IP and MAC address. So the next one is ideally the pop-up flow which corresponds to this logical flow. The security groups. So security groups we can say that it's a virtual firewall within the environment. So it decides what all packets has to enter the virtual machine or what all packets we have to reject. So it allows fine-grailed access control to and from the over virtual machines. So security groups basically mimics or stacks, neutrons, behavior wherever possible. So when a new security groups is created, it drops all the packets by default. The user has to explicitly enable what all packets it has to be forwarded to the virtual machine. Also there will be a default security group which allows the communication between all the virtual machines which is part of the default security group. So security group also you have to manage it either using API or using answer. These are the tables corresponds to security groups. The port underscore group table basically contains all the ports which is associated with this security group. So these two security groups which I have listed here is the drop-all security group and the default security group. So it have the ports column which contains the list of virtual links which is attached to the security group. So the ACLs columns which is showing here will be pointing what ACL rules will be applied to this particular security group. So the security, I have listed two ACLs. It is in the next image I have listed two ACLs which corresponds to the default security group. The column which we have to see is the match. So in the match, the first match allows all egress traffic by default and the second match only allows if the virtual machine is part of this particular security group. You can see that IP4 dot source is equal to default underscore IP4 which is a different address set and the address set will be defined in an address set table. So any IP address which is part of this address set will be able to communicate each other in every ports. Suppose if I have to create a security groups based on this particular example, I have a web server and I have a database server. The web server listens on port 80 and every server should be able to communicate to port 80 and I have a database server which is listening on table 306. So the web server should be able to communicate with the database server on double 306 and no other client should be able to communicate to this database server. This is my requirement I have. So how I will create it is I have to use Ansible. So first I will create two security groups, web server and database security group. Then I will tell what security rule we have to apply on these two security groups. So the first one I am allowing only port 80 for web server security group and the second one I am allowing the database code double 306. So here there is an extra entity which I am defining. It is remote group. So I am telling only the web server security groups, members of web server security groups should be able to communicate with the database server. So OVN, NBCTL, ACL list command can be used to list the security groups associated with the port group. So the first one is for the web server security group. You can see that it's the first two rules is for the egress traffic for IPv4 and IPv6. And the next rule is for egress traffic. So the incoming packets. So the incoming packets will be only allowed if the port is 80. Then the next security group is for database server. It is almost similar to the web server security group. The difference is in the egress traffic it has an extra variable IPv4 source which is equal to the security group or address set of the web server security group. So it will only allow packets to the port double 306 if the address is defined in the address set of web server. So the only the web server groups will be able to communicate with the database. ARP responder. So conceptually it's in ARP in normal networking. If I have to know the IP of, if I have to know the MAC address of a particular IP I will send an ARP broadcast to every servers in the network. So the server which is having this particular IP address will send back with, I'm having this particular IP address and will send back as an ARP replay. So in Oven, we will be having the open flow road specific for ARP request. So also the ARP request also will not leave the hypervisor. ARP request which of non-IPs will be already configured within the open flow table. So when a packet is forwarded from the virtual machine, ARP request is forwarded from the virtual machine to the open flow table. The open flow table automatically manipulates the ARP replay and ARP replay will be provided to the virtual machine. So these are the tables corresponds to the ARP request. So if any request which comes for asking for particular IP address, it already has the MAC address corresponding to this IP address and the ARP replay will be automatically provided. Yep, that's all.