This week I spent some time going through network automation basics. Not deeply, just trying to understand what problem we are actually solving. I was not focusing on tools yet. More on the “why” behind all of this.

I would like to start with one of the scenerio where a retail network with around 500 stores had a full outage during what was supposed to be a routine change.

Everything was managed through CLI. During a security update, an ACL was pushed manually across devices. The configuration itself was not complex, but the order was wrong. A deny all rule was placed before the permit rules.

That was enough to stop traffic everywhere.

At first, it looks like a simple mistake. Someone configured it wrong. But after thinking about it for a while, it did not feel like just a human error. It felt more like a system problem.

Because one small mistake should not be able to take down an entire network like that.

That only happens when the same action is repeated manually across a large number of devices without any real validation in between. The mistake itself was small, but the way it was applied made it big

Where CLI Starts Feeling Uncomfortable

Most networks still run on CLI. Login via SSH , run commands, check output , move to enxt devcie .That is how things are done

But when the number of devices increases, something starts to feel off. Not immediately, but gradually. You spend more time repeating steps than actually thinking about what you are doing. It becomes mechanical.

And the more repetitive it gets, the more it depends on you not making a mistake.

That is the part that does not scale.

It is not about effort. It is about consistency. Doing the same thing correctly, every single time, across hundreds of devices. That is harder than it sounds.

First Thought Was, Just Automate It with Python

Naturally, the next thought was scripting.

Connect to devices, send commands, capture output. It feels like a direct upgrade from CLI. Same workflow, just automated.

This is probably why most people start here. It feels familiar and you can get something working quickly.

But after looking into it a bit more, there is something slightly uncomfortable about it.

You are still dealing with text.

The commands are text. The output is text. Everything depends on how that text looks.

And that is not stable.

A small change in output format can break everything. The information is still there, just displayed differently. That is enough for parsing logic to fail.

I had not really thought about this before. From a human perspective, the output still makes sense. From a script’s perspective, it can completely break.

So now instead of manually checking output, you are writing logic to interpret it. Which adds another layer that can go wrong.

It works, but it does not feel reliable when you think about scaling it.

APIs Felt Cleaner, But Took Time to Click

Then I looked at NETCONF and RESTCONF.

At first, it was not immediately clear why this was better. It just looked like another way of doing the same thing.

But after spending some time with it, the difference started to make sense.

Instead of sending commands, you are sending structured data. Instead of parsing output, you are receiving structured responses.

JSON or XML.

This changes things in a better way.

You are no longer guessing where the data is. You are accessing it directly.

Error handling also becomes clearer. You are not searching for keywords in output, you are reading defined responses.

It feels more predictable.

Still, not everything is available via API. So CLI does not disappear. It just becomes one option among others.

Ansible and Terraform Were Not Obvious at First

This part honestly took me some time. Because it is not just a tool difference. It is a thinking difference.

Earlier the approach was always step by step. Run this command. Then this. Then check. Now it becomes something else. You define what should exist.

For example, instead of writing steps to create a VLAN, you just say VLAN 10 should be there.

The system figures out whether it needs to create it or not.

This felt strange initially. I kept thinking in steps, so this did not click immediately.

But after a while, it started to make sense.

You are not managing execution anymore. You are defining intent.

There is also this concept of idempotency, which sounds complex but is actually simple.

Running the same thing again should not change anything unnecessarily.

That turns out to be very important when you are dealing with repeated operations.

Terraform goes a bit further.

It keeps track of what already exists and compares it with what you want. Then it calculates what needs to change.

That makes things more predictable. You can see changes before applying them.

It feels closer to managing a system rather than running commands on devices.

Controllers Felt Powerful, But Also Slightly Distant

Then I looked at controller-based platforms.This is where you stop thinking about devices directly.

You define something like creating a network across multiple locations, and the system handles the rest.

This looks powerful, especially at scale.But it also feels a bit distant from what is actually happening underneath.

You are relying on the platform to do the right thing.

And while that works for standard use cases, I am not sure how it behaves in edge scenarios.

There is also dependency on the vendor, which changes how flexible your setup is.

So it feels useful, but not something that replaces everything else.

What I Thought Initially vs What I Think Now

Initially, I was trying to figure out which tool is best. That question does not really make sense anymore.

Each approach solves a different part of the problem.

→ CLI is simple but fragile at scale
→ Python scripting gives control but depends on parsing
→ APIs make things structured
→ Ansible and Terraform improve consistency
→ Controllers simplify large environments

It is not about picking one.

It is about understanding where each one fits.

What Actually Stayed With Me

Automation, at least from what I understand now, is not about doing things faster.

It is about making sure the same thing happens correctly every time.

Especially when the system grows.

What I Am Doing Next

Right now I am not jumping into complex automation setups.

Still trying to get basics right. Python network fundamentals
simple scripts

Trying to understand things properly before layering more complexity.

Closing Thought

I am still figuring things out. But one thing feels clear.

Manual processes do not fail immediately. They fail when they scale.

Multicloud is now new normal for Network engineer.

When it comes of AI workload , Companies are no way interested to bet on single cloud provider ,they prefer multi cloud option and for good reason .Reason is simple no one cloud is best on everything

💡 Why Go Multi-Cloud for AI?

Each cloud provider has its own strength

• One might be excellent in providing top tier AI/ML service

• Another might be good in serverless compute

• Third may be providing good pricing as compared to others

So its now the cloud architect task to pick the best provider considering all below points.

