Pythonic Networks with NAPALM

00:00 When you think of networks, you probably think of physical things, routers, switches, firewalls,

00:04 and that kind of stuff. But increasingly, network engineers are managing massive networks that are

00:09 better managed via software than by admin applications. On this episode, you'll meet

00:14 David Barroso, who created Napalm, a vendor-neutral, cross-platform, open-source project that provides

00:20 a unified API to network devices. This is Talk Python to Me, episode 128, recorded July 17, 2017.

00:28 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the

00:47 ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter,

00:52 where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm,

00:57 and follow the show on Twitter via at talkpython. This episode is brought to you by Linode and

01:03 Rollbar. That's right. Welcome to Linode, who has joined Talk Python to Me as a major sponsor.

01:09 Be sure to check out what both of them are offering during their segments. It really helps support the

01:13 show. David, welcome to Talk Python. Thank you for having me here. It's been a long time coming that

01:19 we've talked about Python, all sorts of things, but no networking really, right? And so you're here to

01:24 help us fix that problem and talk about Python and network programming.

01:28 Yeah, here I am. Happy to follow.

01:30 Yeah, it's going to be great. So we're going to talk about your project, Napalm, and you're doing a bunch of

01:36 exciting stuff there. It seems like it's still going strong. It's been around for a few years. But before we get

01:40 into all that, let's start with your story. How did you get into programming, networking, Python, that sort of stuff?

01:46 Well, my background is network engineering, but I haven't always been a network engineer. I started like many, many years ago, more like systems engineer. So just dealing with Linux, Windows, Apache, Nginx, whatever. Then I was just doing, well, anything, Bash, Perl, Python, whatever you had to use to the job.

02:11 Then at some point, I had to move some data I had on a wiki page into something I could actually query. So I was just investigating what the best tool for that would be. And I came into some page that was actually talking about Django.

02:29 And I thought that was kind of like the perfect fit. And so I could actually say that Django was what really introduced me into Python and drove me to learn more about it. And then just like regular evolution, just career path, I just landed more into the networking side of things, which made me more focused on the network stuff, rather than on systems or actual Python or something.

02:55 But Python has been always there just trying to help me get the job done somehow.

03:00 I see. That's really cool. So you've done a lot of work with these systems engineering, with configuring services like Nginx and things like that. And just like Python has always played an important role in sort of making that work.

03:11 Yeah, I remember using CFEngine like more than a decade ago and doing a lot of Perl. Like back in the day, it was mostly Perl. But likely, it's not that much Perl nowadays. It's Python.

03:22 Yeah, I definitely think there's less Perl in the world than there used to be. That's good. And so what are you doing day to day? Like you're doing network stuff for your main job, right?

03:32 Yeah, so I'm a network systems engineer at Fastly. I spend most of my day both automating the network and building a control plane where we can actually integrate with the application.

03:46 So it's not the network is not only automated, but it's somehow directed by the application. The application can say like, oh, yeah, I want to send this packet via this path.

03:56 I want to send this other packet via this other path. So I'm working on these two areas.

04:01 Yeah, and that's pretty major stuff. I'm not sure everyone knows what Fastly is.

04:05 So maybe give them the quick elevator pitch.

04:07 Well, we are a CDN. The cool thing about Fastly is that we expose all of our services and configurations by an API.

04:16 So you can actually integrate with us. So it's not like the traditional CDN where you just send your objects and they catch them until you can send a new object and then they catch that as well.

04:30 So it's a matter of, yeah, I want to be able to respond in this way if the HTTP headers are like this. And you can actually do that in real time just by configuring it via the API.

04:44 That's kind of cool. You're a web developer. You should check it out.

04:47 Yeah, that sounds really cool. So you guys probably handle a little bit of network traffic, huh?

04:51 Yeah, yeah, yeah. We do a lot. Okay, I don't recall the numbers exactly, but I think it's about 5 million requests per second and a few terabits of bandwidth.

05:04 So yeah, it's quite a lot of traffic.

05:07 Yeah, that's crazy. You think about like a number of requests per second for like a RESTful API or something like that.

05:13 That might just be a couple of bytes response of JSON or something. But typically CDNs serve images and videos and files, right?

05:22 Like that's a crazy amount of traffic.

05:23 Yeah, we do all kind of traffic like video, music, images, JavaScript, even API. We have a few APIs behind us.

05:32 And that's because of the integration that I was mentioning before.

05:35 Yeah, yeah.

05:36 But yeah, that's not really my expertise.

05:37 No, no, but it's all built upon the network, which is super cool.

05:41 So traditionally people maybe configured networks by logging into like a Cisco router or switch or something like that.

05:51 And then, you know, maybe using the CLI there or using some tool.

05:56 But working with networks these days is becoming more and more a programming type of experience, right?

06:03 Yeah, I think that the network is following the same evolution that the system world experienced like 10, 15 years ago.

06:10 Like before you would just like edit your Apache.com from the virtual host files and all that kind of by hand and like CF engine came along, Puppet.

06:22 So the network is kind of now having that transition nowadays.

06:26 Like people was used to go through the console, SSH, or maybe some tools used to use SNMP to try to configure certain things.

06:36 But yeah, nowadays it's like tools like Puppet, Ansible, Solstack, Stagstock are starting to come to the network as well, which is interesting and cool.

06:47 Yeah.

06:47 Finally.

06:48 Yeah, that's great.

06:49 That sounds really exciting.

06:50 How's that affecting the whole ecosystem of network engineers?

06:55 Are people excited about this change?

06:57 Are they like, oh, my experience is no longer relevant.

07:01 It's not fun anymore.

07:02 Or like what's the general feel, do you think?

07:05 You will find both.

07:06 Like some people is like, oh, yeah, this sounds cool, a different way of doing things.

07:11 And I can just automate this and focus on more interesting stuff.

07:15 While other people is a bit more scared because, I don't know, maybe they are older engineers that they don't really have the time to pick up the new tools or the new programming languages.

07:25 So they might be a bit more averse to the change.

07:29 I think it's, yeah, you will find all sorts of people having all sorts of opinions.

07:35 Sure, of course.

07:37 So one of the terms that I hear frequently around the space is software-defined networks or SDNs.

07:43 What's the SDN?

07:44 That's mostly marketing.

07:46 Like vendors keep pitching SDN, but SDN doesn't really mean anything.

07:52 Like the original term was coined by some people at Stanford that were working with OpenFlow, which was like a super low-level API to try to program the switcher.

08:06 But that didn't translate well into hardware.

08:08 So it never took off.

08:11 OBS in the Linux stack uses OpenFlow, for example, for some things.

08:15 But that's software-based, which is fine because you don't have the hardware limitations to install all those flows.

