Like snowflakes in a snowstorm, snowflake networks look consistent when viewed from a distance, but show many differences upon close examination. A snowflake network will typically use slightly different hardware models, running different operating system versions, with different interconnection methodologies on different interfaces. The configurations also tend to be different.
My NetCraftsmen co-worker David Yarashus cleverly described snowflake networks as "opportunistic networking." The organizations that build snowflake networks tend to install whatever hardware is on hand or whatever hardware is the least expensive, using whatever circuits are available. In doing so, they save capital expense at the cost of greater operational expense, because snowflake networks are much more difficult to manage than networks that are based on consistent designs.
Snowflake designs include both LAN and WAN environments, where each floor of a building is the functional equivalent of a WAN remote branch. Both LAN and WAN designs are best if the number of variations is very small. Variations in network design extend into load balancer, firewall, and access switch subsystems. These additional systems should use consistent designs. If there are differences, then operating procedures have to be customized for each unique design.
For the rest of this article, I’ll use the word "site" to identify a common network design segment, irrespective of whether it is a WAN site, a LAN site, or a firewall/load balancer segment.
When network design segments are consistent, network staff will know which interfaces are in use at a given site. Consistency eases problem detection and troubleshooting.
Without realizing the impact, a network team focused on delivering network services and fixing problems will often make small changes that create wide variations in site designs. As a result, it’s common to find a set of sites that use a similar high-level design, but have different implementation details.
For example, the interfaces that provide similar functionality may be different across sites, due to the network hardware in use. Another common variation occurs with remote site WAN connectivity, where some sites are dual-homed to two data centers while other sites connect to neighboring sites. This is a particularly troublesome design because a failure of the main data center link causes backup traffic to be routed to the neighboring site, overloading its links and impacting its operation. Two sites are then impacted. Resiliency design gets complicated very quickly and service-level agreements for both branches are difficult to maintain.
Standardized Network Designs
Standardized network designs reduce workload because a network team can build fixed operating procedures (also known as run-books) for common tasks like troubleshooting. Network security is enhanced because the same firewall and access-control list (ACL) rules are in place at multiple sites, reducing the network security team’s workload.
The benefits don’t end there. Standardized designs use well-defined bills of materials and documentation. In addition, a standard design that varies only by a set of subnets and VLANs reduces documentation time. You may need to purchase refurbished equipment for a new site if you’re not quite ready to switch to a new site design. Make deliberate changes in site design and work with your equipment vendor to maximize the longevity of the new design.
As much as possible, standardize site configurations, too. For example, you can derive interface descriptions from the site name and create ACLs and firewall rules from the assigned IP subnets and VLANs. You can use an IP address management system to select the IP address subnets to be assigned to a site.
Network standardization facilitates network automation, and automation reduces the effort required for network maintenance, resulting in reduced operational expense. An ideal situation would have two remote branch designs and only need two automation variants to provision, configure, check, and troubleshoot all the remote sites. The number of variables per remote site might be very small, perhaps simply the subnet IDs to use for the site. Network security is greatly simplified and enhanced because firewall rules and ACLs can be standardized and built automatically from the IP addresses used in the branch.
After site installation, an automation system can validate that all branches, both new and old, conform to the design. Other automation scripts can verify the correct connectivity and operation of the network, by checking that the neighbors, routing tables, and root bridges are correct. If each branch of a single design differs only by IP subnet, these checks become easy to automate.
Standardized network designs also facilitate the creation of network testing facilities for use in testing proposed configuration changes before deploying them on an operational network. Equipment vendors are now creating virtual instances of their operating systems, allowing automated test environments to be built without having to purchase a significant amount of network equipment. This allows creation of a continuous integration and continuous deployment (CI/CD) development cycle for the network, corresponding to the similar CI/CD cycles used in modern software development.
Conversely, snowflake network designs make automation more difficult. More information must be specified to do simple things like verifying network connectivity and operation. Gaining the advantages of automation is difficult in such an environment. The automation workload with snowflake networks is increased because each unique site and its automation systems must be maintained in sync with each other.
Design consistency significantly reduces the amount of effort to run a network. There’s an important trade-off involved with using standardized designs. The same hardware, software, interfaces, and design must be used for each design in order to achieve reductions in operational costs. When done well, a marginal increase in capital costs can result in a significant reduction in operational expense.