The Sum, Not Just the Parts: Thinking Holistically About Your Network
Ethan Banks and Drew Conry-Murray had me on Heavy Networking to talk through a blog post of mine, The Network as a Whole. Why one VLAN change can end in Wi-Fi complaints, why certs do not teach design, and why you should break your labs on purpose.
12 June 2026 · 2 min read
Heavy Networking 831, a Packet Pushers podcast. Published 12 June 2026. Hosts: Ethan Banks and Drew Conry-Murray.
Ethan read my post The Network as a Whole and asked me to come talk about it. The idea is simple to say and hard to practice: a network is an interconnected system, so what you change on one device has consequences beyond that device. To do the job well you have to hold the whole thing in your head.
Where the idea came from
Thirty years ago I read David Bohm's Wholeness and the Implicate Order, a physics book with philosophy mixed in. Bohm's point was that most of us stare at the explicate, the tangible details, and miss the implicate order underneath, the way everything is folded into everything else. Earlier this year I was doing advisory work, looking at networks with people, and it clicked. Someone would ask for help with BGP and traffic engineering, and once you dug in BGP was never the only problem. You had to see the whole system before the individual parts made sense.
Certs teach configuration, not design
A cert tells you what a root bridge is and how to compute OSPF cost. It does not tell you why you would pick one protocol over another, or what happens three hops away when you change something. The example in the post is a small VLAN change that triggers a root bridge election, which changes the topology, which makes a link run hot, which ends in users complaining about Wi-Fi. If you do not understand how those layers are related, you will never connect the change to the complaint.
How to build that kind of thinking
- Learn in public. Do the work behind the cert, not just the exam. Communities like The Art of Network Engineering and the USNUA exist for this.
- Read postmortems. Internet outage RCAs are the best free education in unintended consequences. Cloudflare's are the model for how to write one.
- Break your labs. Getting a lab to work teaches you almost nothing. Break it, put test traffic through it, and learn what each failure state looks like so you recognise it in production.
- Reflect after you fix something. A lot of engineers fix and move on. Ask why it happened, and why the design was the way it was. The person before you was usually not an idiot, and you find that out when you swap their choice out and have to put it back.
- Ask the senior people. If asking "I do not understand this part of the network" gets you punished, that tells you something about where you work.
The parts people skip
Drew asked where the gaps usually are. My answer: switching. Operators spend all their time on routing and leave every switch at the same bridge priority, so the root bridge election is a free-for-all and the closet switch can win when the core fails. Ethan's line for it is that your network is not a democracy, rig every election. The same goes for the boundary between the network and the server team when NSX or micro-segmentation blurs it. Be the person who understands both sides, because "it looks fine up to my port" is not an answer anyone in leadership wants to hear.
We closed on overlays and AI. Overlays are the answer to everyone being everywhere, but they are an abstraction, and when they break you still need to know what the underlay is doing. And if you are going to use AI, at least ask it why. The people who still understand how the whole system fits together are going to be worth more, not less.