• Better uptime and distory recovery

• Dependability on one vendor

• Flexibility and more power while renewing the contract

• Most importantly meeting data residency & sovereignty laws

❓ Is It Common for AI Workloads?

While multicloud is now standard in many IT companies but still less common for AI training Why ?

• Training models is very resource-intensive

• Highly Optimized on a single cloud or even on premises

• Often involves massive datasets which is more expensive to move across clouds.

But once the model is trained...

• Inference (making predication) is less resource intensive

• Can be deployed closer to user

• Reducing latency and providing better user experience.

That’s why inference workloads (predications) are more likely to be spread across clouds.

💾 Managing Data in a Multi-Cloud World

AI workloads run on data—and lots of it.

Managing that across clouds? Needs solid strategy. Here’s a breakdown:

• Portability & Interoperability

  Keep data in sync across clouds using available tools like AWS DataSync.

• Smart Storage Strategies

  Localize storage near compute to reduce data transfer latency

  Hybrid storage(on prem+cloud) offers flexibility and compliance benefits

• Data Consistency

  Use distributed database and leverage available synchronization tools to keep data up to date and accurate across cloud

• Security & Compliance

  Encrypt data in transit and at rest.

  Use governance tools for compliance and auditing

• Cost Optimization

  Use compression

  Avoid unnecessary cross-cloud movement

  Use fast storage for active data wheras cheap storage for archived data.

🔍 Final Thought

Multi-cloud AI isn’t just a trend—it’s a smart, strategic move if done right. But it requires planning, the right tools, and a mindset focused on portability, security, and efficiency.

Container - It’s word that pops up everywhere right ? May be you have gone through few youtube videos .Many of them decent and good jobs explaining concept but here, I want to explain containers in a way that’s super simple, natural, and easy to relate and most importantly, these are my own notes as I’m learning this myself, and as I do, I want to make sure I learn and share along the way.

🚦 The Real-World Problem

Why we even need to know or care about container ?

If you have worked in deveolpment or IT operations, you might be aware of struggle

• The code works perfectly in ppe enviornemnt or on deveoplers own machine

• As soon as code is pushed on production ? Error , crash , mismatch some or other issue

  This disconnet between Dev and Ops is frustrating — it’s sometime costly for companies .And even it today’s exponentially growing tech , its not expected move slow or break things in production. . So what’s the fix ?

  📦 Enter Container-Based Architectures

  We can say Container is solution of the problem . It packages everything application needed - the code , the runtime, libaries and dependencies —- into a single unit .Thus making apps:

• Easily to deploy

• Easier to Update

• Easier to run on any machine

🧱 From Monolith to Microservices

Let’s look at architecure now →

• On the left, you have a traditional way (Monolithic) — all parts of the application bundled together (…all one big block).

• On the right, you split that into smaller services ( Microservcies )— each one running independently in its own container .

Why this is awesome:

• You can scale each part separately.

• You can update one service without touching the others.

• You can deploy services faster and with fewer errors.

Deployment Models: Bare Metal → VMs → Containers

We had bare Metal , VMs then whey there was need of Container .Lets see difference of all three in simplastic way :

Bare Metal

Apps runs directly on the OS . One change or update has potentail to break everything .Its headache for Dev /OPS to troubleshoot or update

Subscribe now

Virtual Machines

Apps now run inside a full virtaul OS .Its more stable but use lot of resourse and is bit slow to start .Each VM can be servaral GBs in size .

Containers

APps shre the Host OS but are completed isolated to each other .Container starts in second and use less resourse .Its portable ,easy to move scale and replicate.

USP — > One container = One service = Super clean and efficient

🧠 How Containers Work

Imagine a container like a lightweight box that holds your application code , all dependencies it need to run and contains seetinga nd config file.

Now, imagine these containers running on your system, isolated but lightweight — just like you ahve multiple apps installed on your phone.

Technically speaking:

• Containers run in a namespace — a sandboxed space on the host OS.

• They behave like mini virtual machines, but they’re just regular processes.

• They share the host’s kernel but are managed separately.

⚙️ Why Developers and Engineers Love Containers

• Fast to Start: Seconds, not minutes

• Clean Deployments: No leftover or conflicts

• Repeatable: “It works on my machine” becomes “It works everywhere”

• Composable: Build systems from plug-and-play components

• Scalable: Quickly spin up more containers during high demand

🧰 Example Tools and Features in the Container Ecosystem

• Docker – The most popular tool to create and manage containers

• Docker Compose – To define multi-container setups

• Kubernetes – For large-scale orchestration

• Monitoring & Telemetry – Containers can be monitored app-wise, not just machine-wise

🧪 For Network Engineers: Why It Matters

Containers aren’t just for app developers — they’re changing network automation too:

• Run various tools like NetBox, or custom scripts in containers

• No OS dependency: works on Linux, Mac, or Windows

• Spin up test labs, tools, or dashboards in seconds

• Extend network devices with containerized apps — safely and easily

🔚 Wrapping It Up

Containers are transforming how we build, deploy, and scale applications. They’re:

• Lightweight

• Fast

• Isolated

• Portable

Whether you're a developer, a DevOps engineer, or even a network engineer, learning Docker and containers will level up your game.

Last week, I was watching a random AI video on YouTube when a thought struck me:

What if AI actually had a important role in networking industry?

This post is the outcome of that thought and bit reserach .

I’ve written a lot of Ansible playbooks recently.

