Speaker 1: Welcome to the deep dive. We're here to cut through
Speaker 1: the noise and get straight to what matters. And today, Wow,
Speaker 1: we're jumping into a really big shift happening right now
Speaker 1: in it specifically network engineering. The old roles, the way
Speaker 1: things were always done, it's all changing and changing really fast.
Speaker 1: So our mission today is basically to give you a
Speaker 1: shortcut a way to understand this whole transformation. We're looking
Speaker 1: at how Python Linux are becoming well essential tools for
Speaker 1: automating networks. We're drawing on insights from introduction to Python
Speaker 1: network automation and you know, other solid sources. Think of
Speaker 1: this as your guide to the skills, the mindset, and yeah,
Speaker 1: the practical stuff you need to become what people are
Speaker 1: calling a hybrid engineer. Okay, so let's unpack this. Think
Speaker 1: back maybe ten years, maybe a bit more, the traditional
Speaker 1: network engineer role. What did that look like. You were
Speaker 1: probably you know, knee deep in installing kit, configuring lands wands,
Speaker 1: a real master of OSPF, e I, g RP, BGP,
Speaker 1: all that good stuff. Your world was pretty much OSI
Speaker 1: layers one through four, right happy in that specific bubble.
Speaker 2: Yeah, definitely. And Cisco Systems, I mean they were the
Speaker 2: name the one stop shop for pretty much everything network
Speaker 2: related for a long long time. Absolutely, but it's it's
Speaker 2: fascinating how quickly things started to shift. You had these
Speaker 2: disruptive forces appearing. Virtualization started getting big software to define
Speaker 2: networking SDN, those concepts started bubbling up, and then for
Speaker 2: some open source tools really took off. Now automation itself,
Speaker 2: I mean that's not new, right, goes way back to
Speaker 2: the Industrial Revolution, nineteen hundred stuff. But today, yeah, it's
Speaker 2: the hot topic, not just networking, but security, data center, cloud,
Speaker 2: you name it. It's fundamental now.
Speaker 1: Yeah, it really is. And here's something our sources really
Speaker 1: drive home. Kind of a stark reality. If you're just
Speaker 1: relying on let's say, passive learning in this market, the
Speaker 1: future looks a bit grim. It feels like history repeating itself.
Speaker 1: You know, adapt or well or get left behind. Yeah, exactly.
Speaker 1: And the core change is that network devices themselves are
Speaker 1: moving from physical boxes to virtual things. And here's the kicker.
Speaker 1: They're increasingly controlled by AP application programming interfaces. Think about
Speaker 1: VMware's NSX or Cisco's ACI. These aren't just products. They
Speaker 1: show this massive shift in.
Speaker 2: Architecture precisely and That's exactly why this idea of a
Speaker 2: hybrid engineer isn't just like a nice to have anymore.
Speaker 2: It's becoming essential. We're talking about people who, yes, have
Speaker 2: their deep knowledge in their main areas a networking, but
Speaker 2: then they stretch, they build skills in other vital areas
Speaker 2: like Linux and coding, Python, maybe go. It creates the
Speaker 2: sort of T shaped knowledge profile, deep expertise but broad
Speaker 2: adaptability T shaped.
Speaker 1: I like that. It paints a good picture. Okay, so
Speaker 1: let's focus on the tool that seems to be at
Speaker 1: the absolute center of this. Python. Its popularity has just exploded.
Speaker 1: I mean some reports show at overtaking Java, JavaScript and
Speaker 1: developer preference. From your perspective, what is it about Python
Speaker 1: that makes it the go to language for network automation.
Speaker 2: Well, it's a combination of things. Really. Python hits this
Speaker 2: sweet spot between being simple enough to get started but
Speaker 2: powerful enough to do complex things. It's got that reputation
Speaker 2: for a low barrier to entry, right, anyone can basically
Speaker 2: start learning. But and this is important, there's a misconception
Speaker 2: there easy to start, yes, truly proficient that takes real persistence, passion,
Speaker 2: Even you can't just watch videos passively. You need projects,
Speaker 2: you need real problems you want to solve with code.
Speaker 2: That's what keeps you going because fundamentally automation means writing
Speaker 2: code lines of instructions. AI is amazing, but it's not
Speaker 2: yet at the point where it can just replicate the
Speaker 2: intuition and experience of a seasoned network engineer. You still
Speaker 2: need the logic.
Speaker 1: That's a really critical point. So the human understanding the
Speaker 1: logic crafting that's still key even with AI coming along.
Speaker 1: It's about using code to solve problems intelligently exactly. So
Speaker 1: to do that you need Python's building blocks. What are
Speaker 1: some of those core concepts that really give a network
Speaker 1: engineer automation power.
Speaker 2: Okay, think of it this way. Python is how you
Speaker 2: talk to your network now and when you get data
Speaker 2: back from devices. It comes in different shait papes for
Speaker 2: network tasks. Honestly, two data structures are your absolute work courses,
Speaker 2: lists and dictionaries.
Speaker 1: Lists and dictionaries.
Speaker 2: A list is perfect when you need an ordered sequence,
Speaker 2: like say, all the interface names on a switch, just
Speaker 2: a simple list. A dictionary, though, is perfect for configuration.
Speaker 2: You have a key like host name and a value
Speaker 2: like rooter one or lan ten, name is the key,
Speaker 2: sales is the value.
Speaker 1: Ah key value pairs, got it right.
Speaker 2: If you get comfortable manipulating those two lists and dictionaries,
Speaker 2: you've honestly tackled maybe eighty percent of the data wrangling
Speaker 2: you'll do in network automation.
Speaker 1: That makes immediate sense. Lists for sequences, dictionaries for configs
Speaker 1: very practical. What about making scripts smart? Making decisions?
Speaker 2: Right, that's where your control statements and loops come in
Speaker 2: super important. You've got if, l if and else that
Speaker 2: lets your script decide, okay, if this interface status is down,
Speaker 2: then I need to log it and maybe send an.
Speaker 1: Alert conditional logic exactly.
Speaker 2: And then you have loops like four loops and wild loops.
Speaker 2: These are amazing for repetitive stuff. Imagine configuring the same
Speaker 2: description on say fifty switch ports. A four loop handles
Speaker 2: that beautifully. No more copy pasting fifty times.
Speaker 1: Oh yeah, I can see the appeal there immediately.
Speaker 2: These loops and conditions they make your scripts dynamic, They react,
Speaker 2: they repeat intelligently. They're not just static command centers.
Speaker 1: So building intelligence into the script itself, and as scripts
Speaker 1: get bigger, organization must become pretty important. Right. That's modules
Speaker 1: and packages.
Speaker 2: Absolutely critical, especially if you're working in a team or
Speaker 2: just want to reuse your code later. Think of a
Speaker 2: module as basically just a single Python file, a dot
Speaker 2: piy file. It might contain a few functions you wrote
Speaker 2: for a specific task, like getting neighbor information from a router.
Speaker 1: Okay.
Speaker 2: A package is like a folder full of related modules.
Speaker 2: It helps you structure bigger projects. Maybe you have a
Speaker 2: package for Cisco iOS tasks, another for Juniper Geno's tasks.
Speaker 2: Keeps things neat reusable.
Speaker 1: Like libraries of your own tools.
Speaker 2: Exactly. One more thing here, error handling. It absolutely must
Speaker 2: learn how to use try and accept blocks. Networks are messy,
Speaker 2: devices might not respond, files might be missing. Your script
Speaker 2: needs to handle that gracefully with try accept, not just
Speaker 2: you know, crash and burn makes your automation robust.
Speaker 1: Robustness yeah, key for anything production. Okay, So Python gives
Speaker 1: us the language, the data, structure, is the logic, the organization.
Speaker 1: But where does this code actually live and run? That
Speaker 1: leads us to Linux, doesn't it? And I have to
Speaker 1: admit I really wish I'd taken Linux more seriously much
Speaker 1: earlier in my career. It felt like this niche thing back.
Speaker 2: Then you're definitely not alone there. It's a common regret
Speaker 2: because while Windows, yeah, it dominates desktops, linuxes without a
Speaker 2: doubt the default OS for serious enterprise level automation period.
Speaker 1: Why is that? What makes it the go to?
Speaker 2: It's a flexible, it's usually more performance for server tasks,
Speaker 2: it's often more cost effective and has a really strong
Speaker 2: security posture when configured right. It's just built for running
Speaker 2: these kinds of back end services, automation engines, and yeah,
Speaker 2: your Python scripts.
Speaker 1: So for a network engineer who isn't aiming to become
Speaker 1: a full time Linux ADMN, what are the must know
Speaker 1: fundamentals the essentials?
Speaker 2: Great question. You need to be comfortable on the command line,
Speaker 2: that's number one. Knowing a bit about its U and
Speaker 2: IX roots helps because many commands are the same across
Speaker 2: different versions or distributions like a Buntu or cinos.
Speaker 1: Right, the different flavors exactly.
Speaker 2: You need to navigate the directory structures. Nowhere common config
Speaker 2: files live because on Linux almost everything is a text file,
Speaker 2: which means you need to get good with a command
Speaker 2: line text editor like v or Nano. Essential for making
Speaker 2: quick changes on a server without a GUI.
Speaker 1: Okay, command line directories, text editors, what else.
Speaker 2: Basic system checking and management commands things like l's t
Speaker 2: CE files cat or less to view files, seep A copy,
Speaker 2: MB to move or rename standard stuff. Then networking commands
Speaker 2: are vital ep editors to see interface configs, replacing the
Speaker 2: older if can fig and netstat is super useful for
Speaker 2: seeing what ports are open, what services.
Speaker 1: Are listening, checking connectivity listening ports yea.
Speaker 2: And crucially, you'll likely need to install and manage some
Speaker 2: basic network services on your Linux box to support your automation,
Speaker 2: things like a TFTP server I mean an FTP server
Speaker 2: using vsftpd and definitely an NTP server using Krony to
Speaker 2: keep time synchronized. This lets you build your own little
Speaker 2: all in one lab server, which is often what your
Speaker 2: network devices will interact with for things like image transfers
Speaker 2: or can fig backups.
Speaker 1: So the goal isn't Linux mastery necessarily, not at all.
Speaker 1: It's about having the confidence and the core skills to
Speaker 1: operate that Linux environment where your automation runs right without
Speaker 1: breaking things.
Speaker 2: That's the sweet spot exactly. You need to be competent
Speaker 2: enough to manage your automation platform effectively.
Speaker 1: Okay, makes sense now, you the listener might be thinking
Speaker 1: this sounds powerful, but theory is one thing, and our
Speaker 1: sources really hammer this home. If you do not build
Speaker 1: your lab yourself, then you will not know how everything works.
Speaker 1: Just watching videos that passive learning it's not good enough.
Speaker 1: You absolutely have to get your hands dirty build it yourself.
Speaker 2: Couldn't agree more. And virtualization is your absolute best friend here.
Speaker 2: It's how you build that playground. You need to understand
Speaker 2: the basic types. There are Type one hypervisors, the bare
Speaker 2: metal ones like VMware ESXi you find in data centers,
Speaker 2: and then type two, which run like an application on
Speaker 2: your desktop OS, perfect for labs and experiments. VMware Workstation
Speaker 2: Pro is a really popular powerful Type two option lets
Speaker 2: you build complex labs just on your own PC.
Speaker 1: Okay, so workstation pro for the environment. What about the
Speaker 1: network devices themselves? Can you run routers and switches virtually?
Speaker 2: Absolutely? That's where tools like GNS three come in. Genius
Speaker 2: theory is fantastic. It started with dynamips for emulating older
Speaker 2: Cisco hardware, but now it's a full graphical environment. You
Speaker 2: can load actual Cisco iOS images into it, older ones
Speaker 2: like the twelve on one x train or newer virtual
Speaker 2: images like the ones from Cisco Modeling Labs, the c
Speaker 2: amount pe images for L two L three functionality.
Speaker 1: So you're running real Cisco code.
Speaker 2: Exactly real code, emulated hardware. You can graphically connect virtual routers, switches,
Speaker 2: even little virtual PCs vpcs to test connectivity. You could
Speaker 2: even bridge this virtual network to your actual PCs network
Speaker 2: using things like Microsoft loop back adapters. It creates this
Speaker 2: amazing self contained sandbox.
Speaker 1: Wow. So this integrated lab environment running Linux, running GNS
Speaker 1: three with virtual devices, that really sounds like the key.
Speaker 1: It's the closest you can get to actually practice and
Speaker 1: experience everything that occurs in the real network environment. Right, build, break, fix,
Speaker 1: automate all safely, precisely.
Speaker 2: It's where the Python knowledge, the Linux skills, it all
Speaker 2: comes together in a practical way. It's indispensable for learning
Speaker 2: this stuff properly.
Speaker 1: Okay, let's pivot now to the real world application. How
Speaker 1: does Python actually talk to network devices? Because let's face it,
Speaker 1: even with APIs growing a ton of gear out there
Speaker 1: still relies on the command line via telnet and SSH.
Speaker 2: That's very true, and Python is excellent for automating those
Speaker 2: interactions too. There are standard libraries like telnet live built in,
Speaker 2: but more often you'll use more powerful third party libraries.
Speaker 2: Is a popular one for SSH at a lower level.
Speaker 2: And then there's Netmeko, which builds on paramco and is
Speaker 2: specifically designed for network devices. It'd understand different vendor prompts, handles,
Speaker 2: pagination makes life much.
Speaker 1: Easier netnico Okay, so what can you do with.
Speaker 2: These ah tons of repetitive tasks? Think about configuring the
Speaker 2: same VLAN on say twenty different access switches. Instead of
Speaker 2: logging into each one, you write a simple Python loop
Speaker 2: using netmeico connect configure, disconnect next switch. Done in seconds.
Speaker 1: That alone sounds like a huge time saver it is.
Speaker 2: Or backing up configurations, schedule a Python script to log
Speaker 2: into all your core devices every night and save the
Speaker 2: running config to your Linux server via SEP or TFTP.
Speaker 1: Nice. And what about security? You mentioned telnet earlier.
Speaker 2: Yeah, this is a big one. Telnet is insecure, sends
Speaker 2: passwords in clear text. You can write a Python script
Speaker 2: to scan your network ranges, check if telnet is enabled
Speaker 2: on devices and if it finds telnet open. Use Python
Speaker 2: with netmeko again to log in via SSH, disable the
Speaker 2: Telnet service and maybe be ensure SSH is properly configured.
Speaker 2: It's automating security policy enforcement.
Speaker 1: That's moving beyond convenience into really critical operational security, powerful stuff.
Speaker 1: What about monitoring, keeping an eye on device health?
Speaker 2: For that, SNNP is still king the Simple Network Management Protocol.
Speaker 2: It's been around forever but is still widely used. You
Speaker 2: need to grasp the basics the idea of polling, where
Speaker 2: your management station asks devices for data versus traps, or
Speaker 2: devices send alerts automatically if something bad happens.
Speaker 1: Okay, polling versus traps.
Speaker 2: In the terminology, SMI is the structure of management information,
Speaker 2: how data is organized. The MIIB management information based of
Speaker 2: like the database of things you can monitor on a device,
Speaker 2: and crucially oid's object identifiers. These are like unique addresses
Speaker 2: for specific pieces of data like one point three point
Speaker 2: six two point one, put one to one point one
Speaker 2: put one point one point one. Did is typically system
Speaker 2: uptime or specific Cisco ID like one put through six
Speaker 2: point four point nine and nine put one button on
Speaker 2: one point five might be this five minute CPU load average.
Speaker 1: There's a great Python module called pi sm it lets
Speaker 1: you easily perform sn mp gt request to fetch specific OIDs,
Speaker 1: or even SMMP set request change configuration, though that's less
Speaker 1: common and needs care. You can also use command line
Speaker 1: tools on Linux like simp walk to explore devices m
Speaker 1: ib and find useful OIDs.
Speaker 2: So give us a practical example. How could you use this?
Speaker 1: Okay, imagine this. You write a Python script using pizmpm
Speaker 1: to pull your main router's CPU utilization o ID every
Speaker 1: few minutes using secure sm mpv three. The script checks
Speaker 1: the return value if the CPU load goes above, say ninety.
Speaker 2: Percent right, instead of just logging it. The script could
Speaker 2: then use the twili o API, maybe running inside a
Speaker 2: lightweight dock or container, send an SMS alert straight to
Speaker 2: your phone.
Speaker 1: Proactive alerting via text message that beats a three am
Speaker 1: phone call waking you.
Speaker 2: Up, doesn't it, jest. It's about getting ahead of problems.
Speaker 2: It's efficiency, yes, but it's also about sanity.
Speaker 1: Sanity definitely value and to make that check happen regularly automatically.
Speaker 1: That's Linux's KRON again precisely.
Speaker 2: Pron is the simple, super reliable Linux scheduler. You write
Speaker 2: a kron tab entry that just says, run this Python
Speaker 2: script every five minutes, set it and forget it. Your
Speaker 2: monitoring is now automated and persistent.
Speaker 1: Perfect. Now there are even more advanced tools out there too, right,
Speaker 1: we should probably mention them briefly.
Speaker 2: Yeah, definitely beyond direct scripting with netmko or piesapp, you'll
Speaker 2: quickly run into tools like antsable. Ansable is huge for
Speaker 2: configuration management. It's agentless, mainly uses SSH and you define
Speaker 2: the desired state in simple yamo files called playbooks. Very
Speaker 2: powerful for ensuring consistency across many devices. It has modules
Speaker 2: like iOS facts to gather device info easily email playbooks.
Speaker 1: Right, and Cisco has their own stuff too.
Speaker 2: We do piats often used with its parsing library called Genie.
Speaker 2: It's a Cisco endorsed Python framework really geared cords, network
Speaker 2: testing and validation. You can use gene to parse complex
Speaker 2: show command put like show version into structured Python data,
Speaker 2: dictionaries and lists. Again makes it easy to grab say
Speaker 2: the uptime or serial number. You can even export that
Speaker 2: data to Excel, maybe visualize it with matt.
Speaker 1: Plotlob data extraction and testing. Okay, and Docker you mentioned
Speaker 1: for the SMS alert Right.
Speaker 2: Docker isn't strictly automation, but it's containerization. It lets you
Speaker 2: package your Python script and all its dependencies into a small,
Speaker 2: isolated container. This ensures your script runs the same way everywhere,
Speaker 2: whether it's on your laptop or a server. Great for
Speaker 2: deploying small focused tools like monitoring scripts or alert handlers.
Speaker 1: Okay, so we have scripting, monitoring, configuration, management, testing frameworks.
Speaker 1: If we try to tile this together, where does it
Speaker 1: really culminate. What's a complex, high value task that this
Speaker 1: approach can tackle.
Speaker 2: Well, if we connect this to the bigger picture, I
Speaker 2: think one of the classic high stress tasks is manually
Speaker 2: upgrading Cisco iOS software in a live production network. Think
Speaker 2: about it, two four seven environment tight change windows, the
Speaker 2: immense pressure not to cause an adage. There were distinct phases,
Speaker 2: the pre checks, the actual upgrade, the critical post checks.
Speaker 2: It's incredibly labor intensive and nerve wracking.
Speaker 1: Oh absolutely, I've been there. It's stressful. So how can
Speaker 1: Python help break down that labor intensive workflow?
Speaker 2: This is where all the pieces come together beautifully, that complex,
Speaker 2: stressful process. Python can turn it into manageable, automatable, modular steps.
Speaker 2: You could have a Python script that first connects via
Speaker 2: sash net miko to run pre checks. Is there enough
Speaker 2: flash space for the new image. What's the current boot variable?
Speaker 2: Save the current can.
Speaker 1: Fig okay the verification stage.
Speaker 2: Then another part of the script could securely transfer the
Speaker 2: new iOS image using SEP or maybe TFTP from your
Speaker 2: Linux server. It can even verify the MTFI hash of
Speaker 2: the transferred file to ensure it wasn't.
Speaker 1: Correct integrity checks nice.
Speaker 2: Then configure the boot system variables to point to the
Speaker 2: new image, save the config and then initiate the reload.
Speaker 1: The point of no return.
Speaker 2: Well hopefully not is after the device reboots. Your script
Speaker 2: connects again to run post checks. Did it boot the
Speaker 2: right image? Or the interfaces up? Can it? Pin key neighbors?
Speaker 2: Is routing working all verified automatically?
Speaker 1: Wow? Breaking that massive task down into automated, verifiable steps
Speaker 1: that really highlights the power exactly.
Speaker 2: It takes that high stress, error prone manual process and
Speaker 2: makes it far more reliable, repeatable, and faster. This is
Speaker 2: where all those Python basics, Linux skills, netmko s and
Speaker 2: mp checks maybe they all converge to solve a really
Speaker 2: significant operational.
Speaker 1: Challenge that really crystallizes the goal, doesn't it. It's not
Speaker 1: about kicking engineers out, not at all. It's about deeply
Speaker 1: understanding what engineers do, their decision processes, their checks and balances,
Speaker 1: and then building tools that amplify their effectiveness, tools that.
Speaker 2: Make their work more efficient, way more accurate, and less
Speaker 2: prone to simple human error during repetitive tasks. It fundamentally
Speaker 2: allows engineers to scale their impact to do more work
Speaker 2: using an application programming interface.
Speaker 1: Essentially, they shift from being purely manual operators to being
Speaker 1: the architects and overseers of intelligent automation.
Speaker 2: That's a great way to put it.
Speaker 1: Well, what a journey we've covered today. Seriously. We started
Speaker 1: with this rapidly changing network engineering landscape, the absolute need
Speaker 1: now to become this hybrid engineer. Then we dove into
Speaker 1: Python basics, the core data types and logic needed, navigated
Speaker 1: essential Linux skills for running our automation, talked about building
Speaker 1: those crucial virtual labs with GNS three and VMware to
Speaker 1: get hands on practice, and finally brought it all together
Speaker 1: with real world automation using Python for SSH, SNMP, monitoring,
Speaker 1: scheduling with Kron, and even tackling something as complex as
Speaker 1: iOS upgrades. So what does this all really mean for
Speaker 1: you listening right now?
Speaker 3: I think the key takeaway is that making this transition
Speaker 3: becoming that cross functional engineer with solid networking plus links
Speaker 3: chops plus coding ability. It's not just a nice to
Speaker 3: have for your CV anymore. It really feels like a
Speaker 3: necessity now for staying relevant for career growth in this
Speaker 3: IT world that's just shifting so quickly under our feet.
Speaker 2: Absolutely, and maybe here's a final thought to leave you
Speaker 2: with something to chew on. Take a hard look at
Speaker 2: your own day to day work right now, what specific task,
Speaker 2: even a small one, could you potentially automate using some
Speaker 2: of these ideas, And then flip the question, Even with
Speaker 2: that automation, what unique human insight, what critical thinking or
Speaker 2: complex problem solving skill that you possess would still be
Speaker 2: absolutely essential because the real power here, the future of
Speaker 2: network programmability isn't just the raw automation. It's the intelligent
Speaker 2: application of it, the smart processing and interpretation of the
Speaker 2: data it provides, and that intelligence, that guidance that still
Speaker 2: comes best from experienced engineers like you.
Speaker 1: Powerful thoughts, indeed, focus on where you add unique human value.
Speaker 1: Excellent point to end on. Thanks so much for joining
Speaker 1: us on this deep dive. Until next time, keep learning,
Speaker 1: keep exploring that automation potential and keep diving deep