IP Route Life
Notes, write-ups, and lessons learned from a life spent routing packets.
Use the sidebar to browse posts, or press / to search.
Welcome to IP Route Life
This is the first post on IP Route Life — a blog about networking, network automation, routing, network design, cloud networking and the day-to-day of working in IT.
What to expect
- Net Dev Ops
- Networking fundamentals and study notes
- Real-world troubleshooting stories
- Config snippets and command references
Why this blog exists
Writing things down is the best way to actually learn them. This blog follows a documentation-as-code approach: every post is a Markdown file, tracked in Git, built into a static site, and deployed automatically.
How This Blog Is Built
This blog follows a documentation as code approach.
The stack
- Posts are written in Markdown
- Git tracks every change
- mdBook turns the Markdown into a static HTML site
- GitHub Pages + GitHub Actions build and deploy the site automatically on every push
- A custom domain with a free, auto-renewing SSL certificate (via Let’s Encrypt, provisioned by GitHub Pages)
Local development
mdbook serve
vscode
This starts a local server with live-reload at http://localhost:3000, rebuilding the site every time a .md file is saved.
Publishing
git add .
git commit -m "New post: <title>"
git push
Pushing to main triggers a GitHub Actions workflow that builds the book and deploys it to GitHub Pages — no manual upload required.
OSPF Multi-Area NetDevOps Lab
Project Overview
This lab demonstrates a multi-area OSPF topology built in Cisco Modeling Labs and managed using beginner NetDevOps practices.
The goal of this project is to reinforce OSPF design fundamentals while learning how network engineers can use automation, validation, version control, and CI/CD workflows to manage network changes.
Lab Goals
- Build a multi-area OSPF topology in Cisco Modeling Labs
- Use Area 0 as the OSPF backbone
- Connect all non-backbone areas back to Area 0
- Validate OSPF neighbor relationships before changes
- Use automation to push a controlled network change
- Validate OSPF routing after the change
- Track all code and configuration changes with Git and GitHub
Topology Design
The lab uses five routers:
| Router | Role | OSPF Area |
|---|---|---|
| R1 | Backbone Router / ABR | Area 0, Area 10 |
| R2 | Backbone Router / ABR | Area 0, Area 20, Area 30 |
| R3 | Internal Router | Area 10 |
| R4 | Internal Router | Area 20 |
| R5 | Internal Router | Area 30 |
OSPF Area Layout
| Link | OSPF Area |
|---|---|
| R1 to R2 | Area 0 |
| R1 to R3 | Area 10 |
| R2 to R4 | Area 20 |
| R2 to R5 | Area 30 |
NetDevOps Workflow
This project will follow a simple network automation workflow:
- Build the baseline topology
- Configure OSPF manually first
- Validate the baseline network state using pyATS
- Use Ansible to push a controlled change
- Run post-change validation using pyATS
- Commit the changes to GitHub
- Use GitLab CI/CD for linting and pipeline checks
Planned Automation Change
The first automated change will add a loopback interface to R3 and advertise it into OSPF Area 10.
Expected result:
- R3 has a new Loopback30 interface
- The loopback route appears in the OSPF routing tables of the other routers
- OSPF neighbor relationships remain stable
Skills Practiced
- OSPF multi-area design
- Cisco IOS configuration
- Cisco Modeling Labs
- Git and GitHub
- Cisco pyATS network validation
- Ansible automation
- GitLab CI/CD fundamentals
Current Status
- Topology built in Cisco Modeling Labs
- IP addressing configured across all routers
- Multi-area OSPF configured successfully
- All OSPF neighbors are in FULL state
- Inter-area routing verified across backbone
Validation Commands Used
- show ip ospf neighbor
- show ip route ospf
- show ip ospf interface brief
Completed Workflow
This lab now demonstrates a basic NetDevOps workflow:
- Built a multi-area OSPF topology in Cisco Modeling Labs
- Established SSH access to all IOSv routers
- Created a pyATS testbed file for device connectivity
- Wrote a Python validation script to check OSPF neighbor state
- Added route validation for OSPF-learned networks
- Used Ansible to add Loopback30 to R3
- Advertised 10.30.30.30/32 into OSPF Area 10
- Re-ran validation to confirm the loopback route propagated to R1, R2, R4, and R5
Validation Results
The pyATS validation script confirms:
- All expected OSPF neighbors are in FULL state
- OSPF routes are present in the routing table
- The new loopback route
10.30.30.30/32is learned by remote routers after the Ansible change