NETWORK ENGINEERING
Network test plan: Checklist for architecture changes
Tom Lancaster
10.30.2006
Rating: -3.66- (out of 5)
|
Previously, I wrote about how test and backout plans work together. For every change you make to your network architecture, you should have a test plan and a backout plan. A test plan, for example, might be as simple as plugging in your laptop and pinging a server to verify connectivity. Most changes are much more complex, however, and usually involve many steps -- requiring a more involved testing plan. In this tip, I will discuss building a test plan and provide a sample checklist of things to put in your plans. Of course, every network project is different, so every test plan is different. Therefore, this checklist is far from comprehensive, but it can serve as a set of examples to help you understand the types of items to construct.
Your test plan is primarily comprised of test cases and test items. Think of a test case as a scenario or a finite state in which your network might find itself. For instance, if you're going through a long, complex network migration that involves several changes, you would want a test case that represents the normal, converged operation of the network and a case for each step along the way. You'd want another test case that represents the failure of a given component, like what happens if you lose your primary WAN circuit, or one of your core routers or switches or a fiber between two devices. Each of these would be a case.
In each test case, you'll have a list of test items or functions or features that you want to evaluate. Each test item should include not just an action, but the success criteria, and if you want to get more sophisticated, criticality. For example, you might want to make sure a business-critical application still works after a network change. So you'd arrange to have the application owners create a transaction or operate the application. Along with that, you'd make sure they describe a successful transaction prior ...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
to execution so there's no question about whether or not it works. And you also want to know if the test fails, if it's important enough to cause your whole change to fail and be backed out. This is because sometimes your change might be more important, and there might be a workaround for the problem.
For the checklist, it's helpful to think in some broad categories. First is basic connectivity at the network layer. Next is application layer connectivity. As another dimension, add performance to each test where it makes sense.
Network connectivity
- Is Layer 2 set up appropriately? (VLANs on the right trunks, PVCs, etc.)
- Do your router tables have the proper routes? (Check the next hops and ages, too.)
- Can you ping everywhere in the network? (Performance: Are the times acceptable?)
- Do traceroutes show paths you would expect?
- If you load balance across the core of your network, verify each link is being used.
- Is DHCP handing out addresses?
- DNS resolving names properly?
- Does your remote access still work?
Application connectivity
- Does VOIP work? Is it showing up in the right queues?
- Are your firewalls and proxies blocking and allowing traffic appropriately?
- Can you browse the Web?
- Are your network management and logging systems working?
- Do your business applications work? (And do transactions complete in an acceptable time?)
- Are backup jobs still working?
As mentioned previously, your chances of success are much greater if you perform several simple tests along the way, rather than waiting until you think you're done and discovering that something doesn't work.
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
|
|
|
|
|
|
