Network Engineer

I start by checking what is fastest to verify rather than assuming it is a router problem from the outset. First I confirm scope: is it one user, one subnet, one site, or everything, since that alone rules out most of the network. I check physical layer status on the affected port or link, then verify Layer 2 with a ping to the default gateway, then Layer 3 with a traceroute to see exactly where the path breaks. I pull recent change logs before touching anything, because in my experience a change made in the last 24 hours is the cause more often than a genuine hardware failure. Once I isolate the failing hop or device, I check its logs and interface counters for errors, drops, or CRC issues rather than guessing. I log every step as I go, both to keep myself honest about what I have actually ruled out and so the next person does not repeat my work.

OSPF is my default for interior routing within a single organisation, since it converges fast, handles topology changes well, and does not require the policy overhead BGP carries. I use it inside a campus or data centre where all routers are under one administrative control and the goal is simply the shortest, most efficient path. BGP comes in once I am routing between autonomous systems: connecting to an ISP, peering with a partner network, or running a multi-site WAN where I need policy control over which paths traffic takes rather than just the shortest one. BGP also gives me path attributes like AS-PATH and local preference to engineer traffic deliberately, which OSPF cannot do. In practice I have run both together: OSPF internally, redistributed carefully into BGP at the edge, with route filtering so an internal routing change cannot accidentally leak into the internet.

I keep three things current at all times: a topology diagram that reflects the actual live network, not the one from the original design; an IPAM system tracking every subnet, VLAN, and allocation so nobody double-assigns an address; and a change log tied to every configuration push, including who made it, why, and the rollback plan. I write runbooks for anything that happens more than once, especially incident response steps, so the fix does not depend on the memory of one engineer alone. I have seen outages take three times longer to resolve simply because the documentation did not match reality, so I treat updating it as part of finishing the change, not an optional follow-up task. I review the topology diagram against the live network quarterly to catch drift before it becomes a problem during an incident.

I use monitoring platforms with anomaly detection built in to flag traffic patterns or latency spikes that fall outside normal baselines, which catches issues before users report them. For repetitive configuration work, like pushing the same VLAN or ACL change across twenty switches, I use Ansible playbooks and Python scripts rather than doing it manually, which also cuts down on typo-driven outages. Where I do not hand off control is anything security sensitive or customer facing: firewall rule changes, BGP policy changes, and anything touching the internet edge get a manual review from me before they go live, regardless of how confident the automation is. I treat AI-assisted tools as good at pattern detection and repetitive execution, and treat my own judgment as the final check on anything that could take down a segment of the network.

During a core switch failure, an entire building lost connectivity, affecting around 400 users for what became a 45-minute outage. I confirmed the failure was isolated to that switch by checking that the redundant switch in the stack was still up but not passing traffic, which pointed to a spanning tree issue rather than a hardware failure. I checked the spanning tree topology and found a misconfigured priority value from a change made the day before, which had caused a loop that the protection mechanisms on the switch were fighting rather than resolving cleanly. I corrected the priority value, forced a spanning tree recalculation, and confirmed traffic was flowing normally within about six minutes of identifying the cause. Afterward I wrote up the incident, added a peer review step for any spanning tree priority change, and updated the runbook so the next engineer could recognise the same symptom faster.

During a period of intermittent slowness affecting a sales team ahead of a big client call, the VP wanted an update every fifteen minutes and had no patience for jargon. I explained it as a traffic jam on one specific road between their office and the internet, not the whole network being broken, which set the right expectation that most systems were fine. I gave a plain timeline: we know where the congestion is, we are rerouting traffic around it now, and we expect it resolved within the hour. I avoided terms like packet loss or MTU and instead described what they would actually notice, like pages loading slowly versus not loading at all. When it was fixed, I confirmed with a specific before and after number: latency dropped from around 400 milliseconds to under 20, so they had something concrete rather than just my word that it was resolved.

I got paged around 2am for a BGP session flapping with our secondary ISP, which was intermittently dropping our backup internet path. It was not customer impacting yet since primary was still up, but flapping BGP sessions can escalate quickly if left alone. I logged in, checked the interface for physical layer errors, and found nothing locally, which pointed to a problem on the provider side. I opened a ticket with the ISP with the specific timestamps and error counters, dampened the session temporarily to stop the flapping from generating excessive log noise, and set a reminder to follow up in the morning if they had not responded. I documented the whole sequence in our incident channel so the team had context without needing to wake anyone else up. The provider confirmed a fibre issue on their end the next day, and I closed the loop by removing the dampening once the session stabilised.

A VLAN is a Layer 2 construct: it segments broadcast domains within switches so that devices in different VLANs do not see the broadcast traffic from devices in other VLANs, even if they are physically connected to the same switch. A subnet is a Layer 3 construct, a logical grouping of IP addresses that determines how routing decisions are made. In practice I map one subnet to one VLAN as a standard convention, since it keeps troubleshooting simple: if I know the VLAN, I know the subnet, and vice versa. The reason to use both together rather than just one is that VLANs give me the physical and broadcast isolation at the switch level, while subnets give me the routing and access control boundary at the router or firewall level. For example, I might put finance and engineering on separate VLANs and separate subnets so I can apply different firewall policy to each without any ambiguity about which traffic belongs where.

I design around zones based on trust level and function rather than physical location: a DMZ for anything internet facing, an internal zone for general corporate traffic, and a restricted zone for sensitive systems like finance or production databases. Traffic between zones has to pass through a firewall, and I write rules on a default deny basis, meaning nothing is allowed unless it is explicitly needed, rather than starting permissive and trying to lock things down later. Every rule gets a description of who requested it and why, since an undocumented rule is the hardest thing to remove safely two years later. I review the full rule set quarterly to remove anything that is no longer needed, since firewall rulesets tend to grow and rarely shrink without deliberate effort. For any new segment, I also think about east-west traffic, not just north-south, since a lot of real breaches spread laterally once they are inside a single trusted zone.

On-premises networking is largely physical: I am managing actual switches, cables, and hardware failure modes, and routing decisions are tied to physical topology. In the cloud, networking is defined in software: a VPC is a logically isolated network within a provider, and VPC peering lets two VPCs route traffic to each other privately without going over the public internet, but it is not transitive, so peering A to B and B to C does not let A reach C without a direct peering connection or a transit gateway. I have used transit gateways to hub multiple VPCs together instead of building a full mesh of individual peering connections, which gets unmanageable past a handful of VPCs. For hybrid setups I have configured both VPN and dedicated connections like Direct Connect back to on-premises, and the main design question is always the same: what is the latency and reliability requirement, since VPN over the internet is fine for backup paths but not for anything latency sensitive.