Keith Townsend, Principal, CTO Advisor

Implementing Network as Code, Part 2 of 3

Network AutomationData Center
Keith Townsend Headshot
Screenshot of host, Keith Townsend, Principal, CTO Advisor, speaking into a microphone, and guest, Ned Bellavance, with a microphone in front of him

How to get started with network as code

Now that you’ve been introduced to network as code in part one of this series, it’s time to understand how to implement it for your own network. Watch for tips and best practices to start off on the right foot.

Show more

You’ll learn

  • Available network automation tools and technologies needed for implementation

  • Best practices for implementing network as code

Who is this for?

Network Professionals Business Leaders


Keith Townsend Headshot
Keith Townsend
Principal, CTO Advisor

Guest speakers

Ned Bellavance Headshot
Ned Bellavance
Founder, Ned in the Cloud



0:02 foreign

0:08 thanks for joining us in our second

0:11 video in a three-part series sponsored

0:14 by Juniper where we're talking about

0:17 network is code we're going to go into a

0:19 little bit more detail on implementing

0:22 Network as code we're going to cover

0:23 three topics tools and Technologies so

0:26 what's out there infrastructure is code

0:28 we're going to re uh address this topic

0:33 a little bit more detail that we did in

0:35 video one and then configuration

0:37 management web network is called this is

0:39 I think one of the best benefits of the

0:43 solution I have with me Ned bellavist uh

0:48 Ned in the cloud

0:49 are you still doing your terraform

0:51 Tuesdays I am I am thanks for asking

0:54 yeah every uh three Tuesdays a month I

0:58 do terraform Tuesdays on my YouTube

1:00 channel where I tackle the different

1:01 terraform related topic some of them are

1:04 very fundamental topics if you're just

1:07 getting started in terraform and some

1:08 cover more advanced things uh for those

1:11 who have been practicing for a while

1:13 so now let's talk about some of the

1:16 tools and Technologies as it relates to

1:18 network as code in the first video we

1:20 know we kind of separated the concept of

1:22 devops and tools we use tools to


1:25 implement devops types of

1:29 uh of management style or operations

1:34 let's talk about kind of the Frameworks

1:37 around Network automation

1:40 sure I mean there's certainly the vendor

1:42 specific Network automation Frameworks

1:44 uh and each vendor is going to do it

1:47 differently and those tend to be

1:48 somewhat specific to just their products

1:51 but there's also more general purpose

1:53 ones for instance a lot of folks like to

1:56 do their automation using ansible

1:58 because ansible doesn't require the

2:01 installation of an agent so you can

2:03 reach out to your networking gear as

2:06 opposed to communicating with an agent

2:08 that is already running on that Network

2:10 gear uh another popular

2:13 I won't say framework but a popular

2:15 language is python a lot of folks in the

2:17 networking Community have really latched

2:19 onto Python and I think that's in large

2:21 part because it's relatively easy to get

2:24 started with and it also has a scripting

2:26 feel as opposed to some other languages

2:29 that are more just difficult to pick up

2:32 and use right away so that's another

2:34 popular uh framework or programming

2:37 language for performing Network

2:39 Automation and then you have things like

2:42 nor near and there's a few other

2:44 Frameworks out there that can help you

2:46 with that process as well so those would

2:48 be all the sort of languages and and

2:51 Frameworks but then there's also

2:52 ancillary things that will help you with

2:55 your network automation like where are

2:58 you going to Source uh the code how are

3:00 you going to automate that code do you

3:02 have an automation pipeline that you're

3:04 plugging it into to do your CI and CD

3:07 and then what are you using from a

3:09 monitoring perspective to validate the

3:12 changes and and make sure that your

3:14 network is healthy so it all forms one

3:17 kind of large construct it's not just

3:19 one tool that's going to do the entire

3:21 thing it tends to be a collection of

3:24 tools and products and solutions

3:26 and the there's a bunch of Open Source

3:29 tools and I think it's really important

3:32 to understand the difference between

3:35 a tool and a framework

3:39 a framework can be independent of a tool

3:42 and a tool can be independent of a

3:43 framework but I think it's been pretty

3:46 consistent if you adopt a at this kind

3:50 of early stage of infrastructure code

3:52 Network as a code if you're adopting a

