 So we're going to try to get you all going with your environments. So I know there were a lot of you that did not RSVP. So we're going to work through the list of all the people and make sure that everyone has a hands-on environment. So if you have any problem, anyone that is wearing the purple Plum Grid Polo can help you with getting the environment set up and logging into the lab. So first of all, I wanted to thank you for joining us today for this lab. I'm happy to see so many people interested in learning about open-stack networking, so that's great. And we hope that we can get you going with a good understanding of the functionality of Neutron, how to configure networks, security policies, and all these sort of things that are important for any multi-tenant environment. So just before we get started, a little bit about myself. And then we'll have another speaker that is now in the back that is trying to help everyone get started with the labs. So my name is Valentina Lari. I've been part of the open-stack community for a very long time. My very first summit was in Santa Clara, at this point, six years back. And I do all sort of things helping customers learn about open-stack networking and SDN and related technologies. And I've been doing that for a number of years. And I have with me Jamal, his part of our system engineering, customer engineering group. And he does a lot of work with, again, with customers on the technical side. So we are part of the team that is here with Plumgrid. And what today is absolutely not about Plumgrid, you're going to see that kind of the backend technology that we're going to use for these lab it's based on what we do. And we are an SDN solution that has a Neutron plug-in. So it's just kind of one of the various options that you have when you go and deploy open-stack networking. So I'll walk you through just 10, 15 minutes. No, 10 minutes. I'll try to do it super quick so that everyone is on the same page in terms of terminology, concepts, what we're doing here. And whenever we refer to specific terms, you are all familiar with what we're talking about. And then we're going to jump into just real quick on the Plumgrid plug-in, which is what you're going to be using today as the backend for open-stack networking. And then we'll go into the hands-on lab. Just a quick raise of hands of how many of you are already familiar with open-stack networking. I've done any type of configuration. Kind of half. OK, so we'll try to squeeze in some more advanced stuff. This is kind of a beginner lab. So I also want to be mindful of the other people that are kind of brand new. But we'll try to put in a few as much as we can in terms of more advanced information there. All right, so real quick on open-stack networking. So obviously, this is what we're going to be doing our hands-on lab today. And the main goal for open-stack networking was to provide networks within open-stack as a service. So the same level of on-demand configurability of networking that you have for compute and storage, this was really the goal of open-stack networking. It wasn't introduced from the very beginning. It was just introduced with a false-sum release. And the goal was to expose this on-demand creation of networks, both through the cloud operator, as well as to the tenants. So you see today, as we go through the lab, you're going to be logging in and creating things as an admin. And those are the more advanced functionalities, like external connectivity, for example, which is where you start mapping virtual and physical constructs together. And you're also going to be doing things as a tenant. So you have your tenant environments that you can go and create your own networks, your own routing, your own security policies, and all sort of things that are needed for your own application in there. So what you see today is that when you interact with open-stack, you're going to interact through the open-stack dashboard, as well as through the open-stack API. What you're going to go is that you're going to hit the Neutron server. Neutron is really a thin layer there. And those API are then going to go to the Neutron plug-in that you're leveraging. In this specific lab, you're going to be using the Plumgrid plug-in as a networking component. So what will happen there is that the API call will be sent from the open-stack layer all the way to the backend component. And the backend component will be the one that will be in practice responsible for actually creating all the networking functionality that you're demanding through the API layer. Now, the actual implementation of this networking functionality obviously greatly varies depending on which backend you're leveraging there. So in the specific case of Plumgrid, we are an SDN solution. We use overlay technologies. So what we do is that we give you the ability to create any type of network functionality because the overlay layer decouples your tenant environment from the physical underlying infrastructure. So you have a lot of flexibility. If you're using an environment that it's a little more traditional where you're actually mapping to balance and physical switches, you have a little more constraints in terms of what you can do for your tenant environments. OK. So what can users do with Neutron? There is a few basic operations that you'll be able to explore today. The main thing is that you're going to be able to create networks. The assumption is that each project, each tenant environment, it's its own isolated bubble. So you'll be able to create any IP address you want to use in there. You all have a hands-on guide. If you don't, we'll get to you. But the hands-on guide will guide you through that. And it will suggest some IP addresses. But it's your own private environment. You can do anything you want in there. So if you want to use 10.10.10, 2020.20, whatever you want, it's your own private bubble. That's the beauty of this model. You're then going to be able to connect, obviously, workloads to each network. And then you're going to be able to start interconnecting networks together with routers. So this is obviously what we're going to go through today. And then the next step, which is very interesting, is the step of providing what we call external connectivity from the tenant environment to, again, external networks. The idea there is that you start leaving your virtual environment, and you start going into your physical legacy infrastructure. So you'll see that this step is when you actually log in as an admin, and you perform some operations as an admin. You're going to start looking at, OK, how am I going to get out of this virtual environment? Which physical interface am I going to map to? Which real IP address I'm going to use to leave my tenant environment and go into the physical world? And then this functionality, known as external networks, is that exposed to the tenants that can then consume it inside their bubble, inside their tenant environment. All right? So you'll see that we'll keep referring to tenant networks, which are the networks that any tenant can create as part of their project. And then we'll refer to the concept of provider networks. Now, provider networks are a very interesting and complex topic. There are three types of provider networks in OpenStack. And that's where it gets real fun. So networks can be external, can be non-external, or can be shared. Today, we're going to do the very simple one, which is the external network. The idea of the other types of networks is that they're going to give you a different type of connectivity between the tenant environment and the external world, and in between tenants as well. If you have more questions on the different type of external networks, we can certainly review some of those as well. Jomal can certainly jump into some of that too. Now, anytime you have an external network or a provider network, you have a question? OK. Anytime you connect the tenant environment with the external network, you'll see that there's actually an implicit NAT function that gets established. The reason for that is obviously that you have your private IP space within the tenant environment, and you're now mapping into the legacy world. And so when you go from your private IP space to the public IP space, you're going to use a NAT function to translate IPs from one side to the other. So a source NAT, it's enabled by default as you exit your project. And also, you can enable floating IPs so that you can actually connect from the outside world into your private environment. So you can have a client sitting out there that wants to connect to a server, that it's a VM within your private project, that can be done through the concept of floating IP. So all of that comes into the picture when you enable a provider network external connectivity type of functionality. OK, so anytime you deploy OpenStack, you're always going to select a plugin. For this exercise, we're going to use the PlumGrid plugin. If you go to the OpenStack marketplace and look for the drivers, you're going to see a very long list of networking plugins and networking options. Those are all tested for Neutron. So when you deploy OpenStack, you can select any of those for the sake of your deployment. As I said, PlumGrid is an overlay-based solution. So what we're going to see is that we're going to have a software component that's deployed inside each server. In our case, we use a component that's called an Iobizer. It's a kernel-based component. Again, don't worry about it today. Just remember that there's a software piece that runs inside each compute node that will actually implement the networking functions that you define through the API layer on top. And then there is an overlay solution. What it means is that there are tunnels, BXLAN tunnels, that get established between compute node and compute node to allow you to have this virtual environment decoupled from the physical infrastructure underneath. Now in the environment that you have in the Handsome Guide, there's a lot more components of what we're going to cover today. There's a lot of PlumGrid-specific monitoring visualization things that you can explore on your own if you're interested in. You're going to have those environments for a while for a few hours, so you can certainly go and do that. We're not going to cover any of the PlumGrid-specific stuff in here. So I think we can quickly just look at this. You're going to bounce back and forth between OpenStack and the backend just to get a feel for how things get translated from one side to the other. This is the same for any plugin that you have. You're always going to see a translation from the OpenStack abstractions to whatever backend implementation you're using there. So just these slides give you an idea of when you create an OpenStack project, this translates to a concept of what we call a virtual domain, which is this tenant environment on PlumGrid-side. And we represent the concept of switches and routers and NAT as little network functions, those are the icons that you'll see on the PlumGrid-side. This just helps to kind of get a context for what you're just going to see during the lab. So during the hands-on lab, we are going to all log into an environment. Again, if you don't have it yet, no panic. We're going to get to one. And Jomali is anyway going to walk you through the steps so you can follow along and we can get to the environment worst case at the end. So you all should have an email or we gave you the IP address manually. You need a BNC client to access your environment. If you have a Mac, you can just log into your Safari window browser and you can just do a screen sharing from there. Otherwise, you can download as a BNC client. You have an IP address. The port is 10.005 and the password is PlumGrid. So all of you should be able to log in. And if not, raise your hand and we'll come help you there. And we're going to do four major things today. We're first going to log in and we're going to start creating projects in OpenStack as an admin. And then we're going to log back in as a tenant. And we're going to start creating our own networks in that environment. We're going to start creating layer 2 networks, interconnect them with routers. We're also going to enable external connectivity for those networks. And last but not least, we're going to start creating security groups so that we can enforce policies between VMs. You'll see it's a very powerful construct in OpenStack. We're not going to get into the monitoring troubleshooting because a lot of the monitoring and troubleshooting is actually specific to the backend. So again, if you're interested in learning more about that, which is more specific to the PlumGrid solution, in the hands-on guide you have three extra exercises that you can go through that are more on the troubleshooting side. And the last thing I want to mention is that if you're interested, we have a certification that PlumGrid is running that it's around OpenStack networking. Obviously, the OpenStack Foundation has a certification that it's broader around the whole OpenStack. But we've been working very closely with the user community for a number of years, and we have developed a certification that it's specific for anyone that wants to learn about OpenStack networking. So you're definitely welcome to check the one out if you want to learn more about it. All right, so let's jump into the hands-on lab. And I'm going to go down and help people. So you have that answer? Yeah. So let's start with the exercise. Most of you have already got the email with the IP address and the port. So you just fill in the IP address with the 10-0005 port and connect to your instance. The password is PlumGrid. I'm actually going to close all the sessions over here so that I can start from the start. So on the instance, you log in into the Chrome browser. And once you log into the Chrome browser, automatically we have three windows already open. One is the PlumGrid console. The second would be the Horizon dashboard. And the third is the PlumGrid Cloud Apex. We're not going to go through the PlumGrid Cloud Apex today in the exercise. It's pretty much going to be everything driven from the Horizon dashboard. And we can switch back and forth between the Horizon dashboard and the PlumGrid console just to see that how packet implementation is done when you perform some networking options, operations from Horizon dashboard. So if you have the first exercise already open, let's start with the first exercise. In the first one, we're just creating a tenant and then creating a user, assigning that tenant or a project to that user and showing that how a different tenant within the OpenStack is implemented in the back end implementation as well. So let's log in into the OpenStack Horizon dashboard with the admin workflow. So once you double click on the Google icon, you are going to see three different windows, right? You just have to go through a different, okay, I'll have Valentina and the other guys actually help it out. There might be a, so are you at the certificate, like a page when you open up the Chrome browser? Just do it, I will click it, it should open. So for the, for the admin, for the Horizon dashboard, it's admin, PlumGrid, for the admin user, yes. And for the PlumGrid console, it's PlumGrid, PlumGrid. If you open up the guide that we sent you side by side, all the information would be in the guide as well, regarding the passwords and so on and so forth. So let's start with the first exercise. In the very first step, what we are doing is that we're creating a new project and seeing that how that project is side by side implemented in the back end implementation. So when we create a project, we can name anything I want. If you just do a MyLab-1, give the description accordingly, project for lab one. In the project members, you can assign different members to this, to your project. I'm going to actually create a user afterwards and then assign that user to this project. And in the quota information, you get all the quotas, which are by default set to the default values. You create a project, you go to the users tab, create a user. In the username, again, fill in any name for the user that you want to create for your project. Just maybe provide the passwords for it. So at the primary project, you assign the project to a particular user. Here, I'm just creating a user lab one for the recently created MyLab-1 project that I just created and assign it as a member of that project. So when you create a user and assign to that project, you can log out and log in as a user of your rising dashboard, which will only have access to that particular tenant. So the first operation is kind of the admin, cloud admins job, where he goes on and creates the tenants and the second is the user job. Yep. Okay, I'll actually, I think, so, Valentina, can you help this guy over here in the front? All right. Somebody would be here right now to actually help you out, so. So we just log in using the same credentials, use a lab one, password was slumgrade. So now we have actually logged in to the first project that we created, MyLab-1. From this project, you can just, like you just have the authority to actually go through just this project and not access the other project. So it's kind of a user-driven steps. Similarly, once we, let's find, yeah. So if you go to the backend implementation on the Plumgrid site, I have a lot of different users which are already created, but you're gonna see that a new tenant has appeared MyLab-1, and if you go to the neutron-based topology that is currently running, since we have not created anything, no networks, no instances, nothing, it's going to show you an empty canvas where there is no topology currently running. But it shows you that a separate tenant, a different tenant has been created in the backend implementation as well. So going back, that's pretty much the first exercise in which we just created a project, created a user, assigned the user to that project and then sign off and log in back again as a user of OpenStackLab. So let's move on to the next exercise. In the next exercise, what we are going to do is that go through an exercise where we create networks, create, for example, a three-tier application networks where you have three different networks connected to a router, and create instances for each network and then just provide connectivity and show that if you have connectivity across your different networks, different subnets. And back and forth, I'll keep on going back and forth from the backend implementation on the PromKit site, on the PromKit console, how the backend implementation is done and how the similar kind of implementation is shown on the OpenStack site, on the Horizon dashboard, on the network topology. Yeah, let me actually, so right now we are at page 17 on the guide, six size two. So on the first page 17 and page 18, you'll notice that the end goal, like how many different networks and what's the end goal in both from the network topology site, what are we trying to drive in this exercise? So we log in into the first project, that's the, I'm already logged in to the MyLab One project over here, and I'm gonna walk through creating three different networks, for example, a three-tier application where you have a web network, a lab network, and a DB network, and then creating instances accordingly. So let's go on to the network tab and create a network in this project. You do a create network, you can provide any arbitrary name for your network. So let's do user one dash web. In this, you can define the subnet name, so it's going to be web network and define, it's going to be a private IP network space, so you are pretty much open to use any IP network space that you wanna use for this network. So just for the sake that we use the same networks as defined in the lab, we can go ahead and use that. Six, eight, 50.0 slash 24, and then we provide the gateway IP as well. If you don't provide the gateway IP over here, it's just going to take the default one, but let's go ahead and provide the first IP as the gateway IP for this network. By default, this network has a DHCP, a word DHCP function enabled as part of the network itself, and you can define different allocation pools on its DHCP, on the DHCP, and accordingly the DNS name servers as well. And if you want to inject some host routes for your VMs for via DHCP, you can do that from the horizon dashboard as well. So once we click create, it creates a network within the first tenant, my lab one. If you go to the network topology within this tenant, you see that there is a network that we created, user one dash web with the same subnet already created. The blue line, it's an external network, and we are gonna get to it in exercise four where we can go over more that what different kind of external networks that we can create, but that's more related to the provider networks that Valentina was discussing earlier. So you have created an orange color subnet over here, the same kind of implementation via backend, if you wanna switch over to the Plumget console, you'll see that it has a network that's created with the same name, user one dash web with the DHCP enabled on it as well. So going back, let's create two more networks, one for the app layer and then another for the DB layer. Let's do user one dash app. So similarly, we can use any other IP address that we have already not assigned to the other network that we just created within this tenant. So it's 192.168. Let's do 40.0 slash 24 and provide the gateway IP as well. Again, the DHCP is enabled by default. So let's do a create. It creates another network and create the third one as well. That's user one dash DB network, provide the gateway IP for this network. So in this manner, we have created three separate subnets, three separate networks within your project one within the first tenant that we just created. And if you switch over to the network topology view within horizon dashboard, you see that three separate tenants which are not connected, which are isolated among each other, are separately created for each different tenant that you had, for each different network that you just created. So from the exercise, I think we have gone on to page 26 now. So we have actually created three different networks just close for a second. Sure. All right, so most of you should have it. We're gonna get you guys all the environments that you're missing. So just to kind of summarize so everyone that was on the wait list. So first of all, the port for the BNC is 10005. The password is Plumgrid. And then the logins for the Plumgrid console, it's Plumgrid, Plumgrid. The opensack one is admin Plumgrid, okay. And if you want the hands-on guide, I put it on a teeny URL, URL. So if you guys wanna, you wanna just open a, just open, I just wanna put. So it's tiny URL, URL slash G-T-A-E-J-H-K, G-T-A-E-J-H-K, yes. So tiny URL, URL. Tiny URL. Dot com. Oh, okay. Okay, so just write down the URL as well. Okay. So let me. Hold on, open this. Tiny URL, G-T-A, just leave it like this. So it's G-T-A-E-J-H-K. So most of you have already got to the, right. So anybody who has not yet got to the instance yet. Yeah, so this is the link. So anybody who wants to get the link for the user guide, that's the link that has just been uploaded with the user guide. So it's tinyurl.com, G-T-A-E-J-H-K. If you've already signed in, you will probably see the same user guide already emailed to you. So you can use that from there as well. Yep. Can you just, I couldn't hear you. Can you just come again? So we are actually creating networks from within the project itself. And that's not an external network. That's not a provider network. We actually are creating internal networks. So in the exercise, the second exercise that you have, you actually have to log in through the user that you just created. And within the user tab, let me actually go back and show you. So this is the user that I created. And once you go to the user in the network tab, you see networks and you just do a create network and that's the only workflow that you should have. Are you logged in as an admin user? As an admin? So once you actually select as an admin, you actually get the admin role. And from the admin role, you can actually, so you can actually create the external networks as well. But right now for this exercise, we are just creating the internal networks and not the external provider networks. So that's the exercise that's going to be exercise four, which we are going to get to it later on. On the guide, if you have a guide, we are following, we are right now on page 26. So we started the page 17, the exercise two and right now on page 26. So let me just go back. It's tinyurl.com, this one. Yep, so tiny, tiny URL. Okay, let me actually, okay. So for the user guide, you can access the user guide from the link that is provided right now. So if most of you already joined in and have access to the user guide, I can actually recap the first two exercises quickly as well. All right. Okay, so in the first exercise, let's actually log out and sign back again. So you sign it into the OpenStack dashboard using the credentials admin plumb grid. And you can sign it into the, you can again sign back into the plumb grid console using the username as plumb grid and password plumb grid as well. So let's just quickly go over the first two exercises what we did earlier. So when you sign into the admin, as an admin of your resin dashboard, you can go on and create projects to create tenants and projects within your OpenStack deployment. So we go to the projects tab from your admin tab and you can do a create project. Within that create project, just give any name that you want for your project. So if you open up this, there are like within the guide that we have over here at this link, all these steps have snapshots as well side by side. So you can open them up side by side and just walk through them. So you do a create project, add any name. Let's do one. Within the project members, you can leave it as it is and just go on to the create the project. And later on when you create the user, you can assign that user to the project that you've created. So go to the user tab, click the create user, add in any name. Just one. Given the passwords and from the primary project tab, you can actually scroll down to the project that you just created for yourself. So it's my lab test one and assign the role for this. You can just assign the role as member for the user that you're creating. Once you create the user and assign it to a particular project, you can log out from your admin dashboard and log in into the OpenStack horizon dashboard as a user of it. So you can do my lab test one with a password. And in this way you are actually into a new tenant. Again, which you just created. If you check from the OpenStack horizon dashboard and go to the network topology, it's completely empty except the external network which is the provider network which has already been created from the admin workflow. Just to save time, we have already created that. But from the tenant topology itself, there is completely empty. Similarly, if you see the backend implementation from the console that how this network is, this new project that you created, is it creating the backend as well? So you have my lab test one and you have the test lab over here as well. So this is the first exercise. Just creating the project, creating a user and assigning that user to that project role and then logging into the OpenStack horizon dashboard with the user credential that you just created. So in the same tenant, let's go on to the page 17 of your user guide and create the next few networks. Within the exercise two, you are going to create multiple different networks. For this exercise, we are using, we are trying to create a three tier network topology. Where you have three different networks and are connected with each other via router. So let's create three different networks within that tenant. Go to the network tab. Within the network tab to networks, do a create network over here. And here you can again name anything. So let's do user one dash web. Assign the subnet name. Provide any private IP space that you wanna do. So you can do 192.168.50.0. I'm just following exactly the same current address schemes as you have in the guide as well. So you have 192.168.50.0 slash 24. And on the gateway IP, you provide the gateway IP. If you don't provide the gateway IP again, it's going to choose a default one by itself. By default the DHCP network function is already enabled when you create a network or a subnet in your project. Just do a create. So that actually leaves you to create one subnet within your project that you just created. If you just scroll down to the network topology tab, you'll see that you have one network that is created completely isolated from all the other networks that you have and that's the topology that you have right now. If you do the same thing on the backend ones and within your network, which was that how the backend is implemented. So you have a network which is already created. Same name and with the DHCP VNFS, we have enabled the DHCP as well. So let's go to the networks tab and create two more networks just to complete the exercise. So we have user two dash app. The subnet name is anything else again. You can choose arbitrary IP or schemes. Let's do 40.0 slash 24. Just want to confirm it was 50.0. Let's do 40 this one. Here's the one that dash app. Add in the subnet name. Let's do one, I do one, six, eight, 40.0 slash 24, do a gateway IP and this way we have created the second network. Let's go and create the third network as well. So user one dash DB. Do a subnet name as DB, 192, 168, 30.0 slash 24, 192, 168, 30.1 and just do a create. So that actually allows you to create three different networks and you can see the same in the network topology. So you have three isolated networks created within the MyLab test one project that you just created. On the back end, if you want to see the back end implementation, switch on to the Plumgate console. You can really range your topology over here as well. So you have three separate networks which are created at the back end. Each has DHCP enabled, but each are totally separate right now as there is no router in between them to route the traffic in between them. So let's go on and so that actually is page 26 of our exercise. So let us know if you have any questions. We can slow down or like fasten the pace as well. So moving on, we create a router and then create the router interfaces for all the three networks that we just created. So we go on to the router tab within the network options and click on the create router tab. We can provide any router name. So you have user one dash router. And similarly, if you check on the console, you have a user one router that is created. Right now this user one router is not connected to any of the networks that you created. So you have to attach the interface of this router to each of the three networks that you just created earlier. So you have, you enter into the user one router config and go to the interfaces tab and click on the add interfaces. So you have, and there you, within the add interface tab, you can pretty much select all the different networks that are part of your current project. So you are in the my lab test one project. It will only show you the three networks that you just created. We can also provide the IP address, but since we already have provided the gateway IP when we were creating the network, so the same IP is going to be taken by this, by the router as well. So we have, so this way we have created one interface with the DB network that we have, and similarly we create two more interfaces with one with the app, one with the web subnet, and the third one with the application app subnet. So you see, within the interfaces tab on the horizon dashboard, you have three different interfaces, part of the router. So yeah, and each has got the same IP that you provided as a default gateway for your network when creating a network. So you go to the network topology tab and see that if you have, if you can see the same thing in the network topology. So you have a router, which is showing that it has three interfaces which are active with one of the networks as 192.168, 50.1, 40.1, and 30.1, and similarly the names are mentioned over here as well. If we can see the same thing, how it is implemented in the backend, we can go onto the Plumget console and see that there is a router in between the three networks that you have just created, and it's connected to each of the three networks. So this is, so as a last step within this exercise, you're going to create two VMs or in fact, VMs in each of the three networks that you created and just see that whether you can have traffic connectivity between these three VMs. So moving forward, let's go on and go to the compute part of compute tab within the project one, go to the instances and launch an instance which will then allow you to actually pick the different security groups and different networks which you have already created. So let's name this as web VM. You can select the different flavors as well. So right now we are just bringing up, since it's just a single instance, we are just bringing up a very minor, tiny flavor of CROS already configured. Within the network, I've named this as a web VM, so let's pick the web network as the VM is connected to. So you have to use a one web as your interface with which the VM would connect to. You do a launch and the VM gets created within that particular network. Once it's active, it goes through a process of spawning and then once it's active, you'll see that the IP address that it got from the DHCP that was enabled on this network, so it's the same network and since we never gave any pool for the DHCP, it's pretty much the whole slash 24 as a pool for the DHCP. We can see the same thing on the network topology. So if you go on the network topology, you check the VM, okay, it's up right now and it's connected right now to user one web. So let's go on and create two more instances. We go again to the launch instance. This time we are creating a DB VM. We select the same image that is available and we select the DB network over here. This time the DB VM should come up with the DB network and you can see that the IP address that this DB VM is getting is from the same network pool that you have for the database for the DB network that you created. So you can go back again to the network topology just to see that the VM is up if it's connected to the current correct network. So you have a DB VM which is connected to a DB network within the network topology. If you navigate to the networks tab, you can see the same ports within the networks as well. So if you go to the, we had just created a VM which is part of the DB network. You enter into the DB network details and you see that there are two interfaces, two ports which are created as part of the DB subnet. So you have one as the interface with the router. It shows the router interface and the other is the compute Nova, for the Nova instance that you just created. So going back, let's create another instance. So the third one is app VM. And in this one we are going to use a third subnet that we created so that's user one app. Let's create a VM over here. So this time when the VM comes up as an active state you'll see that the IP address it's getting is from that subnet. So we have three VMs which are right now connected to three different subnets. And then each of these subnet has an interface with the router so that the traffic can be routed in between the three networks. So that's login into any one of the VMs and see that if we can ping any of the other VMs from that VM. So we, in fact just let me go back. So if you just click on any of the VMs, you're going to the VM details. On the console tab you can directly go to the console of this VM. So just do a on the console over here. It's a Syros VM so it's the admin is Syros and password is CapsWin. So once you enter, let's just confirm that if we have the same IP over here as we are showing in the, so it's 40.3. Let me go back to the instance details to the horizon dashboard. So on the horizon dashboard we had a similar IP for the app VM as 40.3. So the app VM internally has the same IP as well as it's shown in the horizon dashboard. So let's go back again to the instance and try to connect to any of the two other two VMs. So we can ping, we can send a ping traffic for 30.3 or 50.3 and it should work because from the network topology you can see that there is a router in between the three networks. So the VM from each of the networks should be able to ping other VMs. So just do ping 192, 168, 50.3 networks and similarly let's try the other one which was 30.3, this works as well. So this actually completes the exercise two where just to recap you created three separate networks. Then you created a router in between these networks, attach the interface of this router to each of these network that you created and then spawned VMs within each of this network and then try to pass traffic across it. So as the network is directly connected to each of the networks, you have the traffic connectivity across the networks. So that ends our second exercise and now we are actually on the page 35 by the end of page 35 and from page 36 we can start off the exercise three. All right, so moving on, I'm actually going through the exercises so that we can complete the three, four and five exercises within by the time limit that we have and you have the leverage to actually check other instances, what else that you can do with the instance itself. So let's moving on, let's go with the exercise three. Within exercise three, what we are gonna try into two is trying to figure out that how these tenants are different projects that you created that are completely isolated from each other. So they are completely separate different networks. So yeah, so yeah, let's pause. Okay, so let's just recap a little bit of what we've done so far since we've been doing a lot of different things and I know some people were kind of trying to catch up with the overall thing. So what we did in this environment, we created a bunch of projects, right? So each of these projects is a tenant and for each of these projects we started creating some of these networks. So you saw that as you started creating networks you started getting these vertical lines show here. So those are your layer two environments and for each of those you specified a specific IP range. And as you started creating VMs and attaching VMs to these networks you started seeing that the VMs were getting IP addresses that belong to that subnet that we have there. So for whatever you selected, if you follow the guide you selected dot 30, dot 40 and dot 50 and that's the IP address that the VMs got in that environment. You can see that dot one is your default gateway so that goes assigned to the router interface and then the dot three is the interface that got assigned to the VM itself. Okay, so these are your layer two subnets and then what we did as the next step is that we went back to the network and we started creating routers, right? So the concept of router it's obviously layer three construct and it's what we will use to interconnect the different subnets within a tenant environment. Now I know some of you were asking me where is this router living? How is it implemented? So the answer for that is that it depends and the implementation of the router depends heavily on the backend that you're leveraging. So the router could reside on a central component what is usually referred to as a network node and that is kind of a server that is dedicated to advanced functions. So that can perform layer three functions so you will kind of send the packets through that element there. In a Plumgrid environment it's quite different because we actually have a kernel component which is the Iovizer I was referring to earlier that can implement layer two, can implement layer three, can implement layer four, can implement security. It's the one that collects all the statistics that you see in the cloud apex window for example. So when you create a router you actually don't spin any central element. You just leverage this distributed functionality that we have as part of the Iovizer framework. Okay, so just to kind of clarify where things live. In a Plumgrid environment everything lives distributed. The beauty of OpenStack is that it doesn't matter. If you're just a consumer of OpenStack as a tenant all you see is these abstractions, these layer two subnets, these routers, these functionalities that you have here. Okay, now once we have created this network topology you can see that the tenant has a bunch of networks, the VMs can talk to each other but what it's missing here is that they actually cannot connect to the outside world. And I know some of you had questions on okay, how do I connect out? Right, so this is where things start becoming interesting because we started seeing the interaction between the tenant world and the provider world, the admin of the cloud. Okay, so we're gonna start now going through the next step which is how we connect from a tenant environment to the external network. And we're gonna see that actually that step is something that the cloud admin has taken care of for me ahead of time. I have already an external network that is created which is this blue network and as a tenant I can just consume it. Do you have a question? Do you need help? Okay, Deepa? Okay, I have a question please. So the cloud, if the cloud Apex dashboard if you cannot get to it, some instances that are having open is the same IP address and the same port slash cloud Apex with a capital A if you want to play with that. So we'll take a look at the environment if this is not showing. Okay, so the question is when I launch a VM and I connected through a network is that going through OBS? And the answer is not because in this specific lab that you're working on, there is no open-b-switch. Open-b-switch is one of the plugin options that you have and in this lab you're not using open-b-switch, you're using a different backend. So if there was open-b-switch in the picture the layer two functionality would be provided by open-b-switch and the layer three functionality would be either implemented as an agent or through the network node. Here because you're using Plumgrid, the layer two and layer three functionality are implemented by Plumgrid inside the kernel. Okay, so it's one of the other backend depending on what you select at the beginning of time. Any other general questions? So the default user, all the Plumgrid stuff it's Plumgrid Plumgrid and the open stack one it's admin Plumgrid. Yeah, the console is Plumgrid Plumgrid and cloud Apex is Plumgrid Plumgrid. Yes, yes, yes. Yes, so when you see projects, usually projects will show up on the Plumgrid side when the two databases sync and sometimes the trigger is the creation of the first network. So when you create the first subnet that's when the project will show up on the Plumgrid side and when the VMs will show up and all that. Okay, I'll come take a look in a sec. Okay, so if everyone is following along up until now what we're going to do next is we're gonna go into the external network. So Jamal will come back and keep going through the next couple of exercises. So what we're going to do for the next two exercises is first we're gonna look at the external network so what we're going to do is we're actually going to log out as a user and we're gonna log back in as an admin and we're gonna take a look at the external network configuration and then we're gonna go back as an admin and connect to the external network and then the last step that we're going to do as part of this lab is that we're gonna configure security policies to further isolate and micro segment workloads within a project. Okay, and we'll keep coming around and helping you guys. So for the external networks we have created an external network already. We just pre-configured. So within my lab, within my instance over here I have created a number of different tenants and different projects so that's why you see all the different tenants, all the different projects, all the different networks creating each of these tenants and since it's an admin user you get the view of overall how many different tenants are created. So when you click on the networks tab you get all the networks created and all the different tenants that you have. So within the external network you see that one of the networks among there is an external network which is connected to which has a subnet which is routable from the outside. So you have an external subnet with this particular gateway IP from which you can actually, once you can connect to this subnet you can move on or you can actually have the connectivity from your virtual world, from your project, from within your tenant to an external world, to the legacy world. A similar kind of implementation for the back-end implementation is done through a service through a... So in the back-end implementation we have an external network created as well. We just shown over here. So you can actually log in into your... For this exercise what we are going to do is to log in back into your project, into your tenant and then connect your router with the external network and see that how internal VMs can have the traffic connectivity with the outside world. So let's log out from this admin tenant and log back in as one of the projects that we created. So it was user lab test or test lab. Let me just confirm what are the credentials for my user. So I have my lab test one. So I log in back into the project by the same user credentials that I created for the lab test, for the project. So you have my lab test one. Here we have, so you get the overview, the summary that you have three instances which are connected to three different networks that you created. So just go over the network topology. So you have three different networks, brace devices, and that are connected to a router. And now the router is not connected anywhere on the external network, so you cannot connect outside with the external world right now. So let's go to the routers and do a set gateway operation which then allows you to pick whichever external networks that you have already created and connect your router with the external network. So we have just created one external network that we just saw from the admin workflow. So you actually log in as an admin and see what are the different external networks that you have. And from here you can choose whichever external networks are allowed to you from the admin workflow. So we have created one external network and we are going to do a set gateway operation for the external network that you just created. So we choose set network, select network as external, and click on the set gateway. So what it does is that it creates an interface between the router and the external network. So now if you check the network topology, you see that the router, the tenant router, the virtual router within that tenant is right now connected with the external network that you have created from the admin workflow. So all the VMs, so all the different three, all these three networks now are connected to the same router and should have connectivity outside as well. So we can now actually go into the VMs and see if they have connectivity, for example, if they can ping Google. So let's do ping.a.a.8 and you should see that it's connected with the outside world. So let us know if you have any questions we can... Yeah, all right, yep. Okay, yep. So every time you create an external network, you can take a look, I think on the Plumgrid side it's a lot clearer what happens there. So what happened here is that, as you can see, a NAT VNF got created. So every time you connect a tenant environment to an external network, a NAT function gets implemented in the backend. Now this is again a question of where it gets implemented and all that, but forget that part. Whenever you create a NAT function, the moment you enable external connectivity, S NAT gets enabled on that NAT function. So if you actually go and look at the NAT configuration, you can look at what has been configured there and you can see that Alba NAT was configured so that you can map your private IP space to the public IP space of the external network. So that's the first step, that's S NAT, Alba NAT. Now the moment you, instead, want to get someone from the outside to connect to a VM, it's when you define floating IP and that will obviously correspond to inbound NAT and the way you would do that is you would actually do it from the openSack side, you would go to an instance and what you can do is you can select, for example, your web, VM and you can associate a floating IP. Okay, so once you associate a floating IP, it's when you would start seeing your inbound NAT configuration getting created. So NAT always, always comes in the picture when you use an external network type of provider API. Okay, any other question on the external connectivity? So this is certain, the external network is a very tricky point because it's where you have these two worlds, right, the virtual and the physical coming together. So it's usually something that the cloud admin controls as you saw before, right? The cloud admin was the one that created the environment, you created the external network for you and you as a tenant are just consuming this as part of your project, all right? Yeah, so let's go to the next, which is the last exercise we're gonna be able to cover today together, which is the security policy function. So the importance of security policy is obviously that once you create your tenant environment, what you want to be able to do is to farther segment workloads that are part of your project. For example, if you have your web app and web app and DB tier, you might want to define policies across the three environments, okay? So again, the implementation of these policies can vary depending on the backend, but from an open stack perspective, it's a very simple abstraction, you just define groups and you start mapping VMs to these groups. So for example, you're gonna find a DB group, a web group, an app group, and you can start defining what type of policies you wanna enforce between them. Do you wanna let them connect? Do you wanna not let them connect at all? Do you wanna just allow specific protocols or ports to be open? So that is what we do through security policies. So Jamal will walk you through a couple of examples of security policies. And then as I said, there's a lot more things that you can do obviously. There's a lot of API based configuration that you can do. So what we did today was UI driven. Everything that we did can also be done as an API. So we'll see if we have a couple of minutes to show you maybe just a couple of API calls just to give an idea of what they correspond under the cover. But this is kind of what we wanted to cover today and you're welcome to continue to work a little more on your instances. Obviously on the side, if you wanna go more into the advanced scenarios. So let's go into the security part. So for the last exercise, that's exercise five. Let me share the page number as well. What we're actually going to do is to have a scenario where you have similar three tier kind of application and you wanna have security policy to block some traffic and allow some traffic. So you, for example, if you want to have two different networks and you have web and app, you have web and DB network and you want to connect, have traffic connectivity like ICMP traffic connectivity between DB and web networks, but you wanna block SSH traffic from DB to web, but the web can connect why SSH to the DB networks. So let's go on into the process and I can actually then elaborate more on each step that how do you apply that. So when we created these three VMs earlier, I have created them with the default security group. So what I'm gonna do is that create two more with some different security groups that I'm gonna create right now and those security groups will have rules that can actually enable me to actually allow the traffic that I want for each network and deny the traffic that I want as well. So let's go to the access and security and by default each, you'll see that each project and each tenant that you created by default gets created with a default security group. It has some default security rules as part of its group. So let's go on and create a new security group which we can call DB and then assign VMs accordingly to it. So let's go on and create a security group that is known as let's say security group DB. Security group for DB networks. So as you create a new security group from your Horizon dashboard, you can actually manage its rules. So if you just go into the manage rules section, you'll see that there are two rules which are automatically created within your security group. Now let's go on and delete these because we wanna create rules which specify what we wanna accomplish over here. So we want to have ICMP traffic being allowed from both web and DB networks but only the web should be able to SSH to the DB and DB should not be able to SSH back into the web. So let's go on and delete these two rules and create another rule. So right now in fact, we'll actually delete all the rules, create the VMs and then see how step by step that we can go. So go back to the access and security, create another security group that is for the web VMs. So let's do security group dash web. The security group dash web, let's go on inside and then delete the default security rules that are part of the security group again. Let's select all, delete the rules. So right now you have created two different security groups. One you named as security group DB and then the other one as security group web and deleted the default rules that were part of the security group, right? So let's bring up one VM in each of these groups and then see that whether these VMs can have traffic connectivity between them or not. So let's do a web VM that has zero image. So within the access and security tab, you see that all the security groups that you created as part of your project are available right now. So you have security group web, you have security group DB and the default one which is created. If you don't pick and choose over here, by default you'll get the default security group. But right now we are creating a new VM and we are making it part of the security group. It's known as the web VM so we are making it a part of the security group web. Similarly on the network, we are also going to attach it to the web network and then create the launch. Since this is a very small instance, I'm actually going to delete the other VMs so that we can create multiple different VMs over here. So we have a single web VM which is part of the web network and it's connected to the web security group. Let's go on and create another VM which we can call DB and then attach it to the DB network and bring it on with the security policy as the security group DB that we just created. Security group DB, details is DB. On the networking tab, you can add the DB network over here. So let's go on the network topology and see that if we have the two VMs up. So one VM is connected to the web, the other one is connected to the DB part. Once you actually, if you go back to the instance details, you can see in each of the instance details that which security group are they connected to. So over here, you can see the security groups it has attached to a security group DB and there are no rules currently defined. So when there are no rules defined in your security groups, it is implicit deny for all the traffic that is going out. So right now, you should not be able to connect to anything outside. It should be completely isolated. So let's go back and check the other instance quickly as well. So we have web VM, it's connected to security group web. So we can actually then log in into each of the VM and see that whether we have connectivity or not. So let's log into the DB VM just to confirm if we have the correct IP addresses over here. So this is the DB network and let's try sending a pink packet to sending an ICMP to 50.4 which is our web VM. So let's do 192.168.50.4 and we should not be seeing any traffic. So you see earlier we, I mean, if you check the network topology, you have a router which is connected to both instances. You are earlier able to connect to both of them because you had security policy allowing you to have connectivity between the two security, between the two VMs. Right now, you are connected to a security group which has no rules as part of its security policy. So it's implicit deny for all the traffic that is coming out of the VM. So you cannot connect to the other VM, there is no traffic connectivity. Let's go to the instances, like let's go to the web instance as well and then just send a pink packet from there as well just to see that if we have no connectivity from that end as well. So lock in, so it's the same VM, 192.168.30.4 so you cannot have any packet over there as well. So let's do one thing. Let's keep the pink running on each of the VMs and then subsequently we can create the security group rules and see that how the traffic would be allowed in each case. So we have a DBVM which is trying to connect to the web VM and we have a web VM which is trying to connect to the DBVM and both are not connected right now. So let's go to the existing security again. Let's start with security group web. Manage rules, here there are no rules specified right now because we deleted all the rules. So it's an implicit deny for all of them. If we add rules we can add different custom based rules but let's just allow ICMP packets to go outside of this VM. So let's do all ICMP. The direction would be egress and since we can actually have the remote as the default, the other security group where we want to actually connect, send the traffic to. So when you have the remote as a security group you get the options that which security group you wanna create the security group rule for. So you can do security group DB. So this actually now is creating a rule, an ICMP rule which is allowing all egress and ingress traffic for between the security group web and security group DB. So once you do an ad you should see that from the web VM because it was the web security group that we created the security group web we actually added the rule in. You should see that in the web VM you should the traffic starts flowing. So we have allowed the ICMP packets to actually go through and come back only from the web security group. So if the traffic is initiated from the web VM that is allowed right now. Let's go and check what's going on on the other end. So we have one VM over here and similarly on the other security group we can add the security group rule over there as well just to allow the ICMP traffic from DB as well. So we have all ICMP, we have egress. In this case we are currently in the DB security group. So we will, the remote security group would be security group web and do an ad over here that would actually allow you to have complete flow across the two security groups. So traffic initiated from either of them should be allowed in this case. So let's stop this and just test it once again. It works from the web VM right now. So this is the web VM that we created with the web security group and let's try it again with the DB VM and ping it to the web. The traffic initiated should work because we have a security group rule that allows the ICMP package to go through. So let's try the next step where we want to accomplish that we have the SSH from DB. We should have the SSH traffic. The DB should be allowed, the web VM should be allowed to SSH into the DB but the DB VM should not be allowed to SSH back into the web VMs. So let's quickly go, here just two minutes. Do you want to go through the? Yeah, I think we're running out of time. So I wanted to wrap up and make sure that everyone has all the information next. So we're going to leave these environments running for another hour or two but there were a lot of environments so we cannot keep them running forever. There is a couple of follow ups. So if you want to learn more, I know there were a lot of questions about Plumgrid and the technology underneath. We are in the expo floor. Our booth is C21 so you can come see us. We're going to be hanging around here as well. If you want to keep testing and you want us to just keep your environment running for a little longer than an hour or two, just see us again outside and we can keep it running longer. We can give you up to three days which you can just cannot do it for all of us, all of you guys. We hope this session was helpful. We apologize for the bumpy start but we wanted to get as many people in. Thanks a lot for sticking through the bumpy start and I hope it was good for you. And we got to wrap up because we were invited to go first.