08:21 But yeah, in the hardware world, like the real SDN never took off because of hardware limitation.

08:27 And now it's just used as a marketing term by, yeah, by many, many vendors.

08:33 Okay, of course we have software-defined networks now.

08:36 So there is this whole level of automation, though.

08:40 There is the ability to run scripts against like Cisco routers or various other types of routers.

08:47 And that's kind of where Napalm came in, right?

08:51 Previously, there was, for each vendor, each type of device you're going to work with, it was like a totally unique way of working with it, right?

08:58 Yeah, like each vendor has its own API.

09:01 Like if you go, you're logging into an iOS device by Cisco, for example, and you start typing commands.

09:08 The commands are going to be completely different from a Juniper device, for example.

09:12 And the CLIs, they're completely different.

09:16 They return different things to different commands.

09:19 They may have even different interfaces to actually connect to them programmatically.

09:25 Like, for example, iOS until very recently didn't have anything.

09:28 So you were using things like NetMiko, which is a Python library that works on top of Paramiko.

09:35 So it's basically just SSH expect-based, kind of.

09:39 Like Juniper used to have NetConf.

09:42 Well, it still has NetConf, which is actually a network protocol to configure devices.

09:48 And some other devices may have like a REST API.

09:51 Like there are just many ways.

09:52 So when you have to do something as simple as, I want to connect to my network and I want to retrieve the IP addresses that you have configured on the interface,

10:02 you have to start just like adding a lot of boilerplate.

10:05 Like, okay, if device equals to iOS, do this.

10:09 If device equals to this other vendor, just do this other thing.

10:14 So yeah, it used to be kind of a nightmare.

10:16 That's pretty much what I tried to solve with NAPALM.

10:22 Okay.

10:22 So NAPALM is an acronym, right?

10:24 What's it stand for?

10:25 Acronym is actually, it has actually an interesting story.

10:28 It was reversed, engineer.

10:29 Like I first came up with the acronym and then I tried to find some meaning to it.

10:35 Because, I mean, before it was all these if else statements that was mentioned, like if vendor this, if vendor that, right?

10:41 And I was writing sunscreen.

10:44 I was super pissed.

10:45 Like, I mean, this is just stupid.

10:46 This is just insane.

10:47 So, I mean, I want just to leave this on fire.

10:51 So the name came out of that and then I started just thinking, like, okay, now let's try to make some meaning out of it.

10:58 So, yeah.

11:00 So I came up with this network automation and programmability abstraction layer with multi-vendor support.

11:06 But, yeah, the name was actually reversed in here.

11:08 Yeah, that's pretty cool.

11:10 I mean, you have the important letters.

11:12 You got the N, the A, the P, and then you got to get creative about the ALM, right?

11:18 Yeah.

11:18 But, yeah, I wanted something with fire, basically, because that's actually my thing at the moment.

11:24 You're like, all right, we got to burn this down.

11:26 This is, like, messed up, right?

11:27 Yeah.

11:28 I've heard it.

11:28 Your co-creator of this library, was it, is her name Elsa?

11:32 I might be remembering.

11:33 Elisa Jasinska.

11:35 Elisa, Elisa.

11:36 That's right.

11:36 Yes.

11:37 You guys started this together, right?

11:39 Yeah.

11:39 So I started working on this when I was at Spotify.

11:43 And then I was just talking with her after a conference.

11:45 And she was like, oh, that's super cool.

11:47 I actually have exactly the same problem.

11:50 So then I just went back to my manager.

11:51 Like, okay, yeah, I've been talking with people.

11:53 And it turns out that there is some interest on collaborating on this.

11:57 So I just open sourced it.

11:58 And I started working with her.

12:00 And then other people came in.

12:03 And, yeah, now it's actually a pretty big community by now.

12:06 Yeah, it's going really strong now.

12:09 Yeah.

12:09 And I had heard there was even some places where people were using more or less like screen

12:15 scraping to get configuration out of some of these tools and some of these systems because

12:19 it was just so hard to do, right?

12:21 Yeah, there is a lot of screen scraping in devices like iOS, for example, from IA Bay Fisco.

12:26 Those devices traditionally didn't have any interface to interact with them.

12:32 So it was always like, yeah, SSH to the device.

12:35 And then just type this command.

12:37 Look for the prompt.

12:38 Now let's try to parse this thing.

12:40 And there is still a lot of that, to be honest.

12:43 Like, we do a lot of screen scraping with Napalm because, yeah, I mean, if they don't provide

12:47 the tools, we have to fix it ourselves.

12:49 But at least we fix it.

12:50 So when we are trying to solve the problem, like meaning what you are trying to solve at

12:56 your job, you don't have to care about parsing because we already fixed that problem.

13:01 Right.

13:01 So maybe something like that happens deep down when you call a function for a particular device,

13:06 but nobody knows and nobody cares.

13:09 I hope they care so they can act their vendors.

13:11 So the vendors return some JSON, XML, I don't care, just some structured data.

13:16 So a lot of what you guys do with Napalm is not write these vendor-specific communications

13:23 per se, right?

13:25 You might find libraries that are out there and just integrate them into Napalm, right?

13:29 Yeah.

13:29 What we try to do is just provide an abstraction layer, which means that if there is a library

13:34 already that can talk with the device, we will just use it.

13:38 Like, for example, for Juniper, they maintain a library to work with those devices.

13:44 So we just use that one.

13:46 That means that we only have to care about transforming data, for example, and providing

13:50 like common behaviors.

13:52 Like this method behaves in the same way, regardless if it's Juniper or Cisco.

13:57 And when you run this other method, the data that you return, it comes back normalized.

14:03 Right.

14:04 We don't really bother in dealing with the transport and connecting to the device.

14:08 Like someone else is caring about that.

14:10 We just provide the abstraction.

14:12 Yeah, that's really cool.

14:13 So you basically just do like an adapter to make it all look the same, the various libraries

14:18 that are out there.

14:18 What are some of the major libraries, Python libraries that people or that are maybe that

14:22 you're built upon?

14:23 So the two major ones, I would say that it's the Juniper library I mentioned, which is called

14:29 Pi EC, as Pi EZ.

14:31 And the other one is NetMiko.

14:35 That's quite popular, actually.

14:37 It's built on Paramiko.

14:38 And it's specifically to be able to interact with network devices because each one has different

14:46 idiosyncrasies.

14:47 Like one has this, I don't know, like the new line.

14:51 It's using this code, which is super old from the early Unix days.

14:56 This other one changes the prompt.

14:58 So you have to take into account.

15:00 So yeah, it builds on top of Paramiko, but it knows how to the tiny, gritty details of

15:05 each platform.

15:06 Yeah, yeah.

15:07 That sounds like something you don't want to write yourself that you would just like to