Honestly, it felt magical at first. Push changes across routers with a single play — amazing.
But over time, something about it didn’t sit right.

I kept asking myself: Is this really automation? Or just scripted execution?

The Realization

The more I automated — using Ansible, Python, and even some in-house tools — the more I saw the issue.

Yes, configs got pushed faster. But if something went wrong ?
Manual digging. Logs. Debugs.
No real “Brain” in the system.

It was like teaching a robot to follow steps, but not think.

And then AI started buzzing everywhere. ChatGPT, co-pilots, LLMs...

And the question hit me hard:

What if the system could understand what I want — not just what I tell it?

Subscribe now

What If I Could Say…

“Add a static route for 10.1.1.0/24 via 192.168.1.1 on router R1.”

That’s it.

No YAML. No template variables. Just the intent.

And the system should know:

• Which router R1 is

• What the current config looks like

• Whether that next hop is reachable

• And apply the change safely

Right now, its not a dream. But AI is making it possible.

Where Automation Falls Short

Let’s be honest.

Automation is great. But it:

• Doesn’t understand intent

• Can’t read the network’s topology or policy dependencies

• Doesn’t explain logs

• Doesn’t help you write documentation (which we all love to skip)

• And grows harder to maintain the more scripts you have

We’re building bigger toolboxes — but not necessarily smarter ones.

How AI Can Help

I don’t think AI will replace us. But it’s already helping.

Tools like GPT can:

• Turn natural language into starting configs

• Draft validation logic for pre/post checks

• Generate parts of LLDs

• Parse log outputs and summarize them

And yes — even generate diagrams or mind maps based on device configs.

The One Thing We Always Skip

Documentation.

We all hate it. Most of us leave it to the last minute (or never).
But when something breaks — it’s the first thing we wish we had.

AI can:

• Summarize LLDs

• Highlight change impacts

• Auto-generate diagrams

• Keep things up to date when the network changes

It saves hours of writing and backtracking.

So What’s the Future Look Like?

A hybrid world.

• CLI + YAML + Prompts + AI + Human judgment.

• Systems that suggest. Engineers that decide.

• AI that writes the first draft, and we finalize it.

The goal isn’t to remove engineers.
It’s to remove the repetition — and free us to focus on what matters.

I believe the best network engineers of the in future won’t just configure routers — they’ll Join Hands with AI to design, test, and troubleshoot smarter than ever before.

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

We have already discussed how ansible is used to automate infrastructre .right ?

We right playbooks to handle config and much more .But sometimes these playbooks need senstive information —password API tokens, Licence key ,SSH Keys —Stuff that you dont want to be in plain text.

Now imagine pushing those playbook to Github or Gitlab , may be due to need of collabaration with others. If you just drop your secrets into the YAML as plain text , bascially you are taking risk and sharing your secrets with the world.

🔒 What is Ansible Vault?

Think of Ansible Vault as a password protected envelope for your YAML content . You can encrypyt either:

• Entire files

• Or just individual variables.

This way we can safely version control playbooks with senstive data in locked condition.

🧪 Step-by-Step: Encrypting a File

Let’s say we have critical_data.yml file which has api and licence key

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/critical_data.yml 
---
 api_key: Cisco@123
 licence_key: abcdef
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Let’s Encrypt it :

ansible-vault encrypt ./inventory/critical_data.yml 

It will ask for vault password- choose one and remember. You will need it to decrypt file later

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-vault encrypt ./inventory/critical_data.yml 
New Vault password: 
Confirm New Vault password: 
Encryption successful
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

The contents are now encrypted. ✅

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/critical_data.yml 
$ANSIBLE_VAULT;1.1;AES256
3764346265303562323837363163663030636231373665343763366339343064346331323066638
3035336434306331366230306361396465333635363739300a33373533313238633666666330611
3735616534633434373262343930336136303938303332303136373030313833383739643133361
3032613261666333330a33393431633662623436656538306537336662393838613433383661363
3937653837316337313532353734343432393762346333333636373036353637363032353236306
6438323364373136316432616163396164383564616366653439
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Share

🔓 Decrypting the File

To decrypt it when needed:

ansible-vault decrypt ./inventory/critical_data.yml 

📦 Using Encrypted Files in Playbooks

Lets look back at our playbook

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat ansible_playbook/03_ssh_key.yml 
---
 - hosts: routers
   #gather_facts: false
   vars_files:    
           /home/anurudh/Ansible_Network_Engineer/inventory/critical_data.yml
   tasks:
     - name: Print Ansible Config location 
       ansible.builtin.debug:
        msg: 
        - "{{ ansible_config_file }}"
        - "{{ ansible_user }}"
        - "{{ api_key }}"
        - "{{ license_key }}"((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$  

Let’s run the playbook:

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml 
ERROR! Attempting to decrypt but no vault secrets found
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Expected. We will get ERROR! Attempting to decrypt but no vault secrets found

we need to tell Ansible to ask for the vault password:

ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pas

Then provide the vault password, and boom — it works:

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pass
Vault password: 

PLAY [routers] ******************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************
ok: [r2]
ok: [r1]

TASK [Print Ansible Config location] ********************************************************************************************
ok: [r1] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "ansible_admin",
        "Cisco@123",
        "abcdef"
    ]
}
ok: [r2] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "cisco",
        "Cisco@123",
        "abcdef"
    ]
}

PLAY RECAP **********************************************************************************************************************
r1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
r2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

🤔 Tired of Typing the Password Every Time?