3:54 specific tool

3:56 from my experience you're adopting that

3:59 framework that that the tool was built

4:01 to support is that a fair assessment

4:04 I think each tool is going to have its

4:08 preferred workflow and its preferred way

4:10 for in with for interacting with the

4:13 existing Network and when you think

4:15 about actually starting to use Network

4:18 automation it's not likely that you're

4:20 moving to a green field environment

4:22 where you don't have any network devices

4:24 to start with so the first portion of it

4:27 is how do you bring your existing real

4:29 estate under management and each

4:31 framework is going to have its own way

4:32 of doing that some are going to be

4:34 slightly more painful to do than others

4:37 and then once you actually do bring it

4:39 into the network automation framework

4:41 what's the preferred workflow for

4:44 pushing changes to the environment

4:46 what's the way that you go about testing

4:49 those changes and what's the process for

4:51 rolling back if a change goes wrong each

4:54 one is going to have a slightly

4:55 different process for doing that and I

4:57 think the Frameworks can be pretty

4:59 opinionated in terms of how that's done

5:02 so this goes into some key principles


5:05 around infrastructure's code in general

5:08 I think the promise the ultimate promise

5:12 of any infrastructure is code project is

5:16 that it abstracts the infrastructure

5:19 from the intent the design intent like

5:23 there's what I want to do and then

5:26 there's what I'm doing it on so whether

5:28 it's Amazon AWS Google Cloud Azure

5:34 on-premises a specific Network vendor

5:38 there's the intention and then there's

5:43 the

5:45 configuration of the intention and I

5:48 think a great tool I don't know if we're

5:51 there a great tool will allow me to

5:54 uh apply that intention no matter what

5:58 infrastructure I'm pointing to

6:01 I think there's a spectrum because

6:03 that's a very interesting point you're

6:04 pulling out is I know what I want mm-hmm

6:09 but each Cloud vendor each Network

6:11 vendor is going to implement that

6:13 feature a little bit differently

6:15 and so different infrastructure is code

6:18 tool sets approach this at varying

6:21 levels of abstraction so you could have

6:23 one infrastructure as code tool that

6:25 works across all the different vendors

6:26 but it doesn't try to abstract away the

6:30 underlying components of that particular

6:32 vendor it's saying yes I can configure a

6:35 VPC in AWS I can set up your VMware

6:39 Networking but the way that I do it is

6:41 I'm going to expose those Primitives to

6:43 you you tell me how they should be

6:45 configured and I just make it go happen

6:46 for you so you declare what you want

6:49 I'll go do the hard work but I'm not

6:51 abstracting away the underlying core

6:55 pieces of that technology

6:57 but there's other infrastructures code

6:59 tools that take the approach of we have

7:01 a layer of common functionality across

7:04 all these different platforms

7:06 so what I'm going to expose to you is

7:08 that commonality of features you

7:11 describe where you want it deployed and

7:14 what you want deployed and I will

7:16 interpret that

7:18 through that abstraction layer into how

7:20 it's actually implemented on the

7:22 platform that you're pointing me at

7:24 that can be very difficult to do and you

7:26 do lose a certain level of

7:28 specialization that exists on those

7:30 different platforms if that

7:32 specialization is important to you then

7:34 you're going to go with a tool that

7:35 doesn't hide the abstractions but if

7:37 you're like a server as a server as a

7:39 server I don't care about the underlying

7:42 Specialties that each cloud or platform

7:45 brings to me then you can go with one

7:47 that does abstract those things and it's

7:50 not uncommon for like a platform

7:52 engineering team in an organization

7:54 to work with the tool that has no

7:57 abstractions that is just working down

8:00 in in the deeps but then what they

8:02 present up through like an internal

8:03 developer portal to the application

8:06 teams is something that is highly

8:08 abstracted because the application teams

8:10 don't care and they don't want to know

8:12 exactly how it's implemented in each

8:14 platform so the platform team absolutely


8:17 cares and I think we can give two

8:20 different examples we want one from the

8:22 server world and another one from the

8:25 networking world

8:27 in the server World whether we're

8:30 dealing with AMD Xeon arm Nitro

8:34 Etc we want the benefits of accelerators

8:37 of low efficiency

8:40 Etc we don't want to deal with the

