Network Device Management, Part 4: Topology Control

Network device management involves thinking about a device from several angles. What is the device saying, and who's listening to it? Who can configure the device, and in what ways? Is the device event stream properly related to the event stream of other devices in the network? I've discussed all of these big ideas in the previous posts in this series.

In this concluding series post, I'll discuss a key element of network device management: maintaining control of the network as it was built. All too often, networkers assume that if no one messes with the network device configuration, nothing can go wrong. The reality is that it's possible for network topologies to change due to outside influences. However, that can be controlled. Here are just a few ideas about how to accomplish that.

Topology control
One of my chief concerns as a network architect is enforcing the topologies I've designed. By "topologies," I'm referring to two important areas, both related to how traffic flows through the network. The first is the layer-two topology. This always means spanning-tree, but also could mean multi-chassis link aggregation or frame routing through fabric. The second is the layer-three topology: The routing design, where aspects like routing adjacencies and link costs should be controlled.

I raise the issue of network topology control because many networks I've inherited do no such enforcement. This topic could be a series of blog posts all on its own, but I'll hit a few points here.

1. A network is not a democracy. Rig every election. I've used that line in a blog post before, but I'm using it again as it communicates an important idea. Yes, you can leave network devices and protocols at their default settings. The end result might even work. But don't do that. Instead, configure protocols with purposeful intent. Make sure that the devices you intend to perform certain roles will indeed perform those roles. Leave nothing to chance.

2. Define the spanning-tree root and enforce its placement. Spanning tree is a loop prevention protocol that detects where loops exist in the network and then blocks redundant links to eliminate the loop. The links with the costliest path back to the spanning-tree root bridge are blocked.

Therefore, manually determining which switch becomes the root bridge is of supreme importance in any network design. If you don't set the root bridge priority yourself, spanning tree will elect a root bridge on its own. The end result can be blocked links you weren't expecting, and an unstable spanning-tree topology leading to irregular network outages. Switches with the lowest root bridge priority are elected root. In Cisco networks, the root bridge placement can be enforced by using root guard on appropriate ports.

3. Control which interfaces or VLANs will be used to form routing adjacencies. I have seen dual-core switch topologies where dozens of routing adjacencies were formed between the two switches because the routing protocol was enabled on all VLANs, even though the physical path was just a few links. I also have seen edge routers gleefully sending hello packets out all interfaces, including Internet-facing or carrier-facing interfaces that would never be used to form a routing adjacency. There are a couple of points to ponder here.

The first is that of optimizing routing protocol performance. Routing protocols have to compute all of the paths that are presented to them, and then recalculate when paths disappear. Why have dozens of apparent paths be presented to a routing protocol between two switches, unless they represent a physical reality? It makes more sense to create a specific VLAN just for the routing protocol, and disable the routing protocol on other VLANs between two core switches. This simplifies the routing topology, makes routing recalculations easier, and simplifies the routing table.

The second point is more closely related to security. Why should an interface be willing to form a neighbor relationship if you as the network engineer would never want a routing adjacency to form across that interface? To address both of these situations, my habit for any routing protocol is to set all interfaces to be passive by default, exempting only those interfaces I definitely want to build an adjacency across.

Is it really worth it?
Some IT practitioners might wonder what the point is of all of this. Is it really worth it to do all of this control and enforcement around network devices? From my perspective, the answer is a decided "yes." Behind every issue I name and example I cite, there's a story I could tell, usually a sad story filled with heartbreak, woe, and downtime -- or at least inconvenience and frustration.

I can say from personal experience that these efforts are worthwhile. I'm not saying it's easy to get all of these standards in place, or if they are in place, enforced. There's a lot of work involved, especially if the network had been previously run by the "just make it work" philosophy. But the big payoff is network predictability and stability, and those attributes are incredibly valuable to any organization.