0:00

Fortune 500 companies trust Interoptic for

0:02

optical transceivers and cables. Since 2004,

0:04

Interoptic has provided high-performance optics and

0:06

cables at a fraction of the

0:09

cost of OEM gear. Interoptic products

0:11

are 100% tested and backed up

0:13

by real engineers. Work with the

0:15

optics experts at Interoptic. Find out

0:18

more at Interoptic.com/packet pushers. Welcome

0:20

to Heavy Network the flagship podcast from

0:22

the Packet Pushers podcast network. Heavy networking

0:24

has been coming to you weekly since

0:26

May 2010. I can't believe I still

0:28

have this job. We are coming up

0:30

on our 15th anniversary and that is

0:32

pretty cool. I'm Ethan Banks and with

0:34

me is Drew, Conray Murray. You can

0:37

find us on LinkedIn, Blue Sky and

0:39

the 100% free Packet Pushers community slack

0:41

group. Give us a follow and DM

0:43

us in any or all of those

0:45

places. Our topic today is network automation.

0:47

Okay, so thinking about this, maybe I

0:49

should say today's topic is advanced network

0:51

automation because specifically we're going to jump

0:54

into continuous integration, continuous deployment pipelines. As

0:56

network automation evolves, CICD pipelines have found

0:58

use cases, but getting your head around

1:01

what they are, how they work, whether

1:03

you actually need them, that can all

1:05

be a challenge. Tony Burke is our

1:07

guest today and Tony brought this topic

1:10

to us as it's part of the

1:12

automation curriculum that he teaches as a

1:14

networking instructor. And of course, again, whether

1:17

you need a pipeline at all is

1:19

an open question because we don't do

1:21

things because they're cool. We do things

1:23

because they make our lives easier. Okay, I

1:25

lied a little bit because sometimes

1:27

I want to do things just

1:30

because they're cool, but I don't

1:32

want to put them into broad

1:34

unless I am prepared to live

1:36

with them forever. And so Tony

1:38

is going to help us figure

1:40

out whether or not we need

1:42

pipelines. And if we do need

1:44

them, what they accomplish and if

1:46

we do need them, what they

1:49

accomplish and how to implement them

1:51

and if you've never listened to

1:53

a podcast with Tony before, Search

1:55

for Tony Burke on packetpushers.net to

1:57

find every episode where he...

1:59

has appeared. So Tony, welcome back. And

2:01

let's jump in with the first question here.

2:04

The goal of network automation as we were

2:06

discussing this prepping for the show. We kind

2:08

of agree the goal of network automation is

2:11

not to build a pipeline. There's no specific

2:13

tool. That's the goal. All right so before

2:15

we start talking about pipelines what then is

2:17

the goal of network automation we should be

2:20

keeping in mind. So generally speaking the reason

2:22

why we do automation is not because like

2:24

you said because we're doing something cool is

2:27

because we want to we want to get

2:29

something out of it so there's generally four

2:31

things that we get with network automation in

2:33

general not necessarily CICD but just network automation

2:36

in general so we get scale so the

2:38

number of devices that we can configure is

2:40

going to be much higher with network automation

2:43

than if we were doing it manually. complexity.

2:45

So there is some configurations that are better

2:47

generated than they are typed out by hand.

2:49

So easy B and VX land is one

2:52

of them. There's a lot of spinning plates,

2:54

I think you put it on one of

2:56

our previous podcast. So there's a lot of

2:59

that going on. So you want something to

3:01

generate those configs. So complexity, how often do

3:03

we make these changes? Do we want to

3:05

make them more frequently than we have before?

3:08

We can move from making a change every

3:10

change every two weeks. And then finally accuracy,

3:12

making sure that the changes that we make

3:15

actually work the way that we expect them.

3:18

Okay, so those are those are

3:20

straightforward enough. We've and we've heard

3:22

that before those arguments about network

3:25

automation. The one about accuracy is

3:27

one of the leaders to me

3:29

because because we human suck compared

3:31

to the robots. So if we

3:33

can template our change and know

3:35

exactly what's going to happen without

3:37

us fat fingering things because we're

3:39

doing the change programmatically that's that's

3:41

a win for sure. But then

3:43

everything else just at scale complexity

3:46

of configurations. I haven't had to

3:48

deal with EVP in. And that

3:50

was another one that was, I

3:52

know EVPEN's even more complex by

3:54

a significant margin, but even DMVPN

3:56

was hard. The configuration I'd have

3:58

to put in just for a

4:00

single interface to for a. for

4:02

a DM, VPM facing box was

4:04

enormous and complicated. So, okay. Well

4:06

then, with that backdrop, a scale

4:09

of devices, complexities, configurations, frequency of

4:11

changes, and then accuracy, making sure

4:13

we're taking, reducing the amount of

4:15

finger presses that a human has

4:17

to invoke in order to make

4:19

a change, let's drill into CICD.

4:21

Continuous integration, continuous deployment. Can you

4:23

translate these? What I really think

4:25

of these is developer concepts Tony,

4:27

translate these developer concepts into network

4:30

engineering terms. Yeah, there's a couple

4:32

different ways we could go with

4:34

that. So CICD is a development

4:36

term and it means continuous integration.

4:38

continuous development or something like that.

4:40

And what it was is in

4:42

the early 2000s there was a

4:44

need to rapidly iterate software. So

4:46

developers had been using the more

4:48

traditional waterfall method where they would

4:51

make a lot of changes to

4:53

code and then deploy everything all

4:55

at once. And as you can

4:57

imagine that probably didn't go well.

4:59

You know we have the same

5:01

problem in networking as we make

5:03

some a bunch of changes we

5:05

deploy them all at once and

5:07

they don't go well. With developers

5:09

they probably had at least a

5:12

QA and maybe user acceptance testing

5:14

UAT cycle before they did put

5:16

it into prod but still. you

5:18

would think, you know, one big

5:20

whacking change, right? You would think,

5:22

yes. I mean, I worked in

5:24

a bunch of shops where that,

5:26

where that was the hope that,

5:28

like, man, I hope we catch

5:30

the stuff before we send this

5:33

big massive change into production. But

5:35

yeah, putting into production inevitably, the

5:37

joke would be, yeah, so and

5:39

so just deployed a new version

5:41

and I guess where the beta

5:43

testers the beta testers as they

5:45

released it on an unsuspectinging public.

5:47

So the last job that I

5:49

had where I was a cis

5:51

admin, where I was a Linux

5:54

admin, that was exactly how we

5:56

did it. So the developer. would,

5:58

we were competing against Google if

6:00

that gives you an indication of

6:02

the hubris that was going on.

6:04

But so they, you know, the,

6:06

the management team would come up

6:08

with the new feature and they

6:10

would give it to the development

6:12

team and they would quickly implement

6:15

it. And then their, their entire

6:17

testing process was putting a $2

6:19

transaction to the system. That was

6:21

it. They did nothing else. There

6:23

was no low testing, unit testing,

6:25

integration testing. And then we would

6:27

deploy it at like midnight and

6:29

nine times out of 10 it

6:31

would break like the whole thing

6:33

would halt. And they would try

6:36

to blame the servers and the

6:38

network and all that but it

6:40

was just it was just a

6:42

bad way to deploy that code.

6:44

And we weren't being able, we

6:46

could not keep up with Google

6:48

who was already implementing these CICD

6:50

tactics, the CICD processes. So what

6:52

CICD does is it's a process.

6:54

And I'm going to give you

6:57

a general idea of what that

6:59

process is. It could, it certainly

7:01

would differ from shop to shop,

7:03

but from a developer perspective. So

7:05

if someone comes up with an