8:42 details of how that's achieved the cloud

8:44 providers hide that from us but we do

8:48 have to have the minimum select the

8:50 right instance type so while the

8:53 developer might just want t-shirt sizes

8:55 the platform team specifically knows hey

9:00 I want Xeon Amex uh uh acceleration for

9:04 AI because that's the type of workload

9:07 that we do and these are the types of

9:09 instances in AWS that supports that that

9:12 detail the developer doesn't need to

9:15 know the platform team absolutely needs

9:17 to know and they need to work with the

9:18 infrastructure as cold platform that

9:21 delivers that level of granularity now

9:25 even getting more granule than that is

9:26 networking if I'm configuring a vxlan

9:31 underlay or overlay

9:33 and I want to configure the physical

9:34 Network the number of overlays a

9:39 platform on a switch

9:41 supports matters or may matter right if

9:45 I can only support 500 overlays and I'm

9:48 building thousands I'm a multi-tenant

9:51 organization and I'm building thousands

9:53 of overlays

9:54 I want that capability exposed I want to

9:59 know if I can do packet level inspection

10:04 etc

10:05 etc whatever feature switch levels

10:07 featuring we it can even be a switch

10:09 within the same uh family of switches

10:12 they they're going to have different

10:13 features and it matters when we're

10:16 talking about the underlay

10:18 right and that's why you have things

10:20 like uh you know platform as a service

10:22 where someone has basically built a

10:25 solution that gives you the developer or

10:28 the consumer the T-shirt sizes it gives

10:31 you the silver uh bronze and gold

10:34 classes of performance or whatever and

10:37 underneath they're concerning themselves

10:39 with the actual hardware and software

10:42 that's running directly on those systems

10:44 and just giving you a template that you

10:46 can consume to get the service that you

10:49 want so you know whether you buy that

10:52 platform from a vendor or you're just

10:54 renting it through a subscription I

10:56 think it's fairly common for us to Now

10:59 consume things in an abstract way and

11:01 rely on a platform team or a third-party

11:06 vendor to give us that that shim that

11:08 abstraction that's between the physical

11:11 hardware and low level operating system

11:13 and how we actually want to consume it

Configuration Management

11:17 so let's talk about configuration

11:20 management let's give something we

11:22 talked about and kind of you know the

11:23 the application developer the platform

11:25 team but as we know operations is what

11:28 keeps the world moving like they're not

11:32 and one of the most frustrating aspects

11:36 of managing a large Network or even a

11:40 small network is configuration

11:42 management we have plenty of tools on

11:45 the

11:47 I think storage and and server side and

11:51 even vmsi to manage configuration but

11:54 the network side has been kind of

11:56 relaxed because we have these different

11:57 you know we can have a hundred different

12:01 switches and network devices with

12:03 slightly different configurations and

12:06 understanding that there's not like a

12:07 really gold image that stays in every

12:10 single server and we're doing diff

12:13 between that gold image they're kind of

12:15 it's like wrangling cats

12:18 can be yeah that's certainly the case

12:20 someone could go oh there's a problem so

12:23 I'm going to go troubleshoot that

12:24 problem on the network and so I'm going

12:25 to log into these two switches and add

12:27 some additional monitoring don't worry

12:28 I'll remember to turn it off later

12:30 oh yeah the the wireless switch CPU

12:33 running so high oh I turned on

12:36 monitoring two months ago and I forgot

12:37 to turn it off exactly right so the the

12:40 idea behind configuration management is

12:42 being able to declare

12:45 how you would want ideally a particular

12:47 device or set of devices to be

12:50 configured and then it's up to the

12:52 software to do the imperative portion

12:55 which is actually go out and make it so

12:57 and usually that imperative portion has

13:00 three different functions in it get set

13:03 and test and I've had to write these

13:05 tests myself or get write these

13:07 functions myself in different cases the

13:09 test simply looks at what you've

13:11 declared and the actual state of that

13:13 device and goes do those two match yes

13:16 or no

13:17 the get is what allows it to actually go

13:20 out and get that information from the

13:22 device to run the test in the first

13:24 place and then the set is okay I've

13:27 determined that they're different and

13:28 now I want to take what's in the

13:30 configuration and push it to that device

