WEBVTT

1
00:00.000 --> 00:04.480
Alright friends, let's talk about network automation in the modern world.

2
00:04.480 --> 00:08.560
So you may recall when we first talked about Ansible, one of the big benefits

3
00:08.560 --> 00:09.120
was that

4
00:09.120 --> 00:14.080
no matter if you had an old dusty legacy device, if you could SSH enter the

5
00:14.080 --> 00:14.960
device and access

6
00:14.960 --> 00:19.130
to CLI, then ultimately you could automate that device. The same thing would be

7
00:19.130 --> 00:19.760
true for

8
00:19.760 --> 00:24.200
regular Python, you could use things like NetMico to connect over SSH and do

9
00:24.200 --> 00:24.800
your management,

10
00:24.800 --> 00:30.130
but again you're just managing the CLI. Now of course you can automate things
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:24.800 --> 00:30.130
but again you're just managing the CLI. Now of course you can automate things

11
00:30.130 --> 00:31.040
via the CLI,

12
00:31.040 --> 00:35.630
but you're kind of trying to use a square peg in a round hole right here. And

13
00:35.630 --> 00:36.480
the NetWorking

14
00:36.480 --> 00:40.800
world kind of realised it. So what actually happened was we had a development

15
00:40.800 --> 00:41.760
of more modern

16
00:41.760 --> 00:45.860
protocols to handle automation. Now this is what we're going to be talking

17
00:45.860 --> 00:47.520
about in this particular

18
00:47.520 --> 00:51.600
video, at least one of the modern protocols. So drumroll please, what is the

19
00:51.600 --> 00:52.720
name of this protocol

20
00:52.720 --> 00:57.520
that we are talking about? Well this one is called RestConf. Now you may recall

21
00:57.520 --> 00:58.320
from a previous

22
00:58.320 --> 01:02.720
scale we happened to talk about Rest API. Remember, representational state
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:58.320 --> 01:02.720
scale we happened to talk about Rest API. Remember, representational state

23
01:02.720 --> 01:03.280
transfer,

24
01:03.280 --> 01:07.610
the thing that uses HTTP with all of the HTTP methods and data scores that type

25
01:07.610 --> 01:08.240
of thing,

26
01:08.240 --> 01:11.900
well this is pretty much what we're talking about. We are effectively

27
01:11.900 --> 01:12.720
introducing the world

28
01:12.720 --> 01:17.320
of rest into our configuration management. Now first thing to state about Rest

29
01:17.320 --> 01:18.000
Conf is that it

30
01:18.000 --> 01:24.040
is a more modern implementation of something known as NetConf. So NetConf is

31
01:24.040 --> 01:25.360
older than RestConf,

32
01:25.360 --> 01:29.660
but it is also quite a bit more complex, at least because of the ability or

33
01:29.660 --> 01:31.280
rather the requirement
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:29.660 --> 01:31.280
rather the requirement

34
01:31.280 --> 01:35.550
to work with XML, you know, our old favourite, not really. So what I thought I

35
01:35.550 --> 01:36.880
would do would be to

36
01:36.880 --> 01:41.080
first deal with RestConf. And once we have that in the rear mirror then we can

37
01:41.080 --> 01:42.000
cycle back in an

38
01:42.000 --> 01:46.160
upcoming scale to talk a little bit more about NetConf. But for context just

39
01:46.160 --> 01:47.120
understand that

40
01:47.120 --> 01:52.120
RestConf kind of comes out of NetConf. It's pretty much a subset of NetConf

41
01:52.120 --> 01:52.880
that has been

42
01:52.880 --> 01:57.430
designed to work in this type of Rest API style manner. So you may recall when

43
01:57.430 --> 01:59.040
it comes to Rest APIs,

44
01:59.040 --> 02:03.190
if you just watched the previous scale we were utilising things such as HTTP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:59.040 --> 02:03.190
if you just watched the previous scale we were utilising things such as HTTP

45
02:03.190 --> 02:03.760
methods,

46
02:03.760 --> 02:08.820
these are still in play with respect to RestConf. So that means if you want to

47
02:08.820 --> 02:09.680
read information

48
02:09.680 --> 02:13.290
from a device, what would you do? You would send an HTTP get request if you

49
02:13.290 --> 02:14.560
want to modify

50
02:14.560 --> 02:18.540
your configuration. What could you do? Well you could send things like a post

51
02:18.540 --> 02:19.600
request. Maybe you want

52
02:19.600 --> 02:24.000
to delete a look back. What could you do? Send an HTTP delete request. So as

53
02:24.000 --> 02:24.960
you can probably tell,

54
02:24.960 --> 02:29.540
we really are heavily reliant on HTTP and more specifically we're going to be

55
02:29.540 --> 02:31.200
using HTTP. So this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:29.540 --> 02:31.200
using HTTP. So this

56
02:31.200 --> 02:38.160
means the default port for RestConf is going to be the default HTTP. So let's

57
02:38.160 --> 02:39.440
just back up a