15:10 use.

15:11 Yeah, yeah.

15:11 Yeah, yeah.

15:12 So before we get into how it works, what hardware vendors do you support?

15:17 The list is getting long, right?

15:19 It used to be pretty short at the beginning.

15:20 Yeah, the original one was just four vendors because that's actually the ones that I and

15:25 Elisa had in our networks.

15:27 But nowadays it's, so from Fisco, it's iOS, iOS XR, and NXOS because if I have only one operating

15:37 system, you're going to have three.

15:38 Right, of course.

15:39 Why not?

15:39 It's Juniper.

15:42 It's Arista.

15:44 It's Fortinet.

15:46 It's, who else?

15:48 Microtech.

15:49 There's people working on Brocade as well.

15:52 Oh, there's Palo Alto as well.

15:55 There are probably a few more, but yeah, I don't recall them right now.

15:58 Yeah, of course.

15:58 No, but it's pretty comprehensive these days, huh?

16:01 Yeah, it's quite extensive.

16:02 And people keep working on adding more and more.

16:05 So one of the really important building blocks was these libraries that we talked about, the

16:10 actual communication with the various devices.

16:12 The other one is Ansible.

16:14 And you actually added SaltStack and StackStorm as well, right?

16:19 Yeah, I mean, we try to provide just a library.

16:21 We try not to have opinions on how people should be doing things.

16:25 So we try to just provide the basic Python library so people can either integrate with their own

16:31 framework or just write their own script.

16:35 So the three major tools that we integrate with are Ansible, SaltStack, and StackStorm.

16:42 Okay, that's really cool.

16:44 So let's just pick Ansible, for example, but it would be similar to others.

16:48 Can you maybe describe to me how we would use Napalm and Ansible?

16:54 And let's have some kind of goal, right?

16:56 Let's suppose you want to set up a load balancer, a couple of web front ends, and maybe a database server,

17:05 and some caching tiers, and try to build that network all together so that, you know,

17:09 only the right pieces can see each other and things like that.

17:14 How would that work?

17:14 So the way it would work is that you would have templates for your services, right?

17:19 But now with Ansible, you would have another template to map how this new service maps into

17:25 the network as well.

17:26 That might be like a new VLAN, a new IP address, somewhere else.

17:29 So you would just write another template as you did for Nginx and, I don't know, MySQL

17:36 or whatever you're using in your network.

17:39 And then you just have to, when you just compile this template with the data and you get like

17:45 an actual output, the only thing you have to do is tell Napalm to use that configuration.

17:48 file and apply it into the device.

17:51 And then you can do two things.

17:52 Either you apply it straight into the device or you just get a diff that you can actually

17:58 peer review or, you know, or something of the like.

18:01 That's a pretty nice experience that you can go to your network and reach out to all the

18:06 devices, right?

18:07 You'd set up your Ansible scripts and, you know, one for the load balancer, one for the

18:11 web tier, maybe things like that.

18:12 And you'd set them up and you could say, go query them the way they are now.

18:17 Figure out the changes that you would push to them and then generate a text diff of what

18:23 we're about to do to it, right?

18:25 Yeah.

18:25 I mean, the only difference between managing like your web server and your network with

18:30 Ansible and Napalm is going to be that instead of reloading the service, you're going to be

18:36 applying the configuration with Napalm into the device.

18:38 But the rest should be exactly the same workflow.

18:41 Just the template model, the data coming from your backend or YAML file.

18:46 And yeah.

18:47 Yeah.

18:47 Yeah.

18:47 It's really nice.

18:48 So that probably makes it pretty easy to store these in like GitHub or somewhere like that

18:53 and have like a history of the changes you've applied to your devices.

18:56 Yeah.

18:57 That's pretty much what everybody is doing.

18:59 Just like, yeah.

19:00 Just have it as any other template on your GitHub or whatever you're using.

19:05 Yeah.

19:05 And one thing you guys talked about is you push the entire configuration for the device over

19:11 to it.

19:11 But somehow the device knows to actually only apply the delta.

19:15 How does that work?

19:16 So, yeah.

19:17 So you can do both things.

19:18 You can either apply just a snippet of configuration.

19:21 Like if you just want to configure a VLAN, you can choose to configure that single VLAN.

19:27 Or you can apply the entire configuration.

19:31 The problem with applying snippets of configuration is that the way that devices work, you don't

19:37 have a single configuration file where you just like apply it on the device and then reload

19:42 the service.

19:42 And only what's on that file is what's going to be applied.

19:46 Actually, on a network device, you actually tell the network device how to do things.

19:51 Would be like going to a Linux box and start configuring the network using IP route commands.

19:57 IP route at this interface or IP route at this routing here.

20:02 So you're actually telling the device what to do and how to do it.

20:05 So if you're merging snippets of configuration, you have to be aware that if you want to remove

20:10 a VLAN, for example, you have to tell it remove this VLAN.

20:13 It's not good enough to just send the list of VLANs that you want.

20:18 That's why I'm trying to...

20:20 This is my kind of like a personal opinion.

20:23 I like instead just somehow compiling the entire configuration of the device, send it

20:28 to the device and tell the device, now reload the service, which is exactly how I would manage

20:33 Nginx and my SQL or something.

20:35 And just like, here's my config file.

20:36 Now reload.

20:37 I don't care what you had before.

20:39 Just do this.

20:40 All right.

20:40 This...

20:41 I want you to be like this.

20:42 Now be that way.

20:42 Yeah.

20:43 So that works well with most devices, but this feature for Napalm to use it has to be supported

20:50 natively.

20:50 And most of the devices nowadays, like iOS supports it, Arista supports it, Juniper, like the major

20:57 vendors support this, these features.

21:00 You're going to actually send a entire config file and reload the service.

21:04 It's a great quote, quote on the reload the service.

21:07 Yeah.

21:08 This portion of Talk Python To Me is brought to you by Linode.

21:13 Are you looking for bulletproof hosting that is fast, simple, and incredibly affordable?

21:17 Look past that bookstore and check out Linode at talkpython.fm/Linode.

21:22 That's L-I-N-O-D-E.

21:24 Plans start at just $5 a month for a dedicated server with a gig of RAM.

21:28 They have 10 data centers across the globe.

21:31 So no matter where you are, there's a data center near you.

21:34 Whether you want to run your Python web app, host a private Git server, or even a file server,

21:38 you'll get native SSDs on all the machines, a 40 gigabit network, 24-7 friendly support,

21:45 even on holidays, and a seven-day money-back guarantee.

21:48 Want a dedicated server for free for the next four months?

21:51 Use the coupon code python17 at talkpython.fm/Linode.

21:58 One of the consequences of the way Napalm works is that if somebody goes and manually starts changing the network settings or something, right?

