A network engineer exists because every distributed system rides on a shared,\ncontended, physical medium that does not care about your intentions. Packets get\nlost, reordered, and delayed; links fail; tables go stale; and somebody is always\nsending more traffic than the wire can carry. The engineer's reason for being is\nto make that hostile substrate behave like a predictable utility — delivering\nbits with bounded latency, acceptable loss, and enough redundancy that a single\nfiber cut doesn't take down a hospital, a trading floor, or a country.
\n","wordCount":87},{"heading":"Core Mission","id":"core-mission","markdown":"Move data between any two endpoints reliably, securely, and fast enough that the\napplication above never has to think about how — while links fail, traffic surges,\nand the topology changes underneath you.","html":"Move data between any two endpoints reliably, securely, and fast enough that the\napplication above never has to think about how — while links fail, traffic surges,\nand the topology changes underneath you.
\n","wordCount":32},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is configuring routers and switches; the actual work is\ndesigning a system whose behavior emerges from thousands of devices each making\nlocal decisions. A network engineer designs topologies and addressing plans\n(subnetting, VLANs, VRFs); chooses and tunes routing protocols (OSPF, IS-IS, BGP)\nso traffic finds good paths and reroutes around failure; segments the network for\nsecurity and blast-radius control; sizes links and queues so congestion degrades\ngracefully instead of collapsing; secures the edges with firewalls, ACLs, and\nNAT; and operates all of it — monitoring, capacity planning, and the 2 a.m.\ntroubleshooting that is mostly working the OSI stack bottom-up. Underneath it is\nchange control: one fat-fingered prefix can black-hole a region in seconds.","html":"The visible work is configuring routers and switches; the actual work is\ndesigning a system whose behavior emerges from thousands of devices each making\nlocal decisions. A network engineer designs topologies and addressing plans\n(subnetting, VLANs, VRFs); chooses and tunes routing protocols (OSPF, IS-IS, BGP)\nso traffic finds good paths and reroutes around failure; segments the network for\nsecurity and blast-radius control; sizes links and queues so congestion degrades\ngracefully instead of collapsing; secures the edges with firewalls, ACLs, and\nNAT; and operates all of it — monitoring, capacity planning, and the 2 a.m.\ntroubleshooting that is mostly working the OSI stack bottom-up. Underneath it is\nchange control: one fat-fingered prefix can black-hole a region in seconds.
\n","wordCount":122},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **The network is a shared, contended resource.** Bandwidth, buffer space, and\n table entries are finite and fought over. Every design decision allocates\n scarcity.\n- **Troubleshoot bottom-up.** Link, then layer 2, then IP, then routing, then the\n application. Most \"network problems\" are duplex mismatches, MTU issues, or DNS\n — not routing.\n- **Redundancy that hasn't failed over is theory.** Two paths you've never tested\n are one path.\n- **Keep the control plane and data plane separate in your head.** Forwarding is\n fast and dumb; routing is slow and smart. Confusing them is how you misdiagnose.\n- **Fail closed for security, fail open for availability — and know which one\n this device is.** A firewall that fails open is a breach; a transit router that\n fails closed is an outage.\n- **Document the addressing plan or lose the network.** An undocumented network\n is one resignation away from unmaintainable.\n- **Change slowly where the blast radius is large.** A core BGP change is a\n one-way door at line rate.","html":"A network engineer sits between everyone and the wire, which makes them the\ndefault suspect for every problem. The relationship with application and SRE\nteams is one of proof: they report "the network is slow," and the engineer\ndemonstrates, with captures and flow data, where the latency or loss actually\nlives — often above layer 4. With security engineers they share firewall policy,\nsegmentation, and incident response; with cloud architects they extend routing\nand segmentation into VPCs and overlays; with facilities and carriers they manage\nthe physical plant and circuit SLAs. The recurring friction is the blame\nboundary; engineers who earn trust hand back evidence, not opinions.
\n","wordCount":106},{"heading":"Ethics","id":"ethics","markdown":"Networks carry the traffic people cannot opt out of — emergency calls, medical\ntelemetry, financial settlement — which makes the engineer a quiet steward of\nthings that must not stop. The duties: design for the failure that takes lives or\nlivelihoods, not just the SLA; resist deep packet inspection and interception\nbeyond what's lawful and disclosed, because the tools that shape traffic can\nsurveil it; be honest about what redundancy actually buys versus what's vendor\ntheater; and treat fair queuing as fairness, since deciding whose packets wait\ndecides whose service degrades. When asked to quietly throttle, block, or\nmonitor, the obligation is to make the decision and its consequences explicit.","html":"Networks carry the traffic people cannot opt out of — emergency calls, medical\ntelemetry, financial settlement — which makes the engineer a quiet steward of\nthings that must not stop. The duties: design for the failure that takes lives or\nlivelihoods, not just the SLA; resist deep packet inspection and interception\nbeyond what's lawful and disclosed, because the tools that shape traffic can\nsurveil it; be honest about what redundancy actually buys versus what's vendor\ntheater; and treat fair queuing as fairness, since deciding whose packets wait\ndecides whose service degrades. When asked to quietly throttle, block, or\nmonitor, the obligation is to make the decision and its consequences explicit.
\n","wordCount":108},{"heading":"Scenarios","id":"scenarios","markdown":"**The app that \"works in the office but not over the VPN.\"** A user reports a web\napp that loads on the LAN but hangs on submit through the VPN. The novice blames\nthe VPN. The expert works the stack: ping succeeds, small pages load, large POSTs\nhang — the signature of an MTU/MSS problem. The tunnel's encapsulation overhead\nshrinks the effective MTU; ICMP \"fragmentation needed\" is filtered, so PMTUD\nsilently fails and full-size packets are black-holed. The fix is MSS clamping on\nthe tunnel interface, not a VPN restart. A successful ping proved reachability and\nhid the fault one layer up.\n\n**A core BGP change that black-holes a region.** During a planned summarization,\nan engineer advertises an aggregate but forgets a discard route for the\nunallocated portion, so traffic to unused addresses is accepted then dropped.\nMonitoring shows pings to live hosts fine but rising drops elsewhere. The\ndisciplined response is mitigate first: withdraw the change, let the network\nreconverge to known-good, confirm restoration, then reproduce the summarization\nin the lab with the correct null route and a prefix filter before re-attempting.\nThe postmortem fix is a change-review checklist requiring a tested rollback for\nevery core routing change.\n\n**Designing connectivity for a new data center.** Requirements: low east-west\nlatency, contained failure domains, room to grow. The engineer chooses a\nleaf-spine Clos fabric over three-tier, because it gives predictable equal-cost\nhop counts and scales horizontally by adding spines. They run BGP in the underlay\nfor simple, scalable ECMP, allocate a clean IP plan for double the racks, keep\neach rack to one VLAN, and put management on a separate out-of-band network. The\ntradeoff: more routing config and BGP sessions in exchange for deterministic\nlatency and a failure domain that stops at one leaf.","html":"The app that "works in the office but not over the VPN." A user reports a web\napp that loads on the LAN but hangs on submit through the VPN. The novice blames\nthe VPN. The expert works the stack: ping succeeds, small pages load, large POSTs\nhang — the signature of an MTU/MSS problem. The tunnel's encapsulation overhead\nshrinks the effective MTU; ICMP "fragmentation needed" is filtered, so PMTUD\nsilently fails and full-size packets are black-holed. The fix is MSS clamping on\nthe tunnel interface, not a VPN restart. A successful ping proved reachability and\nhid the fault one layer up.
\nA core BGP change that black-holes a region. During a planned summarization,\nan engineer advertises an aggregate but forgets a discard route for the\nunallocated portion, so traffic to unused addresses is accepted then dropped.\nMonitoring shows pings to live hosts fine but rising drops elsewhere. The\ndisciplined response is mitigate first: withdraw the change, let the network\nreconverge to known-good, confirm restoration, then reproduce the summarization\nin the lab with the correct null route and a prefix filter before re-attempting.\nThe postmortem fix is a change-review checklist requiring a tested rollback for\nevery core routing change.
\nDesigning connectivity for a new data center. Requirements: low east-west\nlatency, contained failure domains, room to grow. The engineer chooses a\nleaf-spine Clos fabric over three-tier, because it gives predictable equal-cost\nhop counts and scales horizontally by adding spines. They run BGP in the underlay\nfor simple, scalable ECMP, allocate a clean IP plan for double the racks, keep\neach rack to one VLAN, and put management on a separate out-of-band network. The\ntradeoff: more routing config and BGP sessions in exchange for deterministic\nlatency and a failure domain that stops at one leaf.
\n","wordCount":305},{"heading":"Related Occupations","id":"related-occupations","markdown":"The network engineer shares the bottom-up, failure-first instinct of the site\nreliability engineer but reasons in packets and paths rather than services and\nSLOs. Systems administrators are the closest operational cousin and often the\nrole network engineering grows out of. Security engineers think adversarially\nabout the same segmentation and firewalls. Cloud architects extend routing,\naddressing, and segmentation into virtual overlays where the same laws apply\nwithout the wire. Electrical engineers own the physical layer beneath layer 1 —\ncabling, optics, and signal integrity.","html":"The network engineer shares the bottom-up, failure-first instinct of the site\nreliability engineer but reasons in packets and paths rather than services and\nSLOs. Systems administrators are the closest operational cousin and often the\nrole network engineering grows out of. Security engineers think adversarially\nabout the same segmentation and firewalls. Cloud architects extend routing,\naddressing, and segmentation into virtual overlays where the same laws apply\nwithout the wire. Electrical engineers own the physical layer beneath layer 1 —\ncabling, optics, and signal integrity.
\n","wordCount":84},{"heading":"References","id":"references","markdown":"- *TCP/IP Illustrated, Volume 1* — W. Richard Stevens\n- *Computer Networks* — Andrew Tanenbaum\n- *Internet Routing Architectures* — Sam Halabi\n- *Network Warrior* — Gary Donahue\n- RFC 791 (IP), RFC 793 (TCP), RFC 4271 (BGP-4)","html":"