7:07

idea for a new feature in

7:09

a given code base, so it's

7:11

given to the developer, the developer,

7:13

typically just one person, will write

7:15

the code to implement that feature.

7:18

And then when they're done, then

7:20

they they'll do a commit to

7:22

a like a get repository could

7:24

be get hub get lab whatever

7:26

that commit will automatically kick off

7:28

a series of processes. So the

7:30

thing about C. ICD is it

7:32

integrates testing before deployment and after

7:34

deployment and even automation of the

7:36

deployment, but it also automates going

7:39

from one step to the next.

7:41

So by just doing a commit

7:43

to that code base. in the

7:45

in the get hub repo or

7:47

get lab repo or whatever it

7:49

is, it automatically kicks off a

7:51

bunch of tests. So generally they

7:53

start off with what's called unit

7:55

test. So just testing the individual

7:57

functionality of that code. And there

8:00

is ways to write tests for

8:02

your code and. And if it

8:04

passes all those, if it doesn't

8:06

pass those tests, then the developer

8:08

gets a report, the developer goes

8:10

in and tries to fix those

8:12

problems. And then once there is

8:14

a good test, then it goes

8:16

into integration testing. So integration testing

8:18

tests integration with the other components

8:21

of whatever system, it could be

8:23

microservices or whatever, making sure that

8:25

it works with a credit card

8:27

transaction processor, etc. etc. So once

8:29

all that's done, then it will

8:31

get built. Maybe they'll be of

8:33

like a pre-deployment process. And by

8:35

the way, the software that's doing

8:37

this shepherding through the process could

8:39

be get have actions, it could

8:42

be Jenkins, there's a bunch of

8:44

other tools that are specific to

8:46

a platform like a typescript or

8:48

whatever, and those are software development

8:50

platforms. And then when it's time

8:52

for production. time to go to

8:54

deploy to production and of course

8:56

that's automated as well. The only

8:58

manual part about this process would

9:00

be the editing of the code

9:03

and then probably the big shiny

9:05

button that says deploy. So generally

9:07

we like humans to actually do

9:09

the deploy to decide okay we're

9:11

ready to deploy but they're deploying

9:13

this in the middle of the

9:15

day. So they're not waiting until

9:17

like a low usage time. So

9:19

the the blue sky is the

9:21

Facebook. the Netflix is they're deploying

9:24

typically several times per day dozens

9:26

of times reading Google's case are

9:28

probably deploying thousands of times per

9:30

day. But because this process is

9:32

so trusted now it doesn't work

9:34

out every time there's always going

9:36

to be problems but this because

9:38

this process is so trusted they're

9:40

able to rapidly iterate on the

9:42

software platforms and get quality code

9:45

out much faster than they ever

9:47

have been before. Are

9:50

there mechanisms in place? I'm just thinking

9:53

of the example you gave of like,

9:55

okay, I'm writing the part of the

9:57

code for this website that, you know,

9:59

attaches an image to a picture when

10:01

a user does a search on an

10:03

item. To make sure, I guess I'm

10:05

thinking like, there's so many moving parts

10:07

here, like, okay, I tested it against

10:09

the code that's published now, but the

10:11

folks doing the credit card transactions are

10:13

also updating almost at the same time.

10:15

So how do we know that their

10:17

changes that they're making are going to

10:19

work with the changes that I just

10:21

made that worked with version X of

10:23

the code, but now it's version X.1

10:25

and they're making a change and maybe

10:27

something broken. the thing I did that,

10:29

do you see where I'm getting at?

10:31

Yeah, yeah, there's always those issues that

10:33

can come up. And a big part

10:35

of this process is testing. We test

10:37

the code before, and we test the

10:39

code after. So once it goes, before

10:41

we goes into production, we're doing unit

10:43

tests and integration tests, and then after

10:45

the code is deployed, we're doing other

10:47

types of tests to make sure that

10:49

everything's working the way that we expect

10:51

it to work. Now I want you

10:53

to keep that in mind because that's

10:55

going to be a big part of

10:57

the transition from the software development world

10:59

over to the networking development world. The

11:01

integration with other components really isn't a

11:03

big issue when we move it over

11:06

into the networking world, but it certainly

11:08

is an issue in the developer world,

11:10

where they have that kind of thing.

11:12

Another thing about the deployments is if

11:14

there is a problem that happens after

11:16

all the tests pass and they deploy

11:18

it and they still find a problem,

11:20

then they write a new test. So

11:22

the number of tests that they have,

11:24

these unit test integration integration, these unit

11:26

test integration tests, they tend to go

11:28

over time. they're kind of always paired

11:30

together spoken in the same breath almost.

11:32

Are they inseparable? Do you, if you're

11:34

doing one, do you have to do

11:36

the other as well? Yeah, pretty much.

11:38

In fact, they're really hard to separate.

11:40

And for example, Arista says, you know

11:42

what, we're just gonna call continuous integration.

11:44

They don't even use CICD. And so

11:46

the two terms are, they're hard to

11:48

separate. It's hard to cut the process

11:50

off that says continuous integration and the

11:52

other part. And the boundary between them

11:54

can get a little fuzzy. So we

11:56

just we just use it in the

11:58

same breath and there's not. a point

12:00

in separating them. You also, and the pipeline

12:03

is another thing that's in the same breath

12:05

as CI and CD, is that, how do

12:07

we think of that? Is that just the

12:09

practical tool for delivering CI and CD? Yeah,

12:11

that's the pipeline is how do we get

12:14

from step A to step B to step

12:16

B to step C to steps D? It's

12:18

the glue that ties it all together. So

12:20

there's a process that will do the unit

12:22

test. There's a process that will do the

12:25

integration test. There's a process that will do

12:27

the integration test. There's a process that will

12:29

build the artifacts for deployment. There's a process

12:31

that will do deployment. So how do we tie

12:33

all that together? figuring out all the different steps

12:36

in the order that they need to be achieved

12:38

in, and then finding the software that's going to

12:40

do that automation to get from one step to

12:42

the other. So again, that's like get have actions

12:45

or Jenkins or something like that. Yeah, I filled it

12:47

with Jenkins a little bit and it really

12:49

demystifies pipeline, even if you don't have using

12:51

Jenkins as a tool, just some of the

12:53

so many tutorials out there and it's so

12:55

widely supported that if trying to get your

12:57

head around what the pipeline does as a

12:59

series of steps as kind of glue that

13:02

makes the whole process happen. To me, Tony,

13:04

it's like it comes quick just spending a

13:06

few minutes with it's like, oh, okay, I

13:08

see what's going on here. Yeah, yeah, there's

13:10

not really anything too complicated about it.

13:12

It's just when this happens, do this.

13:15

And then when that is done, do

13:17

this thing next. So is pipeline

13:19

a logical construct or is there

13:22

also sort of a software application

13:24

attached to it? Or is it just a

13:26

set of processes and we'll find

13:28

different software applications to help us

13:31

stitch those processes together? It's the

13:33

latter. It's a concept. We've got

13:35

these, we've got all these steps, like, you

13:38

know, think about a deployment process. We've got

13:40

all these steps we need to accomplish. How

13:42

much of it can we automate? And usually

13:44

we can automate most of it. We don't always

13:46

have to automate, but most of it, but

13:49

we can. And again, the only part that

13:51

we generally don't automate is the actual deploy,

13:53

you know, the decision to hit the button

13:55

that says deploy, the big shiny red button.

13:57

But other than that, the rest of it, we, we

13:59

can. do through automation and how do

14:01

we stitch all that together and that's

14:04

what like Jenkins or get-up actions do.

14:06