22:07 They SSH in there and they make a few changes and then just log out.

22:13 And they don't save that anywhere, right?

22:15 Napalm will basically wipe that away, won't it?

22:17 If you're using this replace operation that I just described, yeah, that's exactly how it would work.

22:24 It's just like, yeah, I just created this VLAN by hand and you didn't save it in your template or in your database or something.

22:31 Yeah, it's going to be completely wiped out.

22:34 If you're using the other method where you're just applying snippets of configuration,

22:39 then unless you're explicitly removing the configuration, Napalm won't remove it.

22:44 Because Napalm won't even know that the configuration is in there.

22:47 Right.

22:48 Unless that snippet has exactly to do with that part that was changed, they might not never interact, right?

22:53 Yeah.

22:53 So some people are combining both manual with automated operations.

22:57 So they prefer to use this method where you just tell the device, apply this snippet of configuration.

23:04 So it depends a bit on what you are trying to accomplish and what your network looks like.

23:09 For some people, the network is so full of snowflakes that actual automating every tiny detail is literally impossible.

23:18 Yeah.

23:19 Yeah, of course.

23:20 I can imagine places like that.

23:22 It never was really built all at once.

23:25 It just kind of grew this way.

23:26 Oh, yeah.

23:27 Organic design.

23:29 Yes, of course.

23:30 Is there a way to go in reverse?

23:32 Like, I know I could come up with a bunch of Ansible scripts and I could generate a network out of it.

23:38 But is there a way to go to a network and say, now generate me the set of Ansible scripts that would reverse engineer it?

23:47 So that you could sort of start from an existing network, come up with these scripts, and then going forward, go in reverse, use Napalm to work with it.

23:54 So what I have done to migrate from this snowflake environment to a fully automated environment is I just copy the configuration file.

24:05 I mean, I just copy the configuration of the device and just put it into a static file.

24:09 And I just deploy that static file with Napalm.

24:13 And the only thing I'm doing is just override the configuration that it's already there.

24:16 The configuration is just completely static.

24:18 And then I start just taking bits of the configuration that is just defined statically into templates.

24:26 So that way I can just start migrating bit by bit.

24:29 Like, okay, now I have automated the VLANs.

24:31 So I can just remove the VLANs from the static configuration file and use a template for that.

24:37 The only thing I have to do is append one file into the other with Ansible.

24:41 And now I'm going to automate, like, the interface generation.

24:45 So I just take that away and automate that bit.

24:48 So you can start doing this step by step and just keeping your configuration statically defined somewhere else.

24:54 Yeah, that's a pretty good idea.

24:55 Just copy it over and go, this is how it is.

24:57 And then we're going to pull out the little pieces that change every now and then that we want to automate.

25:02 And everything else, we can just forget it, just leave it.

25:04 Okay.

25:04 Yeah, yeah, it makes a lot of sense.

25:06 So Napalm is written entirely in Python, right?

25:10 If I can trust GitHub's little measure of what languages are involved in this project, it's like all Python.

25:16 Yeah, it's all Python.

25:17 Yeah, yeah.

25:18 That's really cool.

25:18 You don't have too many performance considerations or anything where you might bring in Cython or other types of things, right?

25:25 It's more just quick communicate over the network to the device and the device has to do the heavy lifting.

25:31 Yeah, I mean, we are talking about something that you're interacting with.

25:35 I mean, you're interacting with the device over the network and you're probably using some API or method to interact with the device, which is not extremely fast.

25:46 So it's not like you're doing mathematical computation.

25:51 So I don't think that, yeah, that performance is a concern.

25:56 No one has brought that up at least.

25:58 Yeah.

25:59 And if it is, it's probably not your performance issue that you can work with, right?

26:04 It's like, well, this device is just slow when I do this to it.

26:06 Yeah.

26:06 I mean, most of the devices, like you type, like, I don't know, show interfaces.

26:10 And maybe the device has like 100 interfaces.

26:12 So the device takes like one or two seconds to actually return all the data.

26:17 So it's like, yeah, we could optimize like 10 milliseconds out of two seconds.

26:22 So, okay.

26:23 Yeah, of course.

26:23 Yeah, exactly.

26:24 Don't worry about it.

26:25 Yeah, I guess the real trick would be to make sure you're using the latest APIs and libraries from the various vendors.

26:31 Like if you were previously doing some weird screen scraping thing and now they have a JSON API, like switch to that, right?

26:36 Yeah, that's actually the main challenge we have.

26:38 Like trying to use the latest APIs, it usually don't go that well because, yeah, because vendors, I'm sorry, vendors, users still have like networks running operating system from the, I don't know, early 2000.

26:51 I mean, I have seen a lot of people with, yeah, my device has a 10 years uptime.

26:56 Like maybe you should count that on security advisories more than instead of in years.

27:01 That's really interesting.

27:04 So I'm paranoid about like security issues and things like that on my servers and on things like Nginx and stuff.

27:15 And if there's an update, like that thing is, even if it causes a reboot, it's getting applied because it's on the internet.

27:22 That's such a bad thing.

27:24 And so to think that a device is up for 10 years, that's probably needs some attention.

27:29 Well, the thing is that for most legacy networks, like reloading a device is super hard because you might bring down a lot of systems.

27:38 Like because everything uses the network.

27:41 It's the very foundation.

27:42 It's like taking away memory or the CPU or something, basically.

27:46 Exactly.

27:46 Exactly.

27:47 And most of the networks are actually completely isolated from the internet.

27:51 So the only way of actually trying to exploit like some bugs would be by first getting inside your network by just hacking the VPN or the bastion that you might have in your network.

28:05 So there is like certain degree of isolation in the network as well.

28:09 So upgrading is not.

28:10 It's not as critical as like a front end web server that's taking traffic off the internet.

28:14 Yeah.

28:14 Yeah.

28:14 That's one thing to pass the traffic along.

28:17 It's another to be the endpoint to like send it into your executing code.

28:21 Okay.

28:23 Interesting.

28:24 So one thing I wanted to ask you about is like there's a lot of cloud computing and other sort of programmable, automatable systems like virtual private servers, you know, things like Linode or DigitalOcean.

28:36 And then we've got EC2, we've got Azure and Heroku.

28:40 How does this whole network automation story fit with that?

28:45 Like, is there any place for say Napalm in AWS or is this really, I have my own data center.

28:51 I want to manage that or I would go do something with AWS or.

28:55 Yeah.

28:55 So the main focus of Napalm is actually like physical infrastructure.

29:00 So we don't really have any hooks with any of the, all the cloud companies, like none of them.

29:06 Like, yeah, we mostly operate on switches, routers, firewalls, all this kind of thing.

29:12 Yeah.

29:12 And you, you rarely have that low level of access in any of those places.

