OpenStack Provider vs. Tenant Networking (3 of 4)

this video is the third in a series your ultimate goal should be that hands-on lab right there on the bottom this is provider vs. tenant network so what we want to do is have it clearly understood what the difference is between these two types of networks then Zack is going to come in and show you how to actually wire all of this stuff up using the OpenStack command so here's an example of showing the network function virtualization to create a tenant network in this particular case both of these virtual machines are connected on the same tenant and the traffic flow couldn't be simpler it's just like this so we see a Linux tap to a Linux bridge where the security group is running to a bridge internal connections through the integration bridge now more importantly what I want you to observe is that virtual machine 1 and virtual machine 2 are in the cloud Nova built all of this nova knew the source nova knew the destination and as long as we tell nova the name of the integration bridge it wires everything up for us so the command to create the network that actually allows these to be networked is really straightforward because all the hard work is done in the name of all this stuff now let's take a look at that same diagram this time at a higher level because I think it might be interesting to introduce the fact that there might be more than one compute node in fact there would be many of them what if I have two virtual machines running on the same computer first of all I want you to observe that the traffic flow is tremendously efficient if these two virtual machines are talking to each other the traffic stays on the same computer note staying within the integration bridge never leaving in this particular case we see that both the source and the destination of the same tenant it's on the same compute and it's on the same subnet now what if we have an example where it is the same tenant but a different compute node and and it's still the same subnet well in that particular case as long as OpenStack knows what the name of the VLAN bridge is and it does because we told it then what OpenStack is going to do is it's going to select from a pool of VLAN so let's say we create a pool of 400 VLANs then OpenStack is free to choose whichever one it wants to of that pool and it would then use that particular VLAN up to network everything in this yellow VLAN so the traffic that you'd see again couldn't be simpler it's simply tag with a VLAN tag and remains between the two now hopefully you're thinking well wait a minute this doesn't look as efficient as if both of these virtual machines would be on the same computer note I would agree with you and there's no reason when you're deploying the virtual machines if you know they're going to be very chatty put them on the same computer know that but you know that being said this still works fine and since we're trying to understand the difference between provider Nets and tenant networks this is a tenant network why both the source and the destination are within OpenStack and it was within open stacks ability to build all the network function virtualization it handled all of that for us so now what if we have a situation where it's the same tenant the same compute node but it's a different subnet so I'm showing VM one the yellow one as the same tenant as VM two but they're on different subnet so I made the purple one a different color again the traffic flow couldn't be simpler and the way that the people in OpenStack figured this one out is that OpenStack creates a network namespace it installs to bridge internals it puts the the rules in place with IP tables and voila a router created right out of thin air and now we have a router running between these two subnets it works just great and it does pass the rule and the rule being both the source and destination are within openstack the OpenStack mechanism itself was able to build all of this didn't have to read anyone's mind it said okay same tenant so I open sac will create the quantum router and wire all this up for us our last example of a tenant network is what if we have the same tenant different compute nodes and different subnets other than some asymmetry in the way the packets flow probably no surprise what you're going to see happen is when traffic leaves the yellow subnet it's actually routed onto the purple guy's subnet on the originating end now we're actually in the correct VLAN so that the destination requires no routing it goes right straight in when you look at the path returning the same thing but on the other side so there's a bit of asymmetry in this but it's actually quite elegant so if I run the animation for you again you'll see the traffic flow working like this on that on the egress in egress ingress and egress relative to virtual machine number one now finally let's talk about provider networks so the number one the organization that built and paid for the hardware that runs OpenStack is called the provider so the provider wrote the check and built all of this the provider installs connectivity to the outside of the cloud or this won't be very interesting now that external connectivity could be Internet it could be enterprise local area networks or whatever networks you would would care to connect so this is the distinguishing factor right here OpenStack can't read our minds in this particular case if we're going to somewhere outside of the cloud then that is a service that's provided by the provider hence the name provider network so we say that these networks that connect to the outside are called provider networks and only an OpenStack admin can create a price a provider network so in this particular case we see the virtual machine passing through a router for reasons I will explain in a moment through is provider access and then on to the outside only an admin can build this because OpenStack can't figure this one out we have to configure this so that one that once the provider network is built if you attach to this network it's guaranteed to go to wherever that destination is and incidentally you can have lots of provider networks you're not restricted to just one so let's hop back to that network function virtualization and take a look at the wiring so I'm going to put a divider line right here and I'm going to show you the part that connects right here is actually a tenant network the other part the part that continues on out of the cloud is the provider network now without playing around with any configuration without doing some permissions modification a tenant is certainly allowed to create its own tenant Network a tenant is allowed to create this router a tenant is certainly allowed to create an interface to the router that connects to the tenants network if the provider network is shared then the tenant is allowed to create that other interface which connects to the provider network so zach is going to show you this shortly so you're going to see it will create the router then you'll create the interface on the inside he'll create the interface on the outside and now it might make more sense if we take a look at the rest of this flow by sort of obfuscating the background like this and let's just take a look at the flow itself so what we have now is a provider network that has a certain IP address range and here's the thing the IP address range that the tenant creates up here can be whatever the tenant wants the IP address range the tenant grades could actually step on the provider networks IP address range and we all know that if you run into a situation like that the solution is a NAT so unless you play around with the config files when that connection to the provider network is built the router is definitely given an IP address on the provider network and the router will perform an act function specifically what will happen is a floating IP address will be configured by the tenant to point to that virtual machine and this is a one-to-one assignment so when a floating IP address is assigned it is pointed directly to that virtual machine and no other virtual machine so interestingly the virtual machine has an IP address from the tenant network the virtual machine has no idea that a floating IP address was assigned to it notice the virtual machine even know what the floating IP address is but here's the thing if you're in the outside world out here and you want to get to that virtual machine knowing the virtual machines IP address is not going to help you you actually have to know how to get to the floating IP address which actually in the network function virtualization is assigned to the outside interface of the router the OpenStack configuration of the router itself is smart enough to perform the net and relay the traffic into the virtual machine now I'm going to assume at this stage that there's going to be questions because there always is in class and rather than avoid typing out an answer every time this question comes in I'm going to answer it right now and here's the question can I connect directly to the provider router I don't like this floating IP address I don't want this floating IP address I am an enterprise we don't do that this is like Amazon Elastic IP we're considerably smaller than that in inches of course you can but we're going to tweak a few things namely in the XE Nova policy JSON file we're going to have to find a rule that's titled just like this that network : attached external network and we're going to scratch out that only the admin can do it we got to get rid of that leaving nothing but those two quotation marks right there now as soon as this rule is applied then tenants are going to be allowed to attach this virtual machine right to the provider net skipping the floating IP address and all that stuff making it look a lot like a classic VMware deployment now just eyes wide open on this guy's as to what just happened yes it's really nice because it's for instance if I had a load balancer or another service out there I could bring traffic into here and we have layer two connectivity because man they are on the same subnet right straight up there that yeah that's great that works I just want you to realize that look at it from the other perspective if you do it this way a really powerful virtual machine just got layer 2 connectivity to a provider network now if the provider network is your network well fine it's your virtual machine and it's your network but if you're a service provider and you're selling these services the likelihood of you allowing your tenant to do something like this is extremely low but it is possible so that brings us to the end of the provider vs. tenant networks if you made it this far the coup de Gras is actually the last video right down there that's the hands-on lab Zach is going to walk you through that and if you got this far it definitely that's the one to take good luck on the certified OpenStack exam by the way you

Channel: Alta3 Research, Inc.

Views: 7,058

Keywords: openstack, certified openstack administrator, neutron networking, openstack neutron, linux netorking, network function virtualization, cloud netorking, kvm, openvswitch, openvswitch openstack, openstack networking, Alta3, Alta3 Research, Alta3 Research Inc, Training, IT Training, devops, Computer Training, Tech, IT

Id: 8LaeIUQVwKc

Length: 12min 29sec (749 seconds)

Published: Mon Mar 13 2017