It has been a busy couple of months since finishing my capstone.
I officially graduated from Western Governors University with my B.S. in Information Technology, and I also started a new position as a Network Support Specialist at NEOnet. The capstone ended up being a fitting final project for the degree; I built a multi-site campus network, discussed it during my interview, and then moved into a position where I am now supporting network infrastructure professionally.
The biggest change has been the type of networking I am learning. Most of my experience before this point was centered around route/switch, campus networks, security, and the usual infrastructure services sitting behind them. I am still working with all of that, but I have also started digging much further into Cisco Unified Communications and how voice actually moves through a network.
I also had the chance to return to the (OH)NUG Cleveland Summer Event, which felt well-timed now that networking has become the center of my work rather than something I was still trying to move toward professionally.
Finishing WGU
Graduating from WGU feels less dramatic than I expected, mostly because the transition into my new position happened so quickly. I submitted the capstone, passed, completed the remaining graduation steps, and then moved directly into learning an entirely new area of networking.
Still, finishing the degree means a lot to me.
When I chose the BSIT instead of the Network Engineering and Security program, I wanted the freedom to shape a general IT degree around the work I was already doing. That ended up being the right decision. I used projects to explore VXLAN-EVPN, fiber attenuation, Linux, network services, protocol emulation, and eventually the Cisco CML campus network that became my capstone.
The program gave me enough room to make the work relevant instead of treating every assignment like an isolated academic exercise. It also forced me to document and explain what I built, which has probably been more useful professionally than memorizing another list of terms for an objective assessment.
My capstone was the clearest example of that. It was not a production network or a full SD-WAN deployment, but it was large enough to expose real design and troubleshooting problems. I had to work through BGP, centralized DHCP and DNS, ACL behavior, syslog, WAN impairment, and the difference between what the topology actually proved and what I originally wanted it to prove.
That project also came up during my interview at NEOnet, so it ended up serving as more than a graduation requirement. It gave me a complete technical story to talk through: what I designed, why I made certain decisions, what broke, and where I deliberately limited the scope.
Starting at NEOnet
My new position as a Network Support Specialist has been a major step forward because networking is now the center of my work rather than one responsibility mixed in with everything else.
I am still very early in the position, and I have a lot to learn about the systems and environments I will be supporting. I also need to be careful about what I discuss publicly, so this blog will not turn into a running diary of production configurations or customer issues. What I can write about are the technologies themselves, the labs I build around them, and the concepts I am learning as I become more familiar with voice.
Before moving on, I would like to thank my previous supervisor, Kyle Livengood, for referring me to this position. His referral helped open the door to an important next step in my career, and I am grateful for his support.
Getting Into Cisco Voice
So far, Cisco voice has been the largest new subject for me. It combines the route/switch and troubleshooting experience I already have with a call-control system that has its own routing, policy, and media decisions layered on top of the network.
A Cisco phone first has to become a functioning network endpoint. It may learn its voice VLAN through CDP or LLDP-MED, request an address through DHCP, receive its TFTP information through option 150, download its configuration, and then register with Cisco Unified Communications Manager.
Once the phone is registered, CUCM has to determine what happens when someone dials a number. Partitions and Calling Search Spaces control which destinations a phone is allowed to reach, while route patterns, route lists, route groups, and transformations determine where the call goes and what the digits should look like along the way.
This has probably been my favorite part of voice so far because it feels similar to routing, except the prefixes are telephone numbers and the forwarding policy is distributed across several CUCM objects. Two phones can have perfect IP connectivity while still being unable to call one another because the dial plan does not provide the necessary reachability.
I have also been learning the separation between signaling and media. SIP establishes and manages the call, while SDP describes details such as the proposed codecs, addresses, ports, and DTMF capabilities. Once the session is established, the audio or video is normally carried through RTP.
That separation explains several problems that initially seem strange. A phone can ring, the call can connect, and the timer can begin counting while neither person can hear the other. SIP may have completed successfully, but RTP could still be blocked, routed incorrectly, or sent toward an unreachable address.
Cisco Unified Border Element, or CUBE, adds another layer by sitting between separate voice systems and creating a SIP call leg on each side. It can translate numbers, modify SIP headers, negotiate codecs, anchor media, and handle differences between CUCM and an outside provider. Since CUBE runs on IOS XE and uses dial peers to match and route calls, parts of it feel familiar even though the traffic being routed is now a conversation instead of an IP packet.
I have been using the 350-801 CLCOR material as a loose outline for my studies. I am not rushing toward an exam date, but the blueprint has been helpful for identifying the areas I understand, the areas I only recognize by name, and the areas I have not encountered yet.
Hopefully, I will get my CCNP one of these years :)
(OH)NUG Cleveland Summer Event 2026
On July 9, I attended the (OH)NUG Cleveland Summer Event at the Wild Eagle in Broadview Heights.
Last summer, attending my first OHNUG meeting was one of the highlights of the year. At that point, I was still working toward a full-time networking position and trying to meet more people involved in the field. Returning this year felt different because I had finished WGU, started working at NEOnet, and finally had more practical context for the conversations happening around me.
The keynote was presented by Mitch Vaughan and was titled Interop Testing — Into the Thunderdome!
The subject felt especially relevant after spending the past several weeks learning Cisco voice. Interoperability is one of the recurring challenges in collaboration systems. Two platforms can both claim to support SIP while still disagreeing about headers, timers, codecs, SDP behavior, or some small implementation detail that prevents a call from working correctly.
Standards give vendors a common language, but they do not guarantee that every implementation will behave exactly the same. At some point, the only way to know whether two systems work together is to put them in the same environment and test what they actually do.
The event also included a panel discussion on emerging networking ideas and trends. I enjoyed hearing from engineers working across different parts of the industry and seeing how they approach new technologies without treating every new product or idea as an automatic replacement for what already works.
That is one of the things I enjoy most about OHNUG. The presentations are useful, but the value also comes from being in a room with people who operate real networks and are willing to talk honestly about their experiences.
Certification books, labs, and online courses are important, but they cannot completely replace meeting people, asking questions, and hearing how experienced engineers approach problems that do not have a clean answer in the documentation.
It was good to be back.
A Change in Direction
A lot of the older content on this site focuses on cybersecurity. I started with CTFs, practical ethical hacking, network-security labs, and the idea that I would eventually move into a security-focused engineering role.
I do not consider that time wasted, and I am not planning to remove those posts. Security taught me to inspect traffic, understand protocol behavior, question trust boundaries, and pay attention to what a system is actually doing instead of what the diagram says it should be doing.
All of that still applies to voice. SIP trunks need to be secured, certificates and TLS matter, firewall policy can break signaling or media, and an overly permissive dial plan can become an avenue for toll fraud. Voice is not replacing the networking and security knowledge I already have; it is giving that knowledge a more specific direction.
At this point, I am less interested in pursuing cybersecurity as a separate destination and more interested in becoming stronger at the infrastructure that carries communication. That includes route/switch, network operations, call control, SIP, gateways, and whatever else I need to understand to troubleshoot the network from end to end.
My earlier capstone post described the move toward VoIP as a pivot rather than a reset, and that still holds up. I am using many of the same troubleshooting habits, but applying them to a much deeper voice stack than I understood before.
What’s Next
The blog will probably start reflecting this change as I get further into the material.
I want to build out a voice lab where I can document CUCM registration, partitions and Calling Search Spaces, route patterns, digit manipulation, SIP trunks, CUBE, dial-peer matching, and media troubleshooting without involving any production systems. I would also like to spend more time reading SIP ladders and packet captures, since that seems like the most direct way to understand what a failed call was actually trying to do.
There will still be route/switch and infrastructure content. Voice depends on those systems, and I am nowhere near finished learning them. The difference is that I now have a new application sitting on top of the network, with its own control plane, routing logic, and very audible failure modes.
For now, I am grateful to have finished WGU, grateful to Kyle for helping me reach this opportunity, grateful for my new position at NEOnet, and grateful to be part of a networking community where people are willing to share what they know.
Thanks for reading, and God bless.
