WEBVTT 0:00:03.180000 --> 0:00:07.360000 Hello and welcome this video titled SDN's relationship to management control 0:00:07.360000 --> 0:00:09.740000 and data planes. 0:00:09.740000 --> 0:00:14.260000 So we first need to define what these planes are. 0:00:14.260000 --> 0:00:19.660000 So everything that a networking device can do, a router, a switch, a firewall 0:00:19.660000 --> 0:00:24.440000 can do, can be categorized as residing in one of these planes, the management 0:00:24.440000 --> 0:00:27.040000 plane, the control plane and the data plane. 0:00:27.040000 --> 0:00:29.460000 Sometimes the data plane is also called the forwarding plane. 0:00:29.460000 --> 0:00:30.860000 They're one and the same. 0:00:30.860000 --> 0:00:35.160000 So let's talk about what these planes are and specifically how they relate 0:00:35.160000 --> 0:00:38.660000 to our controllers and our software divine networking. 0:00:38.660000 --> 0:00:40.980000 So number one, the management plane. 0:00:40.980000 --> 0:00:45.520000 So the management plane is responsible for giving you the network administrator 0:00:45.520000 --> 0:00:53.220000 access to control and configure, monitor and troubleshoot the device. 0:00:53.220000 --> 0:00:57.940000 So for example, as it says here, any feature or protocol that exists to 0:00:57.940000 --> 0:01:03.300000 give you the human being, this ability resides in the management plane. 0:01:03.300000 --> 0:01:09.480000 So when you are accessing the command line, you are accessing the management 0:01:09.480000 --> 0:01:16.400000 plane. When you are accessing the web based GUI of a lightweight access 0:01:16.400000 --> 0:01:19.480000 point controller, you are accessing the management plane. 0:01:19.480000 --> 0:01:25.240000 When you are issuing telnet or SSH commands to remotely get into something, 0:01:25.240000 --> 0:01:27.460000 that is the management plane. 0:01:27.460000 --> 0:01:32.600000 When you are doing SNMP, that is the management plane, especially if you 0:01:32.600000 --> 0:01:38.080000 are using SNMP to issue right operations to configure variables within 0:01:38.080000 --> 0:01:43.960000 the MIB. So what relationship does software defined networking have with 0:01:43.960000 --> 0:01:47.620000 this? Because typically, the management plane has involved one or two 0:01:47.620000 --> 0:01:51.640000 things, either you connecting to the console port and configuring away, 0:01:51.640000 --> 0:01:57.500000 or you remotely establishing a telnet SSH or maybe HTTP session and once 0:01:57.500000 --> 0:01:59.500000 again, configuring away. 0:01:59.500000 --> 0:02:01.820000 So how does SDN relate to this? 0:02:01.820000 --> 0:02:08.400000 Well most SDN controllers rely on existing management plane mechanisms 0:02:08.400000 --> 0:02:15.260000 such as what you are already familiar with, SSH, HTTPS. 0:02:15.260000 --> 0:02:20.200000 Some new mechanism has been developed for new types of access. 0:02:20.200000 --> 0:02:25.540000 You might hear of NetConf Yang or XML based commands. 0:02:25.540000 --> 0:02:36.160000 So the idea behind this is, you know, if you are well versed in the Cisco 0:02:36.160000 --> 0:02:40.620000 iOS command line and you know what the commands are to implement routing, 0:02:40.620000 --> 0:02:45.180000 implement switching, implement spanning tree, that is great. 0:02:45.180000 --> 0:02:53.940000 So imagine for a second that we built an SDN controller and let's say 0:02:53.940000 --> 0:02:59.540000 it was all GUI based and so I went into a drop, so I am on the controller, 0:02:59.540000 --> 0:03:04.040000 I went into a drop down box in the controller and that drop down box said 0:03:04.040000 --> 0:03:10.100000 configure root bridge, drop down box, select switch, okay I see switch 0:03:10.100000 --> 0:03:13.680000 one, switch two, okay I want switch three to be the root bridge and the 0:03:13.680000 --> 0:03:18.080000 moment I selected switch three in the background, what that controller 0:03:18.080000 --> 0:03:22.480000 did was it established an SSH session just like you would do in secure 0:03:22.480000 --> 0:03:27.980000 CRT or hyper terminal and SSH session to that switch and then it sent 0:03:27.980000 --> 0:03:32.240000 to that switch over that SSH session command you are used to spanning 0:03:32.240000 --> 0:03:36.140000 dash tree, BLAN 2 root, something like that. 0:03:36.140000 --> 0:03:39.880000 Well that would be great but what if you also want to integrate that same 0:03:39.880000 --> 0:03:45.200000 SDN controller with a Juniper network, a Juniper switch or an ERISTA switch 0:03:45.200000 --> 0:03:48.040000 or a HOA switch or something like that. 0:03:48.040000 --> 0:03:52.780000 Well now you are asking the developer of that SDN controller to integrate 0:03:52.780000 --> 0:03:58.540000 Juniper commands, ERISTA commands, HP commands, that is a tall order to 0:03:58.540000 --> 0:04:03.840000 do all that. So instead some very smart people said you know what, we 0:04:03.840000 --> 0:04:08.160000 should come up with some common language that can be used at the management 0:04:08.160000 --> 0:04:13.780000 plane and this common language if vendors will support it, controllers 0:04:13.780000 --> 0:04:17.840000 can use this common language to reach out and do basically the same things 0:04:17.840000 --> 0:04:22.700000 that the CLI would do in Juniper or the CLI would do in Cisco and that 0:04:22.700000 --> 0:04:25.580000 is basically what NetConf is all about. 0:04:25.580000 --> 0:04:29.800000 NetConf is a way of let's coming up with a standardized way that we can 0:04:29.800000 --> 0:04:36.280000 send structured defined data, defined commands to a device no matter what 0:04:36.280000 --> 0:04:39.440000 that device is as long as it supports NetConf. 0:04:39.440000 --> 0:04:44.200000 So now if I have a Cisco switch and a Juniper switch and an ERISTA switch 0:04:44.200000 --> 0:04:48.960000 and they all say they are all manufactured to support NetConf then that 0:04:48.960000 --> 0:04:53.780000 means that I can still connect to the console and issue CLI commands. 0:04:53.780000 --> 0:04:58.480000 I can still remotely SSH or tell it into it via secure CRT and issue my 0:04:58.480000 --> 0:05:03.300000 CLI commands but in addition to that now something like a controller can 0:05:03.300000 --> 0:05:07.740000 send commands via a different structure, a different language called NetConf 0:05:07.740000 --> 0:05:12.340000 and accomplish the exact same thing I was doing with the CLI and now we 0:05:12.340000 --> 0:05:15.340000 don't have to worry about the differences between Juniper and ERISTA and 0:05:15.340000 --> 0:05:20.060000 Cisco. That's sort of the idea behind NetConf Yang as well as XML. 0:05:20.060000 --> 0:05:24.020000 All right so that was the management plane. 0:05:24.020000 --> 0:05:26.300000 What is the data now we are skipping forward to the data plane otherwise 0:05:26.300000 --> 0:05:29.180000 known as the forwarding plane. 0:05:29.180000 --> 0:05:36.980000 So the data plane is those memory structures, those tables and databases 0:05:36.980000 --> 0:05:40.140000 that actually act on data. 0:05:40.140000 --> 0:05:44.440000 So when data comes into a router switch you have to ask yourself what's 0:05:44.440000 --> 0:05:45.940000 going to look at that data. 0:05:45.940000 --> 0:05:47.920000 Is it going to be the routing table? 0:05:47.920000 --> 0:05:50.100000 Is it going to be the SEF tables? 0:05:50.100000 --> 0:05:55.960000 Is it going to be some sort of security table that enforces access lists? 0:05:55.960000 --> 0:06:01.800000 All that stuff that will actually look at the packet and make decisions 0:06:01.800000 --> 0:06:07.120000 on the packet and decide where the packet goes that stuff resides in the 0:06:07.120000 --> 0:06:13.940000 data plane. Your MAC address tables, your routing tables, even the cables 0:06:13.940000 --> 0:06:18.360000 and NIC cards and packet buffers and queues, all that stuff touches your 0:06:18.360000 --> 0:06:22.320000 packets, is used to forward your packets, that stuff resides in the data 0:06:22.320000 --> 0:06:31.440000 plane. So like it says, MAC address tables typically have no MAC addresses, 0:06:31.440000 --> 0:06:33.880000 they have to be learned by the switch. 0:06:33.880000 --> 0:06:35.260000 Routing tables have no routes. 0:06:35.260000 --> 0:06:41.720000 So the data plane is not responsible for the learning of this information. 0:06:41.720000 --> 0:06:47.040000 So whatever features, whatever protocols are working in the data plane, 0:06:47.040000 --> 0:06:49.900000 for example, Cisco Express forwarding. 0:06:49.900000 --> 0:06:55.300000 If you look at the design documents and the technical documents of Cisco 0:06:55.300000 --> 0:07:00.260000 Express forwarding, nowhere in there will it say, how does Cisco Express 0:07:00.260000 --> 0:07:04.340000 forwarding learn that the route to the 5050 network is reachable via that 0:07:04.340000 --> 0:07:07.620000 way? And that the route to the 99 network is reachable via two different 0:07:07.620000 --> 0:07:09.620000 paths, but that's the best one. 0:07:09.620000 --> 0:07:11.060000 SEF doesn't do that. 0:07:11.060000 --> 0:07:15.020000 SEF will take that information that was learned by something else. 0:07:15.020000 --> 0:07:18.020000 You can put that information into a SEF table. 0:07:18.020000 --> 0:07:21.700000 And now once it's in the SEF table as a packet comes in, Cisco Express 0:07:21.700000 --> 0:07:25.500000 forwarding can look at that packet compared against the table and figure 0:07:25.500000 --> 0:07:26.880000 out where it needs to go. 0:07:26.880000 --> 0:07:31.780000 But SEF is not responsible for the initial population of the table. 0:07:31.780000 --> 0:07:33.540000 That is the control plane. 0:07:33.540000 --> 0:07:35.040000 We talked a little bit about this already. 0:07:35.040000 --> 0:07:36.880000 The control plane does that. 0:07:36.880000 --> 0:07:40.360000 So I don't think we need to go into that. 0:07:40.360000 --> 0:07:43.280000 We've already discussed the control plane. 0:07:43.280000 --> 0:07:48.020000 So also, let's take a step back here. 0:07:48.020000 --> 0:07:50.760000 I don't think this is coming up here. 0:07:50.760000 --> 0:07:51.920000 We didn't answer the question. 0:07:51.920000 --> 0:07:54.660000 We answered the question, how does a software defined networking controller 0:07:54.660000 --> 0:07:56.480000 deal with the management plane? 0:07:56.480000 --> 0:08:02.240000 We said, well, it has the ability just like you to issue SSH CLI commands 0:08:02.240000 --> 0:08:06.940000 or HTTP, but it also has the ability to use something called NetConf or 0:08:06.940000 --> 0:08:11.200000 RESTConf, which is like a derivative of NetConf to reach in there. 0:08:11.200000 --> 0:08:14.480000 So it can manage the device just like you can. 0:08:14.480000 --> 0:08:18.140000 How does an SDN controller affect the forwarding plane? 0:08:18.140000 --> 0:08:21.380000 Well, this goes back to the previous video about where we were talking 0:08:21.380000 --> 0:08:25.520000 about the differences between the imperative approach and the declarative 0:08:25.520000 --> 0:08:32.160000 approach. If I have an SDN environment that supports the imperative approach, 0:08:32.160000 --> 0:08:36.300000 then that means my SDN controller actually has the ability to reach in 0:08:36.300000 --> 0:08:41.520000 to the memory that's holding the routing table and put a route right in 0:08:41.520000 --> 0:08:45.400000 there. It has the ability to reach in to the MAC address table and put 0:08:45.400000 --> 0:08:47.240000 a MAC address right in there. 0:08:47.240000 --> 0:08:54.480000 But typically speaking, when a packet comes into a router switch, does 0:08:54.480000 --> 0:08:56.640000 the router switch even in that approach? 0:08:56.640000 --> 0:09:00.080000 I just said, even in the imperative approach, does the router switch then 0:09:00.080000 --> 0:09:03.220000 say, a controller, what do I do with this? 0:09:03.220000 --> 0:09:09.220000 No, it doesn't. The router switch still has its own local forwarding plane, 0:09:09.220000 --> 0:09:11.280000 its own local data plane. 0:09:11.280000 --> 0:09:16.280000 Because remember, the controller was the control plane. 0:09:16.280000 --> 0:09:18.040000 It populated that table. 0:09:18.040000 --> 0:09:21.520000 But once it populated that table, the controller does not see the actual 0:09:21.520000 --> 0:09:26.160000 packet. It does not see the actual Ethernet frame of your telnet session, 0:09:26.160000 --> 0:09:27.700000 of your web browsing session. 0:09:27.700000 --> 0:09:28.940000 The router does. 0:09:28.940000 --> 0:09:30.320000 The switch does. 0:09:30.320000 --> 0:09:33.160000 So as that packet or frame comes in, it's still going to be that router 0:09:33.160000 --> 0:09:39.100000 switch's job to ultimately forward it based on that table. 0:09:39.100000 --> 0:09:45.560000 So SDN, ideally in the imperative approach, will separate the control 0:09:45.560000 --> 0:09:50.160000 and data plane. So in the imperative approach, it's called stateful SDN 0:09:50.160000 --> 0:09:54.200000 because the controller itself knows everything. 0:09:54.200000 --> 0:09:55.480000 It knows all the routes. 0:09:55.480000 --> 0:09:59.260000 It knows the connections because it's got the brain of the routing protocol 0:09:59.260000 --> 0:10:03.360000 in itself. It has the intelligence to learn MAC addresses and populate 0:10:03.360000 --> 0:10:06.720000 that stuff itself. 0:10:06.720000 --> 0:10:10.040000 It can directly program the data plane. 0:10:10.040000 --> 0:10:14.440000 So some Cisco controllers can do that. 0:10:14.440000 --> 0:10:16.400000 Some Cisco controllers cannot. 0:10:16.400000 --> 0:10:19.980000 Other Cisco controllers do what's called the declarative approach. 0:10:19.980000 --> 0:10:20.780000 We talked about this. 0:10:20.780000 --> 0:10:23.060000 This is stateless SDN. 0:10:23.060000 --> 0:10:27.840000 This is basically where the controller says, okay, router, you do routing 0:10:27.840000 --> 0:10:29.220000 like you always have. 0:10:29.220000 --> 0:10:31.800000 You learn your EIJRP neighbors. 0:10:31.800000 --> 0:10:34.080000 You figure out how to learn your OSPF neighbors. 0:10:34.080000 --> 0:10:38.620000 You know, you form your EIJRP topology table and you populate the routing 0:10:38.620000 --> 0:10:39.320000 table with that. 0:10:39.320000 --> 0:10:40.800000 You do all that stuff. 0:10:40.800000 --> 0:10:45.060000 And then just report back to me what you've learned, what your tables 0:10:45.060000 --> 0:10:48.240000 look like, what the state of your interfaces are. 0:10:48.240000 --> 0:10:52.140000 So this is called stateless SDN. 0:10:52.140000 --> 0:10:55.420000 Both the control and data planes reside within the networking devices 0:10:55.420000 --> 0:10:59.720000 themselves. And the controller though can listen to an application running 0:10:59.720000 --> 0:11:06.260000 on a server and then it can declare to the networking devices what it 0:11:06.260000 --> 0:11:10.020000 thinks the overlay network needs to look like. 0:11:10.020000 --> 0:11:15.940000 All right, and that concludes this particular session. 0:11:15.940000 --> 0:11:16.640000 Thank you for watching.