13:33 and so that would be the set function so

13:35 that's basically what all these

13:36 configuration management tools do is you

13:39 define something declaratively they get

13:41 the config they test the config and then

13:43 if there's a difference they set the

13:45 config

13:46 so that sounds a lot like the CI CD

13:50 process over in the development side

13:51 like there's the existing code that's

13:55 running

13:56 there's the code that we want to deploy

13:59 and there's the detecting if there's a

14:02 Delta between it and then there's a

Advanced Concepts

14:04 bunch of other tests how should we think

14:07 about

14:08 kind of this Advanced topic of cicd when

14:11 it comes to network automation network

14:13 is code

14:15 I think there's a key difference between

14:17 the software development the application

14:19 deployment life cycle and the update and

14:22 management of network configuration and

14:24 probably the biggest thing is you can do

14:27 you can deploy multiple versions of your

14:29 application simult side by side and you

14:32 can do something like blue green testing

14:34 you can do something like canary

14:36 rollouts

14:38 so you can over time move to a new newer

14:41 version of the application while keeping

14:43 the previous version up and easily roll

14:45 back if something goes wrong and modern

14:47 tool sets like what we have in

14:49 kubernetes where you can do that sort of

14:51 phased rollout and roll back if you need

14:52 to make it really easy to do that with

14:55 applications

14:56 I highly doubt that most organizations

14:58 run two of every Network device so that

15:01 they can do this

15:02 so when you are talking about the

15:05 continuous integration continuous

15:07 delivery and deployment process of your

15:10 network configuration there needs to be

15:12 a ton of testing in that pipeline to

15:16 thoroughly vet the updated configuration

15:19 to

15:21 do a plan or some sort of dry run to

15:24 determine the actual changes that are

15:26 going to going to be applied and then do

15:29 some sort of as it rolls out testing to

15:31 verify that the network is functioning

15:33 properly as it rolls out and have a way

15:36 to roll back because this isn't like an

15:39 application where I can have two

15:40 versions run at the same time I've got

15:42 one version of my network and that's the

15:44 one that's carrying everything else

15:47 yeah the network is definitely a pet the

15:50 even if we we take borrow some of these

15:53 Concepts from the software development

15:55 world the network itself is a pet I have


15:59 one internet connection to a T I have

16:02 one internet connection to my business

16:05 partner even if I have multiple switches

16:08 there are many single points of failure

16:11 and quite frankly you know if I update

16:15 the version of OS on my switch and I

16:19 need to roll back

16:20 that switch is going to be down for the

16:22 time that I need to roll back so a lot

16:26 of this a lot of the cicd process we may

16:29 borrow from software development but the

16:32 way that we test it is very different

16:34 and some of the simplest things such as

16:37 validating the configuration change

16:40 makes sense like I can't tell you the

16:44 number of times that I went to make a

16:46 configuration change on a switch the

16:51 commands made sense in my mind I made

16:54 the change and they were accepted but

16:56 they broke the network we can't test for

16:59 every scenario yet but that basic check

17:03 needs to be part of our version of CI CD

17:06 in the network World absolutely

17:09 all right so that wraps up this uh

17:13 the video on the three-part series we

17:16 talked about tools and Technologies

17:17 infrastructure is code uh some basic

17:20 principles and we even gave our

17:23 operations folks some candy by talking

17:27 about configuration management slapping

17:29 the hand of those folks who try to make

17:32 changes directly remember use the

17:34 infrastructures code tool to make all

17:37 changes otherwise the next time you go

17:40 to deploy you're going someone's going

17:42 to come to you and say hey we saw you

17:45 logged into the switch left we tried to

17:47 deploy and there was a different

17:49 different configuration the tools that

17:52 you select should be able to do all of

17:53 that or you have processes to do that

17:55 stuff

17:56 in the next video we're going to talk

17:58 about we're going to talk about Advanced

18:00 topics and network as code Network

18:02 testing and validation so we're going to

18:04 dive a little bit deeper into

18:07 configuration management CI CD network

18:09 monitoring and analytics and then

18:12 finally the most important topic

18:14 security and compliance I promise you

18:18 that section for those of you who've

18:20 ever had to answer audit requests you

18:23 want to see that module in the next

18:26 video talk to you soon

Show more