You might have noticed that we have to provide Vault password everytime while running playbook

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pass
Vault password: 

Shouldn’t be great if we dont have to provide Vault password everytime?

Lets see how it can be done.

Lets create a vault password file to store the vault password .

In my case i have take vault password as 1234

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/vid_pass 
1234
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Then update your ansible.cfg:

vault_password_file=/home/anurudh/Ansible_Network_Engineer/inventory/vid_pass

ansible.cfg file for reference

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat ansible.cfg 

[defaults]
inventory = /home/anurudh/ansible/inventory/cisco_devices
transport = network_cli
#host_key_checking =False  # Disables SSH host key checking
vault_password_file=/home/anurudh/Ansible_Network_Engineer/inventory/vid_pass
 

Now you can run your playbook without --ask-vault-pass:

ansible-playbook ansible_playbook/03_ssh_key.yml 

It picks up the password automatically. Nice.

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml 

PLAY [routers] ******************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************
ok: [r2]
ok: [r1]

TASK [Print Ansible Config location] ********************************************************************************************
ok: [r1] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "ansible_admin",
        "Cisco@123",
        "abcdef"
    ]
}
ok: [r2] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "cisco",
        "Cisco@123",
        "abcdef"
    ]
}

PLAY RECAP **********************************************************************************************************************
r1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
r2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Yes, you have got it !!! We have used now Ansible-Vault feature to encrypt our critcial data. You know, we can go ahead and encrypt even out vault password file ?

I hope you can try even to encrypt vault password file .Its all same as above.

Share Automation

✅ Recap

• Ansible Vault is your built-in secret protector.

• It plays nice with Git and automation pipelines.

• Use it to keep your playbooks clean and your credentials safe.

✅ Action Step for You Today

Try it, break it, automate it.
If you’re doing infra-as-code, this is a must-have tool in your Ansible workflow.

I’ll guide you, one simple post at a time.

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

Ever stare at a bunch of IPs and think, "This would be so much easier if these routers had names?" Same. Instead of setting hostnames manually on each Cisco box, here’s a simple way to get Ansible to do it for you. No copy-pasting the same command again and again. Just clean automation.

Let’s get straight into it.

Start With Your Inventory

Open up your hosts.ini file. Here's how I set mine up:

[anurudh@localhost ansible_start]$ cat hosts.ini 

[routers]
1.1.1.1
2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios[anurudh@localhost ansible_start]$ 

This tells Ansible: “Hey, we’re working with Cisco IOS gear, here are the devices, and here’s how to log in.”

Make Sure Ansible Knows What’s Up

Next, check your ansible.cfg. You don’t need anything fancy — just make sure it points to your inventory file and uses the right connection method:

Subscribe now

[anurudh@localhost ansible_start]$ cat ansible.cfg 

[defaults]
gathering = explicit
inventory = hosts.ini
transport = network_cli
#host_key_checking = False  # Disables SSH host key checking
[anurudh@localhost ansible_start]$ 

That commented-out line disables SSH key checking — helpful during testing, but use it wisely.

Now the Fun Part: Auto-Generate Hostnames

You don’t want to manually set hostnames like R1111 and R2222, right? Let Ansible do that. Here's a tiny playbook that makes it happen:

[anurudh@localhost ansible_start]$ cat 04_config_hostname.yml 

---
 - name: Configure Hostane on Cisco routers
   hosts: ios_devices
   gather_facts: no 
   
   tasks:
    - name: set hostname based on IP
      cisco.ios.ios_config :
         lines:
            - hostname R{{ inventory_hostname | regex_replace('\\.', '') }}
            
[anurudh@localhost ansible_start]$ 

What’s happening here?

• inventory_hostname is the IP of each device.

• The regex_replace('\\.', '') bit strips out the dots.

• So 1.1.1.1 becomes R1111. Neat, right?

Let’s See It in Action

Run the playbook like this:

[anurudh@localhost ansible_start]$ ansible-playbook  03_ping_router 

PLAY [check connectivity to cisco routers] *************************************************

TASK [ping the router] *********************************************************************
ok: [1.1.1.1]
ok: [2.2.2.2]

PLAY RECAP *********************************************************************************
1.1.1.1                    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
2.2.2.2                    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost ansible_start]$ 

Once it runs, SSH into your devices to confirm the hostname stuck:

[anurudh@localhost ansible_start]$ ssh cisco@1.1.1.1
(cisco@1.1.1.1) Password: 

R1.1.1.1#exit
Connection to 1.1.1.1 closed.
[anurudh@localhost ansible_start]$ ssh cisco@2.2.2.2
(cisco@2.2.2.2) Password: 

R2.2.2.2#

If you see that hostanme R111 for router 1 and R2222 for router 2, congrats — it worked.

Recap

• You learned how to build hostnames from router IPs

• You used Jinja2 to clean them up

• You pushed config with Ansible

• You did it without repeating yourself 50 times

If you’ve got more routers to name, this setup will save you hours. Add this to your playbook toolbox — you’ll use it again.

Action Step for You Today

Just one thing: make sure to go through the concepts and follow along with the tasks.

I’ll guide you, one simple post at a time.

Buy Me A Coffee

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

In this post, we will have a deep dive into:

• Why SSH matters for Ansible

• How to set up key-based ssh access(no password required)

• Real setup providing steps to push your public key to Cisco routers

• Testing your setup and tshoot with playbooks.

🚀 Why SSH Matters for Ansible

