Speaker 1: The world of network engineering is moving incredibly fast, isn't it.
Speaker 2: It really is. It feels like the ground is constantly
Speaker 2: shifting under our feet.
Speaker 1: Yeah. Just yesterday we were all, you know, neck deep
Speaker 1: in command line.
Speaker 2: Interfaces, clies everywhere exactly.
Speaker 1: Yeah, and now it's all about API's automation.
Speaker 2: It's a lot keeping up with the complexity that constant
Speaker 2: push for automation. Yeah, it can feel like a real
Speaker 2: uphill battle sometimes.
Speaker 1: But today we're trying cut through some of that noise.
Speaker 1: We want to give you, our listener, a focused look
Speaker 1: at a tool that's become well, absolutely essential in this landscape.
Speaker 2: It's fascinating this shift, you know, moving away from manually
Speaker 2: poking each device, yeah, device by device, towards a world
Speaker 2: where code, actual software defines and controls the infrastructure.
Speaker 1: The potential there for efficiency, for scale, it's just huge,
Speaker 1: it is.
Speaker 2: But it definitely means network engineers need to add some
Speaker 2: new skills, some new tools to their belt.
Speaker 1: Absolutely. And the real star the focus of our deep
Speaker 1: die today is Python.
Speaker 2: Ah.
Speaker 1: Python, Yes, we're looking at its crucial role in modern
Speaker 1: network engineering. And look, this isn't just our opinion. Now
Speaker 1: we've drawn our insights from a really solid resource, Mastering
Speaker 1: Python Networking, fourth edition.
Speaker 2: That's a comprehensive book, very practical.
Speaker 1: It really is. Think of this deep dive as your
Speaker 1: shortcut to understanding the key stuff from that book. It
Speaker 1: takes a very hands on approach, you know, using Python
Speaker 1: for all sorts of network.
Speaker 2: Tasks, and it covers a massive amount of ground, doesn't it.
Speaker 2: Looking at the big picture. It goes from like basic device.
Speaker 1: Interactions, fundamental all the way up.
Speaker 2: To advanced automation, even touching on network security with Python.
Speaker 1: It really shows how central Python has become. It's everywhere
Speaker 1: in networking, right across the board, and that's why we're
Speaker 1: here for you, the learner. Our goal today is to
Speaker 1: boil down those core concepts, show you the practical waves
Speaker 1: Python is actually being used right now. We want to
Speaker 1: give you those you know, aha.
Speaker 2: Moment, the actionable stuff exactly.
Speaker 1: Knowledge you can actually use without getting totally bogged down
Speaker 1: in every single tiny detail. So ready to jump in.
Speaker 2: Let's do it. But it raises that first question, maybe
Speaker 2: the most fundamental one, why Python, you know, with everything changing,
Speaker 2: what makes it the go to language for network engineers?
Speaker 1: That's the perfect place to start, and our source the
Speaker 1: book tackles this head on. It describes Python as a
Speaker 1: full spectrum.
Speaker 2: Language fall spectrum. I like that.
Speaker 1: Think about it. On one end, it's super easy to
Speaker 1: get started with, I mean the classic print Hello.
Speaker 2: World, everyone's first program.
Speaker 1: Right, pretty much, it's like the entry point.
Speaker 2: Yeah.
Speaker 1: But then on the other end of that spectrum, yeah,
Speaker 1: Python power some massive, incredibly complex systems. The book actually
Speaker 1: uses YouTube as an example.
Speaker 2: Wow, YouTube, Okay, that definitely shows scale and power.
Speaker 1: It really does. But here's where it gets particularly interesting
Speaker 1: for network folks, I think. Okay, the book emphasizes Python's
Speaker 1: strength in scripting and acting as like a glue.
Speaker 2: Glue okay, explain that.
Speaker 1: Well. It means it's fantastic for quickly automating tasks, sure,
Speaker 1: but also for connecting different existing systems or components together.
Speaker 2: Ah. I see, so not just building things from scratch,
Speaker 2: but making different tools or platforms talk to each other exactly.
Speaker 1: And for someone maybe just starting out with network automation,
Speaker 1: that flexibility is a huge plus.
Speaker 2: Yeah, that makes sense. Let's engineer start small, right, automate
Speaker 2: maybe one repetitive.
Speaker 1: Task like updating VLANs or.
Speaker 2: Something, right, and then gradually build up to more complex
Speaker 2: stuff as they get more comfortable as their needs grow.
Speaker 2: It's a very uh, practical, on ramp.
Speaker 1: Step by step approach. Yeah. Okay, so let's get into
Speaker 1: the nitty gritty actually talking to network devices a core interaction. Yeah.
Speaker 1: The book points to a pretty big shift around twenty
Speaker 1: fourteen moving away from purely manual CLI management the old way,
Speaker 1: towards using programmatic APIs.
Speaker 2: That was a key turning point. Definitely, before APIs got
Speaker 2: really common, it was just typing commands manually into terminal windows.
Speaker 2: So much typing, Yeah, very hands on one device at
Speaker 2: a time, tedious, And.
Speaker 1: As networks just got bigger or complex, that manual way
Speaker 1: it just couldn't scale. Could it speed efficiency?
Speaker 2: No way. The book even suggests it was becoming a
Speaker 2: terrible waste of engineering talent just doing those repetitive CLI
Speaker 2: tasks over and over.
Speaker 1: I could see that.
Speaker 2: And you know, while we still use the CLI sometimes
Speaker 2: maybe for initial setup or some tricky troubleshooting.
Speaker 1: Sure, it's not gone entirely.
Speaker 2: No, but the industry realized we needed ways for machines
Speaker 2: to talk to machines effectively for automation, and that's where
Speaker 2: APIs really took off.
Speaker 1: The book acknowledges. And this is important that we still
Speaker 1: need to interact with older, you know, legacy devices sometimes
Speaker 1: the ones that don't have those shiny modern APIs.
Speaker 2: Right, the reality of most networks, you've got a mix
Speaker 2: of old and new.
Speaker 1: So for those older boxes, things like telnet and SSH
Speaker 1: are still relevant for that basic, low level interaction.
Speaker 2: The book even gives a simple example, doesn't it, using
Speaker 2: Telnet to connect to a device at one ninety two
Speaker 2: point one sixty eight point two point five one.
Speaker 1: Yeah, user named Cisco password Cisco. Just a basic illustration
Speaker 1: of connectivity.
Speaker 2: But crucial point Telnet is not secure. Everything's in plaintext.
Speaker 1: Big security risk there.
Speaker 2: Absolutely, That's why SSH is the standard now encrypted connection.
Speaker 2: And Python has some really good tools for handling SSH programmatically,
Speaker 2: and the.
Speaker 1: Book introduces peramico as like the foundational Python library.
Speaker 2: For this paramco. Yeah, it handles the low level SSH
Speaker 2: protocol stuff.
Speaker 1: It shows a basic code snippet for making an SSH
Speaker 1: connection with Peramico takes care of the encryption, authentication, all
Speaker 1: that underlying complexity for you.
Speaker 2: Think of peramiico as the engine, right, providing that secure
Speaker 2: communication channel, giving you quite fine green control if you need.
Speaker 1: It, right, and then what's cool is how other libraries
Speaker 1: build on top of that.
Speaker 2: Engine exactly, which leads us to netmico. The book talks
Speaker 2: about netmeik being built using Peramco.
Speaker 1: So netmko uses Peramco.
Speaker 2: Underneath pretty much.
Speaker 1: Yeah.
Speaker 2: Netmiko essentially puts a more user friendly layer on top,
Speaker 2: specifically designed for network engineers interacting with network gear. It
Speaker 2: simplifies common.
Speaker 1: Tasks, ah, okay, so it makes it easier to just
Speaker 1: like send a command and get the output back from say, yes,
Speaker 1: Cisco router exactly.
Speaker 2: Netmko is built for that. It knows how to handle
Speaker 2: the prompts and peculiarities of different network operating systems Ciscoios Junior,
Speaker 2: per Junos, Arista, EOS, lots of others. It smooths out
Speaker 2: those interactions.
Speaker 1: That sounds incredibly useful, less time fighting with raw ssh.
Speaker 2: Definitely, which brings us to a really really critical concept
Speaker 2: in automation, idempotency.
Speaker 1: Adempotency Okay, sounds important, let's break that down.
Speaker 2: The book emphasizes this heavily, especially when you're scripting interactions
Speaker 2: with network devices.
Speaker 1: So idempotency it means that if you run the same
Speaker 1: automation script multiple times, Yeah, if you have the exact
Speaker 1: same end result as running it just once, it shouldn't
Speaker 1: like keep adding the same config line over and over
Speaker 1: or cause weird side effects on the second or third run.
Speaker 2: Precisely, think about a script that configures a specific vlan. Okay,
Speaker 2: if it's not ideentpatan, running it twice might try to
Speaker 2: create the same vline again, which could cause an error
Speaker 2: or worse, lead to some unexpected configuration mess right.
Speaker 1: Definitely not what you want in your network errors and
Speaker 1: inconsistencies creeping in.
Speaker 2: Absolutely not. And the book points out that those older methods,
Speaker 2: the ones relying on screen scraping just reading text output
Speaker 2: from the CLI, yeah, they were particularly bad for this,
Speaker 2: not idempatent at all, usually because if the format of
Speaker 2: the CLA output changed just slightly, maybe after a software upgrade.
Speaker 1: Your script would break or misunderstand things exactly.
Speaker 2: It's inherently fragile trying to parse unstructured human readable.
Speaker 1: Text, which is a huge reason why moving towards APIs,
Speaker 1: which could use structure data is so much more reliable.
Speaker 2: That's the key reliability and efficiency.
Speaker 1: Perfect segue into API driven network management. The book really
Speaker 1: pushes this as the way forward, moving beyond that fragile
Speaker 1: screen scraping. So what are the main wins here?
Speaker 2: Well, the fundamental win, as you said, is structured data.
Speaker 2: APIs typically give you information back in formats like JSON
Speaker 2: or XML.
Speaker 1: Okay, json and XML computer friendly formats.
Speaker 2: Right, So instead of your Python script trying to guess
Speaker 2: where the important info is in a block of CLI text,
Speaker 2: which can change, it gets a neat, predictable data structure.
Speaker 2: It knows exactly where to find the interface status or
Speaker 2: the routing table entries. It's like getting data from a
Speaker 2: well organized spreadsheet versus trying to read handwritten notes. Much
Speaker 2: more reliable.
Speaker 1: Makes sense, and the book gets into some specifics which
Speaker 1: is really helpful. It covers a range of vendor APIs.
Speaker 1: Let's start with Cisco. They mentioned NXAPI for the Nexus switches.
Speaker 1: How's that work?
Speaker 2: So Cisco NXAPI especially lets you talk to Nexus switches
Speaker 2: using standard web protocols, mostly HTTP or hdtps.
Speaker 1: Like talking to a website.
Speaker 2: Kind of yeah. The book specifically mentions sending HI posteam
Speaker 2: request to a particular URL on the switch ins to
Speaker 2: execute CLI commands.
Speaker 1: Ah, so you can still run CLI commands, but via
Speaker 1: an API call exactly.
Speaker 2: You package the command and the PSA requests, send it off,
Speaker 2: and you get the output back, often structured as JSON.
Speaker 2: It's like a programmatic interface to the CLI.
Speaker 1: That sounds way better than SSH screen scraping. And the
Speaker 1: book also mentioned Cisco provides a sandbox environment for NXAPI.
Speaker 2: Yeah, that's super helpful. It means you can play around,
Speaker 2: test your API calls, figure out the request and response.
Speaker 1: Formats without touching your live production network exactly.
Speaker 2: Reduces risk, speeds up development, great for learning.
Speaker 1: What about other Cisco stuff? Netconf and YANG keep popping
Speaker 1: up in modern networking.
Speaker 2: Discussions, right, So, netconf that's the network configuration protocol. It's
Speaker 2: a standardized protocol defined in RFC's for managing network devices.
Speaker 1: It's a bandardize okay, yeah.
Speaker 2: It usually runs over a secure channel like SSH and
Speaker 2: uses XML to encode the configuration data and commands.
Speaker 1: XML for the data format. ANG.
Speaker 2: YANG is the data modeling language. Think of YANG as
Speaker 2: the blueprint or the schema for a network device's configuration
Speaker 2: and its operational state.
Speaker 1: So YANG defines what you can configure.
Speaker 2: And monitor precisely. It describes the data structures, the available options,
Speaker 2: the data types. It brings structure and predictability to network
Speaker 2: device data. The book even points to the Yang gethub
Speaker 2: project where you can find loads of these models.
Speaker 1: Okay, so YANG is the model, that kind off is
Speaker 1: the protocol to transfer configurations based on that model, often
Speaker 1: using XML over ssh.
Speaker 2: Got it.
Speaker 1: That's a good summary.
Speaker 2: And then there's Cisco ACI application centric infrastructure that takes
Speaker 2: a different approach again right, more controller based.
Speaker 1: Yeah. ACI is all about that central controller managing the
Speaker 1: entire network fabric. The book explains that you interact with
Speaker 1: ACI primarily through RESTful APIs.
Speaker 2: Rest API, so using standard HTTP.
Speaker 1: Methods exactly, things like get to fetch information, posts to
Speaker 1: create or update configurations, or policies, delete to remove things. It's
Speaker 1: all done by talking to the ACI controllers API. Very
Speaker 1: API centric.
Speaker 2: Like ordering food online. You mentioned get the menu, post
Speaker 2: the order.
Speaker 1: Yeah, that kind of idea standard web actions applied to
Speaker 1: network management.
Speaker 2: Okay. Moving across the aisle to Juniper Networks, the book
Speaker 2: covers their approach to including netcom right.
Speaker 1: Similar to Cisco, Juniper supports netcom over ssh. The book
Speaker 1: mentions using a specific Python library called unclient for this
Speaker 1: and client okay, yeah, and it shows examples of using
Speaker 1: a client to connect your Geniper devices, retrieve configuration sections,
Speaker 1: and even make changes.
Speaker 2: And Juniper also has its own Python library, doesn't it pie.
Speaker 1: Z it does. The book introduces PIEZ, which stands for
Speaker 1: Python Easy.
Speaker 2: I think makes sense.
Speaker 1: It's Juniper's library designed to simplify interacting with Juno's devices.
Speaker 1: It provides a higher level abstraction over NETCN, making common
Speaker 1: tasks easier.
Speaker 2: So potentially less code to write for standard operations compared
Speaker 2: to using client directly.
Speaker 1: It seems to be the idea. Yeah, more tailored to
Speaker 1: Juniper workflows.
Speaker 2: Okay, what about Arista? They have EAPI yep.
Speaker 1: Arista's EAPI also relies on web protocols, typically Jason RPC
Speaker 1: over HTDPS. The book mentions configuring connection details in a
Speaker 1: file dot epi dot com. You can pick file and
Speaker 1: then using the piple Python library to send commands and
Speaker 1: get structured data back. It even shows an example of
Speaker 1: creating vlands using pioppy.
Speaker 2: So another vendor, another API, another Python library to help.
Speaker 1: Pretty much the pattern and we shouldn't forget vos the
Speaker 1: open source option.
Speaker 2: Oh the book is it a mention too?
Speaker 1: Yeah. Briefly mentions a library called vingient for interacting with
Speaker 1: vostavisis programmatically.
Speaker 2: So the key thing here for you, the learner, is
Speaker 2: seeing this pattern right. Vendors provide APIs, maybe net conframe,
Speaker 2: maybe rest, maybe something pustom like NXAPI or eapi, and
Speaker 2: then there are often Python libraries, either from the vendor
Speaker 2: or the community, to make using those APIs easier exactly.
Speaker 1: And while we focused on vendor specifics, the book does
Speaker 1: also highlight that there are vendor neutral libraries and approaches too.
Speaker 2: That's important things not tied to just one company's way
Speaker 2: of doing things.
Speaker 1: Right. They might sometimes lag a bit behind on the
Speaker 1: absolute bleeding edge features compared to a vendor's own library, sure,
Speaker 1: but they offer the benefit of consistency if you have
Speaker 1: a multi vendor network. Plus, many are open source so
Speaker 1: you can see how they work even contribute.
Speaker 2: Good point. Okay, so we've covered Python talking to individual
Speaker 2: devices via CLIs and APIs. What about orchestrating tasks across
Speaker 2: many devices, managing the whole infrastructure?
Speaker 1: Ah, now we're getting into network automation frameworks and the
Speaker 1: big one the book highlights is ansable.
Speaker 2: Ansable. Yeah, you hear that name a lot, definitely.
Speaker 1: The book describes it as a Python based framework, But
Speaker 1: what makes it really stand out is it's focus on
Speaker 1: being declarative.
Speaker 2: Declarative okay, what does that mean? In practice?
Speaker 1: It means instead of writing a script that lets every
Speaker 1: single command to run and sequence step one, step two.
Speaker 2: Step three, the imperative way, right.
Speaker 1: With antsable, you mostly just declare the desire end state
Speaker 1: you want. You say, I want this VLAN to exist,
Speaker 1: or I want this NTP server configure, and.
Speaker 2: Ansible figures out how to make that happen, checking if
Speaker 2: the villain already exists, adding it if it doesn't.
Speaker 1: Exactly, it checks the current state. It only makes the
Speaker 1: necessary changes to reach the desired state you declared. That's
Speaker 1: the power of declarative automation. It's less about how and
Speaker 1: more about what.
Speaker 2: That sounds much more robust and potentially idempatant by nature.
Speaker 1: It often is. Yes, yeah, that's a major goal. So
Speaker 1: the book explains Ansible uses inventory files to know which
Speaker 1: devices to manage. It shows an example using the IONI
Speaker 1: format like iOS devices followed by host names IOSV one,
Speaker 1: iosv two.
Speaker 2: So just a list of your network here pretty much.
Speaker 1: And then you write playbooks in YAMO format YAML.
Speaker 2: Okay, that structured text format.
Speaker 1: Yeah. Playbooks define the automation tasks, and inside playbooks you
Speaker 1: use Ansible.
Speaker 2: Modules modules like pre built functions Kina.
Speaker 1: Yeah, they're like the tools Ansimble uses to interact with systems.
Speaker 1: The book gives to Cycle as an example, a module
Speaker 1: specifically for managing access control lists on Cisco and XOS devices.
Speaker 2: So there are modules for configuring interfaces, VLANs, routing protocols.
Speaker 1: All that stuff, loads of them for network devices, servers,
Speaker 1: cloud platforms, and playbooks organize these modules into tasks. You
Speaker 1: can also have handlers, which are tasks triggered by changes
Speaker 1: variables to customize things may be stored in hostars per device,
Speaker 1: and loops to apply tasks to multiple devices easily.
Speaker 2: That looping sounds essential for scale configure the same setting
Speaker 2: on hundreds of switches exactly.
Speaker 1: And one more key ansiable feature of the book mentions
Speaker 1: is templating using ginga.
Speaker 2: Ginga templating how's that used?
Speaker 1: It lets you create configuration templates with placeholders for variables.
Speaker 1: So you can have a standard interface config template and
Speaker 1: then fill in the specific IP address or description for
Speaker 1: each device using variables from your inventory.
Speaker 2: Ah, So you generate device specific configs from a common template.
Speaker 1: Very efficient, very keeps things consistent but flexible. Okay, switching
Speaker 1: gear slightly but still relevant to modern workflows.
Speaker 2: Docker containers containers big topic in software development. How does
Speaker 2: it fit into networking?
Speaker 1: Well? The book points out Docker has become the standard
Speaker 1: for packaging and deploying applications, and those benefits apply to
Speaker 1: network related tools and services too.
Speaker 2: Like packaging a monitoring tool or maybe even a small
Speaker 2: network service.
Speaker 1: You build exactly. You package the application and all its dependencies, libraries,
Speaker 1: run time, everything into a container. Think of it as
Speaker 1: a self contained little box for your software.
Speaker 2: And the benefits the book highlights are.
Speaker 1: Consistency is a big one. It runs the same way
Speaker 1: on your laptop as it does on a server or
Speaker 1: in the cloud, Isolation, containers don't interfere with each other,
Speaker 1: and easier deployment you just ship and run.
Speaker 2: The container image makes sense standardized units of software.
Speaker 1: The book mentions Docker files that's the recipe for building
Speaker 1: a container image, and Docker composed for managing applications made
Speaker 1: up of multiple containers that need to work together right.
Speaker 2: Like a web app with a database, or.
Speaker 1: Maybe a network monitoring stack with different components. It also
Speaker 1: touches briefly on container networking, how containers talk to each
Speaker 1: other and the outside world using concepts like bridge or
Speaker 1: host networking.
Speaker 2: Okay, and specifically for network labs. The book mentions container lab.
Speaker 1: Yeah, this sounds really cool. Container lab is a tool
Speaker 1: specifically designed to make it easier to spin up lab
Speaker 1: environments using containerized network operating SYSTEMSS.
Speaker 2: So you can run like a virtual Cisco or Arista
Speaker 2: or Juniper device inside a container for testing exactly.
Speaker 1: It mentions sr linux as an example. It simplifies building
Speaker 1: and tearing down virtual network topologies for practice, testing, automation scripts,
Speaker 1: learning new features.
Speaker 2: That sounds incredibly useful for network engineers. Way lighter than
Speaker 2: full VMS maybe potentially.
Speaker 1: Yeah. Okay, so we've configured devices, automated tasks, packaged tools.
Speaker 1: What about actually monitoring the network? Keeping an eye on
Speaker 1: things crucial aspect?
Speaker 2: The book dedicates a good chunk to network monitoring with Python.
Speaker 2: Where does it start?
Speaker 1: SNMP starts with the classic SNMP, the Simple Network Management
Speaker 1: Protocol been around forever, still widely used the work, but
Speaker 1: as the book notes, it has limitations. It can put
Speaker 1: a load on the device CPU, the agent running there,
Speaker 1: and you need to know the specific OIDs, those numeric
Speaker 1: addresses for pieces of data.
Speaker 2: The MIBs and OIDs Yeah, can be complex.
Speaker 1: Right, You need the right oid to ask for, say,
Speaker 1: interface traffic counters or CPU load. The book does show
Speaker 1: how Python can be used to send SMMP queries and
Speaker 1: get data back, though even shows restricting SNMP access via
Speaker 1: an ACL, So.
Speaker 2: Still relevant, but maybe not the only answer. How about
Speaker 2: visualizing the data you collect?
Speaker 1: Good question? Making sense of numbers? The book introduces Python
Speaker 1: libraries like mattplot lib and pigol for creating charts and graphs.
Speaker 2: Matt plot lob is very common in the data science world,
Speaker 2: Pigole maybe less so.
Speaker 1: Mattplotlib for static charts, pigol maybe more, or for interactive
Speaker 1: web based charts. The book shows examples of creating line graphs,
Speaker 1: maybe tracking bandwidth use over time, visualizing trends.
Speaker 2: Seeing spikes or drops is much easier on a graph
Speaker 2: than in a table of numbers.
Speaker 1: Definitely, and it shows saving these graphs too. But what
Speaker 1: about visualizing the network structure itself? The topology?
Speaker 2: Ah? Yeah, how things are connected?
Speaker 1: The book mentions graph is for that graph is.
Speaker 2: That's the tool that generates diagrams from a text description
Speaker 2: right using the dot language exactly.
Speaker 1: You describe the nodes, devices and edges, links and dot
Speaker 1: format and graphiz draws the picture. The book shows a
Speaker 1: simple example a core node connected to a distribution node
Speaker 1: connected to an access switch.
Speaker 2: Really helpful for understanding network layout, especially complex ones.
Speaker 1: In Python has libraries that wrap graph is, making it
Speaker 1: easy to generate those dot descriptions programmatically from your network data.
Speaker 1: The book even has an example using LLLEDP neighbor info
Speaker 1: to dynamically build a topology map.
Speaker 2: That's pretty neat. Okay, so that's device stats and topology.
Speaker 2: What about analyzing the actual traffic flowing through the network?
Speaker 1: Deeper insights. The book covers flow based monitoring, NetFlow, s flow, ipfax.
Speaker 2: The flow technologies giving you info like source sustination, IPS ports,
Speaker 2: traffic volume.
Speaker 1: Exactly, understanding who's talking to whom, what applications are using bandwidth.
Speaker 1: The book mentions using pythons built in socket instruct modules
Speaker 1: for parsing raw NetFlow packets low level stuff yeah, and
Speaker 1: for s flow. It mentions external tools like slow tool
Speaker 1: and the slow RT collector that you might integrate with.
Speaker 2: And it also mentions end top right for even more
Speaker 2: detailed traffic analysis.
Speaker 1: It does end top or end topping. It's a popular
Speaker 1: open source traffic monitoring tool. In the book notes, it
Speaker 1: has a Python extension for deeper programmatic interaction and analysis.
Speaker 2: So Python can touch pretty much every aspect of monitoring. Okay,
Speaker 2: we've configured, automated, monitored. Can Python actually be the network
Speaker 2: service itself?
Speaker 1: A good question, Yes it can. The book introduces Flask
Speaker 1: as a way to build your own network web services
Speaker 1: or APIs using Python.
Speaker 2: Flask that's a popular micro web framework right known for
Speaker 2: being lightweight and flexible exactly.
Speaker 1: The book shows a super simple Hello networkers example just
Speaker 1: to get the idea.
Speaker 2: Across the Hello world of web apps.
Speaker 1: Basically, but you can build much more complex things. You
Speaker 1: could create your own custom API, maybe one that lists
Speaker 1: other systems, query network status, or even trigger specific automation
Speaker 1: tasks you've built.
Speaker 2: So building your own internal network tools with a web
Speaker 2: front end or API precisely.
Speaker 1: The book even touches on defining data models for your
Speaker 1: network resources using an extension called Flask school Alchemy. If
Speaker 1: you need a database, and importantly, how to secure these
Speaker 1: APIs you build using Flask httb out for authentication and authorization.
Speaker 1: You don't want just anyone triggering network changes via your API.
Speaker 2: Definitely need security there, Okay, flask for building services. What
Speaker 2: about performance, especially when dealing with lots of network devices
Speaker 2: that might response.
Speaker 1: Yeah, waiting for network io is a classic bottleneck. The
Speaker 1: book addresses this with a section on asynchronous programming using
Speaker 1: Python's asnc io features.
Speaker 2: Async io that's about doing things concurrently, not blocking while
Speaker 2: waiting for stuff.
Speaker 1: That's the core idea. When your script sends a command
Speaker 1: to a switch and is waiting for the response, a
Speaker 1: normal synchronous script just sits.
Speaker 2: There idle, wasting time.
Speaker 1: Right, asynchronous code using libraries like acincio that the book introduces,
Speaker 1: can switch to working on other tasks while waiting, like
Speaker 1: talking to another switch.
Speaker 2: Concurrently, so you can potentially interact with many devices much faster.
Speaker 1: That's the promise. The book mentions libraries like scrappoly, which
Speaker 1: are specifically designed for asynchronous interaction with network devices, highlighting
Speaker 1: the potential for significant speed ups, especially for large scale automation.
Speaker 2: Makes sense. Efficiency is key. Yeah, Now what about the cloud?
Speaker 2: Networking doesn't stop at the data center edge anymore?
Speaker 1: Absolutely not. The book has a chapter dedicated to cloud networking.
Speaker 1: Focusing on the big players AWS and Azure.
Speaker 2: Okay, Amazon Web Services and Microsoft Azure.
Speaker 1: Give a high level comparison of their core networking concepts
Speaker 1: AWS Virtual Private Clouds vpcs and Azra Virtual Networks v
Speaker 1: nets basically your private network space in the cloud.
Speaker 2: Understanding how cloud networking maps to traditional concepts is important, definitely.
Speaker 1: The book briefly touches on KEYAWS components, subnets, internet gateways,
Speaker 1: route tables, security groups like firewalls, elastic ips, net gateways,
Speaker 1: the building.
Speaker 2: Blocks, and similarly for Azure.
Speaker 1: YEP mentions azurevnets, subnet network security groups, n sgs, VPN
Speaker 1: gateways for site to site connections, expressed route for private connections.
Speaker 1: Gives you a feel for the Azure networking landscape.
Speaker 2: And crucially, how does Python fit in through their.
Speaker 1: SDK software development kits. The book highlights BOTO three for AWS.
Speaker 2: Bout three Yeah, that's the standard AWSSDK for Python.
Speaker 1: And the Azure mgmt Network Library for Azure. These SDKs
Speaker 1: let you use Python to programmatically create, can figure, and
Speaker 1: manage all those cloud networking resources we just mentioned.
Speaker 2: So infrastructure as code, but for your cloud network using Python.
Speaker 1: Exactly powerful stuff. Okay, we're generating lots of data, logs,
Speaker 1: monitoring stats, maybe flow data. How do we manage and
Speaker 1: analyze all that effectively?
Speaker 2: Good point data overload is real. The book introduces the
Speaker 2: Elastic stack for this, the elk.
Speaker 1: Stack, Elastic Search, log Stash, Kebana.
Speaker 2: That's the one, a very popular open source solution for
Speaker 2: centralized logging and analysis.
Speaker 1: How does it break down?
Speaker 2: Log Stash and related tools called Beats is used for
Speaker 2: collecting and processing data from various sources cyslogs, from routers,
Speaker 2: application logs, et cetera. Elastic Search is the distributed search
Speaker 2: and analytics engine where the data gets stored and indexed,
Speaker 2: and Kubana is the visualization layer dashboards charts exploring the data.
Speaker 1: So collect with log stash, beats, store in search with
Speaker 1: elastic Search, visualized with Cubana.
Speaker 2: That's the basic workflow, and of course the book mentions
Speaker 2: the elastic Search Python co Cliant library, so you can
Speaker 2: interact with your elastic Search data programmatically using Python two.
Speaker 1: Okay, makes sense for handling large volumes of network data. Now,
Speaker 1: all these scripts, configurations, templates, playbook files, how do we
Speaker 1: manage the code itself?
Speaker 2: Version control absolutely essential? The book provides a solid introduction
Speaker 2: to using.
Speaker 1: Git get, the standard for version control these days pretty much.
Speaker 2: The book explains the benefits tracking changes over time, collaborating
Speaker 2: with others on the same codebase, like ansable playbooks or
Speaker 2: Python scripts, being able to roll back to a previous
Speaker 2: working version of something breaks.
Speaker 1: Yeah, that rollback capability.
Speaker 2: Is a life saver, it really is. The book also
Speaker 2: clarifies the difference between Get the tool itself and GitHub,
Speaker 2: a popular web platform for hosting Git repositories and collaborating.
Speaker 1: Good distinction, and it covers basic Git commands.
Speaker 2: Yeah, the fundamentals dock commit to save changes, push to
Speaker 2: send changes to a remote repository like GitHub, pull to
Speaker 2: get changes from others, and also mentions dot get ignored
Speaker 2: files for telling Get which files not to track, like
Speaker 2: passwords or temporary files. Right, don't want secrets in your
Speaker 2: Git repo? Definitely not. And for deeper Python integration, the
Speaker 2: book introduces libraries like get python for interacting with local
Speaker 2: Git repos and pi GitHub for interacting with the GitHub api, so.
Speaker 1: You can even automate GET operations from within your Python scripts.
Speaker 2: If needed, you can building on version control. The next
Speaker 2: logical step is automating the testing and deployment process, Continuous
Speaker 2: integration or.
Speaker 1: CI, CICD, big topic and DevOps. How does it apply here?
Speaker 2: The book introduces the principles of CI automatically building, testing,
Speaker 2: and validating changes every time someone commits new code. For networks.
Speaker 2: This could mean automatically linting your Python scripts, checking playbook syntax,
Speaker 2: maybe even spinning up a lab environment like with container
Speaker 2: lab and running tests against virtual devices.
Speaker 1: Catching errors early automatically.
Speaker 2: That's the goal. The book uses git lab as an
Speaker 2: example platform as it has CICD capabilities built in okay up.
Speaker 2: It explains get lab runners, the agents that execute the
Speaker 2: CI jobs, and the dot get lab Dashchi dot IML
Speaker 2: configuration file where you define your CI pipeline, the stages.
Speaker 1: And jobs to run, and it shows an example.
Speaker 2: Yeah, a simple example using Nornier, another Python automation framework
Speaker 2: within a get lab CI pipeline to maybe run some
Speaker 2: validation commands on devices.
Speaker 1: After change, automating the automation checks. Cool.
Speaker 2: Yeah.
Speaker 1: Finally, to make all this automation reliable, we need good
Speaker 1: testing practices.
Speaker 2: Right absolutely. The book wraps up by introducing Test driven
Speaker 2: development TDD for network.
Speaker 1: TDD, writing tests before or alongside the actual code.
Speaker 2: That's the idea. It forces you to think about requirements
Speaker 2: and how to verify your code works correctly before you
Speaker 2: write it, or at least concurrently. The book mentions Python's
Speaker 2: built in unit as framework and the popular third party
Speaker 2: PI test framework.
Speaker 1: Shows basic examples assertions.
Speaker 2: Yeah, simple examples of writing test functions with assertions, checks
Speaker 2: like a certain result expected value to verify your codees
Speaker 2: as intended.
Speaker 1: And it mentions in network specific testing framework too.
Speaker 2: Briefly, Yeah, it introduces piats, which is a Cisco developed
Speaker 2: but quite powerful and broadly applicable Python based framework specifically
Speaker 2: designed for network testing and validation.
Speaker 1: Wow. Okay, we have covered a ton of ground there,
Speaker 1: from basic Python syntax right up to CICD and TDD
Speaker 1: for network automation.
Speaker 2: It really shows the breadth of Python's application in networking today.
Speaker 1: So let's try and summarize. What are the absolute key
Speaker 1: takeaways for you the learner listening to this.
Speaker 2: I think the main thing is just how absolutely fundamental
Speaker 2: Python has become. It's not just one tool for one
Speaker 2: job anymore. No, it's everywhere, right from talking to individual devices,
Speaker 2: legacy or modern using libraries like paramico or netmeko.
Speaker 1: To orchestrating entire infrastructures with frameworks like ansable.
Speaker 2: To monitoring performance, visualizing topology, analyzing traffic.
Speaker 1: Managing cloud networks with SDKs like photo.
Speaker 2: Three, tut, handling logs with the ELK stack, managing code
Speaker 2: with GET, automating tests with CICD. Python is the common thread.
Speaker 2: It really bridges that gap between traditional networking skills and
Speaker 2: the modern programmable, software driven world.
Speaker 1: It's the glue. Like the book said earlier. Okay, so
Speaker 1: here's something to chew on. Looking forward, how do you
Speaker 1: think the continued evolution of device APIs maybe more standardization
Speaker 1: like with YANG and the ongoing development of Python libraries.
Speaker 1: How is that going to further reshape network engineering?
Speaker 2: That's a great question. More abstraction, easier intent based networking,
Speaker 2: proactive management driven by AI, analyzing network data via Python.
Speaker 1: What new possibilities does this unlock, maybe moving beyond reactive
Speaker 1: fixes to truly innovative self managing networks. It's definitely something
Speaker 1: to think about, isn't it?
Speaker 2: It really is, And that leads to a question for you,
Speaker 2: the listener, which specific part of all this sparked your
Speaker 2: interest the most? Was it the device interaction, the large
Speaker 2: scale automation with antsible cloud networking, maybe the testing side.
Speaker 1: What area feels most relevant or exciting for you to
Speaker 1: explore further.
Speaker 2: Because the next step is really getting hands on.
Speaker 1: Absolutely, we strongly encourage you, the learner, to actually explore
Speaker 1: some of these libraries we.
Speaker 2: Mentioned paramico Netmko, maybe your vendor specific SDK.
Speaker 1: Antsable, flask Asensio if you're feeling brave.
Speaker 2: The cloud SDKs like Boto three, the Elastic search client,
Speaker 2: get Python tie test.
Speaker 1: Pick one or two that seem interesting, and definitely consider
Speaker 1: setting up a lab environment.
Speaker 2: Crucial for practice. Use tools like ciscocml, eve ng, or
Speaker 2: maybe try that container lab approach we discussed.
Speaker 1: Get some hands on keyboard time. Try connecting to a
Speaker 1: virtual device, running a simple playbook, writing a small script.
Speaker 1: That's where the real learning happens.
Speaker 2: Don't hesitate to dive into the official documentation for these tools,
Speaker 2: look at examples on GitHub. There are tons of resources
Speaker 2: out there.
Speaker 1: The journey into Python networking is well, it's ongoing, but
Speaker 1: it's definitely an exciting one to be on right now.