A little corner of the internet
I work on networks, build tools, and spend some of my free time looking up. This is where I share what I’m working on and a few things that interest me.
Hello there
I’m a Network Engineer supporting Walmart Global Tech through Apex Systems. My day-to-day work is in L2 network operations: figuring out what’s gone wrong, getting service back, and helping the next investigation go a little smoother.
My work moves between day-to-day production troubleshooting and rotating escalation coverage. That can mean working through a persistent connectivity problem or joining an active outage where several teams need a clear picture of what the network is doing.
I use packet analysis, monitoring data, and device diagnostics to investigate routing, switching, circuit, hardware, and network-service issues. I carry out operational remediation, coordinate with carriers, vendors, and engineering teams, then validate restoration and monitor stability.
Our team supports retail, club, distribution, campus, data center, and WAN connectivity, alongside DNS, DHCP, and IP address management. L2 is the operational step beyond front-line triage: I investigate and restore service, escalating design or lifecycle changes with the evidence engineering teams need.
The day job
I work from the symptom back to the fault: interface errors, a missing route, an unstable peer, or a circuit that is no longer carrying traffic as expected. I compare device state with monitoring history and packet behavior to narrow the problem across LAN, WAN, and backbone environments.
Assessing business impact, applying operational fixes, and validating stability. When hardware fails, I coordinate replacement and vendor support, track progress, and keep a clear handoff across shifts.
A connectivity issue can involve the physical link, switch port, VLAN, power delivery, or services such as DNS and DHCP. I trace those dependencies—including the infrastructure serving wireless access points—and bring in specialist teams with the findings they need to continue the investigation.
Python, shell scripts, and APIs for inventory queries and troubleshooting helpers. Runbooks, diagnostic playbooks, and incident lessons make the next investigation easier.
A few familiar tools
Made along the way
Tools that make work easier, and experiments that help me understand networks better.
Interactive network troubleshooting tool
I built an interactive terminal application for exploring device information, routing state, interface statistics, and circuit data during troubleshooting.
Why I built it During troubleshooting, I often need several views of the same device: its hardware, interfaces, neighbors, and routing state. Writing separate queries and working through raw results interrupts that investigation. TitanView brings those lookups into one menu-driven workflow.
Python · Interactive terminal UI · Search & filtering · Formatted tables
Search for a device, select the intended result, and move from its overview into interfaces, neighbors, routing information, or performance metrics. Autocomplete and readable tables make the results easier to navigate. I refined device selection and usability around the friction I encountered in engineering workflows, so more of the interaction stays focused on the question being investigated.
Hands-on wireless engineering
I designed and built a three-access-point lab to study how RF conditions and client roaming affect the experience of using a wireless network. Overlapping coverage, segmented SSIDs and VLANs, and a wired test server let me investigate more than whether a client was simply connected.
Why I built it I wanted to understand why a client could show a good signal and still perform poorly—or stay attached to a distant AP when a closer one was available. I tested channel plans, channel widths, and transmit power, then compared the RF measurements with throughput, latency, retries, and interruptions during roaming.
Wireshark · iPerf3 · Python · 802.11 · RF analysis · VLANs
I established RF baselines, changed channel and power settings, and repeated walking tests with continuous traffic. A wired iPerf3 server kept Internet performance out of the comparison. I brought client telemetry into a dashboard and built Python analysis to flag unhealthy measurements and potential sticky-client behavior. In my tests, strong RSSI alone did not guarantee a healthy connection; wider channels and higher power also came with tradeoffs. Comparing clients showed how much roaming behavior depends on the device itself.
Home networking & service observability
I deployed Pi-hole and Unbound on a Raspberry Pi to filter DNS requests across my home network. What started as an ad-blocking project grew into a lab for recursive DNS, device behavior, segmentation, and the reliability of a service every client depends on.
Why I built it I wanted visibility into the domains my devices requested and a way to apply filtering across devices that cannot run browser extensions. I separated trusted, IoT, and guest clients, tested different filtering policies, and checked that legitimate applications still worked after changes.
Raspberry Pi · Linux · Pi-hole · Unbound · Python · Grafana · Wireshark
I used dig, query logs, and packet captures to compare cached and uncached lookups and isolate failures between clients, Pi-hole, and Unbound. Python tooling summarized service health and flagged unusual query patterns for investigation. I also stopped services and tested a secondary resolver to observe recovery behavior. The main lessons: aggressive blocklists can break useful features, encrypted DNS can bypass local filtering, and a query spike is a reason to investigate rather than proof of malicious activity.
Astronomy meets automation
I’m building a Raspberry Pi-based controller to bring telescope control, image capture, environmental sensing, and session telemetry into one place. The aim is an autonomous imaging workflow; today, the individual components are working while the end-to-end automation is still taking shape.
Why I built it An imaging session involves coordinating the mount, camera, guiding, and changing conditions. I want to connect those steps through a modular control layer so less of the session depends on manual intervention—and so the logs help explain what happened when something goes wrong.
Raspberry Pi · Linux · Python · Mount & camera control · Environmental sensing · Telemetry
Mount communication, sidereal tracking, basic exposure sequences, environmental sensing, dew-point calculation, manual PWM heater control, and a telemetry dashboard are functional. The current sequencer still assumes the telescope is positioned and guiding is already established. Next up are guide telemetry, plate solving, and automatic dew-heater adjustment. Target acquisition, dithering, autofocus, scheduling, meridian flips, and autonomous safety shutdown remain planned; fault logging is working, but automated recovery is not complete.
I also experiment with troubleshooting scripts and personal networking: VLANs, segmentation, VPNs, and wireless links. It’s another way to work through how networks behave.
Working things out
I start with what is failing, who or what is affected, and when the behavior changed. That scope sets the urgency and helps focus the investigation.
I compare monitoring history, device state, and packet captures to isolate the fault. When the evidence points beyond the network, I share what I have ruled out and what still needs investigation.
After applying an operational fix or coordinating a replacement, I check that service has recovered and watch for stability. A cleared alert is one signal; the affected service also needs to work.
During the incident, I communicate impact, findings, and the next action. At handoff, I document what was tested, what changed, and what remains open so the next shift can continue the work.
I capture recurring patterns in problem records and runbooks, escalate issues that need longer-term engineering changes, and build helpers for the lookups I keep repeating.
Away from the keyboard
Outside of work, I’m a big space enthusiast. I own several telescopes and recently started exploring astrophotography. Astronomy is something I enjoy both through a telescope and through the things I read.
A few space and astronomy reads I’ve enjoyed.
Quanta Magazine Podcast & transcript
A conversation with Adam Riess about why measurements of cosmic expansion disagree—and what might resolve the Hubble tension.
Scientific American Article
An investigation into quasars that rapidly dim or brighten, and what those changes reveal about matter around supermassive black holes.
Scientific American Article
A look at the first generation of stars in the early universe.
Say hello
Have a network problem, a project idea, or a good space article to share? I’d be happy to hear from you. Career conversations are welcome, too.