Okay. Well, let's do some visualizations, Tony.

14:08

Let's say I'm far enough along with

14:10

my network automation. I'm on a journey,

14:13

Tony. It's far enough along on my

14:15

journey that I can I can make

14:17

configuration magic happen with with Python or

14:19

Ansible and I'm curious about a pipeline.

14:22

So what does a pipeline bring to

14:24

the table for me? Well, let's take

14:26

a step back. So we talked about

14:28

CIC in terms of software development and

14:31

what we did, what we've done with

14:33

a lot of network automation is we've

14:35

taken a lot of the concepts that

14:37

they've done in the software world and

14:40

we translated them into the into the

14:42

networking world and like any kind of

14:44

translation like that, not everything copies over

14:47

one to one. So let's talk about

14:49

what a pipeline would look like, what

14:51

CIC to looks like in terms of

14:53

network administration, network automation. And there's again

14:56

it's one of the things where there

14:58

could be a lot of variability but

15:00

I'm going to give you a very

15:02

general simplified concept of it so it

15:05

starts off with a type of network

15:07

change so I want to add a

15:09

V land to my fabric or I

15:11

want to add a new upstream provider

15:14

so BGP or I want to if

15:16

I've got an SDWAN solution I want

15:18

to add a new new site so

15:20

I've got the idea. So then I

15:23

go into the, in most CICD, we've

15:25

got some sort of network automation that

15:27

it works as what we would call

15:29

network as code or intent based networking.

15:32

So we have an abstracted representation of

15:34

desired networking state. So that could be

15:36

a yamel file, could be a spreadsheet,

15:38

something abstracted. So there's no syntax. It's

15:41

just Vlan 10 and the SPI is

15:43

going to be 10101 slash 24, something

15:45

like that. So we can describe what

15:48

we want without giving it actual syntax.

15:50

It could be on a fabric wide

15:52

basis. So I've got just one file

15:54

that will configure dozens or hundreds of

15:57

devices or it could be on an

15:59

individual device basis. So I'm looking at

16:01

leaf one or router five, or it

16:03

could be combination thereof. And so I've

16:06

got these files or I've got these

16:08

abstracted representations of desired configuration state, and

16:10

then I make the change. Now with

16:12

networking as code, once I make the

16:15

change, then the next step would be

16:17

to generate the configs from that abstracted

16:19

data model. We call it a data

16:21

model. So a yamel file spreadsheet, whatever.

16:24

So I run a command and then

16:26

it takes the information in that abstracted

16:28

representation and will generate actual syntax for

16:30

the devices. So now I've got syntax.

16:33

One of the things that I could

16:35

do before I generate that though, I

16:37

forgot is I could do like a

16:40

spell check for yamel. There's called linting

16:42

or a linter. It just checks to

16:44

the amel to make sure that I

16:46

didn't make a mistake on the yamel.

16:49

Or it might even be notorious for

16:51

its ability to get it wrong because

16:53

you got to have the white space

16:55

correct and so correct. Yeah. So it'll

16:58

just check to make sure that the

17:00

animal is correct that you've got lists

17:02

correct or dictionaries correct or whatever. And

17:04

then if you put in some kind

17:07

of schema can check against the schema

17:09

as well, just to make sure you

17:11

get the formatting rate before you even

17:13

go to generate the config. So then

17:16

we generate the config. We could also,

17:18

these are just text files typically. Most

17:20

devices in the networking world, there are

17:22

a few exceptions, but most devices in

17:25

the networking world, use a single configuration

17:27

model. So there's one file that has

17:29

the entire configuration for a device. For

17:32

those of us who have worked in

17:34

the Cisco world or even the Arista

17:36

world, that's running config. So we've got

17:38

a bunch of configs. We could potentially

17:41

run some tests on those. Then we're

17:43

ready for deployment. So the next step

17:45

after that is to take those configs

17:47

and then push them to the various

17:50

devices where they need to go. After

17:52

that is done we've got a new

17:54

deployment we've got a new configuration state

17:56

on our devices so what it would

17:59

to do then we want to do

18:01

some automated testing. So there's different libraries

18:03

that can allow us to do some

18:05

some testing. So that is generally the

18:08

the pipeline that we have for network

18:10

automation. Let me let me quickly read

18:12

this back to you 20. The pipeline

18:14

then is a way to it's almost

18:17

like automating automation or it's it's really

18:19

automating a lot of the operational tasks

18:21

that I should be doing. That is,

18:24

if I was doing all of this

18:26

by hand, and I, you know, if

18:28

I forget about automation completely, just go

18:30

old school, if I was to be

18:33

sitting at a CLI and typing commands

18:35

in at the CLI to create a

18:37

change, I would then, what I should

18:39

be doing from there is checking that

18:42

my change went well. I have routing

18:44

adjacencies that I'm expecting and I'm seeing

18:46

routes in the routing table that I'm

18:48

looking for or whatever it is, a

18:51

million things I would be looking for.

18:53

And as a responsible network engineer, I

18:55

probably would have built a list of

18:57

this is what I expect to see

19:00

when this is done kind of thing

19:02

so I can manually go back and

19:04

check those things. That's a pipeline that

19:06

I work through by hand, this whole,

19:09

writ large, everything that you just described

19:11

is something that I would have done

19:13

manually. The first step of my automation

19:16

on my automation journey might be, I'm

19:18

going to take the one thing that's

19:20

hard to do and bake that into

19:22

a script so that I can push

19:25

a change to 100 devices or a

19:27

thousand devices, whatever it might be, you

19:29

know, and then proceed from there. Now

19:31

we're saying, I don't. want to have

19:34

to remember all the little things that

19:36

I should be doing pre during and

19:38

post delivery of this change. I want

19:40

some process to track all of that

19:43

for me. That's the pipeline. It's what

19:45

the pipeline is doing. Is that fair?

19:47

Yeah. And another way to look at

19:49

it is the pipeline is all the

19:52

steps I need to do to actually

19:54

make the change happen through network automation

19:56

and then... And do I want to

19:58

automate those steps, the combination of those

20:01

steps? So all the steps I just

20:03

mentioned to you can be automated, the

20:05

generating the config, you know, that says

20:07

network automation step, pushing the config through

20:10

automation. So, you know, one of the

20:12

things that I really think we should

20:14

be doing is getting away from. Getting

20:17

away from pacing things into terminal windows.

20:19

There's so many problems that can happen

20:21

with that. You know, ask me how

20:23

I know, but. Show me, show me

20:26

on the terminal where the paste buffer

20:28

hurt you, Tony. So many problems, you

20:30

know, like you paste into a window

20:32

and there's a syntax error and it

20:35

goes by so quickly. You're like, okay,

20:37

so it didn't take that command. So

20:39

that's going to be a fun little

20:41

surprise when I, you know, go to

20:44

do testing and. figure out what didn't

20:46

get accepted. Or yeah, I paced 100

20:48

lines and 75 of them got taken.

20:50

I don't know which 25 didn't. So,

20:53

so anyway, yeah, so we've got all

20:55

these individual steps, generate the config, pre-test

20:57

the config, deploy the config, do post-employment

20:59

testing. So our pipeline's probably not as,

21:02

you know, pipeline, just another word for

21:04

the steps that we need to do.

21:06

And do we want to glue them

21:09

together with some sort of automation? You

21:11

know that's that's that's what CICD is

21:13

is gluing it all together with automation.

21:15

We don't have to do that. You

21:18

know we we get probably most organizations

21:20

will get 95% of the benefit of

21:22

network automation by just generating the config

21:24

from some sort of template deploying it

21:27

through automation versus pasting it into a

21:29