29:17 Yeah.

29:17 I mean, there could be like, maybe, yeah, I'm, I'm not a juicer myself of the public cloud.

29:23 So I'm not sure how they work, but there might be some room for like, I don't know, maybe integrating with how, with the firewall, their firewalls and load balancers.

29:34 But yeah, I don't know.

29:35 I haven't heard of anyone even considering something like this.

29:39 Sure.

29:39 I mean, there are APIs for the load balancers and APIs for the firewalls, but yeah, I'm not sure.

29:45 I'm not sure if it makes sense, but maybe, maybe it makes sense somehow.

29:48 Right.

29:49 But, but maybe not the same.

29:51 Right.

29:51 Maybe say, I want to connect these three machines and I want to have this in a virtual private network and whatnot.

29:56 Like that possibly could be a thing, but I'm not sure if it really makes sense to mix these tools.

30:00 I will say if someone comes up with something after hearing this podcast.

30:04 Yeah, exactly.

30:06 Maybe you'll get a pull request.

30:07 What about like Dockers?

30:09 If I'm a Docker, if I'm using Docker or like, I've got a bunch of them running together managed like by Kubernetes.

30:15 But let's say that's on my own network.

30:17 Well, if it's on your network, I'm pretty sure that you could somehow orchestrate configuring the network somehow with, with Napalm.

30:25 I don't know the details of Kubernetes, but I know people doing exactly that with OpenStack.

30:32 So their provisioning system just uses, uses Napalm to orchestrate the physical network with the rest of the, I don't know how it's called, Neutron.

30:42 I think it is the network plugin for, for OpenStack.

30:46 Interesting.

30:46 Yeah.

30:46 So what's the story between Napalm and OpenStack?

30:50 So OpenStack being like.

30:51 I don't know the details, to be honest.

30:53 I know that someone I was working on just like they have their, they're just in OpenStack to just deploy their virtual infrastructure.

31:02 And one of the pieces is actually configuring the network, right?

31:07 So someone had just written up plugin, which I don't know if it was just in production, actually, to just like configuring.

31:15 Like, for example, if I'm deploying this service, I need to configure this BGP station in here or this VLAN in there.

31:21 So it was just a matter of doing that with Napalm.

31:24 Okay.

31:24 Yeah.

31:25 There probably is some opportunities for some kind of integration there.

31:29 But, you know, I don't do enough with OpenStack, honestly.

31:31 I mean, yeah.

31:33 All right.

31:35 So can you maybe give us like the general workflow of working with Napalm?

31:39 So we start breaking down the devices into different services, right?

31:44 Like here's a firewall.

31:46 Here's a web server.

31:48 Things like that, right?

31:49 It depends on what you're doing, actually.

31:51 Because we try to just provide the API as generic as possible so you can write your own workflow.

31:57 So we do a set of methods, for example.

32:01 One set of methods just interact with the device configuration.

32:05 So you can say like, okay, I want to deploy this configuration.

32:08 Or I want to replace the existing configuration with this one.

32:13 This is the method that was mentioned before where you just wipe everything out, right?

32:19 Okay.

32:19 Now I have this configuration loaded.

32:21 I want to either discard it, commit it, or just get a diff back.

32:27 So these are just basic, primitive, so you can actually build your own workflow.

32:31 You can just integrate it with, I don't know, with Jenkins, for example, to stage the change and get a diff back, open a pull request and have someone validate it.

32:41 Like, for example, that's a common workflow.

32:44 And the other set of methods, it's getting data out of the network.

32:47 Like, I want to get the interfaces of my devices.

32:50 Or I want to get the BGP neighbors of my network.

32:53 Stuff like that.

32:55 So you can actually have into your Jenkins job, like after the change has been made.

33:03 Just get the data out and verify that the interface that you configure is actually configured as you want it.

33:09 So, yeah, we don't really have built-in workflow, but we try to just have the basic primitives so people can write their own workflows and just, yeah, integrate as they want.

33:19 Yeah, it's pretty agnostic to the way that the vendors want you to work.

33:22 You can come up with your own workflow, and because it'll talk to all the devices the same, that more or less should work, right?

33:30 Yeah.

33:30 Yeah, for example, I like more the workflow of just generating the entire config and send it to the device.

33:36 Because that way I know that what I told the device, it's going to be in there.

33:40 Rather than having to tell the device how to do things, like, yeah, I don't know how to do it.

33:45 Just get this done.

33:46 But other people prefer more like not all sorts of operations where they have like a self-service portal and they just click somewhere like, okay, create this, delete that.

33:56 So, yeah, it depends on your preference, I guess.

34:00 Yeah.

34:00 And probably how you're using your network and how often it changes and whatnot.

34:04 So, you mentioned Jenkins.

34:07 Like, what's the story with continuous integration?

34:09 Like, what are you seeing people do with Napalm and CI?

34:12 I would say that the common thing that people does with CI and Napalm is mostly automated deployment.

34:18 Like, for example, I just change some data on a YAML file, right?

34:23 And that triggers a Jenkins job that just runs an Ansible playbook, for example.

34:27 And Ansible playbook connects to the device, loads the new candidate configuration, and retrieves back a div.

34:36 And the div just gets just, it's posted into some PR sort of tool.

34:42 Could be Garrett or maybe another GitHub repo.

34:46 So, that's a common workflow.

34:47 Another workflow I have seen, it's a bit weird.

34:53 I don't remember who did this.

34:55 But we have a framework within Napalm where you can define certain rules.

34:59 Like, for example, I want to verify that all my BGP neighbors are sending me at least five prefixes.

35:05 We have a framework to describe things like that, for example.

35:09 Or I want to check that my interfaces have no errors.

35:11 It's just a YAML file where you can just describe certain data and validate it.

35:16 So, I've seen some people that when they deploy something on the application, they run this sort of validation tool to verify that the network is working fine.

35:27 Like, for example, we start this backup.

35:29 We want to check that we are not having interface errors at the same time.

35:33 So, I've seen people not connecting completely unrelated pieces and verifying stuff with CI as well.

35:40 Okay. And things like, I made a change to the network, but I don't expect the number of endpoints to change.

35:47 So, let's make sure that that is still a constant number or something like that, right?

35:51 Yeah, it was a kind of weird workflow.

35:53 They were trying to explain to me, I was like, okay, that sounds all confusing and cool.

35:58 So, I didn't really understand it very well.

36:03 Yeah, interesting.

36:04 This portion of Talk Python to Me has been brought to you by Rollbar.

36:08 One of the frustrating things about being a developer is dealing with errors.

36:11 Relying on users to report errors, digging through log files, trying to debug issues, or getting millions of alerts just flooding your inbox and ruining your day.