58
02:39.440 --> 02:44.080
little bit for a moment. Remember what I just said about NetConf? NetConf is

59
02:44.080 --> 02:45.680
quite a bit more complex

60
02:45.680 --> 02:50.850
than RestConf and one of the reasons is because of its reliance on XML. So you

61
02:50.850 --> 02:52.240
will be pleased to know

62
02:52.240 --> 02:57.250
that with respect to RestConf, but RestConf also does XML. Okay, okay, okay,

63
02:57.250 --> 02:58.960
that was kind of anticlimactic.

64
02:58.960 --> 03:02.580
Perhaps you were wanting a better solution, but the good news is that I'm only
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:58.960 --> 03:02.580
Perhaps you were wanting a better solution, but the good news is that I'm only

65
03:02.580 --> 03:04.160
kidding on. We do

66
03:04.160 --> 03:08.870
have the ability to work with XML if we so wish with RestConf, but RestConf and

67
03:08.870 --> 03:10.160
the style of a true

68
03:10.160 --> 03:15.230
Rest API, we do also have the ability for JSON supports. So pretty much if you

69
03:15.230 --> 03:16.960
want XML, you can have it.

70
03:16.960 --> 03:20.720
But if you're not any type of RestConf enabled device is going to give you this

71
03:20.720 --> 03:22.400
ability to pull back

72
03:22.400 --> 03:27.040
and work with this JSON data much, much easier at least in my opinion. Again,

73
03:27.040 --> 03:28.160
big thing to remember

74
03:28.160 --> 03:32.640
here with respect to RestConf. If you recall when we talked about Rest APIs, we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:28.160 --> 03:32.640
here with respect to RestConf. If you recall when we talked about Rest APIs, we

75
03:32.640 --> 03:33.840
saw we had particular

76
03:33.840 --> 03:37.430
response codes, so that would mean that, you know, if you happen to have a

77
03:37.430 --> 03:38.560
successful request,

78
03:38.560 --> 03:42.320
the response code would start with a two. And if it was a successful retrieval

79
03:42.320 --> 03:42.960
of information,

80
03:42.960 --> 03:47.440
if you get request, you could expect to see a 200 response code, whereas if you

81
03:47.440 --> 03:48.560
happen to successfully

82
03:48.560 --> 03:53.350
create something, it would be a 201. These response codes are absolutely still

83
03:53.350 --> 03:54.800
valid and prevalent

84
03:54.800 --> 03:58.510
within RestConf, so it's going to give you a lot of information about the state

85
03:58.510 --> 03:59.760
of your request.

86
03:59.760 --> 04:05.660
Now pop quiz, if you can remember how exactly do we target particular resources
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
03:59.760 --> 04:05.660
Now pop quiz, if you can remember how exactly do we target particular resources

87
04:05.660 --> 04:06.240
when we're working

88
04:06.240 --> 04:11.390
with the Rest API? Well, if you remember, if we specify a particular URL and

89
04:11.390 --> 04:12.800
make a request to it,

90
04:12.800 --> 04:16.990
that's going to allow us to target a very particular resource within the Rest

91
04:16.990 --> 04:18.000
API server in a

92
04:18.000 --> 04:21.500
similar way or other in the exact same way, should I say? This is what we're

93
04:21.500 --> 04:22.320
talking about with

94
04:22.320 --> 04:25.770
network automation. So let me just highlight this to you. Imagine we've got our

95
04:25.770 --> 04:26.560
little router here,

96
04:26.560 --> 04:31.580
router one, and over here, this is me with my little Linux machine, okay, with
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:26.560 --> 04:31.580
router one, and over here, this is me with my little Linux machine, okay, with

97
04:31.580 --> 04:32.480
all of my Python

98
04:32.480 --> 04:36.710
code and all that stuff, as opposed to logging in and managing this device via

99
04:36.710 --> 04:37.920
SSH. Instead now,

100
04:37.920 --> 04:41.830
what I will be doing is making HTTP extra questions of the device. And on this

101
04:41.830 --> 04:43.120
device, because it has

102
04:43.120 --> 04:46.540
been configured to use RestConf, it's kind of acting like a little web server

103
04:46.540 --> 04:47.920
in a way, okay? So now

104
04:47.920 --> 04:52.870
imagine if you happen to have some OSPF configurations on this device, as

105
04:52.870 --> 04:54.960
opposed to logging in via SSH and

106
04:54.960 --> 05:00.150
typing, you know, show IP OSPF database or show IP OSPF interface, whatever it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
04:54.960 --> 05:00.150
typing, you know, show IP OSPF database or show IP OSPF interface, whatever it

107
05:00.150 --> 05:01.360
may be. Instead,

108
05:01.360 --> 05:06.570
you're going to send an HTTP get request to the target device. And in order to

109
05:06.570 --> 05:07.600
specify that you want

110
05:07.600 --> 05:11.690
OSPF information in your get request, what you're going to do is to target a

111
05:11.690 --> 05:13.440
very particular URL.

112
05:13.440 --> 05:18.020
Now, here is the crux of RestConf. This is a very, very big topic. And we

