WEBVTT 1 00:00:00.080 --> 00:00:04.360 The world of network engineering is moving incredibly fast, isn't it. 2 00:00:04.360 --> 00:00:06.320 It really is. It feels like the ground is constantly 3 00:00:06.320 --> 00:00:07.400 shifting under our feet. 4 00:00:07.519 --> 00:00:10.000 Yeah. Just yesterday we were all, you know, neck deep 5 00:00:10.000 --> 00:00:10.839 in command line. 6 00:00:10.720 --> 00:00:13.240 Interfaces, clies everywhere exactly. 7 00:00:13.439 --> 00:00:16.519 Yeah, and now it's all about API's automation. 8 00:00:17.160 --> 00:00:20.280 It's a lot keeping up with the complexity that constant 9 00:00:20.320 --> 00:00:23.399 push for automation. Yeah, it can feel like a real 10 00:00:23.480 --> 00:00:24.719 uphill battle sometimes. 11 00:00:24.760 --> 00:00:28.239 But today we're trying cut through some of that noise. 12 00:00:28.640 --> 00:00:31.600 We want to give you, our listener, a focused look 13 00:00:31.719 --> 00:00:35.799 at a tool that's become well, absolutely essential in this landscape. 14 00:00:35.880 --> 00:00:40.159 It's fascinating this shift, you know, moving away from manually 15 00:00:40.200 --> 00:00:43.560 poking each device, yeah, device by device, towards a world 16 00:00:43.600 --> 00:00:47.600 where code, actual software defines and controls the infrastructure. 17 00:00:47.679 --> 00:00:50.840 The potential there for efficiency, for scale, it's just huge, 18 00:00:50.920 --> 00:00:51.280 it is. 19 00:00:51.359 --> 00:00:54.759 But it definitely means network engineers need to add some 20 00:00:54.880 --> 00:00:56.640 new skills, some new tools to their belt. 21 00:00:56.719 --> 00:00:59.799 Absolutely. And the real star the focus of our deep 22 00:00:59.840 --> 00:01:01.520 die today is Python. 23 00:01:01.679 --> 00:01:02.280 Ah. 24 00:01:02.320 --> 00:01:06.079 Python, Yes, we're looking at its crucial role in modern 25 00:01:06.079 --> 00:01:10.760 network engineering. And look, this isn't just our opinion. Now 26 00:01:10.920 --> 00:01:15.920 we've drawn our insights from a really solid resource, Mastering 27 00:01:16.040 --> 00:01:17.719 Python Networking, fourth edition. 28 00:01:17.959 --> 00:01:20.719 That's a comprehensive book, very practical. 29 00:01:20.920 --> 00:01:23.319 It really is. Think of this deep dive as your 30 00:01:23.359 --> 00:01:27.000 shortcut to understanding the key stuff from that book. It 31 00:01:27.040 --> 00:01:29.920 takes a very hands on approach, you know, using Python 32 00:01:29.959 --> 00:01:31.560 for all sorts of network. 33 00:01:31.200 --> 00:01:34.079 Tasks, and it covers a massive amount of ground, doesn't it. 34 00:01:34.200 --> 00:01:38.239 Looking at the big picture. It goes from like basic device. 35 00:01:37.879 --> 00:01:40.120 Interactions, fundamental all the way up. 36 00:01:40.079 --> 00:01:43.879 To advanced automation, even touching on network security with Python. 37 00:01:44.319 --> 00:01:48.000 It really shows how central Python has become. It's everywhere 38 00:01:48.040 --> 00:01:50.319 in networking, right across the board, and that's why we're 39 00:01:50.319 --> 00:01:52.560 here for you, the learner. Our goal today is to 40 00:01:52.599 --> 00:01:56.400 boil down those core concepts, show you the practical waves 41 00:01:56.439 --> 00:01:59.200 Python is actually being used right now. We want to 42 00:01:59.239 --> 00:02:01.000 give you those you know, aha. 43 00:02:00.640 --> 00:02:03.359 Moment, the actionable stuff exactly. 44 00:02:03.000 --> 00:02:06.319 Knowledge you can actually use without getting totally bogged down 45 00:02:06.319 --> 00:02:10.560 in every single tiny detail. So ready to jump in. 46 00:02:10.479 --> 00:02:14.080 Let's do it. But it raises that first question, maybe 47 00:02:14.080 --> 00:02:18.360 the most fundamental one, why Python, you know, with everything changing, 48 00:02:18.599 --> 00:02:22.000 what makes it the go to language for network engineers? 49 00:02:22.120 --> 00:02:25.439 That's the perfect place to start, and our source the 50 00:02:25.479 --> 00:02:29.479 book tackles this head on. It describes Python as a 51 00:02:29.520 --> 00:02:30.719 full spectrum. 52 00:02:30.280 --> 00:02:32.439 Language fall spectrum. I like that. 53 00:02:32.599 --> 00:02:35.120 Think about it. On one end, it's super easy to 54 00:02:35.120 --> 00:02:37.479 get started with, I mean the classic print Hello. 55 00:02:37.280 --> 00:02:39.199 World, everyone's first program. 56 00:02:38.960 --> 00:02:40.919 Right, pretty much, it's like the entry point. 57 00:02:41.039 --> 00:02:41.280 Yeah. 58 00:02:41.280 --> 00:02:43.800 But then on the other end of that spectrum, yeah, 59 00:02:43.879 --> 00:02:48.759 Python power some massive, incredibly complex systems. The book actually 60 00:02:48.840 --> 00:02:50.120 uses YouTube as an example. 61 00:02:50.199 --> 00:02:53.080 Wow, YouTube, Okay, that definitely shows scale and power. 62 00:02:53.240 --> 00:02:55.759 It really does. But here's where it gets particularly interesting 63 00:02:55.759 --> 00:02:58.719 for network folks, I think. Okay, the book emphasizes Python's 64 00:02:58.719 --> 00:03:02.280 strength in scripting and acting as like a glue. 65 00:03:02.360 --> 00:03:03.520 Glue okay, explain that. 66 00:03:03.879 --> 00:03:07.400 Well. It means it's fantastic for quickly automating tasks, sure, 67 00:03:07.759 --> 00:03:11.599 but also for connecting different existing systems or components together. 68 00:03:11.800 --> 00:03:14.439 Ah. I see, so not just building things from scratch, 69 00:03:14.560 --> 00:03:18.479 but making different tools or platforms talk to each other exactly. 70 00:03:18.520 --> 00:03:20.879 And for someone maybe just starting out with network automation, 71 00:03:20.960 --> 00:03:23.039 that flexibility is a huge plus. 72 00:03:23.280 --> 00:03:26.879 Yeah, that makes sense. Let's engineer start small, right, automate 73 00:03:26.919 --> 00:03:28.479 maybe one repetitive. 74 00:03:27.919 --> 00:03:29.479 Task like updating VLANs or. 75 00:03:29.479 --> 00:03:32.120 Something, right, and then gradually build up to more complex 76 00:03:32.159 --> 00:03:34.599 stuff as they get more comfortable as their needs grow. 77 00:03:35.000 --> 00:03:37.879 It's a very uh, practical, on ramp. 78 00:03:37.759 --> 00:03:40.000 Step by step approach. Yeah. Okay, so let's get into 79 00:03:40.000 --> 00:03:44.479 the nitty gritty actually talking to network devices a core interaction. Yeah. 80 00:03:44.719 --> 00:03:48.599 The book points to a pretty big shift around twenty 81 00:03:48.599 --> 00:03:54.120 fourteen moving away from purely manual CLI management the old way, 82 00:03:54.199 --> 00:03:55.919 towards using programmatic APIs. 83 00:03:56.080 --> 00:03:59.159 That was a key turning point. Definitely, before APIs got 84 00:03:59.159 --> 00:04:03.080 really common, it was just typing commands manually into terminal windows. 85 00:04:03.280 --> 00:04:06.039 So much typing, Yeah, very hands on one device at 86 00:04:06.080 --> 00:04:08.360 a time, tedious, And. 87 00:04:08.280 --> 00:04:12.400 As networks just got bigger or complex, that manual way 88 00:04:13.039 --> 00:04:16.040 it just couldn't scale. Could it speed efficiency? 89 00:04:16.240 --> 00:04:19.000 No way. The book even suggests it was becoming a 90 00:04:19.240 --> 00:04:22.800 terrible waste of engineering talent just doing those repetitive CLI 91 00:04:22.959 --> 00:04:23.920 tasks over and over. 92 00:04:24.120 --> 00:04:24.720 I could see that. 93 00:04:25.040 --> 00:04:28.120 And you know, while we still use the CLI sometimes 94 00:04:28.160 --> 00:04:30.800 maybe for initial setup or some tricky troubleshooting. 95 00:04:30.839 --> 00:04:32.000 Sure, it's not gone entirely. 96 00:04:32.199 --> 00:04:35.279 No, but the industry realized we needed ways for machines 97 00:04:35.279 --> 00:04:39.000 to talk to machines effectively for automation, and that's where 98 00:04:39.040 --> 00:04:40.560 APIs really took off. 99 00:04:40.600 --> 00:04:43.800 The book acknowledges. And this is important that we still 100 00:04:43.839 --> 00:04:47.800 need to interact with older, you know, legacy devices sometimes 101 00:04:47.920 --> 00:04:51.040 the ones that don't have those shiny modern APIs. 102 00:04:50.600 --> 00:04:52.959 Right, the reality of most networks, you've got a mix 103 00:04:53.000 --> 00:04:53.720 of old and new. 104 00:04:53.920 --> 00:04:56.759 So for those older boxes, things like telnet and SSH 105 00:04:56.879 --> 00:04:59.680 are still relevant for that basic, low level interaction. 106 00:05:00.319 --> 00:05:02.959 The book even gives a simple example, doesn't it, using 107 00:05:03.000 --> 00:05:06.600 Telnet to connect to a device at one ninety two 108 00:05:06.639 --> 00:05:08.480 point one sixty eight point two point five one. 109 00:05:08.480 --> 00:05:11.439 Yeah, user named Cisco password Cisco. Just a basic illustration 110 00:05:11.519 --> 00:05:12.240 of connectivity. 111 00:05:12.480 --> 00:05:16.920 But crucial point Telnet is not secure. Everything's in plaintext. 112 00:05:17.240 --> 00:05:18.560 Big security risk there. 113 00:05:18.639 --> 00:05:22.399 Absolutely, That's why SSH is the standard now encrypted connection. 114 00:05:22.759 --> 00:05:26.879 And Python has some really good tools for handling SSH programmatically, 115 00:05:26.959 --> 00:05:27.160 and the. 116 00:05:27.120 --> 00:05:31.600 Book introduces peramico as like the foundational Python library. 117 00:05:31.160 --> 00:05:35.079 For this paramco. Yeah, it handles the low level SSH 118 00:05:35.160 --> 00:05:36.040 protocol stuff. 119 00:05:36.120 --> 00:05:39.079 It shows a basic code snippet for making an SSH 120 00:05:39.160 --> 00:05:43.399 connection with Peramico takes care of the encryption, authentication, all 121 00:05:43.439 --> 00:05:44.959 that underlying complexity for you. 122 00:05:45.040 --> 00:05:48.519 Think of peramiico as the engine, right, providing that secure 123 00:05:48.560 --> 00:05:52.120 communication channel, giving you quite fine green control if you need. 124 00:05:52.000 --> 00:05:54.600 It, right, and then what's cool is how other libraries 125 00:05:54.600 --> 00:05:55.439 build on top of that. 126 00:05:55.399 --> 00:05:59.439 Engine exactly, which leads us to netmico. The book talks 127 00:05:59.439 --> 00:06:02.319 about netmeik being built using Peramco. 128 00:06:01.920 --> 00:06:03.639 So netmko uses Peramco. 129 00:06:03.279 --> 00:06:04.160 Underneath pretty much. 130 00:06:04.240 --> 00:06:04.439 Yeah. 131 00:06:04.680 --> 00:06:07.800 Netmiko essentially puts a more user friendly layer on top, 132 00:06:08.120 --> 00:06:11.680 specifically designed for network engineers interacting with network gear. It 133 00:06:11.759 --> 00:06:13.079 simplifies common. 134 00:06:12.800 --> 00:06:15.399 Tasks, ah, okay, so it makes it easier to just 135 00:06:15.560 --> 00:06:18.240 like send a command and get the output back from say, yes, 136 00:06:18.319 --> 00:06:19.600 Cisco router exactly. 137 00:06:19.639 --> 00:06:21.879 Netmko is built for that. It knows how to handle 138 00:06:21.959 --> 00:06:27.720 the prompts and peculiarities of different network operating systems Ciscoios Junior, 139 00:06:27.759 --> 00:06:31.120 per Junos, Arista, EOS, lots of others. It smooths out 140 00:06:31.120 --> 00:06:32.079 those interactions. 141 00:06:32.240 --> 00:06:36.720 That sounds incredibly useful, less time fighting with raw ssh. 142 00:06:36.120 --> 00:06:40.480 Definitely, which brings us to a really really critical concept 143 00:06:40.720 --> 00:06:42.759 in automation, idempotency. 144 00:06:42.920 --> 00:06:45.480 Adempotency Okay, sounds important, let's break that down. 145 00:06:45.600 --> 00:06:49.319 The book emphasizes this heavily, especially when you're scripting interactions 146 00:06:49.319 --> 00:06:50.560 with network devices. 147 00:06:50.639 --> 00:06:54.319 So idempotency it means that if you run the same 148 00:06:54.360 --> 00:06:58.120 automation script multiple times, Yeah, if you have the exact 149 00:06:58.199 --> 00:07:00.639 same end result as running it just once, it shouldn't 150 00:07:00.680 --> 00:07:03.199 like keep adding the same config line over and over 151 00:07:03.519 --> 00:07:05.920 or cause weird side effects on the second or third run. 152 00:07:06.000 --> 00:07:10.519 Precisely, think about a script that configures a specific vlan. Okay, 153 00:07:10.560 --> 00:07:13.360 if it's not ideentpatan, running it twice might try to 154 00:07:13.399 --> 00:07:16.040 create the same vline again, which could cause an error 155 00:07:16.199 --> 00:07:19.680 or worse, lead to some unexpected configuration mess right. 156 00:07:19.800 --> 00:07:22.399 Definitely not what you want in your network errors and 157 00:07:22.480 --> 00:07:23.920 inconsistencies creeping in. 158 00:07:24.079 --> 00:07:27.399 Absolutely not. And the book points out that those older methods, 159 00:07:27.519 --> 00:07:30.639 the ones relying on screen scraping just reading text output 160 00:07:30.639 --> 00:07:33.560 from the CLI, yeah, they were particularly bad for this, 161 00:07:33.800 --> 00:07:37.040 not idempatent at all, usually because if the format of 162 00:07:37.079 --> 00:07:41.240 the CLA output changed just slightly, maybe after a software upgrade. 163 00:07:41.040 --> 00:07:43.920 Your script would break or misunderstand things exactly. 164 00:07:43.959 --> 00:07:49.120 It's inherently fragile trying to parse unstructured human readable. 165 00:07:48.720 --> 00:07:52.639 Text, which is a huge reason why moving towards APIs, 166 00:07:52.839 --> 00:07:55.759 which could use structure data is so much more reliable. 167 00:07:55.839 --> 00:07:59.040 That's the key reliability and efficiency. 168 00:07:59.120 --> 00:08:02.639 Perfect segue into API driven network management. The book really 169 00:08:02.680 --> 00:08:05.439 pushes this as the way forward, moving beyond that fragile 170 00:08:05.439 --> 00:08:07.839 screen scraping. So what are the main wins here? 171 00:08:08.199 --> 00:08:10.720 Well, the fundamental win, as you said, is structured data. 172 00:08:10.800 --> 00:08:14.160 APIs typically give you information back in formats like JSON 173 00:08:14.319 --> 00:08:14.879 or XML. 174 00:08:15.000 --> 00:08:17.959 Okay, json and XML computer friendly formats. 175 00:08:18.040 --> 00:08:20.680 Right, So instead of your Python script trying to guess 176 00:08:20.680 --> 00:08:23.160 where the important info is in a block of CLI text, 177 00:08:23.240 --> 00:08:26.839 which can change, it gets a neat, predictable data structure. 178 00:08:27.000 --> 00:08:30.040 It knows exactly where to find the interface status or 179 00:08:30.199 --> 00:08:33.480 the routing table entries. It's like getting data from a 180 00:08:33.519 --> 00:08:37.320 well organized spreadsheet versus trying to read handwritten notes. Much 181 00:08:37.320 --> 00:08:37.960 more reliable. 182 00:08:38.120 --> 00:08:40.639 Makes sense, and the book gets into some specifics which 183 00:08:40.679 --> 00:08:43.240 is really helpful. It covers a range of vendor APIs. 184 00:08:43.840 --> 00:08:47.600 Let's start with Cisco. They mentioned NXAPI for the Nexus switches. 185 00:08:47.799 --> 00:08:48.440 How's that work? 186 00:08:48.559 --> 00:08:51.960 So Cisco NXAPI especially lets you talk to Nexus switches 187 00:08:52.080 --> 00:08:56.000 using standard web protocols, mostly HTTP or hdtps. 188 00:08:55.559 --> 00:08:57.080 Like talking to a website. 189 00:08:56.720 --> 00:09:01.279 Kind of yeah. The book specifically mentions sending HI posteam 190 00:09:01.320 --> 00:09:05.279 request to a particular URL on the switch ins to 191 00:09:05.440 --> 00:09:07.039 execute CLI commands. 192 00:09:07.279 --> 00:09:09.840 Ah, so you can still run CLI commands, but via 193 00:09:09.879 --> 00:09:11.279 an API call exactly. 194 00:09:11.360 --> 00:09:13.960 You package the command and the PSA requests, send it off, 195 00:09:14.039 --> 00:09:16.720 and you get the output back, often structured as JSON. 196 00:09:16.799 --> 00:09:18.799 It's like a programmatic interface to the CLI. 197 00:09:18.960 --> 00:09:22.080 That sounds way better than SSH screen scraping. And the 198 00:09:22.080 --> 00:09:25.519 book also mentioned Cisco provides a sandbox environment for NXAPI. 199 00:09:25.799 --> 00:09:28.159 Yeah, that's super helpful. It means you can play around, 200 00:09:28.240 --> 00:09:31.200 test your API calls, figure out the request and response. 201 00:09:30.879 --> 00:09:34.440 Formats without touching your live production network exactly. 202 00:09:34.480 --> 00:09:37.279 Reduces risk, speeds up development, great for learning. 203 00:09:37.519 --> 00:09:41.080 What about other Cisco stuff? Netconf and YANG keep popping 204 00:09:41.159 --> 00:09:42.759 up in modern networking. 205 00:09:42.360 --> 00:09:46.320 Discussions, right, So, netconf that's the network configuration protocol. It's 206 00:09:46.320 --> 00:09:50.000 a standardized protocol defined in RFC's for managing network devices. 207 00:09:50.039 --> 00:09:51.279 It's a bandardize okay, yeah. 208 00:09:51.320 --> 00:09:54.480 It usually runs over a secure channel like SSH and 209 00:09:54.600 --> 00:09:58.279 uses XML to encode the configuration data and commands. 210 00:09:58.000 --> 00:10:00.679 XML for the data format. ANG. 211 00:10:00.960 --> 00:10:04.799 YANG is the data modeling language. Think of YANG as 212 00:10:05.039 --> 00:10:09.120 the blueprint or the schema for a network device's configuration 213 00:10:09.279 --> 00:10:10.519 and its operational state. 214 00:10:11.080 --> 00:10:13.320 So YANG defines what you can configure. 215 00:10:12.919 --> 00:10:16.799 And monitor precisely. It describes the data structures, the available options, 216 00:10:16.840 --> 00:10:20.639 the data types. It brings structure and predictability to network 217 00:10:20.679 --> 00:10:24.039 device data. The book even points to the Yang gethub 218 00:10:24.080 --> 00:10:26.200 project where you can find loads of these models. 219 00:10:26.279 --> 00:10:28.320 Okay, so YANG is the model, that kind off is 220 00:10:28.320 --> 00:10:31.480 the protocol to transfer configurations based on that model, often 221 00:10:31.559 --> 00:10:33.399 using XML over ssh. 222 00:10:33.399 --> 00:10:33.720 Got it. 223 00:10:33.799 --> 00:10:34.600 That's a good summary. 224 00:10:34.840 --> 00:10:39.720 And then there's Cisco ACI application centric infrastructure that takes 225 00:10:39.799 --> 00:10:42.320 a different approach again right, more controller based. 226 00:10:42.519 --> 00:10:45.279 Yeah. ACI is all about that central controller managing the 227 00:10:45.399 --> 00:10:48.440 entire network fabric. The book explains that you interact with 228 00:10:48.519 --> 00:10:51.759 ACI primarily through RESTful APIs. 229 00:10:51.519 --> 00:10:54.879 Rest API, so using standard HTTP. 230 00:10:54.519 --> 00:10:58.120 Methods exactly, things like get to fetch information, posts to 231 00:10:58.200 --> 00:11:02.559 create or update configurations, or policies, delete to remove things. It's 232 00:11:02.600 --> 00:11:05.879 all done by talking to the ACI controllers API. Very 233 00:11:05.919 --> 00:11:06.759 API centric. 234 00:11:06.960 --> 00:11:09.679 Like ordering food online. You mentioned get the menu, post 235 00:11:09.720 --> 00:11:10.080 the order. 236 00:11:10.159 --> 00:11:12.919 Yeah, that kind of idea standard web actions applied to 237 00:11:13.120 --> 00:11:14.000 network management. 238 00:11:14.120 --> 00:11:17.559 Okay. Moving across the aisle to Juniper Networks, the book 239 00:11:17.559 --> 00:11:20.080 covers their approach to including netcom right. 240 00:11:20.399 --> 00:11:24.320 Similar to Cisco, Juniper supports netcom over ssh. The book 241 00:11:24.360 --> 00:11:28.000 mentions using a specific Python library called unclient for this 242 00:11:28.200 --> 00:11:31.000 and client okay, yeah, and it shows examples of using 243 00:11:31.000 --> 00:11:34.519 a client to connect your Geniper devices, retrieve configuration sections, 244 00:11:34.559 --> 00:11:35.519 and even make changes. 245 00:11:35.720 --> 00:11:39.159 And Juniper also has its own Python library, doesn't it pie. 246 00:11:38.840 --> 00:11:43.080 Z it does. The book introduces PIEZ, which stands for 247 00:11:43.159 --> 00:11:43.799 Python Easy. 248 00:11:43.840 --> 00:11:44.720 I think makes sense. 249 00:11:44.759 --> 00:11:48.200 It's Juniper's library designed to simplify interacting with Juno's devices. 250 00:11:48.639 --> 00:11:51.960 It provides a higher level abstraction over NETCN, making common 251 00:11:52.000 --> 00:11:53.799 tasks easier. 252 00:11:53.480 --> 00:11:57.919 So potentially less code to write for standard operations compared 253 00:11:57.960 --> 00:11:59.679 to using client directly. 254 00:12:00.000 --> 00:12:02.159 It seems to be the idea. Yeah, more tailored to 255 00:12:02.240 --> 00:12:03.200 Juniper workflows. 256 00:12:03.519 --> 00:12:06.360 Okay, what about Arista? They have EAPI yep. 257 00:12:06.399 --> 00:12:10.639 Arista's EAPI also relies on web protocols, typically Jason RPC 258 00:12:10.799 --> 00:12:14.480 over HTDPS. The book mentions configuring connection details in a 259 00:12:14.480 --> 00:12:17.600 file dot epi dot com. You can pick file and 260 00:12:17.600 --> 00:12:20.840 then using the piple Python library to send commands and 261 00:12:20.960 --> 00:12:23.720 get structured data back. It even shows an example of 262 00:12:23.840 --> 00:12:25.440 creating vlands using pioppy. 263 00:12:25.600 --> 00:12:29.240 So another vendor, another API, another Python library to help. 264 00:12:29.320 --> 00:12:31.559 Pretty much the pattern and we shouldn't forget vos the 265 00:12:31.600 --> 00:12:32.360 open source option. 266 00:12:32.440 --> 00:12:33.559 Oh the book is it a mention too? 267 00:12:33.639 --> 00:12:36.480 Yeah. Briefly mentions a library called vingient for interacting with 268 00:12:36.559 --> 00:12:38.039 vostavisis programmatically. 269 00:12:38.360 --> 00:12:41.120 So the key thing here for you, the learner, is 270 00:12:41.559 --> 00:12:46.440 seeing this pattern right. Vendors provide APIs, maybe net conframe, 271 00:12:46.600 --> 00:12:51.879 maybe rest, maybe something pustom like NXAPI or eapi, and 272 00:12:51.919 --> 00:12:55.000 then there are often Python libraries, either from the vendor 273 00:12:55.120 --> 00:12:59.480 or the community, to make using those APIs easier exactly. 274 00:12:59.519 --> 00:13:02.159 And while we focused on vendor specifics, the book does 275 00:13:02.200 --> 00:13:06.000 also highlight that there are vendor neutral libraries and approaches too. 276 00:13:06.399 --> 00:13:09.039 That's important things not tied to just one company's way 277 00:13:09.080 --> 00:13:09.759 of doing things. 278 00:13:09.879 --> 00:13:12.639 Right. They might sometimes lag a bit behind on the 279 00:13:12.720 --> 00:13:16.279 absolute bleeding edge features compared to a vendor's own library, sure, 280 00:13:16.399 --> 00:13:18.600 but they offer the benefit of consistency if you have 281 00:13:18.639 --> 00:13:21.840 a multi vendor network. Plus, many are open source so 282 00:13:21.879 --> 00:13:23.759 you can see how they work even contribute. 283 00:13:23.879 --> 00:13:26.759 Good point. Okay, so we've covered Python talking to individual 284 00:13:26.799 --> 00:13:30.720 devices via CLIs and APIs. What about orchestrating tasks across 285 00:13:30.799 --> 00:13:33.200 many devices, managing the whole infrastructure? 286 00:13:33.240 --> 00:13:36.720 Ah, now we're getting into network automation frameworks and the 287 00:13:36.720 --> 00:13:38.759 big one the book highlights is ansable. 288 00:13:38.879 --> 00:13:41.440 Ansable. Yeah, you hear that name a lot, definitely. 289 00:13:41.600 --> 00:13:44.279 The book describes it as a Python based framework, But 290 00:13:44.440 --> 00:13:46.480 what makes it really stand out is it's focus on 291 00:13:46.519 --> 00:13:47.320 being declarative. 292 00:13:47.519 --> 00:13:49.559 Declarative okay, what does that mean? In practice? 293 00:13:49.639 --> 00:13:52.600 It means instead of writing a script that lets every 294 00:13:52.600 --> 00:13:55.519 single command to run and sequence step one, step two. 295 00:13:55.320 --> 00:13:57.360 Step three, the imperative way, right. 296 00:13:57.759 --> 00:14:00.600 With antsable, you mostly just declare the desire end state 297 00:14:00.639 --> 00:14:02.919 you want. You say, I want this VLAN to exist, 298 00:14:03.039 --> 00:14:05.720 or I want this NTP server configure, and. 299 00:14:05.759 --> 00:14:08.080 Ansible figures out how to make that happen, checking if 300 00:14:08.080 --> 00:14:10.240 the villain already exists, adding it if it doesn't. 301 00:14:10.360 --> 00:14:13.120 Exactly, it checks the current state. It only makes the 302 00:14:13.159 --> 00:14:16.600 necessary changes to reach the desired state you declared. That's 303 00:14:16.639 --> 00:14:20.559 the power of declarative automation. It's less about how and 304 00:14:20.679 --> 00:14:21.279 more about what. 305 00:14:21.600 --> 00:14:24.799 That sounds much more robust and potentially idempatant by nature. 306 00:14:24.639 --> 00:14:26.919 It often is. Yes, yeah, that's a major goal. So 307 00:14:27.039 --> 00:14:30.399 the book explains Ansible uses inventory files to know which 308 00:14:30.440 --> 00:14:33.720 devices to manage. It shows an example using the IONI 309 00:14:33.879 --> 00:14:38.000 format like iOS devices followed by host names IOSV one, 310 00:14:38.440 --> 00:14:39.399 iosv two. 311 00:14:39.480 --> 00:14:42.519 So just a list of your network here pretty much. 312 00:14:42.600 --> 00:14:45.240 And then you write playbooks in YAMO format YAML. 313 00:14:45.600 --> 00:14:47.399 Okay, that structured text format. 314 00:14:47.600 --> 00:14:51.840 Yeah. Playbooks define the automation tasks, and inside playbooks you 315 00:14:51.960 --> 00:14:53.159 use Ansible. 316 00:14:52.720 --> 00:14:55.600 Modules modules like pre built functions Kina. 317 00:14:55.720 --> 00:14:58.799 Yeah, they're like the tools Ansimble uses to interact with systems. 318 00:14:59.240 --> 00:15:01.799 The book gives to Cycle as an example, a module 319 00:15:01.879 --> 00:15:06.639 specifically for managing access control lists on Cisco and XOS devices. 320 00:15:06.879 --> 00:15:11.879 So there are modules for configuring interfaces, VLANs, routing protocols. 321 00:15:11.320 --> 00:15:14.720 All that stuff, loads of them for network devices, servers, 322 00:15:14.720 --> 00:15:18.559 cloud platforms, and playbooks organize these modules into tasks. You 323 00:15:18.559 --> 00:15:21.879 can also have handlers, which are tasks triggered by changes 324 00:15:22.279 --> 00:15:25.279 variables to customize things may be stored in hostars per device, 325 00:15:25.600 --> 00:15:28.399 and loops to apply tasks to multiple devices easily. 326 00:15:28.480 --> 00:15:31.639 That looping sounds essential for scale configure the same setting 327 00:15:31.679 --> 00:15:33.519 on hundreds of switches exactly. 328 00:15:33.840 --> 00:15:36.679 And one more key ansiable feature of the book mentions 329 00:15:36.759 --> 00:15:38.720 is templating using ginga. 330 00:15:38.559 --> 00:15:40.240 Ginga templating how's that used? 331 00:15:40.519 --> 00:15:44.759 It lets you create configuration templates with placeholders for variables. 332 00:15:45.039 --> 00:15:47.519 So you can have a standard interface config template and 333 00:15:47.559 --> 00:15:50.360 then fill in the specific IP address or description for 334 00:15:50.399 --> 00:15:53.200 each device using variables from your inventory. 335 00:15:53.320 --> 00:15:57.600 Ah, So you generate device specific configs from a common template. 336 00:15:57.759 --> 00:16:02.559 Very efficient, very keeps things consistent but flexible. Okay, switching 337 00:16:02.600 --> 00:16:05.559 gear slightly but still relevant to modern workflows. 338 00:16:06.039 --> 00:16:10.799 Docker containers containers big topic in software development. How does 339 00:16:10.799 --> 00:16:12.000 it fit into networking? 340 00:16:12.320 --> 00:16:14.639 Well? The book points out Docker has become the standard 341 00:16:14.720 --> 00:16:18.559 for packaging and deploying applications, and those benefits apply to 342 00:16:18.679 --> 00:16:20.600 network related tools and services too. 343 00:16:21.200 --> 00:16:24.279 Like packaging a monitoring tool or maybe even a small 344 00:16:24.320 --> 00:16:25.039 network service. 345 00:16:25.039 --> 00:16:29.039 You build exactly. You package the application and all its dependencies, libraries, 346 00:16:29.120 --> 00:16:31.720 run time, everything into a container. Think of it as 347 00:16:31.759 --> 00:16:33.759 a self contained little box for your software. 348 00:16:33.799 --> 00:16:35.960 And the benefits the book highlights are. 349 00:16:35.960 --> 00:16:38.720 Consistency is a big one. It runs the same way 350 00:16:38.759 --> 00:16:41.000 on your laptop as it does on a server or 351 00:16:41.000 --> 00:16:44.759 in the cloud, Isolation, containers don't interfere with each other, 352 00:16:45.200 --> 00:16:47.080 and easier deployment you just ship and run. 353 00:16:47.120 --> 00:16:50.159 The container image makes sense standardized units of software. 354 00:16:50.399 --> 00:16:54.000 The book mentions Docker files that's the recipe for building 355 00:16:54.039 --> 00:16:57.960 a container image, and Docker composed for managing applications made 356 00:16:58.000 --> 00:17:00.480 up of multiple containers that need to work together right. 357 00:17:00.360 --> 00:17:02.480 Like a web app with a database, or. 358 00:17:02.440 --> 00:17:05.880 Maybe a network monitoring stack with different components. It also 359 00:17:05.920 --> 00:17:09.480 touches briefly on container networking, how containers talk to each 360 00:17:09.519 --> 00:17:13.079 other and the outside world using concepts like bridge or 361 00:17:13.160 --> 00:17:13.960 host networking. 362 00:17:14.400 --> 00:17:19.359 Okay, and specifically for network labs. The book mentions container lab. 363 00:17:19.559 --> 00:17:22.240 Yeah, this sounds really cool. Container lab is a tool 364 00:17:22.279 --> 00:17:24.799 specifically designed to make it easier to spin up lab 365 00:17:24.920 --> 00:17:28.400 environments using containerized network operating SYSTEMSS. 366 00:17:28.680 --> 00:17:32.200 So you can run like a virtual Cisco or Arista 367 00:17:32.319 --> 00:17:35.599 or Juniper device inside a container for testing exactly. 368 00:17:35.640 --> 00:17:38.960 It mentions sr linux as an example. It simplifies building 369 00:17:39.000 --> 00:17:43.759 and tearing down virtual network topologies for practice, testing, automation scripts, 370 00:17:44.160 --> 00:17:45.039 learning new features. 371 00:17:45.079 --> 00:17:48.519 That sounds incredibly useful for network engineers. Way lighter than 372 00:17:48.559 --> 00:17:50.039 full VMS maybe potentially. 373 00:17:50.119 --> 00:17:55.160 Yeah. Okay, so we've configured devices, automated tasks, packaged tools. 374 00:17:55.599 --> 00:17:58.279 What about actually monitoring the network? Keeping an eye on 375 00:17:58.319 --> 00:17:59.599 things crucial aspect? 376 00:18:00.079 --> 00:18:03.079 The book dedicates a good chunk to network monitoring with Python. 377 00:18:03.240 --> 00:18:04.039 Where does it start? 378 00:18:04.279 --> 00:18:07.839 SNMP starts with the classic SNMP, the Simple Network Management 379 00:18:07.839 --> 00:18:11.440 Protocol been around forever, still widely used the work, but 380 00:18:11.720 --> 00:18:14.440 as the book notes, it has limitations. It can put 381 00:18:14.440 --> 00:18:16.799 a load on the device CPU, the agent running there, 382 00:18:17.279 --> 00:18:20.720 and you need to know the specific OIDs, those numeric 383 00:18:20.799 --> 00:18:22.319 addresses for pieces of data. 384 00:18:22.400 --> 00:18:25.680 The MIBs and OIDs Yeah, can be complex. 385 00:18:25.319 --> 00:18:27.680 Right, You need the right oid to ask for, say, 386 00:18:28.160 --> 00:18:31.720 interface traffic counters or CPU load. The book does show 387 00:18:31.720 --> 00:18:34.200 how Python can be used to send SMMP queries and 388 00:18:34.240 --> 00:18:38.559 get data back, though even shows restricting SNMP access via 389 00:18:38.640 --> 00:18:39.680 an ACL, So. 390 00:18:40.079 --> 00:18:43.200 Still relevant, but maybe not the only answer. How about 391 00:18:43.279 --> 00:18:44.920 visualizing the data you collect? 392 00:18:45.039 --> 00:18:49.160 Good question? Making sense of numbers? The book introduces Python 393 00:18:49.200 --> 00:18:52.799 libraries like mattplot lib and pigol for creating charts and graphs. 394 00:18:53.039 --> 00:18:55.599 Matt plot lob is very common in the data science world, 395 00:18:55.960 --> 00:18:57.000 Pigole maybe less so. 396 00:18:57.279 --> 00:19:00.920 Mattplotlib for static charts, pigol maybe more, or for interactive 397 00:19:00.960 --> 00:19:04.960 web based charts. The book shows examples of creating line graphs, 398 00:19:05.200 --> 00:19:09.359 maybe tracking bandwidth use over time, visualizing trends. 399 00:19:09.039 --> 00:19:11.920 Seeing spikes or drops is much easier on a graph 400 00:19:11.960 --> 00:19:13.640 than in a table of numbers. 401 00:19:13.319 --> 00:19:16.880