So I ordered this book from Amazon, Networks by Mark Newman, for $80.

Yes, $80. For a book about networks.

Not a switch. Not a cable tester. Not a tiny firewall appliance with “enterprise” printed on the box, the same way a microwave burrito calls itself cuisine. A book. Paper, ink, equations, diagrams, and the quiet threat that somewhere inside those pages is the math behind why networks behave nicely in textbooks and like raccoons in a dumpster fire in production.

And let me be clear: I did not buy this because I am pretending to be an expert.

I am not.

That is the whole point.

I bought it because I am trying to understand networking beyond the surface level. I can study commands, protocols, configurations, diagrams, and vendor documentation, but at some point I have to ask the rude little question standing in the corner:

Do I actually understand the structure underneath all this?

Or am I just memorizing commands like a tired parrot with sudo privileges?

That is where graph theory comes in.

Not as academic decoration. Not as intellectual cosplay. Not so I can start saying “vertices” in casual conversation and become the human equivalent of a mandatory webinar. I am learning it because networks are made of relationships: devices, links, paths, failures, bottlenecks, dependencies, and routes. If I want to become better at network engineering, I need to understand those relationships better.

Annoying? Yes.

Useful? Also yes.

Before Routers, There Were Bridges

Graph theory did not begin with Cisco, Juniper, Microsoft, Linux, Azure, or some YouTube guru shouting about subnetting beside a neon keyboard and a wall of fake plants.

It began in 1736 with Leonhard Euler and the Seven Bridges of Königsberg problem. The question was simple: could someone walk through the city and cross every bridge exactly once? Euler’s brilliance was not in admiring the bridges. Any tourist with comfortable shoes could do that. His brilliance was in stripping the problem down to what mattered: the land areas and the bridges connecting them (Biggs et al., 1986).

Land became nodes. Bridges became edges. A city became a graph.

That move still matters. It is the same kind of thinking network engineers need when troubleshooting. Ignore the decorative nonsense for a moment. Forget the rack, the cable colors, the vendor logo, and the network diagram that looks like it was assembled during a hostage negotiation.

Ask the real questions.

What is connected to what? Where does the path break? Is there another route? What happens when this link fails? And why, in this modern age of cloud computing and artificial intelligence, is the printer still treated like a sacred village elder?

Euler was not troubleshooting Wi-Fi, but the thinking is disturbingly familiar.

The Network Is Already a Graph

A computer network is a collection of devices connected by links. In graph theory, those devices are nodes, and the links are edges.

That sounds almost too simple, which is usually how powerful ideas sneak into the room without a vendor demo, subscription tier, or “AI-ready” white paper.

A firewall connected to a core switch is a graph. A core switch connected to access switches is a graph. A data center connected to branch offices is a graph. A cloud network connected to on-premises infrastructure is also a graph, except now the cable is invisible and the monthly bill has developed a personality disorder.

Graph theory gives structure to the things network engineers deal with every day: paths, loops, redundancy, bottlenecks, failure points, and dependencies.

It is not academic decoration.

It is the skeleton under the network.

Which is useful, because sometimes the network diagram is just a beautiful lie with arrows.

Why Newman’s Networks Matters

Mark Newman’s Networks: An Introduction is not only about computer networks. It treats networks as a broader science, covering social networks, biological networks, technological networks, information networks, and infrastructure networks (Newman, 2010).

That is exactly why I wanted the book.

Computer networking is part of a larger idea: connected systems. I am not reading Newman because I already understand all of this. I am reading him because I do not want my understanding of networking to stop at commands, configuration examples, and whatever the vendor documentation decided to bless as “best practice” this fiscal quarter.

Commands matter. I still need them. But I also want to understand structure, topology, flow, and failure. I want to understand why some systems are resilient and others are merely expensive. I want to know why certain devices become dangerously important, why redundancy can either save you or stab you in the back, and why traffic does not always take the path lovingly drawn in the diagram.

The diagram may lie.

The graph usually tells the truth.

Rude, but helpful.

Revisiting the Math I Need

Part of why I bought Newman’s book is that I know I need to revisit the math.

Again, not because I am an expert nor trying to impress anyone. And definitely not because I woke up one morning with a romantic longing for equations. I have problems, but I am not yet that far gone.

I bought it because I am still learning, and I want to understand what is really happening underneath computer networking.

Networking is not just commands. Commands matter, but they are not the whole story. A command can configure an interface. It cannot, by itself, teach me why a topology is fragile, why traffic takes one path instead of another, or why redundancy sometimes saves the day and sometimes creates a disaster with better cable management.

That is why I need the math.

I need graph theory because networks are built from relationships. I need discrete math because networks involve logic, paths, trees, sets, and algorithms. I need some linear algebra because larger networks can be represented with matrices, which is basically what happens when a network diagram stops pretending to be friendly. I need probability and statistics because links fail, packets drop, queues fill, and monitoring data can lie with the confidence of a dashboard in a management meeting.

And I need algorithms because routing is not magic. Shortest paths, spanning trees, flow problems, and convergence all depend on algorithmic thinking.

This does not mean I am trying to become a mathematician.

I am trying to become a better network engineer.

There is a difference.

One proves theorems.

The other tries to figure out why everything worked yesterday and now Accounting cannot reach the file share.

Why I Am Learning This for Network Engineering

I am learning graph theory because I want to understand networking beyond configuration.

