WEBVTT

1
00:00.000 --> 00:04.160
Alright friends, so let's walk through the validation challenge then. So we've

2
00:04.160 --> 00:06.000
been asked some questions about netconf.

3
00:06.000 --> 00:11.200
The first one is, "Are configurations made via netconf secure?"

4
00:11.200 --> 00:16.000
Well the answer to this is a resounding "Yes, they are absolutely secure"

5
00:16.000 --> 00:20.170
because the entire channel has been encrypted because essentially we're going

6
00:20.170 --> 00:22.000
to be using SSH as transportway,

7
00:22.000 --> 00:25.000
which as we know is a secure protocol.

8
00:25.000 --> 00:29.360
Alright, so fairly simple and resounding answer to the first question, what is

9
00:29.360 --> 00:30.000
the next one?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:30.000 --> 00:35.000
Well, we're asked which port number does netconf use? What does SSH use?

11
00:35.000 --> 00:41.030
As the actual transport. Although SSH typically is using port 22, in this case

12
00:41.030 --> 00:42.000
here that is not the case.

13
00:42.000 --> 00:46.000
Instead this time we're going to be using SSH port 830.

14
00:46.000 --> 00:50.340
Now the next question is asking is netconf capable of retrieving operational

15
00:50.340 --> 00:51.000
state data?

16
00:51.000 --> 00:55.230
And this is kind of borne out of the idea that netconf is the network

17
00:55.230 --> 00:57.000
configuration protocol.

18
00:57.000 --> 01:01.130
And remember that netconf was essentially built to handle the shortcomings of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:57.000 --> 01:01.130
And remember that netconf was essentially built to handle the shortcomings of

19
01:01.130 --> 01:04.000
SNMP's ability to handle configurations.

20
01:04.000 --> 01:08.500
So clearly we know that netconf was designed with making configuration changes

21
01:08.500 --> 01:09.000
in mind,

22
01:09.000 --> 01:13.230
but it's also very important to realize that we still can retrieve operational

23
01:13.230 --> 01:14.000
state data.

24
01:14.000 --> 01:18.000
So this would be things like the interface counters, this would be things like

25
01:18.000 --> 01:20.000
the state of our OSPF adjacencies.

26
01:20.000 --> 01:24.490
All of this type of data absolutely can be retrieved via netconf, no problem at

27
01:24.490 --> 01:25.000
all.

28
01:25.000 --> 01:28.000
Now next one, this one might be a little bit more in depth.

29
01:28.000 --> 01:32.280
How can netconf help us implement configuration changes in a more reliable
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:28.000 --> 01:32.280
How can netconf help us implement configuration changes in a more reliable

30
01:32.280 --> 01:33.000
manner?

31
01:33.000 --> 01:37.170
Well, first thing is that netconf gives us the ability to utilize a candidate

32
01:37.170 --> 01:38.000
configuration.

33
01:38.000 --> 01:42.250
So if we want to make configuration changes to a whole bunch of devices, we can

34
01:42.250 --> 01:46.000
send out those configs and just put it into the candidate config.

35
01:46.000 --> 01:50.140
And then once we are ready for those configurations to go live altogether, we

36
01:50.140 --> 01:55.440
can then send a commit message to ultimately copy over the configuration that

37
01:55.440 --> 01:59.000
is now in the candidate data store into the live running data store.

38
01:59.000 --> 02:04.000
Now in a similar way, netconf's edit config rpc is actually pretty flexible.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:59.000 --> 02:04.000
Now in a similar way, netconf's edit config rpc is actually pretty flexible.

39
02:04.000 --> 02:08.280
We can specify if we want to merge configurations i.e. just add configurations

40
02:08.280 --> 02:11.000
to the already existing configuration on the device.

41
02:11.000 --> 02:14.830
Or if we so wish we can choose to replace very particular parts of the

42
02:14.830 --> 02:16.000
configuration.

43
02:16.000 --> 02:20.250
So say for example, we want to replace all of the routing information on the

44
02:20.250 --> 02:21.000
device.

45
02:21.000 --> 02:24.000
We can just simply target that very precise piece of data.

46
02:24.000 --> 02:27.900
And as we saw, we can also target very particular pieces of our configuration

47
02:27.900 --> 02:29.000
for deletion also.

48
02:29.000 --> 02:34.610
So lots of flexibility with netconf and that ability to not have the changes go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
02:29.000 --> 02:34.610
So lots of flexibility with netconf and that ability to not have the changes go

49
02:34.610 --> 02:37.000
live immediately really is very, very valuable.

50
02:37.000 --> 02:40.560
Now the last thing is we're asked are there any particular tools we can use to

51
02:40.560 --> 02:44.420
send netconf configurations, whether actually are a whole bunch of different

52
02:44.420 --> 02:48.760
utilities, but one that we saw in this particular skill, which is very well

53
02:48.760 --> 02:52.000
known as one known as NC client, the net conf clients.

54
02:52.000 --> 02:57.500
So this particular library allows us to send all the rpcs that we need, the get

55
02:57.500 --> 03:02.000
rpcs, the getconf, rpcs, the edit rpcs, copy configurations, so on, so forth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:57.500 --> 03:02.000
rpcs, the getconf, rpcs, the edit rpcs, copy configurations, so on, so forth.

56
03:02.000 --> 03:06.530
And when we get our data back, say for example, operational data, we can also

57
03:06.530 --> 03:10.000
manipulate that information utilizing Python directly.

58
03:10.000 --> 03:13.000
So really is a very, very good tool to use.

59
03:13.000 --> 03:17.000
So friends, that is us for our validation challenge on netconf.

60
03:17.000 --> 03:20.000
I hope it's been informative for you and I'd like to thank you for viewing.