WEBVTT 1 00:00.000 --> 00:03.440 So friends, let's talk about the NetConf protocol. 2 00:03.440 --> 00:07.280 Now before we actually begin talking about what NetConf actually is, 3 00:07.280 --> 00:10.320 let's first talk about where it actually came from. 4 00:10.320 --> 00:14.240 So you might be familiar with a particular protocol known as SNMP, 5 00:14.240 --> 00:16.640 the Simple Network Management Protocol. 6 00:16.640 --> 00:21.520 And in many respects, this was the catalyst for the development of NetConf, 7 00:21.520 --> 00:23.760 so what exactly am I talking about? 8 00:23.760 --> 00:26.640 Well, with respect to SNMP, 9 00:26.640 --> 00:30.410 the way it was initially designed was to actually be able to pull back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:26.640 --> 00:30.410 the way it was initially designed was to actually be able to pull back 10 00:30.410 --> 00:32.000 operational state data. 11 00:32.000 --> 00:33.600 So that would be things like, you know, 12 00:33.600 --> 00:36.000 do you have any errors on your interface? 13 00:36.000 --> 00:39.600 Are your OSPF adjacencies in the full state pretty much the type of things we 14 00:39.600 --> 00:40.000 get 15 00:40.000 --> 00:42.480 via our regular CLI show commands? 16 00:42.480 --> 00:45.520 So state data was the first component of SNMP, 17 00:45.520 --> 00:49.820 but the other component was also having the ability to make configuration 18 00:49.820 --> 00:50.560 changes. 19 00:50.560 --> 00:54.720 Now, if you happen to work with SNMP in any real capacity, 20 00:54.720 --> 00:58.320 you'll know that this part here is largely ignored. 21 00:58.320 --> 01:02.800 We mostly use SNMP to ultimately monitor the state of our environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:58.320 --> 01:02.800 We mostly use SNMP to ultimately monitor the state of our environment. 22 01:02.800 --> 01:05.680 So you know, you might configure SNMP to have particular traps 23 01:05.680 --> 01:09.200 and then send alerts, maybe if an interface goes down that type of thing, 24 01:09.200 --> 01:12.880 once again, this is all about monitoring the state of the network, 25 01:12.880 --> 01:15.280 not actually making configuration changes. 26 01:15.280 --> 01:19.840 Now, I don't want to go into all the details about why SNMP kind of failed for 27 01:19.840 --> 01:21.360 configuration changes. 28 01:21.360 --> 01:24.640 Basically, it really just was kind of awkward. 29 01:24.640 --> 01:28.400 You know, it wasn't intuitive and it never really got off the ground. 30 01:28.400 --> 01:33.280 All right, so we have this protocol that was designed for state monitoring WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:28.400 --> 01:33.280 All right, so we have this protocol that was designed for state monitoring 31 01:33.280 --> 01:37.690 as well as configuration changes, but it doesn't really make any type of 32 01:37.690 --> 01:39.520 network configuration changes. 33 01:39.520 --> 01:42.000 So what can you imagine the solution would be? 34 01:42.000 --> 01:45.540 Well, if you happen to think that the development of a protocol that could 35 01:45.540 --> 01:46.480 actually handle 36 01:46.480 --> 01:48.800 the configuration portion of the network, 37 01:48.800 --> 01:51.120 well, you would kind of be on the right track. 38 01:51.120 --> 01:54.640 This is what Nikconn was really designed to handle. 39 01:54.640 --> 01:57.520 Now, first things first, let me just plan to flag right here. 40 01:57.520 --> 01:59.840 I don't want you to get to the wrong end of the stick. 41 01:59.840 --> 02:02.720 Just because the protocol is called Nikconn, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 01:59.840 --> 02:02.720 Just because the protocol is called Nikconn, 42 02:02.720 --> 02:05.280 it's not just about network configuration. 43 02:05.280 --> 02:08.720 Nikconn is also capable of managing state data, 44 02:08.720 --> 02:12.640 so retrieving the information about the current configuration of our network, 45 02:12.640 --> 02:16.740 not just making those changes, but no doubt one of the primary drivers of Nik 46 02:16.740 --> 02:16.960 conn 47 02:16.960 --> 02:19.840 was its ability to make configuration changes. 48 02:19.840 --> 02:23.200 So let's talk about how it actually does this task. 49 02:23.200 --> 02:26.160 Okay, so let's imagine we have a little router over here, 50 02:26.160 --> 02:28.320 and here I am on my little laptop. 51 02:28.320 --> 02:31.040 Now, if I wanted to remotely manage this particular router, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:28.320 --> 02:31.040 Now, if I wanted to remotely manage this particular router, 52 02:31.040 --> 02:33.280 what I could do is I could use SSH, 53 02:33.280 --> 02:36.800 and I could go in and make configuration changes directly via the CLI, 54 02:36.800 --> 02:40.000 you know, typing things like router OSPF1, that type of stuff. 55 02:40.000 --> 02:43.760 Now, notice this portion right here, SSH. 56 02:43.760 --> 02:47.200 The reason why we use this protocol is because it is indeed secure. 57 02:47.200 --> 02:49.760 It wraps the whole communication in encryption. 58 02:49.760 --> 02:53.120 Here's the thing, SSH is very, very commonly used. 59 02:53.120 --> 02:56.240 Everyone pretty much has some experience with it. 60 02:56.240 --> 02:58.080 So the thought process behind Nikconn 61 02:58.080 --> 03:02.490 at the time of its development was why not make use of this particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 02:58.080 --> 03:02.490 at the time of its development was why not make use of this particular 62 03:02.490 --> 03:03.200 transport. 63 03:03.200 --> 03:07.840 So instead of sending CLI commands down the SSH channel, 64 03:07.840 --> 03:10.320 we ultimately send something called RPCs. 65 03:10.320 --> 03:12.880 These are remote procedure calls. 66 03:12.880 --> 03:16.000 Now, we'll talk about this in a little bit more detail very, very shortly. 67 03:16.000 --> 03:19.600 But the first thing to focus in on is this communication channel right here, 68 03:19.600 --> 03:25.220 SSH. Now, typically, your regular SSH is going to be connecting over a default 69 03:25.220 --> 03:26.240 port of 22, 70 03:26.240 --> 03:28.880 but with Nikconn, it actually is a little bit different. 71 03:28.880 --> 03:33.040 The default SSH port is 830. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 71 03:28.880 --> 03:33.040 The default SSH port is 830. 72 03:33.040 --> 03:36.630 Now, one of the things to note about SSH is that it allows us to maintain a 73 03:36.630 --> 03:37.840 stateful connection. 74 03:37.840 --> 03:40.800 So this is one of the advantages, compared to say HTTP. 75 03:40.800 --> 03:44.240 Remember when we used Resconn, it was stateless. 76 03:44.240 --> 03:47.680 In the case of Nikconn, the connection is stateful. 77 03:47.680 --> 03:51.020 So once again, let's imagine here I am here on my laptop and I want to make a 78 03:51.020 --> 03:52.240 remote connection 79 03:52.240 --> 03:54.480 to the router here over Nikconn. 80 03:54.480 --> 03:56.640 So this is going to be SSH 830. 81 03:56.640 --> 04:00.320 Because the connection is stateful, it means the connection can be maintained. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 03:56.640 --> 04:00.320 Because the connection is stateful, it means the connection can be maintained. 82 04:00.320 --> 04:03.040 So we open up the connection to this device here. 83 04:03.040 --> 04:05.840 We then send some configurations down. 84 04:05.840 --> 04:08.560 And then because we have this stateful connection, 85 04:08.560 --> 04:11.920 what we can then do is ultimately send a commit message. 86 04:11.920 --> 04:15.440 If you happen to have experience with Cisco's iOS XR platform, 87 04:15.440 --> 04:19.520 or maybe say for example, Juniper devices, you will actually understand what 88 04:19.520 --> 04:21.200 this commit is all about. 89 04:21.200 --> 04:24.910 But in case you haven't worked with these devices, then let me just describe to 90 04:24.910 --> 04:26.160 you what is going on here. 91 04:26.160 --> 04:30.480 So the thing is, with Nikconn, we actually have different data stores, okay? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 04:26.160 --> 04:30.480 So the thing is, with Nikconn, we actually have different data stores, okay? 92 04:30.480 --> 04:31.520 Let me tell you what they are. 93 04:31.520 --> 04:35.520 So the first data store we have is what is known as the startup data store. 94 04:35.520 --> 04:39.600 Now pretty much this data store stores these startup configurations. 95 04:39.600 --> 04:43.400 So kind of like when you go on your regular CLI and you type the command "Copy 96 04:43.400 --> 04:44.160 Run Start", 97 04:44.160 --> 04:48.320 you are saving the running configuration into the startup data store. 98 04:48.320 --> 04:52.720 So if you happen to reboot the device, your configurations that you just saved 99 04:52.720 --> 04:54.160 are going to be persistent. 100 04:54.160 --> 04:58.170 Now the next data store we have in Nikconn is what is known as the running data 101 04:58.170 --> 04:58.720 store. 102 04:58.720 --> 05:02.160 This is just like when you type the command "Show Running Configuration" WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 102 04:58.720 --> 05:02.160 This is just like when you type the command "Show Running Configuration" 103 05:02.160 --> 05:04.720 and you see the actual live running config. 104 05:04.720 --> 05:08.480 This is the data store that contains that particular information. 105 05:08.480 --> 05:11.120 So these ones are pretty intuitive. 106 05:11.120 --> 05:14.320 But Nikconn also brings a third data store here, okay? 107 05:14.320 --> 05:16.960 And this one is known as the candidate data store. 108 05:16.960 --> 05:20.480 So this one here might be a little bit more confusing and this is what we're 109 05:20.480 --> 05:21.040 talking about 110 05:21.040 --> 05:23.600 with respect to our commit operations. 111 05:23.600 --> 05:27.840 What you can do with the candidate data store is you can make changes to the 112 05:27.840 --> 05:29.600 configuration of your device. 113 05:29.600 --> 05:33.280 But the configurations are quite simply not going to take effect. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 05:29.600 --> 05:33.280 But the configurations are quite simply not going to take effect. 114 05:33.280 --> 05:37.570 They're just going to lie in this candidate data store waiting to go live and 115 05:37.570 --> 05:39.040 they will not go live 116 05:39.040 --> 05:43.920 until you specify that you want to commit them into the running data store. 117 05:43.920 --> 05:46.720 So why would we ever want to do such a thing? 118 05:46.720 --> 05:49.440 Well let's imagine we have some routers here, okay? 119 05:49.440 --> 05:51.440 And we're going to manage them via Nikconn. 120 05:51.440 --> 05:52.880 So here we are over here. 121 05:52.880 --> 05:56.180 So with Nikconn, what we can do is we can open up a connection to all these 122 05:56.180 --> 05:57.440 devices, as so. 123 05:57.440 --> 06:01.190 And then we can begin pushing down all the configurations that we want to these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 05:57.440 --> 06:01.190 And then we can begin pushing down all the configurations that we want to these 124 06:01.190 --> 06:02.080 devices, okay? 125 06:02.080 --> 06:06.380 Now if we specify in our Nikconn configuration that we only want to target the 126 06:06.380 --> 06:07.440 candidate data store 127 06:07.440 --> 06:12.220 of all these devices, then once our configurations have been pushed, nothing is 128 06:12.220 --> 06:13.200 actually going to happen 129 06:13.200 --> 06:16.080 to these devices. So no changes are going to be applied. 130 06:16.080 --> 06:19.730 The running configurations of all these devices are still going to be remained 131 06:19.730 --> 06:20.400 untouched. 132 06:20.400 --> 06:23.590 The difference here is that once we have sent all of our configurations and 133 06:23.590 --> 06:24.480 were now happy for 134 06:24.480 --> 06:28.310 the changes to take effect, we can effectively make them take effect all at 135 06:28.310 --> 06:30.000 once by sending a commit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 06:30.000 --> 06:34.080 message to all of these devices at the same time. And then all of the changes 137 06:34.080 --> 06:34.720 that have been pushed 138 06:34.720 --> 06:39.250 into the candidate data store of all these devices are then copied into the 139 06:39.250 --> 06:40.800 running data store 140 06:40.800 --> 06:45.040 and then take effect on the live configurations. So as opposed to pushing 141 06:45.040 --> 06:46.080 configuration changes, 142 06:46.080 --> 06:50.800 one by one by one, as each line happens to be applied, we can effectively send 143 06:50.800 --> 06:52.400 a bulk configurations, 144 06:52.400 --> 06:56.410 let them lie dormant until we're ready and then flip the switch and they all go 145 06:56.410 --> 06:57.600 live at the very same 146 06:57.600 --> 07:01.840 time. So this is one of the benefits about how Nikconn can actually manage WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 146 06:57.600 --> 07:01.840 time. So this is one of the benefits about how Nikconn can actually manage 147 07:01.840 --> 07:02.880 configuration changes. 148 07:02.880 --> 07:07.250 It's very, very good at this particular task. Now one thing to state about Nik 149 07:07.250 --> 07:08.480 conn is that the data 150 07:08.480 --> 07:12.140 we're actually sending is once again going to be a young model. This is 151 07:12.140 --> 07:13.600 actually mandatory. This 152 07:13.600 --> 07:17.470 is something we have to do very, very similar to what we saw with Resconn. The 153 07:17.470 --> 07:18.240 difference though, 154 07:18.240 --> 07:23.140 if you recall, with Resconn, we had the ability for JSON encoding as well as 155 07:23.140 --> 07:24.480 XML with Nikconn. 156 07:24.480 --> 07:29.410 Unfortunately, it's all going to be XML encoders. We're going to be using our 157 07:29.410 --> 07:30.400 opening tags as well WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 07:29.410 --> 07:30.400 opening tags as well 158 07:30.400 --> 07:34.210 as our closing tags. So you know, this isn't the worst thing in the world. XML 159 07:34.210 --> 07:35.520 is fairly human-readable, 160 07:35.520 --> 07:39.690 but for me, it just isn't quite as good so there are some limitations. And 161 07:39.690 --> 07:41.200 quite honestly, people do 162 07:41.200 --> 07:45.040 complain when you first begin using Nikconn, it can be a little bit daunting 163 07:45.040 --> 07:46.000 and it can be a little 164 07:46.000 --> 07:50.150 bit confusing. This is unfortunately something that everyone just kind of 165 07:50.150 --> 07:51.280 struggles with at first. 166 07:51.280 --> 07:55.050 It takes a little bit of time just to get used to what you're doing. So pretty 167 07:55.050 --> 07:56.240 much what I'm saying is 168 07:56.240 --> 07:59.840 don't beat yourself up if you find this a little bit confusing the first time 169 07:59.840 --> 08:01.040 you see it. Now, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 169 07:59.840 --> 08:01.040 you see it. Now, 170 08:01.040 --> 08:05.070 finally, remember I happen to mention this thing about an RPC, a remote 171 08:05.070 --> 08:06.720 procedure call. Let me just 172 08:06.720 --> 08:11.090 talk a little bit more about that. So pretty much, the RPC is kind of like the 173 08:11.090 --> 08:12.320 instruction that we 174 08:12.320 --> 08:16.400 are sending to the device. So what kind of instructions could we actually send 175 08:16.400 --> 08:17.600 to that device? Well, 176 08:17.600 --> 08:21.590 let's imagine once again, finally, we have our router here and let's say we 177 08:21.590 --> 08:22.960 have a little laptop. 178 08:22.960 --> 08:28.800 Let's imagine I wanted to get the state of my network, but what I could do is I 179 08:28.800 --> 08:29.600 could send what is 180 08:29.600 --> 08:34.290 known as a getRPC. And quite simply, we would then get the state and the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 180 08:29.600 --> 08:34.290 known as a getRPC. And quite simply, we would then get the state and the 181 08:34.290 --> 08:36.080 configuration information 182 08:36.080 --> 08:40.630 from that particular device. So this would be one RPC. Now, another RPC we 183 08:40.630 --> 08:42.000 could send, which is very, 184 08:42.000 --> 08:46.240 very similar as one known as a get-hiphon-config RPC. Now, this might be a 185 08:46.240 --> 08:48.080 little bit confusing at first, 186 08:48.080 --> 08:53.120 but actually is quite important. When we happen to send a regular getRPC, we're 187 08:53.120 --> 08:54.640 getting both state data 188 08:54.640 --> 08:57.940 and configuration data. So that will be things like we have actually configured 189 08:57.940 --> 08:59.040 . So if we happen to 190 08:59.040 --> 09:04.130 configure things like router OSPF1 on the device, this is configuration data we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 190 08:59.040 --> 09:04.130 configure things like router OSPF1 on the device, this is configuration data we 191 09:04.130 --> 09:05.120 have actually 192 09:05.120 --> 09:09.760 since. And when we send a get request, we get this type of config data, but we 193 09:09.760 --> 09:10.960 also get the 194 09:10.960 --> 09:15.680 operational data such as interface statistics. How many errors have been seen 195 09:15.680 --> 09:16.320 on a particular 196 09:16.320 --> 09:20.200 interface? How many unicast packets? How many broadcasts? That type of thing. 197 09:20.200 --> 09:21.440 So the get-config 198 09:21.440 --> 09:25.950 RPC allows us to cleanly separate out configuration data and state data. If we 199 09:25.950 --> 09:26.800 just want to get the 200 09:26.800 --> 09:32.160 config such as, you know, the router OSPF1 configuration we sent, then we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 200 09:26.800 --> 09:32.160 config such as, you know, the router OSPF1 configuration we sent, then we could 201 09:32.160 --> 09:33.280 send this information. 202 09:33.280 --> 09:37.200 If we want to get more general information, we can send the get request to 203 09:37.200 --> 09:38.400 essentially get both 204 09:38.400 --> 09:43.630 state and config. So we have the getRPC, the get-config RPC. The next RPC we 205 09:43.630 --> 09:45.120 can get is the edit 206 09:45.120 --> 09:49.520 config RPC. As you can imagine, this one is used to actually make configuration 207 09:49.520 --> 09:50.880 changes to edit a 208 09:50.880 --> 09:55.140 particular data store. So imagine we wanted to add a new network statement 209 09:55.140 --> 09:56.960 within our OSPF configuration 210 09:56.960 --> 10:01.240 that would require an edit of the config. Therefore, we will send the edit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 210 09:56.960 --> 10:01.240 that would require an edit of the config. Therefore, we will send the edit 211 10:01.240 --> 10:03.120 config RPC. Now if we wanted 212 10:03.120 --> 10:07.780 to delete a particular configuration, what we could then send would be a delete 213 10:07.780 --> 10:08.960 config RPC. So say, 214 10:08.960 --> 10:12.610 for example, you wanted to delete a description on a particular interface. Well 215 10:12.610 --> 10:13.520 , you could send 216 10:13.520 --> 10:19.040 that particular RPC to do that particular task. And we also have the copyconfig 217 10:19.040 --> 10:20.080 RPC, which allows 218 10:20.080 --> 10:24.270 us to essentially copy configurations across different data stores. So if you 219 10:24.270 --> 10:25.280 want to copy the 220 10:25.280 --> 10:28.340 configuration from the running data store into the startup data store, you 221 10:28.340 --> 10:29.200 could send a copy 222 10:29.200 --> 10:34.350 config. So I know that was a lot of theory and overview to get us going. Now we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 10:29.200 --> 10:34.350 config. So I know that was a lot of theory and overview to get us going. Now we 223 10:34.350 --> 10:35.520 have a rough idea 224 10:35.520 --> 10:40.000 about how this weird Nikcon thing actually does operate. Let's now get hands on 225 10:40.000 --> 10:40.960 and begin making 226 10:40.960 --> 10:42.800 in some requests to order the base.