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.
The Leader in Network Knowledge
Where's the Book?
Mike,
You have proven that you have the writing skills and the ability to interest us in standardized diagrams and Design templates etc. I have always made some efforts to provide documentation, but you seem to have it down to a science that we should replicate.
Time to talk to Cisco Press.
Architect your operations and security, too
All of the aforementioned technologies (plus security) will have to be operated, sometimes by multiple groups within your organization. With IOS based firewalls, wireless security, and other modules for the ISR (or ASR functions) you may have a challenge with what logs go where, where to send traps, etc. How will network operations play with that new SIEM system that the security guys are running? You should think about that beforehand as well.
Appreciation
I second the book suggestion.
There is a lack of a good book about network
documentation and the not-technical aspect
of network management.
I have found on the cisco nsp mailinglist an
entry of what should be included in a decent
network documentation. You can find it here:
http://puck.nether.net/pipermail/cisco-nsp/2008-February/047966.html
My current company has all
My current company has all these things in place. Even too much. Well, definetely it gives some help while designing new pieces of our huge network and keep things smooth and stable. But what we really miss is a n ability to innovate. If you want to add something new you need to go through all that documentation which only adds burocracy and slow things down.
I think it's good to have all that papers, but we should always remember not to make these things as a our main product. We are working to build and maintain networks and not papers.