Lets talk about SSH , honestly its one thing which we expect to work while working with ansible.

At its core ,SSH is basically secure tunnel into remote machines. Its how we get in device without physically being there. It used port 22 by default but you can t change it without any issue.

Ansible is agentless, which means it doesn’t need to install anything on the remote machine to work its magic. It just depend upon on SSH to get in, do its job.

So if your SSH setup is broken or misconfigured? Good luck running playbooks. That’s why getting SSH right is half the battle when setting up Ansible.

⚙️ Setting Up SSH for Ansible

Here’s how I usually go about it:

1. Install OpenSSH

Make sure OpenSSH is installed—both on your control machine (where you run Ansible) and the target machines (the ones you want to manage).

To check if it's installed:

[anurudh@localhost ~]$ ssh -V
OpenSSH_8.7p1, OpenSSL 3.2.2 4 Jun 2024
[anurudh@localhost ~]$ 
[anurudh@localhost ~]$ 
[anurudh@localhost ~]$ 

if not , it can be installed like this:

[anurudh@localhost ~]$ sudo yum install openssh-server
Last metadata expiration check: 1:02:08 ago on Sat 03 May 2025 12:33:40 PM IST.
Package openssh-server-8.7p1-45.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[anurudh@localhost ~]$ 

2. Set Up Key-Based Auth

This is important. You don’t want to be typing passwords every time Ansible connects, right?
So generate a key pair on your control node:

[anurudh@localhost ~]$ ssh-keygen

Now if you check your .ssh directory:

anurudh@localhost ~]$ ls ~/.ssh/
id_rsa  id_rsa.pub  known_hosts
[anurudh@localhost ~]$ 

That id_rsa is your private key. Keep it safe. Never share it.

And id_rsa.pub? That’s the one you give to devices so they let you in.

This way, Ansible can log in without needing a password every time.

Subscribe now

3. Test the Connection

Before going all-in with Ansible, test the SSH connection manually:

[anurudh@localhost ~]$ ssh ansible_admin@1.1.1.1

If it logs in without asking for a password—you’re done

Lets walk through each step discussed above with real example

🔧 Real-World Example: Pushing Public Key to a Cisco Device

Let’s go step-by-step on setting up key-based SSH access with a Cisco router.

Lets first check ssh directory in master node

[anurudh@localhost ~]$ ls ~/.ssh/
known_hosts
[anurudh@localhost ~]$ 

Okay, no key yet—let’s generate one:

[anurudh@localhost ~]$ ssh-keygen

After that directory should look like this

[anurudh@localhost ~]$ ls ~/.ssh/ 
id_rsa  id_rsa.pub  known_hosts

Here we have got bot private ( id_rsa ) and public key (id_rsa.pub ) generated. Private key should not leave this machine . We will copy public key to network devices to enable SSH key based authentication.

and now we'll take a look into the public key.

[anurudh@localhost ~]$ cat ~/.ssh/id_rsa.pub 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDiHucZaT0Q6dYc5LD5tYZBfiioPY6WrsryPLV4K7ypw+bS92fWnPorNi5EUvJY4xJ46uCFvIj14JNGBHiUfDDbmX2ZHqsIGe536fh1V7TmkQl/5n1Aq6tikzjui3tBgh5r7O5A3EF6HoU/FsFPGEWPDMLJP0uv2KIVcD5VJDr9SdR62x2b/+6ZhKV6R6v8seEk31El4oFyGIRh8G9e21avqhl9ikoXor9SEaQx5WEVvO3vjHH+JWgyq2QfR3bqC4tXM+BRgpHiJ9PirL/unneZMAQD/+relOVWymY2uMrtSZFvSoWWxE10CabAn2Lc2Fs7MQM6gRFWo4BaPJCCUMwvcv3g7nmIAVY86BDYnzcSCCkR6xzrY4WB1OPfY9bDunDC3ZUWwMHzl/yB8pagl84g83/r/FfGxABntnM7UMBC2rNHUYJYGSOp0GDTO5iJ2YabBoIy99tFEqzoXrqwHsuFxS/oLtNC26eFFuEZ9eAYX1WbV2x9xWipnz6khJo6hw8= anurudh@localhost.localdomain
[anurudh@localhost ~]$ 

So we need to copy and paste this content into Cisco device.

But hold up—Cisco CLI only accepts 256 characters per line. So we need to fold that key before pasting:

[anurudh@localhost ~]$ fold -b -w 64 ~/.ssh/id_rsa.pub

Share

Now let’s jump into the Cisco device:

[anurudh@localhost network_automation_ansible]$ ssh cisco@1.1.1.1(cisco@1.1.1.1) Password: 
R1#

Inside the router

anurudh@localhost network_automation_ansible]$ ssh cisco@1.1.1.1 (cisco@1.1.1.1) 
Password:  
R1#config t Enter configuration commands, one per line.  End with CNTL/Z. R1(config)#username ansible_admin
R1(config)#ip ssh pu 
R1(config)#ip ssh pubkey-chain  
R1(conf-ssh-pubkey)#username ansible_admin 
R1(conf-ssh-pubkey-user)#key-? key-hash  key-string   
R1(conf-ssh-pubkey-user)#key-str 
R1(conf-ssh-pubkey-user)#key-string  
R1(conf-ssh-pubkey-data)#

we will paste public key copied into cisco terminal