36:20 With Rollbar's full-stack error monitoring, you get the context, insight, and control you need to find and fix bugs faster.

36:27 Adding Rollbar to your Python app is as easy as pip install Rollbar.

36:31 You can start tracking production errors and deployments in eight minutes or less.

36:36 Are you considering self-hosting tools for security or compliance reasons?

36:39 Then you should really check out Rollbar's compliant SaaS option.

36:43 Get advanced security features and meet compliance without the hassle of self-hosting, including HIPAA, ISO 27001, Privacy Shield, and more.

36:52 They'd love to give you a demo.

36:54 Give Rollbar a try today.

36:56 Go to talkpython.fm/Rollbar and check them out.

37:00 So to test this out, do you actually have to have the devices like a Juniper device or a Cisco device?

37:06 Or is there like the equivalent of virtual machines for these network devices?

37:10 Most platforms nowadays have a VM equivalent.

37:15 So we can use that for testing.

37:19 But we rely a lot on mocks.

37:22 Like for example, most of the time we, like most of the code is actually just normalizing data.

37:28 But just connecting to a device, retrieving the interface information and normalizing it into a common model.

37:35 So for those things, that's easy to mock.

37:38 You just need the original data, a few use cases, and just test that the parser, normalizer works fine.

37:47 So yeah, we can get away a lot with just mocks.

37:50 But yeah, there are certain things that you need, a VM or something.

37:53 Yeah, that makes sense.

37:54 It's like, so run some particular command on some test lab setup and just capture that text and go, now tell it that it gave you this.

38:03 Yeah.

38:03 With the mock layer in your CI.

38:06 Yeah.

38:07 The thing that you don't want to mock is the configuration management bit.

38:12 Because that's so critical.

38:13 If you miss something up in there, like you might be costing an outage.

38:18 So that we try to always, always test with VMs.

38:22 I want to play it safe there.

38:24 Is it stressful to work on this project?

38:26 About just to think like people might be running this against huge networks, either your own at Fastly or someone else's and just like, okay, I really have to get this right.

38:36 Because it could have real consequences if I mess it up.

38:40 No, I don't think it's stressful.

38:42 No, I don't think so.

38:44 Like the primitives that we provide with Napon to configure the network, it's actually five or six methods.

38:52 And those ones, they're written, they're written.

38:55 Like you don't really have to deal with them.

38:57 So yeah, I mean, it's a bit delicate when you're writing them for the first time.

39:02 But then once that's written, it's just a matter of, yeah, just keep testing.

39:07 I see what you're saying.

39:08 It's kind of low enough that the parts where it may get tricky or not quite right is actually at the person using Napalm, not Napalm itself.

39:18 And I mean, obviously, you're integrating into something as low level as your infrastructure.

39:23 You have to do your homework and actually do some integration testing yourself.

39:28 And make sure that, yeah, the exact version that you're running on the network, it actually works well with Napalm.

39:33 Like maybe you have like this super tiny bug that we have on the operating system of the network, I mean, that we haven't encountered before.

39:40 So that's just, yeah, basic integration testing, I guess.

39:44 Yeah, yeah.

39:44 Do you get requests for people to add support for particular devices that you don't have access to?

39:51 Oh, yeah, all the time.

39:52 And so how do you deal with evaluating those PRs?

39:55 For the configuration management part, we always ask to have proof that it's working.

40:00 And that could be as simple as he just creates a necessary user for me so I can actually validate the testing person while he's running the test on his machine.

40:10 Or I might be running the test on my machine.

40:12 But the thing is that if I don't have access to the device, at least the configuration bit, I need to be able to test it the first time myself.

40:20 Because then once it's tested and it's working in there, it will probably barely change.

40:26 And yeah, and what retrieves data from the device, that's easy.

40:31 That's just a matter of mocking the output.

40:33 So yeah, that's not really a worry.

40:36 Yeah, it just seems like when you work with all these different devices, it's tricky because you probably don't have access to every single variation of them, right?

40:43 Yeah, yeah, correct.

40:44 Yeah, so we just try to at least, at least the first time to validate, not take only the word of the contributor.

40:51 Could you do like screen sharing and just like watch them?

40:54 Yeah, I mean, anything that works for them.

40:56 I mean, if they don't want to share the screen, I mean, and they can just give me access to the device, I can just pull their branch and test it myself.

41:03 I mean, that's fine.

41:04 Yeah, cool.

41:06 So I just wanted to highlight a video presentation that you did at Nanog.

41:12 What was the first?

41:13 I might be getting it wrong.

41:15 Yeah, Nanog.

41:15 Yeah, Nanog.

41:16 I thought that was really helpful.

41:17 It's a little bit dated, right?

41:18 That was, I think, from 2015, but it still shows a lot of the workflow and how people might do it.

41:24 So if they're really interested, I'll be sure to put that video in the show notes.

41:28 People can check it out.

41:29 Yeah, that's actually the video that we recorded when we went live with the project.

41:34 Like, here we are.

41:35 Yeah, here you are a couple years later, and I remember there was just the few devices you guys supported, and now there's a whole bunch.

41:41 Yeah.

41:42 Yeah, so do you want to tell us about some of the major deployments or users of Napalm?

41:47 So I don't really have an official list.

41:50 I never thought about that.

41:52 But I was actually going through the contributors and just trying to see where they work.

41:57 So this list I'm going to mention now is based on trying to check on where people work.

42:03 I don't know if they're actually using it on their networks.

42:06 It might be that the contributor is just, I don't know, doing it on its own spare time.

42:13 I don't know.

42:13 Just disclaimer here.

42:15 But I don't know.

42:15 I've seen contributions from people working at places like some trading firm that, I don't know,

42:22 friendly is called IMC, Nike, Netflix, obviously Spotify, which is where everything started, like eBay.

42:29 Yeah, you were at Spotify when you started working on this, right?

42:32 Yeah, right, right.

42:33 Yeah, I was working at Spotify when I started the project.

42:36 eBay is a big user of Python, so that makes a lot of sense.

42:38 Yeah, I know.

42:39 I have seen some contributions from people working there.

42:42 Again, I'm talking based on where I have seen they work.

42:46 I don't really know what they're doing.

42:48 There are a few IXPs like Lynx and Linux, which if you're a network engineer, you probably know who they are.

42:55 And Fastly, we use it as well.

42:56 And another big contributor is also Cloudflare, which is another CDN.

43:01 But yeah, there are a few contributors.

43:05 They seem to be working in interesting places.

43:07 Yeah, that's great.

43:08 Are you looking for more contributors?

43:10 People always ask me if there are good places to get started in open source that are kind of new.

43:15 They want to check this out.

43:16 So are you looking for competitors and what kind, I guess?

43:19 Anyone could help, actually.

