Chapter 1, “A Business Case for Enterprise Network Testing,” stressed the importance of assessing the business reasons for testing as your first step in crafting an effective test approach. In the same way that a network designer would be foolish to specify equipment or make technical recommendations without prior knowledge of customer requirements, a test engineer would be misguided to attempt writing a test plan without first understanding the triggers, scope, motives, and expectations for the test initiative. By rushing ahead and skipping this critical step, you risk missing the mark in your testing, focusing on the wrong types of tests, or capturing erroneous results. This will waste precious time and resources as you continuously redefine your test plan; add, remove, or modify equipment to your lab topology; rerun your test cases; and generate reports. Taking time to identify the objectives and outline an assessment is critical before you ever step foot into the lab. Only after the following questions are answered should you begin to write a detailed test plan or build a lab topology:
What are the test triggers?
Who is requesting the test and what are their motives?
How much testing is necessary and what constitutes success?
What is the impact of test failure and what are the known risks?
What are the resources (people, lab equipment, and test tools) required to execute the test?
As discussed in Chapter 2, “Testing Throughout the Network Lifecycle,” a complimentary relationship betweennetwork testing and design functions exists in organizations that execute enterprise architecture effectively. We explained how structured testing complements and validates design deliverables, by providing examples of the different types of test requests that you can expect throughout the network’s lifecycle.This chapter will begin to fill in the practical details of what is necessary to build an effective approach toward different types of test requests. It begins with a suggested approach for assessing and scoping a test project, and offers guidance and best practices for the following considerations:
How to identify test case scenarios
How to develop a lab prototype
How to choose the proper test tools necessary to execute the different types of tests
How to write a detailed test plan
As with most technical undertakings, there is no absolute right way to approach systems testing. We do not promote ours as the only way to conduct successful testing. However, this is a proven method that will improve your chances of getting it right the first time.
Andy Sholomon, CCIE No. 15179, works as a Network Consulting Engineer (NCE) in Cisco’s Central Engineering Performance and Validation Testing team. He routinely plans and performs network testing for some of Cisco’s largest Enterprise customers. In his six years at Cisco, Andy has been involved in both planning and deploying some of the largest enterprise data centers in the United States. He has also worked with some of Cisco’s large service provider customers. Before joining Cisco, Andy worked as a Network Engineer in the global financial industry, spending 5 years at UBS in multiple roles, including security engineering, and worked as a Systems Engineer at Spear, Leeds & Kellogg (now a part of Goldman Sachs Group). Andy has been a speaker at the Cisco Live Networkers Conference. Besides the CCIE, Andy holds multiple industry certifications, including the CISSP and MCSE. Andy lives with his wife, daughter and Great Dane in Chapel Hill, North Carolina.
I looked for some forums and I didn't get a clear answer, so let's try again. With the new CCIE test from February 2020 onwards, anyone who is CCNP (valid, exemple, expiring in 2022) will be able to take the new practice test directly, or will need t...
HSRP failback doesnt work properly. standby status changes ACT <=> SBY unstably when its time to failback.but without "mac-address-table secure" setting, the failback worksi think mac address filter is the problem, but i dont know how to fix... can ...
Aren't they all for inband queue?
*show system inband queuing statistics
*show hardware internal cpu-mac inband stats
show system inband queuing statistics (Drop)
Inband packets unmapped to a queue: 0
Inband packets mapped...
Hello all and thanks for your time and expertise. Please note this question is not a hard line technical question per se. Here's the scenario: There's a tech in my department that has zero IT training or background (doesn't even hal...