terminal window. And then doing having some

21:31

sort of post deployment testing and the

21:33

tools for all the for just about

21:36

every vendor that I know of are

21:38

out there to do those three things.

21:40

So in the model we've just talked

21:42

about, can you give an example of

21:45

what would be generating the config is

21:47

a hand it would be me for

21:49

my brain I would generate the config

21:51

but what piece of. software is doing

21:54

that in this pipeline model? So there's

21:56

a couple of options. There is a

21:58

roll your own option. So it's actually

22:01

not that difficult to make a template

22:03

through a template system called Ginger. It

22:05

works with Ansible. It's the built-in template

22:07

system for Ansible. So you write this

22:10

code. It's kind of like Python code.

22:12

But it will, you can generate your

22:14

own custom configuration or custom templates. It

22:16

can read yamel files pretty easily. It'll

22:19

take the values from the yamel file,

22:21

put them into the various places in

22:23

your template, and then out comes syntax.

22:25

So native configuration syntax. So that's one

22:28

way to do it. Quick question on

22:30

that. So you say syntax, which makes

22:32

me think of CLI, config syntax, whatever

22:34

the. vendor demands for a CLI, but

22:37

it could be it could be an

22:39

API call is that it could be

22:41

some other way to push that configuration

22:43

into the device. Most of the time

22:46

we're going to do syntax. We're going

22:48

to replace the running config or whatever

22:50

the equivalent is. There are a couple

22:53

of exceptions. For example, Cisco ECI. There's

22:55

a quasi CLI, but that's not really

22:57

where the configuration state is. The configuration

22:59

state is the manage object model. So

23:02

that would be a API. that we

23:04

deal with, I think you would agree,

23:06

have a single running config or something

23:08

that we call a running config. You

23:11

know, there was something equivalent to it,

23:13

like Juniper, has their, I can't remember

23:15

what they call it, but there's one

23:17

file that has all of the configuration

23:20

in it, and then we're gonna generate

23:22

that. And it is in fact what's

23:24

loaded by the device at boot time

23:26

you actually yeah it goes and seeks

23:29

that and that is how it loads

23:31

its configuration yeah yeah and there's methods

23:33

that you know there's a couple different

23:35

ways to do it Python Ansible a

23:38

couple other ways to take a config

23:40

that you have a text file and

23:42

loaded onto the device and then switch

23:45

over and then most the devices also

23:47

have a method so that if you

23:49

do do a switch over that anything

23:51

already config that is in the old

23:54

config and is also in the new

23:56

config, you don't drop your BB peers

23:58

or anything like that. So only the

24:00

disruptive changes would like drop a, you

24:03

know, drop a session. You're differentiating than

24:05

we're differentiating here, how, you know, we're

24:07

gonna generate a config file and the

24:09

method we deliver that config file. could

24:12

be a variety of things. It could

24:14

be an SSH session that happens in

24:16

the background and and delivers it. A.K.A.

24:18

Ansible could do that. It could be

24:21

delivered by an APA call. Heck, I

24:23

think back in the day, Tony, it

24:25

could have been delivered over S&P, depending

24:27

on the box. Yeah, yeah, in this

24:30

case, we would either, you know, most

24:32

devices have a way to do it

24:34

through like SSH through a screen scra,

24:37

like Net Miko, or it could be

24:39

done through an API, like an API,

24:41

like an API, like an RPC, like

24:43

an RPC, like an RPC. So for

24:46

example with ERISA EOA I teach ERISA

24:48

most of these days so I'm very

24:50

familiar with this process so that's why

24:52

I'm going to use this as an

24:55

example but the other vendors have something

24:57

similar. There's a way to take a

24:59

config and upload it through the through

25:01

EAP so that's a Jason RPC. It's

25:04

basically just encapsulating native EOS syntax into

25:06

a Jason commands remote procedural. I'm sorry

25:08

to hammer on this thing here but

25:10

interestingly what we're not talking about in

25:13

this specific step we are talking about

25:15

building that configuration text file network engineers

25:17

are familiar with we're not talking about

25:19

I want to configure BGP what is

25:22

the data model in this device for

25:24

BGP and the API calls that I'm

25:26

going to make to facilitate a specific

25:28

BGP change instead we're leaning into it's

25:31

a config file with text. Yeah and

25:33

so one of the the concepts that

25:35

we're going to do is removing the

25:38

source. of truth away from the device.

25:40

So for the past 30 years, whenever

25:42

we've configured a device, the single source

25:44

of truth for configuration state has been

25:47

on the device that's been running config,

25:49

and then start of config is how

25:51

it gets booted, or equivalent. So I'm

25:53

just using running config as an example.

25:56

Now we're we're moving that off the

25:58

device. We're moving it into these yamel

26:00

files or spreadsheets or databases or whatever

26:02

it is. Where were we getting the

26:05

information that we need to build the

26:07

config? And every time we do a

26:09

deployment, we're replacing the config entirely. So

26:11

we're doing a full configuration build and

26:14

a full configuration replace. So the yamel

26:16

files that I'm collecting are essentially a

26:18

record of every configuration that's on devices

26:20

I'm touching. Correct. It's our desired configuration

26:23

state. We're going to build. Now, this

26:25

is probably one of the most important

26:27

aspects network automation, not CICD. CICD is

26:30

just the glue that we use that

26:32

we can as an option used to

26:34

glue all this, these processes together. But

26:36

one of the most important steps is

26:39

building our configuration from our data models.

26:41

So don't, you know, the data model

26:43

could be yamel, could be a spreadsheet,

26:45

could be a sequel light database, something

26:48

like that. But now. our desired configuration

26:50

state is not on the devices anymore.

26:52

We will get there, but when we

26:54

make a change, we don't make a

26:57

change on the devices anymore. So this

26:59

means no more CLI configuration. We can

27:01

do CLI troubleshooting. That's no problem. But

27:03

we're not going to go into a

27:06

device and do a run like conftee.

27:08

We're going to go into the data

27:10

model to make the change. Unless it's

27:12

an emergency, but you know, that's like

27:15

open that can of words. around field

27:17

environment then, am I essentially porting the

27:19

existing config off of my devices into

27:22

some kind of yamyl file structure and

27:24

then working from there? you can set

27:26

it up so that you've got properties

27:28

for an individual device, you've got properties

27:31

for a group of devices. So maybe

27:33

all my spines have something similar in

27:35

common. Maybe all my leaves have something

27:37

similar in common. Maybe all my devices

27:40

have something similar in common, like my

27:42

AAA, NTP, DNS, and all that. There's

27:44

ways to do this through the templateing

27:46

system. So there's a couple different files.

27:49

Like there's like, let's say I wanted

27:51

to change my NTP. from one IP

27:53

address or one set of IP addresses

27:55

to another one. Well, I would just

27:58

change one file in YAML and then

28:00

regenerate all the config or let's say

28:02

I wanted to add a new spine,

28:04

then I would probably have to update

28:07

several YAML files and then regenerate the

28:09

configs and then it would build new

28:11

new relationships between the spines and the

28:14

leaves to point the point links. I

28:16

might put an IP address to them

28:18

on them manually or on my something

28:20

like ERista AvD. which also uses yamel

28:23

files, you just define what ports are

28:25

the point to point ports, and then

28:27

it auto assigns IP addresses to them.

28:29

And the benefit here, the reason why

28:32

we're doing that, it does require some

28:34

new skills, some new tooling, the reason

28:36

why we're doing that is that we

28:38

get the accuracy. Because if the template

28:41

is right, and the information is right,

28:43

then the config's gonna be right. Now

28:45

you can get the template wrong, you

28:47