43:20 There is a lot of work to do, both in, I don't know, like something as basic as documentation.

43:25 That's kind of like even if you don't know Python or you're starting with Python, you can always help there.

43:31 And then also something you have to bear in mind is that this is mostly built by network engineers,

43:39 which means that it might not be the best Python.

43:43 So even if you don't know anything about networking, but you just want to help a project by just reviewing the code

43:49 and proposing improvements or something like that, like, yeah, Napalm would be a great fit for that because, yeah, we are mostly network engineers.

43:58 But, yeah, we don't know what we are doing.

44:00 We're just trying to solve problems.

44:03 Hey, we made it work.

44:04 It's great.

44:04 So I asked you earlier about how you deal with the hardware that you don't know about.

44:08 But if somebody's got some new piece of hardware and they want to integrate it into Napalm,

44:13 what are all the steps that they got to go through for that to work?

44:16 So if you're a vendor, which actually has happened already, it's the same workflow as if you were just a regular contributor.

44:23 Like you just come to us proposing the idea.

44:27 That's just so we know that you're working on that because someone might already be working on us.

44:31 It's trying to avoid duplicating effort.

44:35 But I don't know.

44:36 We don't really have a formal structure.

44:38 Like there are certain ways that you have to integrate with the project.

44:42 But that's just part of how the project is kind of designed.

44:48 It's not really like formalities.

44:50 Like, oh, yeah, you have to support at least these three methods.

44:53 And if they're not supported, like it's a completely no-go.

44:56 Like, no, we don't really have strict rules like that.

44:58 I mean, if it's useful, it's useful.

45:00 Even if it's just like a couple of methods, someone else might just pick it up and improve it.

45:06 Right.

45:06 Just getting it started might be a big deal.

45:08 Nice.

45:08 Okay.

45:09 That's great.

45:09 So what's the feature, Nepal?

45:12 Like, what are you guys planning to add?

45:14 Or where is it going?

45:16 Now we just launched a new library where we tried to normalize syslog events, for example.

45:24 This is completely new.

45:25 The first release was launched like maybe a couple of weeks ago.

45:31 So because this, yeah, in the same way that every device has its own CLI and output from different calls.

45:40 Yeah.

45:41 In the same way that that happens, they also send like different syslog events with different data and everything.

45:47 So now we are trying to be able to normalize that.

45:50 So you can just start this service, use it as a syslog endpoint and just normalize the data and send it somewhere else, like whatever, log stash or whatever you're doing.

46:01 And I don't know.

46:03 We're trying now to integrate as well with OpenConfig.

46:06 OpenConfig is an industry effort to normalize the data that devices return, for example.

46:14 So when we started, OpenConfig didn't exist yet.

46:20 So we designed our own data models, to call them in some way.

46:24 And now we are trying to start integrating with this data models.

46:29 Yeah.

46:29 So if there's going to be a standard around all the data, then you guys definitely want to be part of it.

46:34 Yeah.

46:34 So now we're trying to integrate with that instead of just completely designing everything ourselves.

46:39 Like, yeah, if someone is solving that problem for me, why not?

46:42 Yeah.

46:42 And if people want to get in touch, you have both a Slack channel and a mailing list, right?

46:46 Yeah.

46:46 We're in Slack.

46:48 The Slack organization is called Network2Code.

46:51 We can probably add a link on the show notes to the page to register.

46:55 And there is also a mailing list, although it's not very active, to be honest.

46:59 Most people prefer Slack nowadays.

47:01 Looks like email is slowly dying.

47:04 And we actually launched today a webpage to keep all the news posted there and links to the Slack channel and everything.

47:12 So that's actually a good...

47:15 Wow, that's great.

47:15 Just today, huh?

47:16 Yeah, yeah.

47:17 Just like a couple of hours ago.

47:18 Nice.

47:19 Be sure to put that in the show notes that we're sharing so we can make sure everyone has that.

47:24 Yeah, because before we had just the GitHub.

47:27 But GitHub is not great if you want to keep people up to date into like, oh, yeah, we just launched this.

47:33 Or we have fixed this.

47:35 So make sure that you are updating your requirements and stuff like that.

47:39 So, yeah, we built this web too.

47:41 Yeah, nice.

47:42 Yeah.

47:42 And what's the Python 3 versus Python 2 story?

47:45 Do you support both or one or the other?

47:48 Yeah, we actually support both.

47:50 Kirk, which is one of the main contributors and happens to be also the creator of NetMiko, the tool that I mentioned before.

47:58 He really likes Python 3.

47:59 So he worked very, very hard.

48:01 And he got all the code working there.

48:04 That's great.

48:05 Very nice.

48:06 So you don't have to worry in a couple of years when Python 2 gets phased out.

48:11 That's good.

48:12 All right.

48:13 So Napalm seems like a really cool project.

48:15 If you're doing network automation, it seems really excellent.

48:19 So I wanted to ask you why I had you here.

48:21 A few more general questions just about networking type of things.

48:25 So what is the future for network?

48:28 What does it look like for network engineers, do you think?

48:30 More stuff like what you're doing with Napalm or is it changing or what do you think?

48:35 Million dollar question, I guess.

48:36 Everybody keeps asking that.

48:37 I don't know.

48:39 I mean, the way I see it is somehow the network engineer will transition into an SRE type of role.

48:46 Where you're not this CLI jockey that knows all in and outs of a network device, all the knobs.

48:54 Networks are becoming simpler and simpler because people keep just building bigger and bigger.

49:00 So there is less room for snowflakes.

49:03 So I see more like network engineers transitioning into an SRE type of role.

49:08 Okay.

49:08 And do you think things like this data standard you talked about and Napalm itself,

49:14 where you don't actually have to know the details as specifically about the devices?

49:19 Do you think it's more automation programmability, less specific knowledge about the individual devices?

49:25 Well, the thing is that networks traditionally were full of knobs.

49:29 Like you go and you configure OSPF and then you enable this super obscure option in here.

49:36 Then this other knob in that other place.

49:41 Like, yeah, when your network is not so small, you keep just trying to optimize like everything.

49:47 But now when you start building things at a bigger scale, like there is not that much room for those kind of thing.

49:53 Like you need to build something fast.

49:55 Regardless of if you're doing it manually or in an automated way, you need to start standardizing things.

50:01 So my guess is that eventually things will happen.

50:05 I mean, it's the same that happened with other services.

50:07 Like before you had like, I don't know, 20 instances of MySQL and each one was configured differently, trying to optimize every detail.

50:14 Now that you have like 100 MySQL, I don't look the same.

50:17 I didn't really care about anything.

50:20 Yeah, whatever.

50:22 Yeah, it's more about trying to manage 100 things than it is about tweaking little bits.

