This blog on network implementation is the third in my Back to Basics series. The first blog, Gathering Requirements, focuses on why the network is built. The second blog, Network Design, focuses on what is built. This blog focuses on how the network is built.
The goal of ACME Corporation’s data center migration project is to move all the existing applications and services from its existing data center to a new data center. To accomplish this, a few tasks with deliverables exist in this phase of the project.
Build
The low-level design document has been completed and approved. Now it’s time to collect the final information so that network configurations may be created and installed on the network gear. This final information, which consists of physical connectivity, IP addressing, as well as naming and numbering conventions, is collected into one or more repositories.
The physical connectivity information is used to create the cabling requests for the rack-and-stack team. It’s also used to build a detailed physical diagram. The logical information (i.e., IP addressing, naming and numbering conventions) is used to create multiple logical diagrams. Depending on the complexity of the design, separate diagrams may be needed to display underlays, overlays and the routing setup.
While diagrams are being created, configuration templates are also being created. During a lookup in the appropriate repository, the final information is substituted for variables in these templates. The templates are created to match the smallest modules identified in the design phase of the project. The goals are consistency, reusability and repeatability. The templates create small snippets of configuration that are quick to apply and easy to troubleshoot if verification steps fail.
ACME Corporation has yet to adopt the latest techniques in network automation and orchestration. As such, Microsoft Excel is used for both the information repositories and configuration templates. Using formulas and input validation, the build team has an excellent track record of producing reliable results.
Test
ACME’s new data center network was built to support a set of business requirements that translated to technical requirements. Although there are many others, technical requirements include throughput, latency, error rate, and failover times. The only way to verify that the network fulfills these requirements is to test it.
The network was designed from the ground up and then built from the ground up. Network testing should follow this same pattern by first verifying the health of each network component. Does everything power on correctly? Are there errors in any of the Power-On Self-Tests (POST) or device logs? Are the correct physical interfaces attached?
Moving from layer 1 to layer 2, what features (i.e., spanning tree, Multi-chassis Link Aggregation) are being used and are they operating as expected? Using a traffic generator to simulate multiple hosts, is the network learning media access control (MAC) addresses?
At layer 3, are the correct IP addresses configured and able to communicate with each other? Does the routing protocol show the expected neighbor relationships? Does the routing table show all desired routes?
Using specialized network test equipment is the best way to test for errors, latency, throughput and failover times, especially if the requirements call for a highly resilient network. Networks with less stringent requirements may be able to use workstations and laptops to perform adequate testing.
All results should be recorded in a document and saved as baselines to compare to future test results. Once updated, this document should be accepted, approved and signed to confirm a successful build.
Integration
The new network meets business requirements, but it is still isolated and therefore unusable in its current state. The next step is to connect it to the rest of ACME’s network so service migrations can commence.
ACME requires three types of connectivity to integrate the new data center.
- This data center needs to connect to the existing wide area network (WAN) to support all internal corporate users.
- Internet connectivity is required to support remote access users, partner connectivity as well as general Internet access.
- A data center interconnect (DCI) is the dedicated path for service migrations from the existing data center to the new data center.
ACME has an extensive change control process, which until now, hasn’t needed to be followed. Integrating the new data center requires adherence to the process. Configuration changes require a peer review. The entire change requires a Method of Procedures (MOP) document that details all aspects of the change. Additional network diagrams are also required to display the integration and transitions states. Many meetings occur to negotiate a change window.
During the change window, all three connectivity types are implemented and tested. It is essential to perform testing on these connections to make sure they support all requirements. Results should be recorded in the testing document and signed off as a signal to proceed with service migrations.
Decommissioning
Decommissioning an old network can carry as much risk as integrating a new one. To help mitigate this risk, the full change order process is invoked for this step too.
ACME has decided that there is no reason to delay decommissioning once the last service has been migrated. Decommissioning the network is on the critical path because this space is earmarked for another purpose.
Checking for stragglers is a must. All services should have already been migrated or decommissioned, but this needs to be verified. Verification steps can include some of the following.
- Clear port counters and check if they stay at zero or if they increase.
- Check the MAC address and Address Resolution Protocol (ARP) tables for active hosts.
- Check the DCI for unexpected traffic.
Investigate all evidence that points to a service that may incur downtime because of network decommissioning.
Once it’s verified that the original data center isn’t home to active services, execute the MOP.
Got Iteration?
The goal of network implementation is to provide a working network and close out the project. In the last post, we discussed how requirements gathering and design could have iteration within themselves and between each other. The implementation phase also adds iteration, as seen in the figure below.
Problems can arise in any of the Build, Test and Integration phases of implementation. When this happens, there are three possibilities.
- Iterate inside implementation until the problems are addressed.
- Go back to the design phase to adjust the design and then proceed to implementation.
- If going back to design doesn’t help, go back to clarify requirements, then back to design, then proceed to implementation.
If the problems require a visit to requirements gathering, it’s important not to go from requirements back to implementation, skipping design. Doing so would invalidate all design documents. All documentation is important artifacts to this project and future projects that may reference the documentation.
Read My Other Blogs in this Series