get the information wrong, and garbage and

28:50

garbage out, but if you get those

28:52

right, then you're going to get a

28:54

good template, you're going to get a

28:56

good config every time. And the other

28:59

interesting thing is the method in which

29:01

you want to push the config, Tony,

29:03

which is the kill the old one,

29:06

we're going to upload the new one

29:08

in its entirety, and then load it,

29:10

as opposed to the... got a bunch

29:12

of commands, paste them in, and then

29:15

hope the CLI doesn't cough something back

29:17

at you, which is, again, something we're

29:19

all so familiar with. Like, oh, crap,

29:21

it didn't take that because I got

29:24

it out of order. I fat-fingered something,

29:26

or whatever the case may be. Right.

29:28

Yeah. You're really guaranteeing that that if

29:30

your templates are right, you push the

29:33

config in its entirety and do a

29:35

wholesale replace, it's going to work. Yeah,

29:37

and that's that's a big, you know,

29:39

that, you know, all of these are

29:42

meant to eliminate a lot of the

29:44

common problems that we have. So if

29:46

we generate our configuration by a template,

29:48

we're consistent and we're accurate. As long

29:51

as we give it the right template,

29:53

we'll longer give it the right information

29:55

in the data model. You know, not

29:58

to say that you can't get that

30:00

wrong, but it's going to be a

30:02

lot easier to get it right over

30:04

time. So I'm generating good configs and

30:07

I've got a really high confidence that

30:09

my configures are good. Then when I

30:11

do a deployment by using that config

30:13

replace, you know, when we do a

30:16

config, now we only have two potential

30:18

states, we have the previous state, and

30:20

then we have the new state. When

30:22

we're pasting through a terminal window, We

30:25

have three states we have the previous

30:27

state we have the desired state and

30:29

then we have some weird quasi see

30:31

that happens because I got a syntax

30:34

error kicked back or the buffer didn't

30:36

paste every line. So now I've got

30:38

this. I don't know what state I'm

30:40

in right now and I have to

30:43

figure that out and unwind that you

30:45

know that's not a really when you

30:47

have to do that that's going to

30:49

be a pretty bad. This could be

30:52

a pretty bad deployment. And then also

30:54

like scale wise how many terminal windows

30:56

can you paste into? What's your limit?

30:59

What's your personal limit? Is it going

31:01

to be like 20 devices, 50 devices,

31:03

100 devices? With this process, I can

31:05

make rapid changes, accurate changes, and do

31:08

good deployments to hundreds or even thousands

31:10

of devices, then the time it would

31:12

take you to do like 10 devices

31:14

manually. Let's pause for a

31:17

message from our sponsor Interoptic. Interoptic

31:19

is the optical transceiver and cable

31:21

specialist that maximizes your IT savings

31:23

while minimizing network failures. Interoptic provides

31:25

high performing optics at a fraction

31:27

of the price of brand name

31:30

optics. The interoptic experts can help

31:32

you spec the best optical transceivers

31:34

and cables for your network environment.

31:36

Interoptic optical transceivers are 100% guaranteed

31:38

to be operationally equivalent with Cisco,

31:40

Juniper, Extreme, Arista Brocade, Palo Alto,

31:42

and many other switches and routers.

31:44

Due to Interoptic's deep optical transceiver

31:47

technical experience, they can ensure that

31:49

all messages, alerts, alarms, and threshold

31:51

data are equivalent to OEM brands.

31:53

Interoptic deploys rigorous 100% testing on

31:55

their devices before they're shipped. Interoptic

31:57

optical transceivers are built to the

31:59

exact same quality standards as the

32:02

OEMs. and typically come from the

32:04

exact same manufacturing lines. That's why

32:06

insurance companies, retailers, financial services, and

32:08

federal and state government customers deploy

32:10

optics and cables from Interoptic. You

32:12

can purchase the same if not

32:14

better performing optical transceivers tested and

32:16

backed up by real engineers at

32:19

a fraction of OEM costs. Find

32:21

out more at interoptic.com/packet pushers. And

32:23

now back to the podcast. I guess

32:25

one thing I want to make sure I understand

32:27

is how I get from... sort of a

32:29

template which to my mind is just

32:32

sort of an outline to very specific

32:34

actual lines of config how and and

32:36

what is what piece of software

32:38

is looking at my template and saying

32:40

okay in a Cisco environment I would

32:42

write out this set of config stances

32:44

and a wrist I do it this

32:46

way how does that happen? Yeah so

32:48

that would be the ginger template

32:51

file and a ginger template file

32:53

contains either just raw syntax Because

32:55

there's going to be

32:57

some boilerplate in your

33:00

configs that are just going

33:02

to be the same for

33:04

everything. And then you have like,

33:06

let's say in YAMO, I have a

33:08

list of V-L-N-10, V-V-N-T, V-N-T,

33:11

V-N-T, V-N-T, V-N-T, V-N-T, V-N-T,

33:13

V-N-T, V-N-T-V-V-T, and creates VLAN

33:15

10, VLAN 20, VLAN 30. And maybe it

33:17

loops through the interface VLANs to configure

33:19

the SVIs on them as well. So

33:22

it's a little bit of logic

33:24

that you put into the template.

33:26

It's relatively easy to do.

33:28

And then you might take you a

33:30

week to get those templates right. But

33:33

think about the payback after you

33:35

get those templates right. Then

33:37

you're using a Python script

33:40

is referencing the ginger template

33:42

to generate the text file.

33:44

It can. Or more traditionally answerable.

33:46

So Ansible would have, oh, you

33:48

would say, okay, I'm going to

33:50

take this ginger template and this

33:53

yellow file and I'm going to combine them

33:55

and then I'm going to spit out a

33:57

native syntax based on what I

33:59

have. the template or something like

34:01

Arista Avid, the all the template's already

34:04

there. So with Arista Avid,

34:06

Arista has already written the

34:08

templates. So all you do

34:10

is, and it's based off of

34:12

Arista best practices, or Arista validity

34:15

to designs, and you just feed at

34:17

the yamel to, you know, there's yamel

34:19

for the, to build an EVP and

34:21

VX land fabric, to a layer two

34:24

leaf spine fabric, which is like

34:26

the traditional like collapse core, there's

34:28

one to do MPLS. Or

34:30

a set of yamel files and you

34:32

rate these yamel files and it's

34:34

and it gets gets the point

34:36

where it's trivial. Now anything

34:38

new is going to be weird and

34:40

difficult at first, but once you

34:42

get used to it, it's it's

34:45

really trivial to get to the

34:47

point to where like, oh, you want me

34:49

to add a spine to 100 leaves, I can

34:51

do it in two minutes. The

34:53

deployment process would take five. And

34:55

I'm going to get it right. So,

34:58

and this is my opportunity to

35:00

ask all my dumb questions,

35:02

Tony. So thank you. Go

35:04

ahead. Help me understand Ginger

35:06

versus Yammel and how they

35:08

relate. So Yammel, traditionally in

35:10

the network automation world, Yammel

35:13

is a way that we

35:15

use to describe desired state

35:17

in an abstracted fashion. Okay.

35:20

So when I say abstracted fashion,

35:22

I mean like, okay. You know,

35:24

take a like a Cisco config

35:26

on an interface interface E1 IP

35:28

adder 101 101 slash 24, no

35:31

switch port, you know, that's

35:33

the syntax. That's non abstract.

35:35

That's actually what we put

35:38

on the device. An abstract

35:40

representation of this is Ethernet

35:42

one can be an L3

35:44

port. It's going to have an

35:46

IP address of 101, 101 slash

35:48

24. And we can, we can describe

35:51

that in YML. relatively

