Control and data plane connectivity models - Cisco Tutorial

- [Instructor] In this lesson, we're going to talk about the control and data plane connections that exist in the solution. To start with, let's talk about the connection base ports. So, the control management connections are all going to be UDP and they can use different ports. Now, the base ports that we use for UDP connections are 12346, 12446, 12546, 646, 746, 846, et cetera. The key thing that you want to focus is notice that the third octet is going to increase by 100. This is done to provide load balancing as well to provide assurance within the connections. So, there are eight ranges that we can choose, and again, they will increment by 100 off of what the base ports are. Now, in addition to that, it's also important to know that we also have a actual port value that is used, and that is the combined value of this base port, which is based off of the values that I'm going to circle in blue. And it's also going to be based off of what the port offset value is. So, the default value for a port offset is zero. So, if you think about it, if I have 12346, and I've got a port offset value of 0, that's going to give me a 12346. And the next one of 12446, plus 0, will equal 12446. Now, when you set that, it's set across everything across the board, so it doesn't really matter. But if I went into a device and I changed that port offset to, like, 1, then what that would be is, all those values that you've shown before up above would not end in a 6. They would end in a 7. And you can kind of see how that carries forth. And that's just the way that we are going to come up with the actual port that were used. Now, the reason that we actually are going to do this is this is going to help us overcome the limitations with NAT. If we have two edge devices and we only have one public IP address, we could use the port offset to make sure that the R1 and R2 devices have different ports that they're using for the connection. So, just something to kind of be aware of, when we start seeing on the diagrams, while they might say 12346, 12446, et cetera, you can change that by adding into the port offset value. It's not the standard default setting, standard default is zero, but it's a way to kind of overcome that. So now that we talked about that, let's talk about how we actually get the connections. So, we're going to talk focusly on cloud control connections. So, this is how we get to the vBond, the vManage, and the vSmarts. And so if we went through the process of putting 'em into a hosted environment, the way that you would get connectivity is going to be across the internet. So, we have our edge device, and this edge device is located at a branch location. And so it will use the traditional MPLS underlay, which is going to go through your CE. From that, it will hit your core and out to the firewall, which, preferably at that point you're probably going to do some filtering, probably some network address translation. And then from there, he'll be able to reach the vBond, the vSmarts, and the vManage, okay? Now, if you had an edge device in that same data center, he would use the VPN 0 transport to get to the CE, up to the core, through the firewall, and then from the firewall, he's netted, and he has that same reachability to the cloud. So, from this point it's pretty straightforward, nothing is too complicated. Now, adding onto this, we're going to want to make sure that we have connectivity across all the transports for having that highly available solution. So, we're going to go ahead and add in the circuit for the internet. And so within that construct, what the connectivity will be for your edge device, he just goes off for the VPN 0 through traditional internet routing and he's able to reach the cloud. Now, for your box in the data center, we're going to add a transport. Now, he could go up to the core firewall. Realistically, this is just a rough sample. He could directly peer to the internet, but in this case, I just drew it so that he's going to go through a firewall, a different leg, and then he is going to have access into the management cloud. So, we're in good shape from this perspective. Now, one of the things that I do get asked time to time is why are we going across both transports? So, let me go ahead and set something straight for you right now. It's important to note that while we are using the vBond, the vSmarts, and the vManage as our cloud management, a crater could come along and take out our cloud infrastructure, and we'll still be able to forward traffic. Now, depending upon what we have lost the connectivity to could have different ramifications. So to start with, if the vBond is not there and then the router is reloaded, we will not be able to authenticate and then get able to attach to our vManage and vSmarts. So that's something to be kind of cognizant on. If the vManage was to go down, we would lose any of our logs that might've been generated, or the streaming telemetry that's sent to the vManage, but the network's still going to forward business as usual. Now, if the vSmarts were to go down, then we would use the cache time for OMP. And then also, we depend it upon what is the actual key lifetime within IPsec. So by providing that second transport, if there was a problem across, say, the internet where a backhoe ran across, we would still maintain the tunnels from this edge device to the HQ location. But if we only ran the control connection across the internet, at some point that key exchange timeline would die out, and that could bring down the tunnel across that connection, which would be a bad thing. But if we actually still maintain the full control connections to the cloud, we can still do the key exchange, and OMP routes, and all that other fun stuff across that MPLS transport while we're still using that MPLS transport as our tunnel. So that's why we want to provide both options for the management cloud connectivity. Hopefully that makes sense to you. And just to kind of draw out, here are those UDP base ports again that we're going to be using. So again, this might be a little bit more visual. You'll notice that it is the third variable that's incrementing all the way from 12346 to 13046. So, and that does not include the base port, so you add the base port to that, and that will get you what your cloud connections are. And so that's the rules or reports you're going to need to add into the firewall to allow 'em to have connections to that cloud. And those are the ports that you're going to need to open up to allow access to the vBond, vSmarts, and vManage. Now, let's take a look at the on-premise controllers and what that looks like. So, when we talk about on-premise, we can see that we've got the UDP ports as I defined earlier. It's going to be a slightly different behavior, in the fact of what we're going to do is the control connection is going to come across, hit the CE, and from your core, it's just going to go straight to that location. And then if we had a device at your data center, same thing, he's going to go out, hit the CE, or maybe he's just going to go straight up to the core, kind of depends, and it'll have that connectivity. Now, when we add the internet, basically we want to make sure that we put the appropriate firewall rules to allow those ports to have access to the management cloud. And if you have base ports, you might have to expand those rule sets. So, if you have another branch that's using a port offset of one, and everything else is using port offset of zero, you're going to have to count for 12346 and 12347, 12446 and 12447, et cetera, et cetera, et cetera. But the connections will look similar in the fact that they'll go across VPN 0, through the internet, through that firewall you've permitted, and then into that DMZ leg that you created for the vBond, the vSmarts, and the vManage. And so that's what your on-control connections would look like. And then at your data center location, I just ran it through a leg of your DMZ, and again, it's going to get the same connections towards that. And so both these diagrams have showed you what the control plane connection looks like. Not the data plane, but the control plane. And so let's now talk about the data ports. So, the data ports are going to use the same construct, except for we're only going to use five different ranges for the data ports. So, we're going to use 12346, 12366, 12386, 12406, 12426. Now, if you'll notice that what we're actually doing is, on the fourth digit, it's actually incrementing by the value of 20, and the numbers have changed. So, it's the same construct where if we had 12346 and the port offset of 0, then that is 12346. And then if we did 12366 and the port offset of zero, that would equal to 12366. Now, if we change that port offset from 0 to 1, then what that's going to do is that's going to change our values on the end to, like, 12347 and 12367. Something to be cognizant of as you start to look at the data ports, right? So, let's look at what the actual data plane connectivity is going to look like. So, from the data plane model, what's going to actually happen is traffic is going to come in from the PC, it's going to be unencrypted or unencapsulated, it's going to hit the edge on the service-side VPN. And then from there, what we'll do is we will forward traffic across one of the different tunnels. So, it could be taking the path across the internet, or it could take across the MPLS. And then once it reaches there, it will be decapsulated, de-encrypted. And then we'll go through the process of forwarding the traffic straight to your core based off of the service-side VPN routing table. And that's what the data plane connection's going to look like. So, hopefully this section has provided you a little bit more clarity as far as the UDP ports that you're going to be using for your data plane connection, and the UDP ports that you're going to be using for your control plane connection, as well as some of the rules and the logic as far as whether you're on premise or you're on-prem with your cloud deployments. Now, one thing to note, if you're going to do on-prem your own self, is you want to make sure that you place your copies of your vBonds and vSmarts and vManages in geographically disparate locations, so that if you have an issue, right, smoking crater syndrome is a design thing, so that you still have connectivity to your other vBonds and vSmarts and vManages. Thank you.