50:26 Because if you can manage 100, you can just add a few more and get better performance or whatever, right?

50:30 Yeah, the cloud is cheap, right?

50:31 So you just have more compute.

50:32 That's right.

50:34 The other thing I wanted to ask you about was IoT devices, right?

50:37 So we saw recently one of the, it was the biggest denial of service attack.

50:42 And the denial of service attack actually came from a bunch of hacked webcams or something like this, a bunch of these IoT things.

50:51 So it seems to me like having all these little crappy, unsecured, non-updated devices on networks is a problem.

51:00 It's going to be more and more of a problem as things go.

51:02 Like from a network perspective, like what can be done about these things?

51:06 The problem is where are those IoT devices located?

51:09 Are they located like behind a corporate network or are they located behind like someone's home?

51:16 Probably someone's home connected to a crappy firewall, a crappy NAT router that is like hasn't been updated in five years.

51:22 Yeah, I mean, then you have a problem because there is no actual way of automating that box that your provider gave you and didn't even provide you the user and passwords, right?

51:33 Yeah, I guess there is a little hope in there.

51:36 Not a whole lot of hope.

51:37 Do you have any hope for it?

51:39 Do you think like, what do you think is going to happen?

51:42 I don't know.

51:43 I hope that at some point, like the people building those devices actually take some responsibility and pride, I guess, on what they are building.

51:52 And they start building them properly.

51:55 I mean, that's actually the only thing we can hope for because you don't know where they are going to be.

51:59 Like if they're behind a corporate network, you can always secure the perimeter somehow.

52:03 But I mean, yeah, I mean, if it's at your, I mean, at home, like, I don't know.

52:07 Yeah, it's kind of kind of tough.

52:08 Even if you put them on like isolated networks, like my router will let me create multiple, like a guest network and another one, I could put it on there and it won't get to my stuff.

52:17 But still, it becomes a denial of service thing on the internet, right?

52:20 Which is not great.

52:21 Yeah, and you're tech savvy, right?

52:23 Like, I mean, if my parents try to, like, they buy like this Philips bulb that can do like a million things.

52:30 Like, I mean, they have no idea about computers.

52:31 They just bought it with the remote control that it comes and it just works.

52:35 Yeah, it seems to me that the silly cheap light bulbs and other things like this are going to have an interesting fix in the future.

52:42 And networking will probably somehow be part of it, but I don't know what it is yet.

52:45 All right, well, thanks for those questions.

52:47 So, I mean, we should wrap it up.

52:49 We're getting kind of into the show.

52:50 So, a couple of questions for you.

52:53 If you're going to write some Python code, what editor do you use?

52:56 BI, always.

52:57 BI, awesome.

52:59 Yeah, I saw you use it on your demo there in the video.

53:01 That's great.

53:01 And notable PyPI packages.

53:04 Aha.

53:05 So, obviously, we can pip install Napalm, right?

53:08 Yeah, correct.

53:09 Okay.

53:09 So, there's a good one.

53:11 Any others?

53:12 I would say Hammock, which builds on top of requests, and Enmico.

53:17 Yeah, those are probably the two I would mention.

53:19 Yeah, okay.

53:20 I don't know about Hammock.

53:21 That's cool.

53:21 What does it do?

53:22 It's mostly a wrapper on top of requests.

53:25 So, you can start doing, like, you create your instance, and then you do, like, myapi.api.v1.host.get.

53:34 And then the URL just builds itself.

53:36 So, it's kind of like...

53:37 Oh, interesting.

53:38 I see.

53:38 Nice to use.

53:39 It uses, like, the dynamic nature of types themselves to express the URL.

53:43 Okay, that's really cool.

53:45 I got to check that out.

53:46 All right.

53:47 So, it was very nice.

53:48 Thanks for being on the show.

53:49 Any final call for action?

53:50 If people want to get started, how do they do it?

53:52 So, well, if people want to get started, they can always visit our new webpage where you

53:57 can find links to our GitHub repo, to the documentation as well.

54:01 We have instructions on how to use VMs so you can actually start poking at Napalm without

54:07 having to deal with the actual infrastructure.

54:09 So, yeah, our website, it's probably the best place to begin with.

54:14 Okay.

54:14 Excellent.

54:15 Well, David, thank you so much for being on the show.

54:17 It was great to talk about networks with you.

54:19 Yeah, thank you for having me here.

54:20 It was a lot of fun.

54:21 You've got...

54:22 This has been another episode of Talk Python to Me.

54:25 Today's guest was David Barroso, and this episode has been brought to you by Linode and Rollbar.

54:31 Linode is bulletproof hosting for whatever you're building with Python.

54:35 Get your four months free at talkpython.fm/linode.

54:40 Just use the code python17.

54:42 Rollbar takes the pain out of errors.

54:45 They give you the context and insight you need to quickly locate and fix errors that might

54:50 have gone unnoticed until your users complain, of course.

54:53 As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash

54:59 talkpythontome.

55:00 Are you or a colleague trying to learn Python?

55:03 Have you tried books and videos that just left you bored by covering topics point by point?

55:08 Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course

55:14 to experience a more engaging way to learn Python.

55:16 And if you're looking for something a little more advanced, try my Write Pythonic code course

55:21 at talkpython.fm/pythonic.

55:24 Be sure to subscribe to the show.

55:26 Open your favorite podcatcher and search for Python.

55:29 We should be right at the top.

55:30 You can also find the iTunes feed at /itunes, Google Play feed at /play, and

55:36 direct RSS feed at /rss on talkpython.fm.

55:39 Are you looking for a way to support the show?

55:42 Well, taking or recommending one of our courses is really the best way.

55:45 But if that's not for you, you can become a patron.

55:47 Visit patreon.com slash mkennedy for details.

55:51 You can give as little as $1 an episode.

55:53 This is your host, Michael Kennedy.

55:55 Thanks so much for listening.

55:57 I really appreciate it.

55:58 Now get out there and write some Python code.

56:00 Thank you.

56:01 Thank you.

56:02 Thank you.

56:03 Thank you.

56:03 Thank you.

56:04 Thank you.

56:04 Thank you.

56:05 Thank you.

56:05 Thank you.

56:06 Thank you.

56:06 Thank you.

56:06 Thank you.

56:06 Thank you.

56:07 Thank you.

56:08 Thank you.

56:08 Thank you.

56:08 Thank you.

56:08 Thank you.

56:09 Thank you.

56:10 Thank you.

56:10 Thank you.

56:10 Thank you.

56:11 Thank you.

56:12 Thank you.

56:12 Thank you.

56:13 Thank you.

56:14 Thank you.

56:14 Thank you.

56:15 Thank you.

56:16 Thank you.

56:17 you Thank you.

56:20 Thank you.