R1(conf-ssh-pubkey-user)#key-string
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDiHucZaT0Q6dYc5LD5tYZBfiio
PY6WrsryPLV4K7ypw+bS92fWnPorNi5EUvJY4xJ46uCFvIj14JNGBHiUfDDbmX2Z
HqsIGe536fh1V7TmkQl/5n1Aq6tikzjui3tBgh5r7O5A3EF6HoU/FsFPGEWPDMLJ
P0uv2KIVcD5VJDr9SdR62x2b/+6ZhKV6R6v8seEk31El4oFyGIRh8G9e21avqhl9
ikoXor9SEaQx5WEVvO3vjHH+JWgyq2QfR3bqC4tXM+BRgpHiJ9PirL/unneZMAQD
/+relOVWymY2uMrtSZFvSoWWxE10CabAn2Lc2Fs7MQM6gRFWo4BaPJCCUMwvcv3g
7nmIAVY86BDYnzcSCCkR6xzrY4WB1OPfY9bDunDC3ZUWwMHzl/yB8pagl84g83/r
/FfGxABntnM7UMBC2rNHUYJYGSOp0GDTO5iJ2YabBoIy99tFEqzoXrqwHsuFxS/o
LtNC26eFFuEZ9eAYX1WbV2x9xWipnz6khJo6hw8= anurudh@localhost.local
domain                                                                                          

Press enter and exit

R1(conf-ssh-pubkey-data)#exit
R1(conf-ssh-pubkey-user)#
R1(conf-ssh-pubkey-user)#exit
R1(conf-ssh-pubkey)#

Now test it again from your control node:

[anurudh@localhost ~]$ ssh ansible_admin@1.1.1.1
R1#

if you’re in without a password prompt—Great we have done it .

If not, and you're being asked for a password, try updating your SSH config:

[anurudh@localhost ~]$ sudo vi /etc/ssh/ssh_config

add:

PubkeyacceptedKeyTypes +ssh-rsa

Lets run below playbook now

Here’s a simple Ansible playbook to check inventory details:

[anurudh@localhost network_automation_ansible]$ cat 03_cisco_inventory_check 
---
 - name: Cisco inventory check
   hosts: ios_devices
   #
   gather_facts: false

   tasks: 
    - name: print Ansible config location
      ansible.builtin.debug:
        msg:
         - "{{ ansible_config_file }}"
         - "{{ inventory_file }}"
         - "{{ ansible_facts }}"
         - "{{ ansible_user }}"

[anurudh@localhost network_automation_ansible]$ 

run it

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
ok: [R2]
ok: [R1]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R1] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R1", .....},
        "ansible_admin"
    ]
}
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2", ....},            
        "cisco"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost network_automation_ansible]$ 

So R1 is using the ansible_admin user we set up for key-based access. R2 is still using the default cisco user from the group vars.

Lets check our inventory file

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

R1 has its own user and SSH key setup. R2 falls back to the default group settings. Simple, flexible, and super clean.

let change private key file location to something different , if we get error after playbook , it means that ssh key is working perfectecly

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin ansible_ssh_private_key_file=/home/anurudh/.ssh/id_rsa_2
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

configured wrong file name —> /home/anurudh/.ssh/id_rsa_2

lets run same playbook again

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
fatal: [R1]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"ansible.legacy.ios_facts": {"failed": true, "invocation": {"module_args": {"available_network_resources": false, "gather_network_resources": null, "gather_subset": ["min"]}}, "msg": "[Errno 2] No such file or directory: '/home/anurudh/.ssh/id_rsa_2'"}}, "msg": "The following modules failed to execute: ansible.legacy.ios_facts\n"}
ok: [R2]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2" ....},
        "cisco"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost network_automation_ansible]$ 

R1 is failing as it not having correct ssh key path. so we are good and It means R1 is taking SSH authentication .

Lets modify inventory file and correct it

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin ansible_ssh_private_key_file=/home/anurudh/.ssh/id_rsa
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

lets run same playbook again

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
ok: [R1]
ok: [R2]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2".....},
        },
        "cisco"
    ]
}
ok: [R1] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R1"......},
        "ansible_admin"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

We have done it !!!!

Action Step for You Today

Just one thing: make sure to go through the concepts and follow along with the tasks. Try to complete them within two days after the post is published.

I’ll guide you, one simple post at a time.

Buy Me A Coffee

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

When it comes to automation tools for networks and infrastructure, they aren't all built the same way.
Here are some important differences you should know — explained in a way that’s easy to understand:

1. Building vs. Setting Up Infrastructure

• Infrastructure provisioning is like building the house — setting up walls, roofs, windows, and doors (things like servers, network connections, and databases).

• Configuration management is like setting up the inside of the house — adding beds, lights, and furniture (installing and configuring the right software).

Provisioning happens on Day 0 (building), and configuration happens on Day 1 (setting things up properly).

2. Agent-Based vs. Agentless Tools

• Agent-based tools need a little helper (software) installed on each device to manage it.

• Agentless tools don’t need any helper installed; they connect directly.

In networking, agentless tools are often better because many devices don’t allow installing extra software.

3. Centralized vs. Decentralized Control

• Centralized = one big "boss" server tells all devices what to do.

• Decentralized = devices manage themselves or work with each other without a central boss.

4. Special Language vs. Common Language

• Some tools use their own special language (DSL), and you have to learn it to use the tool.

• Other tools use common formats like YAML, making it easier because many people already know it.

5. Declarative vs. Imperative Approaches

• Declarative = you say what you want ("I want a red living room") and the system figures out how to do it.

