Cloud & Network Engineering student · Linux · AWS · Python · Security-aware networking
I learn best by building things and then figuring out why they work—or why they don't.
I'm working through the AWS track of WGU's B.S. Cloud and Network Engineering program. Most of what sticks for me comes from hands-on labs: setting something up, breaking it on purpose, looking at the evidence, and tracing the problem back to the source.
Networking is where I feel most at home, but I also spend a lot of time in Linux, AWS, Python, automation, and security.
I started this project because I wanted a better way to answer a simple troubleshooting question:
What changed?
Network Flight Recorder captures a known-good network state, watches for meaningful changes, and keeps enough evidence around to help explain what happened during a failure.
Some of the pieces I've built into it so far:
- local-first troubleshooting
- Docker-based failure injection
- Python tests and CLI tooling
- Terraform-managed AWS infrastructure
- S3 evidence storage
- CloudWatch metrics and logging
- guarded remediation with verification and rollback
- GitHub Actions for automated checks
Python · Linux · Docker · Terraform · AWS · S3 · CloudWatch · GitHub Actions · pytest · Ruff
I wanted to see what happens when a route disappears, so I built three connected routers with FRRouting and Docker Compose, each in its own autonomous system.
Then I turned off the direct link between two of them. BGP found the backup path, but the return traffic took longer to catch up. Watching the ping pause made the difference between having a backup route and actually recovering a connection much clearer.
I compared the original BGP timers with shorter settings on that link. In two manual runs, lost ping replies dropped from 176 to 7. Both runs recovered through the third router, and restoring the link brought the direct route back.
The repo includes the topology, route filters, commands to repeat the tests, and the results with their measurement limits.
BGP · FRRouting · Docker Compose · Linux · IPv4 · Route filtering · Failover testing
I wanted to understand what "the tunnel is up" actually proves, so I built both sides of a routed IPsec path and traced traffic all the way through it.
The Ubuntu Client at 10.10.10.10 reaches a simulated cloud workload at 10.20.0.10 through two Linux gateways and a strongSwan IKEv2/IPsec tunnel. I worked through NAT exemption, XFRM policy/state, forwarding, return routing, ARP, tcpdump, network namespaces, veth pairs, and duplicate Security Associations.
The finished lab survives reboot on both gateways and returns end-to-end traffic with 0% packet loss. The next phase is applying the same troubleshooting method to AWS Site-to-Site VPN.
Linux · strongSwan · IKEv2 · IPsec · XFRM · nftables · tcpdump · network namespaces · systemd
Read the validation notes → · AWS extension →
This project came from a real workflow problem: knowing whether a sales order actually made it from "created" to "FedEx has the package."
The app watches for a sales-order email, starts a 72-hour timer for the shipping label, matches the tracking number when it arrives, and then starts a second timer waiting for FedEx to acquire the package.
Once FedEx has it, the order is done. The customer can track it from there.
So far it has:
- Gmail intake
- automatic overdue alerts
- alert deduplication
- a browser dashboard
- SQLite persistence
- FastAPI endpoints
- GitHub Actions
- tests around the order and status flow
The next piece is replacing the simulated FedEx event with the real FedEx tracking API.
Python · FastAPI · SQLAlchemy · SQLite · Gmail/IMAP · SMTP · GitHub Actions · pytest
Two Ubuntu systems I used to work through routing, NAT, DNS, SSH, Apache, nftables, and packet inspection with tcpdump.
This lab helped turn a lot of networking concepts from diagrams into things I could actually see and troubleshoot. It is now the local foundation for my Hybrid Cloud VPN Lab.
A documented Tor middle-relay deployment focused on Linux services, TCP/IP, port configuration, logging, and traffic validation.
An authorized lab for learning how insecure direct object references and broken access control show up in real HTTP requests.
My technical journal for routing, distributed systems, cloud architecture, failure analysis, observability, and the engineering lessons I pull out of hands-on labs.
My career-facing portfolio site with project highlights, certifications, career materials, and supporting web pages.
| Area | Working with |
|---|---|
| Networking | TCP/IP, IPv4, subnetting, DNS, DHCP, NAT, VLANs, routing, switching, firewalls, VPN troubleshooting, packet analysis |
| Linux & systems | Ubuntu, systemd, Bash, SSH, NGINX, permissions, services, logging, virtualization, system troubleshooting |
| Cloud & infrastructure | AWS, S3, CloudWatch, IAM, Terraform, Docker, infrastructure as code |
| Development & automation | Python, FastAPI, SQLAlchemy, pytest, Ruff, Git, GitHub Actions, JSON, CLI tooling |
| Security | Network visibility, access control, dependency auditing, evidence protection, secure-by-default design |
- CompTIA Network+
- CompTIA A+
- LPI Linux Essentials
- ITIL 4 Foundation
- CompTIA IT Fundamentals
Right now I'm spending most of my time on Cisco/CCNA concepts, Linux troubleshooting, AWS networking, Python automation, network observability, and defensive security.
I'm trying to get better at following a problem across layers instead of treating each tool as its own separate thing.
I'm working toward network and cloud engineering roles where troubleshooting is a big part of the job.
I'm especially interested in network operations, cloud support, infrastructure support, systems administration, and security-aware networking.
I'm based in North Alabama and especially interested in the Huntsville area.
LinkedIn · Architecture Journal · Portfolio
Light in one hand. Linux in the other.