Yes, I still need IP addressing, subnetting, VLANs, routing protocols, firewalls, DNS, DHCP, VPNs, wireless, switching, and the usual machinery that keeps modern life from sliding back into paper forms, awkward phone calls, and someone saying, “Can you just reboot the server?”

But memorizing configurations is not the same as understanding why a network behaves the way it does. That is checkbox learning. It produces people who can type, but not think. The CLI accepts the command. The network, being less merciful, exposes the ignorance.

Graph theory helps me ask better questions.

What depends on what? Where is the single point of failure? What path will traffic actually take? Is this redundancy real, or just decorative? Is the network resilient, or is it one unplugged cable away from becoming a group therapy session?

That is why graph theory belongs in my network engineering journey. I am not trying to stand in front of the world and declare myself an authority on graph theory. Nobody needs that guy. That guy probably brings a laser pointer to dinner.

I am trying to understand enough of it so that when I look at a network, I do not just see equipment.

I see structure.

I see dependencies.

I see weak points.

I see possible paths.

I see where the design is strong, and where it is one bad Tuesday away from becoming a meeting with “lessons learned” in the subject line.

That is the point.

Not pretending.

Learning.

The slow, humbling, mildly irritating kind.

Routing, Switching, and Other Ways Networks Misbehave

Routing is one of the clearest examples of graph theory in action.

Routers decide how packets move from one network to another. In graph terms, routers are nodes, links are edges, route costs are weights, and routes are paths.

That is the math wearing a badge and quietly judging your topology.

Dijkstra’s shortest path algorithm is one of the classic algorithms for finding efficient paths through weighted graphs (Dijkstra, 1959). OSPF uses shortest-path logic to calculate routes through a network topology (Moy, 1998).

This is not trivia. This is the logic behind real routing behavior.

When a link fails, the topology changes. When the topology changes, routes may change. When routes change, traffic moves differently. And when traffic moves differently, someone somewhere says, “The system is slow,” and now your day has acquired a plot, a villain, and probably a meeting.

Switching has its own graph-theory drama. Ethernet loves connectivity, sometimes too much. Add redundant links without control and you may create a loop. A loop in Ethernet is not a harmless circle. It is a broadcast storm auditioning for disaster cinema.

This is why spanning tree exists. It keeps the network connected while preventing loops by creating a loop-free logical topology. In graph theory language, it preserves enough edges to keep the system connected while removing cycles. In network engineer language, it keeps the network from eating itself because someone thought “more cables” meant “more better.”

Redundancy is good.

Uncontrolled redundancy is chaos with a purchase order.

The Internet and the Cloud Are Still Graphs

BGP takes graph theory and releases it into society without a chaperone.

BGP connects autonomous systems, which are independently managed networks on the Internet (Rekhter et al., 2006). But BGP is not simply about shortest paths. Of course not. That would be too clean, and the Internet was apparently designed to make future engineers question their life choices.

BGP is about policy, preference, peering, transit, filtering, business relationships, and the occasional global routing incident that reminds everyone the Internet is held together by protocols, contracts, and professional anxiety.

The Internet is a graph, but not a clean one.

It is a graph with money, politics, egos, and route announcements capable of ruining everyone’s morning.

Cloud networking did not make this thinking obsolete. It made it more abstract and more expensive, because apparently that is innovation now.

In the cloud, the nodes may be virtual networks, subnets, firewalls, load balancers, VPN gateways, private endpoints, and regions. The edges may be peering links, tunnels, private circuits, routing rules, and service connections.

The cable disappeared.

The topology did not.

The graph did not go away.

It got promoted.

Naturally, promotion came with a subscription model.

Final Thought

So yes, I ordered Newman’s Networks for $80.

Part of me thinks that is ridiculous. Another part of me knows that if I want to get better at network engineering, I need to understand the structure behind the blinking lights.

Computer networking is not just commands. It is not just equipment. It is not just certification acronyms arranged like decorative medals on a LinkedIn headline.

It is topology. It is paths. It is flow. It is failure. It is resilience. And whether we admit it or not, it is math.

Not math for showing off. Not math for academic peacocking. Useful math. Practical math. The kind that explains why a system works on Monday, fails on Tuesday, and somehow becomes a budget item by Wednesday.

I am not writing this as someone who has already mastered graph theory. I am writing it as someone who finally admitted that if I want to understand networking seriously, I need to stop treating the math underneath it like optional background noise.

Because it is not background noise.

It is the structure.

And I am trying to learn the structure.

Graph theory started with bridges. It passed through circuits, trees, paths, flows, and algorithms. Then computer networking arrived and gave it routers, switches, firewalls, cloud platforms, routing protocols, and printers that somehow became constitutional crises.

Networking is graph theory with blinking lights.

And apparently, in my case, an $80 cover charge.

References

Biggs, N. L., Lloyd, E. K., & Wilson, R. J. (1986). Graph theory, 1736–1936. Clarendon Press.

Dijkstra, E. W. (1959). A note on two problems in connexion with graphs. Numerische Mathematik, 1, 269–271.

Moy, J. (1998). OSPF Version 2 (RFC 2328). Internet Engineering Task Force.

Newman, M. E. J. (2010). Networks: An introduction. Oxford University Press.

Rekhter, Y., Li, T., & Hares, S. (2006). A Border Gateway Protocol 4 (BGP-4) (RFC 4271). Internet Engineering Task Force.