What Goes Into a Written Network Architecture?

Some organizations build wonderful networks, but fail to document anything. Shortly after entropy sets in and instability begins to pop up in the network. More likely, if there wasn't a written network architecture to begin with, the network is never built correctly and problems begin from the outset. Many engineers and managers don't see the benefit of a written network architecture until it's too late.

The first blog I wrote on NetworkWorld's Cisco Subnet last July was "My First Rule of Network Architecture: Write it Down". I've also blogged about how Network Design Templates are one of the key part of a written network architecture. I even wrote about standard icons and naming conventions. As you can read, having a written architecture is key to a homogeneous, stable network.

However, I haven't detailed what should actually be in the written architecture; I've just said you need to have one. Obviously, everyone will have different architectures, but the following information should be in every written network architecture. Some of these can also be applied to other technology architectures, for example, IP telephony, Data Center Networks, and Storage Area Networks (SANs).

• Introduction and Business Drivers - this describes why you are writing the network architecture and what are the main business drivers for the network. Availability and consistent performance are given, but what else drives your network? Incredibly high availability for JIT manufacturing? Or maybe flexibility for fast growth?
• Global Network Design - a high-level description, with diagrams, of how the network goes together. People need to understand the big picture to see how all the little parts go together.
• Site Tiers - This is a key part of the network architecture. How do you categorize your sites? Maybe into five Tiers (1-5)? Maybe just three (Big, Medium, Small)? Any which way, you need a way to classify each of your sites so an appropriate Network Design Templates can be used. You should also include Site Decision Matrixes to help people decide which tier a site is, perhaps based on number of employees, or types of applications used, or business criticality.
• Network Design Templates - diagrams for each Site Tier ("1-5" or "Big, Medium, Small", etc.) that can be used repeatedly to build homogeneous networks at each site.
• Bill of Materials - the actual BOM that is used to order the equipment for each Site Tier. It is very important this BOM matches your Network Design Templates exactly since one missing piece of hardware can make a world of difference during installation. Your VAR or Cisco Sales can provide a detailed BOM for you based on your Network Design Templates and standards. Also include any other hardware used in the network like UPSs and cabling.
• WAN Options - types of WAN options that the network architecture will support, for example, MPLS, private lines, and IPSec tunnels. This list should include the WAN technologies that will likely be needed. Even if your entire network is using MPLS, you should have a few other technologies supported since needs can arise that may not be solved by a single WAN technology.
• Site Tracking List - once you have chosen a Site Tier, applied a Template, and picked appropriate WAN technologies for the site, you need to track all these decisions. This way you know how the NYC site is built - maybe as a Tier-2 site with dual MPLS circuits.
• Internet Access - how do people get outbound Internet access? What inbound access to company resources is provided from the Internet?
• Routing - since routing is arguably the key technology in a network, you need a section explaining how routing works. Sections should include normal and backup traffic flows, global routing, IGPs, BGP, static routes, and default routing.
• Configuration Standards - now that you have all the standards defined, you need actual device configuration standards. You should have exact configs for SNMP, booting, DHCP, HSRP, BGP, OSPF, ACLs, interfaces, VLANs, LAN switching....etc....etc...etc. In short, if it's a command on your equipment, have a written configuration standard for it.
• IP Addressing - how your global IP addressing and summarization is done, the policies for subnet allocation, and site specific IP subnetting standards. For example, if you assign a /22 to a Tier-3 site, how is that /22 divided into subnets? This is key to ensure IP addressing is the same at all sites.
• QoS - this can be a huge section that describes all aspects of QoS in your network. From LAN QoS, to IPT, to WAN QoS, to QoS with MPLS carriers, to where the actual applications fit into the QoS model. Take your time on this section since it is a key business enabler, but can also cause huge problems if implemented wrong.
• Wireless LAN - how does the WLAN work? (NOTE: this may require it's own architecture document like IPT and SANs if your WLAN is not simple.)
• Naming Conventions - these are more important than you may originally think. Spend some time to ensure your naming conventions are correct.
• Software Standards - levels, versions, and features sets of software used in the network. From IOS, to VPN concentrators, to firewalls. Each piece of equipment in use should have a software standard. You will also want to include a process for software maintenance and changes.
• Best Practices - a list of best practices for your network; things you have learned over the years that are unique to your environment.
• Network Architecture Review Board and Architecture Revision Process - these are the rules and guidelines on how you will make changes to all the stuff written above.

Ok, that is a lot of stuff. This is not something you're going to write next weekend. It took me 6 weeks to write our first architecture and that was just version 1.0. We are now up to version 5.0 and have a very robust, written architecture. As time goes by your architecture will get better and more mature also. In time, it will be the key differentiator for your network; more important than any piece of hardware, routing protocol design, or network management tool. A written architecture will go more toward making your network stable and scalable than anything you could ever buy from a vendor.

Now, get out there and start writing! ;-)

More >From the Field blog entries:

A Day in the Life....

No Love For Central Office Techs

How to Establish an Architecture Revision Process

Do You Have an Architecture Review Board?

NX-OS's Best Feature: Virtual Device Contexts (VDCs)

Come Visit Me at FutureNet

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.