35:53

easily. And yamel is great because

35:55

it's easy for machines to read

35:57

and it's relatively easy for humans.

35:59

to read and write. Now,

36:01

it gets a little tricky

36:04

when you start out, you

36:06

have to figure about the

36:08

white spaces and the indentation,

36:10

there's always, you know, indentation

36:12

caught me a lot when

36:14

I started out, but, you

36:16

know, now it's second nature

36:18

to me. So that's what

36:20

the YAMEL does. YAMEL is,

36:23

that's the information, you know,

36:25

think about like any kind

36:27

of template. Okay,

36:29

and then so the template

36:31

is, the yamel file is,

36:33

you know, Joe went to

36:35

the, and then the variable

36:38

is a noun or a

36:40

verb or whatever. Right, the

36:42

yamel is the noun on

36:44

the verb, that's where we

36:46

get that from, the template

36:49

is the madlib book itself.

36:51

Okay, so, and ginger is

36:53

the template. and then place

36:55

all the variables where they

36:57

need to go. So the

36:59

ginger template calls the particular

37:02

variables. Like is there a

37:04

dictionary called V-lands? So a

37:06

dictionary is just a key

37:08

value pair. So V-lands, colon

37:10

in the amel. And then

37:13

under that is a list

37:15

of V-lands, 10, 20, 30,

37:17

40, 50. Maybe it's got

37:19

a list with parameters like

37:21

V-land 10 and it's S-V-I-P

37:24

addresses, 10-1. So, yamel

37:26

takes the logic, is there a V-lands

37:28

dictionary? Okay, let's iterate through it, we'll

37:30

loop through it until we're done with

37:32

the list. And we'll generate configs for

37:35

syntax that will configure those V-lands and

37:37

the V-lands and the V-lands in the

37:39

V-land database, then configure the interface V-v-lands

37:42

for the SBI's, and, you know, we'll

37:44

do that for the entire config. So

37:46

there's work I need to do sort

37:48

of ahead of time before I just

37:51

start running into this kind of network

37:53

automation. Yeah, absolutely. Now, so here's the

37:55

interesting part about network automation is we

37:57

have to keep this in mind. We

38:00

do a lot more work. on the

38:02

front end. So our day zero is

38:04

a lot busier than day one. Now

38:06

traditionally when we do deployments, our day

38:09

zero is relatively light. We're doing some

38:11

spreadsheets, we're doing some bizio diagrams, we're

38:13

collecting some requirements, but all of our

38:16

work is done in day one. That's

38:18

when we're standing up the configs, getting

38:20

the configs on them, doing the testing,

38:22

the acceptance testing, etc. Would we do

38:25

network automation? We swap that. We swap

38:27

that. Figuring out the schema for our

38:29

yamel if we're if we're doing that

38:31

or figuring out whose schema we're going

38:34

to use instead like ERISA ABD. Then

38:36

we get it to the point where

38:38

we're building configs and then days day

38:40

one instead of taking a week to

38:43

stand up a fabric it takes an

38:45

afternoon. And then we can also do

38:47

the testing on it too. So we're

38:49

right now we're just talking about the

38:52

configuration generation. One of the points I

38:54

want to get to in this conversation

38:56

Tony is how to discern whether I

38:59

would benefit from having a pipeline or

39:01

not. So if I'm maybe I'm doing

39:03

a lot of things that you described

39:05

where there's even testing involved and so

39:08

on and I've been doing it by

39:10

hand and it's been okay. How do

39:12

I know? We should really as an

39:14

org make the leap and begin using

39:17

a pipeline for our network automation for

39:19

our network automation. Well, one of the

39:21

things we can think of is we've

39:23

already got a pipeline is the steps

39:26

that we're doing. The question is do

39:28

we want to automate that pipeline? Do

39:30

we want to have something shepherd the

39:33

process through? I would say for 95%

39:35

of the organizations out there, we don't

39:37

need CICD. We don't need to automate

39:39

this whole pipeline. Well, why not? Why

39:42

wouldn't I want to? Because it wouldn't

39:44

bring the benefit. The reason why we're

39:46

generating configs is that it makes, one,

39:48

it makes the configs accurate. So the

39:51

chances of me getting a configuration that

39:53

is going to work and work the

39:55

way I intended is way higher than

39:57

if I did it manually. I can

40:00

do it more often. I can make

40:02

changes more rapidly. I can make really

40:04

complex changes. very quickly. And that's because

40:06

we've described our desired state via YAML

40:09

files and then are using those to

40:11

generate them based out of templates from

40:13

Genja. Exactly. Okay. So that's a huge

40:16

benefit right there. And this is not

40:18

something that like, this is not a

40:20

marketing benefit, this is how a lot

40:22

of companies are doing their configuration states.

40:25

Whenever I do deployments, this is how

40:27

I do it. And I do not

40:29

want to go back to doing things

40:31

manually. This is so much better to

40:34

generate these configures. So one if we

40:36

if we're generating our configs versus typing

40:38

them out by hand that's a huge

40:40

benefit we're going to get more accurate

40:43

we're getting more rapid we can deal

40:45

with more complexity we can make these

40:47

changes more rapidly we're going to get

40:50

trusted we're going to get trusted with

40:52

multi vendor better Tony absolutely so I

40:54

can I can have a yamel file

40:56

that has my desired configuration state and

40:59

then I can have a template that

41:01

builds me eristic fix So it's good,

41:03

you know, that again, it's going to

41:05

be a lot of work up front

41:08

that I don't want to, I don't

41:10

want to make it sound like that

41:12

this is just easy, easy. You just

41:14

do a couple of things in like

41:17

a couple hours, you're going to work

41:19

on this tooling to do this. But

41:21

the once you get it, once you

41:23

get it implemented, it's going to save

41:26

you so much time and it's going

41:28

to be so much more accurate. So

41:30

generate the config is number one. It's

41:33

like my biggest pet peeve right now

41:35

is pacing and config through a terminal

41:37

window. No more of this. It's 2025.

41:39

We don't need to be pacing configs

41:42

through terminal windows anymore. Most of the

41:44

vendors have reliable ways to deploy through

41:46

automation. So that's number two. And number

41:48

three, this is relatively new in our

41:51

world, is we've got all these testing

41:53

suites now that we can use to

41:55

test our deployments. So we can do

41:57

unit tests after we make a deployment.

42:00

And I think this is probably one

42:02

of the most un- appreciated aspects of

42:04

network automation. So I've just made a

42:07

change to 100 devices. How do I

42:09

know that 100 devices have been, have

42:11

their, you know, the things worked as

42:13

I expected them to? Well, you know,

42:16

in the old days, you and I,

42:18

we would go into a device and

42:20

we'd run a couple of commands. We'd

42:22

go into like five of those hundred

42:25

devices, some spot checks, you know, that's

42:27

not really accurate. you know that's not

42:29

really comprehensive spot checks because ain't got

42:31

time for all of them yeah nobody

42:34

got time we miss something get to

42:36

run like 20 show commands on a

42:38

hundred devices but automation can can run

42:40

20 show commands on a hundred devices

42:43

and provide me a little report and

42:45

there's there I don't have to do

42:47

it I don't have to do it

42:50

create all this stuff manually myself there's

42:52

a bunch of frameworks that allowed me

42:54

to do this relatively quickly there's like

42:56

pie ATS there's Arista Anta There's all

42:59

these different frameworks that we can build

43:01

that we can build upon so that

43:03

we can run these automated checks after

43:05

we do deployment and if we do

43:08

a deployment and our checks run and

43:10

we still have a problem guess what

43:12

we run a new test just like

43:14