113
05:18.020 --> 05:19.120
briefly covered it in a

114
05:19.120 --> 05:24.050
previous skill. The way we actually specify the information that we want is all

115
05:24.050 --> 05:25.360
about how the data is

116
05:25.360 --> 05:31.090
modeled i.e. We correlated to the Yang model. Now, what I will say here is that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
05:25.360 --> 05:31.090
modeled i.e. We correlated to the Yang model. Now, what I will say here is that

117
05:31.090 --> 05:32.080
the Yang modeling

118
05:32.080 --> 05:36.160
portion of modern network automation. This is by far the most complex part that

119
05:36.160 --> 05:37.200
people kind of get

120
05:37.200 --> 05:41.800
tripped upon. It's unfortunate. But quite honestly, everyone I know seems to

121
05:41.800 --> 05:43.280
agree, Yang just is

122
05:43.280 --> 05:46.840
kind of hard to work with, even though it is very, very powerful. So all I'm

123
05:46.840 --> 05:48.080
saying is, if it does

124
05:48.080 --> 05:51.580
quite make sense, the very first time you look at it, then honestly just be

125
05:51.580 --> 05:52.400
kind to yourself,

126
05:52.400 --> 05:56.280
everyone is kind of the same way, just revisit it. And with some time

127
05:56.280 --> 05:57.600
practicing, it will then

128
05:57.600 --> 06:01.170
begin to sink in. So again, let me just draw this out one more time. Here's the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
05:57.600 --> 06:01.170
begin to sink in. So again, let me just draw this out one more time. Here's the

129
06:01.170 --> 06:02.160
router R1.

130
06:02.160 --> 06:06.240
It has been configured to use the RestConf protocol. Here is our Linux server

131
06:06.240 --> 06:06.960
over here that's

132
06:06.960 --> 06:11.920
going to be making HTTP requests or rather HTTP requests. And say, for example,

133
06:11.920 --> 06:13.200
that the IP address

134
06:13.200 --> 06:17.510
of this particular device, the router itself, let's go and imagine that the

135
06:17.510 --> 06:18.720
address was, I don't know,

136
06:18.720 --> 06:24.480
let's say 10.1.1.1. And also, let's pre-suppose that this device had been

137
06:24.480 --> 06:26.240
configured with a BGP

138
06:26.240 --> 06:29.530
information. So the way the request would actually look would be we would go

139
06:29.530 --> 06:31.360
and target 80 DPS,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
06:29.530 --> 06:31.360
and target 80 DPS,

140
06:31.360 --> 06:35.590
colon, forward slash, forward slash, then we would have either DNS name or the

141
06:35.590 --> 06:36.480
IP address of the

142
06:36.480 --> 06:41.440
target. So in this case here, it would be 10.1.1.1. And then the next

143
06:41.440 --> 06:43.520
components are going to allow us to

144
06:43.520 --> 06:47.080
specify which resource do we want to target. So it might look like, say,

145
06:47.080 --> 06:47.840
forward slash,

146
06:47.840 --> 06:54.320
restcon, forward slash data, forward slash BGP. Okay. So when we send this get

147
06:54.320 --> 06:56.320
request to this URL,

148
06:56.320 --> 07:01.140
this device knows to send back the BGP information over 80 DPS back to here and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
06:56.320 --> 07:01.140
this device knows to send back the BGP information over 80 DPS back to here and

149
07:01.140 --> 07:02.080
we can read it and

150
07:02.080 --> 07:06.980
it's going to be formatted in JSON or if we so wish we can have it come back to

151
07:06.980 --> 07:08.480
us in XML, the BGP

152
07:08.480 --> 07:12.070
information, which means that we can now work with it in a programmatic manner.

153
07:12.070 --> 07:12.560
Now like I say,

154
07:12.560 --> 07:16.830
this part here, the part where we specify the resource, this is absolutely not

155
07:16.830 --> 07:17.760
random, this is

156
07:17.760 --> 07:21.640
related to the Yang tree for whatever the configuration you're trying to target

157
07:21.640 --> 07:23.120
. So again, just hearing

158
07:23.120 --> 07:26.380
this, it does sound a little bit esoteric, but we will get to see examples and

159
07:26.380 --> 07:27.280
it should hopefully

160
07:27.280 --> 07:31.470
begin to slowly make more sense as you get familiar with it. Okay. So now we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
07:27.280 --> 07:31.470
begin to slowly make more sense as you get familiar with it. Okay. So now we

161
07:31.470 --> 07:33.200
know that restcon is going

162
07:33.200 --> 07:36.770
to allow us to interact with a device much like a rest API. We're going to have

163
07:36.770 --> 07:37.280
access to

164
07:37.280 --> 07:41.600
a crowd operations, a response code, that type of thing. With that now said,

165
07:41.600 --> 07:42.400
let's take a look at

166
07:42.400 --> 07:46.310
some particular library we can use in order to make use of requests to write

167
07:46.310 --> 07:47.120
the via Python.