• Imperative = you tell it step-by-step ("First paint the wall red, then bring in a big sofa").

  Subscribe now

6. Extending Tools with Programming

• Many tools let you add extra features using common languages like Python or Go — kind of like upgrading your house with smart gadgets.

7. Push, Pull, and Event-Driven Actions

• Push model = you send instructions to the devices.

• Pull model = devices ask for new instructions themselves.

• Event-driven = devices act when something specific happens (like turning on lights when someone rings the doorbell).

8. Mutable vs. Immutable Infrastructure

• Mutable = you change things in the house while living in it (like repainting while living there).

• Immutable = if you want changes, you build a brand-new house and move in.

Share Automation

9. Managing the "State" of Infrastructure

• Some tools don’t remember what was changed — you have to check manually.

• Other tools keep track of everything they built and know when something needs to be rebuilt or fixed.

Smiles:)

Anurudh

Buy Me A Coffee

Ansible Mastery: Part 3 – Your First Real Playbook to Ping Routers

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check out part 1 & part 2 before diving into this post. .We have already gone through Ansible basics and different files structure used in Ansible in previous post.

• Part 1:Why Every Network Engineer Should Learn Ansible (Even If You’re Just Starting Out)

• Part 2: https://netomate.substack.com/p/why-every-network-engineer-should

Subscribe now

In this post, we will cover :

• Understanding the structure and components of an Ansible Playbook

• Writing a first playbook to ping routers

• How tasks are executed on remote Cisco devices.

Lets dive in.

Create a New Playbook File

I always prefer to start with creating playbook then go ahead with other files around it.

Lets create a new file - 02_ping_router.yml

anurudh@localhost network_automation_ansible]$ cat 02_ping_router.yml
---
 - name: check connectivity to cisco router using ping module
   hosts: ios_devices
   gather_facts: no
   tasks:
     - name: ping the router
       ping:
        

        

This is where we’ll define what to run, on which devices, and how.

Remember: Ansible playbooks use YAML, so indentation matters ! Stick to spaces, never tabs.

Understand Ansible Playbook Structure

Ansible Playbook is YAML file which describes what tasks should be executed and on which hosts. Lets understand each line of playbook

---
 - name: check connectivity to cisco router using ping module
   hosts: ios_devices
   gather_facts: no
   tasks:
     - name: ping the router
       ping:
        

Main Components:-

• name : Human readable title .It tells about exactly what this playbook is used for.

• hosts: which devices to target from inventory file (hosts.ini). Here ios_devcies is group of hosts on which task will be pushed.

• gather_facts: Whether should ansible should collect facts.We will explore about in upcoming posts. currently Lets make it no.

• tasks: The task to be performed .

• Each task uses ansible module .Here we have used “ping” module in our playbook.

  We will talk about module in details in coming posts.

Updated Folder Structure

Here’s your project should look by now.

anurudh@localhost network_automation_ansible]$ tree
.
├── 01_ping_router_local.yml
├── 02_ping_router.yml
├── ansible.cfg
└── hosts.ini

0 directories, 4 files
[anurudh@localhost network_automation_ansible]$ 

If you haven’t set these up yet, I recommend going through Part 2 first for further details.

Run the Playbook

Lets run the below playbook with “ansible-playbook” command .This is very basic playbook is used to check reachability of R1 and R2 from master node.

[anurudh@localhost network_automation_ansible]$ ansible-playbook 02_ping_router.yml 

Expected Output:

Task 1: Ping the routers :

If you see “ok” for each device. Congrats ! your playbook is working .

TASK [ping the router] *************************************************************************************************
ok: [R1]
ok: [R2]

anurudh@localhost network_automation_ansible]$ ansible-playbook 02_ping_router.yml 

PLAY [check connectivity to cisco router using ping module] ************************************************************

TASK [ping the router] *************************************************************************************************
ok: [R1]
ok: [R2]

PLAY RECAP *************************************************************************************************************
R1                         : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
R2                         : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost network_automation_ansible]$ 

If you see “ok” for each device. Congrats ! your playbook is working .

We have just automated our first network verification tasks.

Action Step for You Today

Just one thing: make sure to go through the concepts and follow along with the tasks. Try to complete them within two days after the post is published.

I’ll guide you, one simple post at a time.

Buy Me A Coffee

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

In this post, i will go through how to :

• Set up ansible in system

• Set up lab in GNS/EVE/CML

• Create a basic inventory

• Run first ping command using ansible to test connectivity to network devices

Lets dive in.

Install Ansible

To get start, we will get ansible install in our system

sudo apt update
sudo apt install ansible

Once installed, confirm it by running:

[anurudh@localhost ~]$ ansible --version
ansible [core 2.15.13]
  config file = None
  configured module search path = ['/home/anurudh/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
  ansible collection location = /home/anurudh/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.9.21 (main, Feb 10 2025, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)] (/usr/bin/python3)
  jinja version = 3.1.6
  libyaml = True
[anurudh@localhost ~]$ 

You should see Ansible's version and installation path.

It may be different command for you to install Ansible if you are using any other operating system apart from Linux(Ubuntu)

Refer below link for details

https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

lets now create and go through different files to be used in ansible. Its very crucial to understand each file before actually going through ansible tasks.

Ansible Configuration (ansible.cfg)

Hope you remember the above structure from Ansible post 1.Below is the tree view of my directory .