we do it in the developer world.

43:17

So three things if you do you're

43:19

going to get 95% of the benefits

43:21

for most organizations of network automation and

43:24

it's not a CACD pipeline. Number one,

43:26

generate configs. Number two, deploy configs through

43:28

automation. Number three, test the configs through

43:30

automation after they're deployed. You're going to

43:33

get so much further than if you

43:35

were doing things manually. Now, as icing

43:37

on the cake, as gravy in the

43:39

gravy boat, we could stitch it all

43:42

together with get up actions, Jenkins, or

43:44

whatever. But, you know, if you've got

43:46

a three-person team, probably there's not really

43:48

need benefit for that. It really comes

43:51

into a place when you've got, when

43:53

you're making lots and lots and lots

43:55

of changes. Like if we're making one

43:58

change a week, probably don't need to

44:00

go too much far into like get

44:02

up actions. You know it might if

44:04

you have a particular pain point like

44:07

wouldn't be nice if like I did

44:09

my linting as soon as I did

44:11

my commit. Okay we you know you

44:13

can do that part there. But if

44:16

you're you know smaller teams, less frequent

44:18

deployments probably CICD is not where you

44:20

need to be. But you probably should

44:22

be at the network animation where we're

44:25

generating configs. We're deploying convicts through automation

44:27

and we're testing the deployment through automation.

44:29

Those three things. So it's it's so

44:31

the deciding point, the tipping point for

44:34

whether or not a CICD pipeline makes

44:36

sense for our network automation practice sounds

44:38

like scale. If I'm doing lots of

44:41

changes, maybe I want to go that

44:43

route. Yeah, and most of the most

44:45

of the organizations that I've worked for

44:47

worked with probably don't have the scale

44:50

where that starts to really make sense.

44:52

So it said, you know, not to

44:54

say you can't do it. But, you

44:56

know, the whole purpose of this, of

44:59

this, the idea for this podcast was

45:01

there's a lot of people I'm getting

45:03

like, do I need to do CICD?

45:05

Do I need to do CICD? Do

45:08

I need to do CICD? And the

45:10

answer is probably not, but you should

45:12

probably be doing network automation network automation.

45:15

And almost every medium to large size

45:17

company I've worked with could definitely benefit

45:19

from that process. an onboarding of those

45:21

skills of the skill sets and tools

45:24

and learning the tools like, you know,

45:26

most network engineers don't train on get,

45:28

they don't train on answerable, they don't

45:30

train on APIs. There's going to be

45:33

a transition period where you're onboarding those

45:35

tools, but again, the payoff is so

45:37

much, like I can't imagine myself managing

45:39

a network, a medium to large size

45:42

network, even some small networks manually anymore.

45:44

It would just be, it would just

45:46

drive you nuts. Well, okay, I hear

45:48

the gospel you're preaching. Let's do the

45:51

network automation and you've defined those steps.

45:53

CICD, you defined it as, you know,

45:55

the gravy and the gravy boat. on

45:58

the cake. It's extra, not nice to

46:00

have, not need to have. All right,

46:02

but dude, you got a bunch of

46:04

nerds out there listening that want to

46:07

do the cool things. So the question

46:09

then becomes. If I feel ready to

46:11

do a C.I.C.D. pipeline, other than say

46:13

technical debt, is there more risk that

46:16

I'm adding, more needless complication that it's

46:18

going to be too hard? And I

46:20

really shouldn't bother. Or if I'm feeling

46:22

up for it, can I go that

46:25

route and have it be a good

46:27

thing? Yeah, you know, if you're feeling

46:29

up for it, then yeah, go for

46:32

it. I'm not saying don't do C.

46:34

Don't do C. by not doing CICD

46:36

and like any tool, you know, we

46:38

as nerds, we have to like, we

46:41

have to resist the impulse to try

46:43

to push through a bad tool because

46:45

we think it's cool and it's like

46:47

shiny and it's new and it's like,

46:50

oh, it's really cool, but yeah, it's

46:52

really a pain to use and it's

46:54

impeding us, you know, we want network

46:56

automation to, to accelerate us, not to

46:59

impede us. So that would be the

47:01

only like caution I would like give

47:03

you like and then also you can

47:05

do it in little steps like I

47:08

said like one of the first things

47:10

you can do if you want to

47:12

start putting your pipeline in or putting

47:15

the automation for the pipeline in is

47:17

when I make a commit so instead

47:19

of editing yamel and just the directory

47:21

on my automation controller then I put

47:24

it in get hub and then when

47:26

I make a commit then it runs

47:28

the linting on it that's the spell

47:30

checker for yamel. So maybe I automate

47:33

that process. And then I automate the

47:35

building of the config. So once I'm

47:37

doing a commit, it links it, if

47:39

the lens passes, then it builds all

47:42

the syntax for me. Nice and shiny,

47:44

ready to hit that big red button

47:46

for deploy. So I can do this

47:49

in little steps, versus I don't need

47:51

to just implement it all or nothing.

47:53

And again, it's a tool. If it

47:55

helps you, use it. If it doesn't

47:58

help you, don't use it. I

48:00

think a good closing question would

48:02

be this Tony. Okay, I know

48:05

I don't need CICD pipelines as

48:07

like a primary feature I gotta

48:09

have for my network automation practice.

48:11

And in fact, we could say,

48:13

here are tools that you should

48:15

be using skills that you should

48:17

have before you want to add

48:19

CICD to that mix. And those

48:21

skills we need to have, I'm

48:24

gonna throw some things at you,

48:26

you can correct me, add, subtract,

48:28

whatever you think, Tony, but I

48:30

would imagine Python. Python. Ansible, ginger,

48:32

repositories, get get hub, something along

48:34

those lines where you're doing your

48:36

version control and so on, being

48:38

the biggest ones that are leaping

48:41

to mind, automated testing somewhere in

48:43

there, unless clear on exactly how

48:45

we might implement that, but that's

48:47

another piece. And then if we

48:49

had all that stuff lined up

48:51

and really comfortable with all those

48:53

things, then maybe we would add

48:55

that, that next tool in the

48:57

list might be a pipeline. How

49:00

am I doing? Yeah, yeah, that's,

49:02

that's, that's a really good way

49:04

of putting it. Like you, you,

49:06

you don't need and you probably

49:08

don't want to do a CICD

49:10

pipeline all at once. There's steps

49:12

to get to, like, do you

49:14

have, are you generating configs? Are

49:17

you deploying, are you testing after

49:19

you deploy? If you're not doing

49:21

those three things going. Then you

49:23

can do a CIC and then

49:25

there's other things we can add

49:27

in that pipeline read in the

49:29

steps. One of the things that

49:31

I that I think that we

49:33

really need to work on as

49:36

a network industry is doing the

49:38

pre deployment testing. So we've actually

49:40

got post deployment testing done pretty

49:42

well. I can run I can

49:44

automate running like 50 show commands

49:46

on every device after I do

49:48

deployment and that'll give me a

49:50

good indication. And that'll give me

49:53

a good indication. But now I've

49:55

got all the syntax. How do

49:57

I know that the syntax isn't

49:59

going to cause any... problems when

50:01

it gets loaded on these hundred

50:03

devices. And there's kind of been

50:05

some tools like Batfish, but we

50:07

really don't have a comprehensive pre-deployment

50:09

testing yet. So, you know, that's

50:12

something we need to work on

50:14

as an industry. We just don't

50:16

have the tools for it yet.

50:18

But the three other three tools

50:20

we do, we absolutely do and

50:22

they're mature by now. So configuration

50:24

generation generation generation testing. So if

50:26

we look at those three steps,

50:29

