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