Refactoring the network

The fundamental shift of the enterprise toward the cloud has posed a conundrum for many. The largest issue is the state of most enterprise networks. These networks were designed for an era gone by. Their original designs could not foresee the coming of technologies such as SDN, SDWAN, Segment Routing, the Cloud and an exponential increase in bandwidth that have all happened over the past 10 years.

The IPv4 Internet BGP routing table alone has experienced a 10% year over year growth between 2009 and 2017 along. In 2009 the table eclipsed 286,000 routes. Here in 2017 we are at approximately 650,000. These figures only account for IPv4 routes, and not the full IPv4 and IPv6 tables. During that same period we have gone from token ring and 10Base-T to 100GbE.

Many enterprises find that when they start down the Dev/Ops or Cloud path that their existing network is ill equipped to handle the loads and provide the stability and resilience that is needed.  Building a network is much like building a house. You must start with a good solid foundation. That foundation is the first three layers of the OSI model.

At layer one you need a good physical infrastructure and cabling plant, whether that be fiber optic, or copper twisted pair. Properly sized links are required to ensure adequate bandwidth to the applications which they carry. The second layer is a good switching infrastructure that has designated root bridges. These root bridges need to be aligned with the placement of the layer 3 gateways to ensure optimal traffic paths throughout the network. At layer 3 you need a good solid routing infrastructure that is functioning fully on a dynamic routing protocol (my personal preference is EIGRP due to the ability to summarize addressing at the interface easily). EIGRP can be a mistake though if your implementation is multivendor. While EIGRP is no longer a proprietary Cisco protocol, no mainstream switch, route, or firewall vendors have implemented it into their equipment.

Remember, without the three primary layers being setup properly, your results upon implementing any type of SDN or overlay will suffer greatly.

Application developers are widely familiar with the term refactoring. It is the process of refining code that has developed a “code smell”. These code smells are architecture designs that inhibit future change or can become fault domains in the future.  A network is much like a modern program, built to be hierarchical using both tight and loose couplings between layers, and can also develop a “smell” due to bloat, inefficient switching paths, and suboptimal routing.

Many networks are the product of numerous engineers who have all left their mark on part of the network without a thorough optimization of the solutions they implemented. Have you ever seen a data center that looks like spaghetti? Usually the spaghetti exists within the configurations as well! As a network grows and evolves over time, these small problems eventually grow to a point where they can cause large outages or at a minimum or create a large blast radius for any small problem that occurs.

To put this in context, I was working at a medium size retailer about 3 years ago. They had implemented EIGRP as their IGP. The problem was that they adjusted the metrics on every link to direct traffic in certain directions manually. Thus, they negated the primary reason to utilize a dynamic routing protocol in the first place. This mess that they created had to be completely removed before their wonderful new SDN enabled network would function correctly. In the process of the redesign, we even found an old Cisco Catalyst 3500 XL switch with an uptime of 11 years! That switch was worth every penny the company spent when it was purchased. After finishing the redesign and install, we consolidated over 30 routers to 6 and a few dozen 1U switches into either stacks or chassis based units. Overall, we dropped the power consumption in the data center by 63%. So, there are other intangibles that can be realized through the process of re-architecture and refactoring.

No matter what new technology or automation you plan on implementing, your results will always be better served by re-evaluating current practices and completing an architecture review.