generate config, deploy, config, check, and

50:31

figs after deployment for generate config,

50:33

the tools I'm looking at are

50:35

yammel and ginger. Yeah, yamel and

50:37

ginger, generally speaking, but like, for

50:39

example, if you do a wrist

50:41

to a VD, then it's going

50:43

to be just yamel. You don't

50:45

have to worry about the ginger

50:48

because wrist is already taking care

50:50

of it. But generally speaking, yes,

50:52

if you can, and it doesn't

50:54

take. a ton of work to

50:56

learn ginger. It's a very simple,

50:58

I mean, I'm gonna say relatively

51:00

simple, because if you look at

51:02

it for the first time, you're

51:05

gonna be like, this is Greek

51:07

to me, unless you speak Greek,

51:09

but it looks like some other

51:11

language you've never looked at before.

51:13

So yeah, it's gonna be a

51:15

learning process. And the thing is,

51:17

like, it's so much better doing

51:19

it this way. There's so much

51:21

more stability, there's so much more

51:24

rest and ease and comfort in

51:26

your life when you do it

51:28

this way. And just sorry to

51:30

go through those three steps. So

51:32

generate config, we're talking about yammel

51:34

and ginger, deploy and config, is

51:36

that ancible? Ancible or Python. And

51:38

then for the checking phase after

51:41

the deployment that you mentioned, pie

51:43

ATS? Yeah, pie ATS or ANTA.

51:45

So it's mostly Python. Okay. So

51:47

learn yamel, I think that's one

51:49

of the most important things. Yeah.

51:51

It's, you know, it's hard to

51:53

say that you're going to always

51:55

run into these things. But you're

51:57

generally going to run into Ansible,

52:00

you're generally going to run into

52:02

YAMel, you're generally going to run

52:04

into Python. You don't need to

52:06

be a Python programmer where you're

52:08

like remaking Zelda in Python. But

52:10

for the networking world, we use

52:12

like 20% of Python. So, yeah.

52:14

And then there's plenty of resources

52:17

to learn Python like Kirk Byers

52:19

has that, like four times a

52:21

year, he runs a free course,

52:23

and there's plenty of content out

52:25

there now to learn. Yammels, a

52:27

file syntax. It's not like, you

52:29

know, he's a 900 page book

52:31

to figure out Yamel, it's just

52:33

like understanding the formatting. Yeah, it's

52:36

mostly like figure out the indentation

52:38

and then, um, linting helps. So

52:40

like if you, like if you

52:42

run VS code. So VS code

52:44

is a common editor that we

52:46

use to edit these yamel files,

52:48

Python files, etc. It's a free,

52:50

it's free for Microsoft. And then

52:53

it's got to, you can run

52:55

a linter on it so that

52:57

it does a little red squiggly

52:59

line if you get the, if

53:01

you get the, like, the formatting

53:03

wrong. It's like a spell check.

53:05

Tony, if people want to dig

53:07

into this topic more, did there,

53:09

there's some top of mind resources

53:12

that you would point them to?

53:14

For me is YouTube. I learn

53:16

almost everything through YouTube these days.

53:18

There is a wonderful answerable course,

53:20

free course, by this guy named

53:22

Jeff, by this guy, by the

53:24

name of Jeff Gierling. And there's

53:26

a couple others out there, but

53:29

I think his is the best

53:31

I've seen. It's not network oriented,

53:33

but he teaches you the parts

53:35

that you need for the networking

53:37

part. It's a free course on

53:39

YouTube. And this guy, he did

53:41

it during lockdown in 2020. And

53:43

he's like, you know what, I'm

53:46

just going to do a free

53:48

course. He's got a book you

53:50

can, you can buy or I

53:52

think, I think it's still available

53:54

for free. If not, it's not

53:56

that much money. Kirk Byers for,

53:58

for Python, another Python resource I

54:00

like is called Learn Python the

54:02

Hard Way by Zed Shaw. And

54:05

it's basically like, okay, what's a.

54:07

I've worked through some of that.

54:09

It's been a while, but I've

54:11

worked through some of the Python,

54:13

the highway, it is a great

54:15

resource. Yeah, it's just, it's like,

54:17

it's a stupidly simple way to

54:19

learn Python, because it's like, here's

54:22

a loop, here's how we do

54:24

a loop, here's a four loop,

54:26

here's a while loop, and it

54:28

just shows you examples of everything,

54:30

and you go through it, and

54:32

it's just the one thing, without

54:34

trying to get all fancy. These

54:36

like these one stupid things and

54:38

I think this way calls it

54:41

the hard way because there's like

54:43

25 lessons But each lesson concentrates

54:45

on just one little thing and

54:47

that's I love that way of

54:49

learning Well Tony thanks again for

54:51

joining us today and for dude

54:53

that was an extraordinary braindup that

54:55

was really great but also you

54:58

kept reiterating certain points so it's

55:00

like we didn't just keep going

55:02

off into the sunset we kept

55:04

bringing home the the main points

55:06

thank you for that approach we

55:08

can tell you're an instructor that's

55:10

definitely a teaching technique so that

55:12

was great Tony yeah if I

55:14

want to leave the audience with

55:17

any thought it's this automation is

55:19

hard and then it's easy And

55:21

just like anything else, you have

55:23

to learn it, you have to

55:25

struggle with it at the beginning,

55:27

but once you learn it, oh

55:29

my gosh, like it's the automation

55:31

hump, like on one side of

55:34

this big hill is all the

55:36

stuff you don't know and it

55:38

looks really hard and intimidating. And

55:40

then you have to go over

55:42

that hill, that's all the learning

55:44

and the struggling and the frustrations

55:46

and the indentations. And then on

55:48

the other side of it, you're

55:50

like, I don't know how I

55:53

would be doing this any other

55:55

way. If people want to reach

55:57

out to you Tony, can they

55:59

find you online? Yeah, I'm on

56:01

Blue Sky, Tony dot Burke, on

56:03

Blue Sky, and my infrequently blog

56:05

at data center overlords.com, and then

56:07

I'm on YouTube, just Tony Burke

56:10

on YouTube. Sounds great. Thank you

56:12

again for joining us today, Tony,

56:14

much appreciated. And all of you

56:16

out there listening, thank you for

56:18

listening to Heavy Networking. If you're

56:20

really interested in network automation, this

56:22

is a great episode to get

56:24

your. what your appetite gets you

56:26

started. And as Tony pointed out,

56:29

there is a ton of content

56:31

in the world to help you

56:33

learn about it. I'm going to

56:35

mention a couple of more resources

56:37

beyond what Tony mentioned, the network

56:39

automation nerds podcast, which is part

56:41

of the packet pushers network that

56:43

is hosted by Eric Cho. He

56:46

is the host of mastering Python

56:48

networking. That's a book he's done.

56:50

I think there's at least three

56:52

editions out there's out there's also.

56:54

network automation forum channel up on

56:56

YouTube there. And of course, there's

56:58

slack groups, including the. packet pushers

57:00

community a slack group and the

57:02

network automation forum slack as I

57:05

mentioned there are even more if

57:07

you poke around those just happen

57:09

to be the ones I'm paying

57:11

attention to these days where I'm

57:13

typically logged in you can find

57:15

lots of other resources for networkers

57:17

in general that's all at packet

57:19

pushers.net everything you find at packet

57:22

pushers.net everything you find at packet

57:24

pushers.net is 100% free there's no

57:26

logins we're not tracking you and

57:28

everything that is podcast or videos.

57:30

I have been Ethan Banks along

57:32

with Drew Conroy Murray and until

57:34

next week, just remember that too

57:36

much networking would never be enough.