ansible.cfg → Its ansible config file It will be applicable to current directory .It includes various settings including which inventory to use and the transport method for connecting to devices. Our ansible file content is as below:-

[anurudh@localhost network_automation_ansible]$ cat ansible.cfg 

[defaults]
inventory = hosts.ini
transport = network_cli
#host_key_checking = False  # Disables SSH host key checking
[anurudh@localhost network_automation_ansible]$ 

• Explanation:

  • inventory: Points to your hosts.ini file.

  • transport: Specifies that Ansible will use network_cli to connect to network devices (like Cisco).

  • host_key_checking = False: Disables SSH key verification, which is useful if you're not using trusted SSH keys for the devices.

Inventory File (hosts.ini)

In Ansible, the inventory file lists the devices you want to manage. Here’s an example of an inventory file (hosts.ini) that connects to Cisco routers using network_cli.

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
#1.1.1.1
#2.2.2.2
R1 ansible_host=1.1.1.1
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

• Explanation:

  • [routers]: Defines the group of routers.

  • [ios_devices:children]: Groups devices under ios_devices which are listed as children of routers.

  • [ios_devices:vars]: Specifies global variables for all devices in the ios_devices group.

Test Connectivity Using the Ping Module

The first test you should run is the ping module to check if your Ansible is correctly communicating with the network devices.

We have got our Master node where we have install ansible and running our ping tasks using ping module for Node R1 and R2.

Make sure SSH reachability is enabled from master node to various router switches and all respective nodes. As discussed in post 1 that ansible is agent less and there is no need to install any agent(software ) on nodes. Ansible uses SSH to access nodes and perform various playbook tasks.

[anurudh@localhost network_automation_ansible]$ cat 01_ping_router_local.yml 
---
- name: Simple Ping Test
  hosts: localhost
  gather_facts: no

  tasks:
    - name: Ping localhost
      ansible.builtin.ping:
[anurudh@localhost network_automation_ansible]$ 

The first test you should run is the ping module to check if your Ansible is correctly communicating with the network devices.

Run the Ping Command:

[anurudh@localhost network_automation_ansible]$ ansible ios_devices -i hosts.ini -m ping

• Explanation:

  • ios_devices: The group you defined in your hosts.ini file.

  • i hosts.ini: Specifies the inventory file.

  • m ping: Uses Ansible’s ping module to test connectivity.

• Output

  If successful, you should see a pong response from each device:

[anurudh@localhost network_automation_ansible]$ ansible ios_devices -i hosts.ini -m ping
R1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
R2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
[anurudh@localhost network_automation_ansible]$ 

We have not yet created our first playbook .We will perform same task using playbook in next post.

Troubleshooting Tips

• If the ping command doesn't work:

  • Check if SSH is accessible from your local machine to the routers.

  • Ensure the ansible_user and ansible_password are correct for your devices.

• Make sure that the network_cli connection method is supported by your device and its OS.

  📌 Action Step for You Today

  Just one - Try out the steps and share experiences or questions in the comments.

  Buy Me a Coffee

  I’ll guide you, one simple post at a time.

  We will discuss about execution of our first playbook in next post .

  Smiles:

  Anurudh

Just many of you , I also started my networking journey with manual config troubleshooting the various issue .

But actually we are spending so much time doing the task which can be done in minutes and worst of all ,when something went wrong , we had no way to audit or fix things .

🤖 Enter Ansible: My Automation Partner

Here comes the Superhero Ansible . We will be going through ansible from basic to intermediate to advance. You may see multiple post related to Ansible in coming days. It will have both theory as well as practical examples to try .

Main goal of Ansible series is -:

• Make Ansible simple and actionable

• Teach through networking-focused examples

• Blend theory + "Try This Now" practical’s

• Keep posts bite-sized & consistent

• Help readers build confidence to automate on their own

🛠️ So… What Exactly is Ansible?

Lets start with a theory what is ansible and why network engineer should care ?

Just many of you , i also started my networking journey with manual config troubleshooting the various issue .

But actually we ere spending so much time doing the task which can be doing in minutes .

Yes , its possible by Ansible. Its super tool which can help :

• Push consistent configs across devices

• Automate boring, repetitive tasks

• Reduce human error

• Save time (LOTS of it)

• Focus on what really matters

what really matters is that you need not be python expert.

Ansible is open source automation tool and we can say its task execution engine. What it means that we have to define the task and ansible will perform those tasks. Ansible is project written in python .

Its uses YAML file to read the task and execute it on the network devices.

It automated tasks such config management ,application deployment and much more.

It uses ssh to connect to nodes .It’s called as agentless as there is no need to install any agent to nodes where you require task to be executed.

Core component of Ansible :

• Playbook → File consist of list of plays and respective tasks.

• Inventory →File which identifies the hosts in your environment

• Variable → Are consumed at tasks level used as input to various tasks.

• Config file → Administrative file to control global setting related to ansible environment

Play is element of playbook and executed against a set of hosts . It consists a list of tasks .

Tasks are element of play executed in sequence .Each task calls a module. Modules are written in python and work behind the scene. They are like function already built and we need to call in respective tasks.

Playbook be something like-:

Just this 5-liner shows "it's not scary." Easy to understand and execute.

📌 Action Step for You Today

Just one: you will read concepts mentioned in detail and decide that you will try and execute with me with playbook coming in next post.

I’ll guide you, one simple post at a time.

We will discuss about the ansible environment installation and execution of our first playbook in next post .

Smiles:

Anurudh

Buy me a Cofee