Thursday, October 1, 2015

Introduction to Troubleshooting

Introduction to Troubleshooting

Troubleshooting is a skill, and like all skills, you will get better at it the more you have to perform it. The more troubleshooting situations you are placed in, the more your skills will improve, and as a result of this, the more your confidence will grow. However, don’t start wishing for issues to happen in your organization just so that you can get more experience. Although there is no right or wrong way to troubleshoot, there is definitely a more efficient and effective way to troubleshoot that all experienced troubleshooters follow. This section begins by introducing you to troubleshooting. It then focuses on a structured troubleshooting approach that provides you with some common methods to enhance your efficiency.

Defining Troubleshooting

Troubleshooting at its essence is the process of responding to a problem report (sometimes in the form of a trouble ticket), diagnosing the underlying cause of the problem, and resolving the problem. Although you normally think of the troubleshooting process as beginning when a user reports an issue, you need to understand that through effective network monitoring you may detect a situation that could become a troubleshooting issue and resolve that situation before it impacts users.

After an issue is reported, the first step toward resolution is clearly defining the issue. When you have a clearly defined troubleshooting target, you can begin gathering further information related to it. From this information, you should be able to better define the issue. Then based on your diagnosis, you can propose an hypothesis about what is most likely causing the issue. Then the evaluation of these likely causes leads to the identification of the suspected underlying root cause of the issue.

After you identify a suspected underlying cause, you next define approaches to resolving the issue and select what you consider to be the best approach. Sometimes the best approach to resolving an issue cannot be implemented immediately. For example, a piece of equipment might need replacing, or a business’s workflow might be disrupted by implementing such an approach during working hours. In such situations, a troubleshooter might use a temporary fix until a permanent fix can be put in place.

Let’s look at an example. It is 3:00 p.m. at a luxury hotel in Las Vegas. On this day, the hotel cannot register guests or create the keycards needed for guest rooms. After following the documented troubleshooting procedures, the network team discovers that Spanning Tree Protocol (STP) has failed on a Cisco Catalyst switch, resulting in a Layer 2 topological loop. Thus, the network is being flooded with traffic, preventing registrations and keycards from being completed because the server is not accessible. The network team now has to decide on the best course of action at this point. The permanent fix of replacing the failed equipment immediately would disrupt the network further and take a considerable amount of time, thus delaying the guest registrations further. A temporary fix would be to disconnect the redundant links involved in the loop so that the Layer 2 loop is broken and guests can be registered at that point. When the impact on guests and guest services is minimal, the network team can implement the permanent fix. Consider  Figure 1-1 , which depicts a simplified model of the troubleshooting steps previously described. 


Figure 1-1 Simplified Troubleshooting Flow

This simplified model consists of three steps:
  •  Step 1. Problem report
  •  Step 2. Problem diagnosis
  •  Step 3. Problem resolution
Of these three steps, most of a troubleshooter’s efforts are spent in the problem diagnosis step. For example, your child reports that the toaster won’t work. That is the problem report step. You have it clarified further, and your child indicates that the toaster does not get hot. So, you decide to take a look at the toaster and diagnose it. This is the problem diagnosis step, which is broken up into multiple subcomponents. Table 1-2 describes key components of this problem diagnosis step.

Table 1-2 Steps to Diagnose a Problem


After collecting, examining, and eliminating, you hypothesize that the power cable for the toaster is not plugged in. You test your hypothesis, and it is correct. Problem solved. This was a simple example, but even with a toaster, you spent the majority of your time diagnosing the problem. Once you determined that there was no electricity to the toaster, you had to figure out whether it was plugged in. If it was plugged in, you then had to consider whether the wall outlet was damaged, or the circuit breaker was off, or the toaster was too old and it broke. All of your effort focused on the problem diagnosis step.

By combining the three main steps with the five substeps, you get the following structured troubleshooting procedure:
  • Step 1. Problem report
  • Step 2. Collect information
  • Step 3. Examine collected information
  • Step 4. Eliminate potential causes
  • Step 5. Propose an hypothesis
  • Step 6. Verify hypothesis
  • Step 7. Problem resolution

The Value of Structured Troubleshooting

Troubleshooting skills vary from administrator to administrator, and as mentioned earlier, your skills as a troubleshooter will get better with experience. However, as a troubleshooter, your primary goal is to be efficient. Being fast comes with experience, but it is not worth much if you are not efficient. To be efficient, you need to follow a structured troubleshooting method. A structured troubleshooting method might look like the approach depicted in Figure 1-2 .

If you do not follow a structured approach, you might find yourself moving around troubleshooting tasks in a fairly random way based on instinct. Although in one instance you might be fast at solving the issue, in the next instance you end up taking an unacceptable amount of time. In addition, it can become confusing to remember what you have tried and what you have not. Eventually, you find yourself repeating solutions you have already tried, hoping it works. Also, if another administrator comes to assist you, communicating to that administrator the steps you have already gone through becomes a challenge. Therefore, following a structured troubleshooting approach helps you reduce the possibility of trying the same resolution more than once and inadvertently skipping a task. It also aids in communicating to someone else possibilities that you have already eliminated.

With experience, you will start to see similar issues. In addition, you should have exceptional documentation on past network issues and the steps used to solve them. In such instances, spending time methodically examining information and eliminating potential causes might actually be less efficient than immediately hypothesizing a cause after you collect information about the problem and review past documents. This method, illustrated in Figure 1-3 , is often called the shoot from the hip method . 


Figure 1-2 Example of a Structured Troubleshooting Approach 


Figure 1-3 Example of a Shoot from the Hip Troubleshooting Approach

The danger with the shoot from the hip method is that if your instincts are incorrect, and the problem is not solved, you waste valuable time. Therefore, you need to be able to revert back to the structured troubleshooting approach as needed and examine all collected information.

 A Structured Approach
 No single collection of troubleshooting procedures is capable of addressing all conceivable network issues because there are too many variables (for example, user actions). However, having a structured troubleshooting approach helps ensure that the organization’s troubleshooting efforts are following a similar flow each time an issue arises no matter who is assigned the task. This will allow one troubleshooter to more efficiently take over for or assist another troubleshooter if required.

This section examines each step in a structured approach in more detail as shown in  Figure 1-4 . 


Figure 1-4 A Structured Troubleshooting Approach

1. Problem Report
A problem report from a user often lacks sufficient detail for you to take that problem report and move on to the next troubleshooting process (that is, collect information). For example, a user might report, “The network is broken.” If you receive such a vague report, you probably need to contact the user and ask him exactly what aspect of the network is not functioning correctly.

After your interview with the user, you should be able to construct a more detailed problem report that includes statements such as, when the user does X, she observes Y . For example, “When the user attempts to connect to a website on the Internet, her browser reports a 404 error. However, the user can successfully navigate to websites on her company’s intranet.” Or, “When the user attempts to connect to an FTP site using a web browser, the web browser reports the page can’t be displayed.”

After you have a clear understanding of the issue, you might need to determine who is responsible for working on the hardware or software associated with that issue. For example, perhaps your organization has one IT group tasked with managing switches and another IT group charged with managing routers. Therefore, as the initial point of contact, you might need to decide whether this issue is one you are authorized to address or if you need to forward the issue to someone else who is authorized. If you are not sure at this point, start collecting information so that the picture can become clearer, and be mindful that you might have to pass this information on to another member of your IT group at some point, so accurate documentation is important.

2. Collect Information
When you are in possession of a clear problem report, the next step is gathering relevant information pertaining to the problem, as shown in Figure 1-5 . 


Figure 1-5 A Structured Troubleshooting Approach (Collect Information)

Efficiently and effectively gathering information involves focusing information gathering efforts on appropriate network entities (for example, routers, servers, switches, or clients) from which information should be collected. Otherwise, the troubleshooter could waste time wading through reams of irrelevant data. For example, to be efficient and effective, the troubleshooter needs to understand what is required to access the resources the end user is unable to access. With our FTP site problem report, the FTP resources are accessible through an FTP client. Troubleshooters not aware of that might spend hours collecting irrelevant data with debug , show , ping , and traceroute commands, when all they had to do was point the user to the FTP client installed on the client’s computer.

 In addition, perhaps a troubleshooter is using a troubleshooting model that follows the path of the affected traffic (as discussed in the “Popular Troubleshooting Methods” section of this chapter), and information needs to be collected from a network device over which the troubleshooter has no access. At that point, the troubleshooter might need to work with appropriate personnel who have access to that device. Alternatively, the troubleshooter might switch troubleshooting models. For example, instead of following the traffic’s path, the troubleshooter might swap components or use a bottom-up troubleshooting model.

3. Examine Collected Information
After collecting information about the problem report (for example, collecting output from show or debug commands, performing packet captures, using ping , or traceroute ), the next structured troubleshooting step is to analyze the collected information as shown in Figure 1-6 . 


Figure 1-6 A Structured Troubleshooting Approach (Examine Information)

A troubleshooter has two primary goals while examining the collected information:
  • Identify indicators pointing to the underlying cause of the problem
  • Find evidence that can be used to eliminate potential causes

To achieve these two goals, the troubleshooter attempts to find a balance between two questions:
What is occurring on the network?

What should be occurring on the network?

The delta between the responses to these questions might give the troubleshooter insight into the underlying cause of a reported problem. A challenge, however, is for the troubleshooter to know what currently should be occurring on the network.

If the troubleshooter is experienced with the applications and protocols being examined, the troubleshooter might be able to determine what is occurring on the network and how that differs from what should be occurring. However, if the troubleshooter lacks knowledge of specific protocol behavior, she still might be able to effectively examine the collected information by contrasting that information with baseline data or documentation.

 Baseline data might contain, for example, the output of show and debug commands issued on routers when the network was functioning properly. By contrasting this baseline data with data collected after a problem occurred, even an inexperienced troubleshooter might be able to see the difference between the data sets, thus providing a clue as to the underlying cause of the problem under investigation. This implies that as part of a routine network maintenance plan, baseline data should periodically be collected when the network is functioning properly.

Documentation plays an extremely important role at this point. Accurate and up-to-date documentation can assist a troubleshooter in examining the collected data to determine whether anything has changed in relation to the setup or configuration. Going back to the FTP example, if the troubleshooter was not aware that an FTP client was required, a quick review of the documentation related to FTP connectivity would indicate so. This would allow the troubleshooter to move on to the next step.

4. Eliminate Potential Causes
Following an examination of collected data, a troubleshooter can start to form conclusions based on that data. Some conclusions might suggest a potential cause for the problem, whereas other conclusions eliminate certain causes from consideration (see Figure  1-7 ).


Figure 1-7 A Structured Troubleshooting Approach (Eliminate Potential Causes)

It is imperative that you not jump to conclusions at this point. Jumping to conclusions can make you less efficient as a troubleshooter as you start formulating hypotheses based on a small fraction of collected data, which leads to more work and slower overall response times to problems. As an example, a troubleshooter might jump to a conclusion based on the following scenario, which results in wasted time:

A problem report indicates that PC A cannot communicate with server A, as shown in Figure 1-8 . The troubleshooter is using a troubleshooting method that follows the path of traffic through the network. The troubleshooter examines output from the show cdp neighbor command on routers R1 and R2. Because those routers do not recognize each other as Cisco Discovery Protocol (CDP) neighbors, the troubleshooter leaps to the conclusion that Layer 2 and Layer 1 connectivity is down between R1 and R2. The troubleshooter then runs to the physical routers to verify physical connectivity, only to see that all is fine. Reviewing further output and documentation indicates that CDP is disabled on R1 and R2 interfaces for security reasons. Therefore, the output of show cdp neighbors alone is insufficient to conclude that Layer 2 and 1 connectivity was the problem. 


Figure 1-8 Scenario Topology

On another note, a caution to be observed when drawing conclusions is not to read more into the data than what is actually there. As an example, a troubleshooter might reach a faulty conclusion based on the following scenario:

A problem report indicates that PC A cannot communicate with server A, as shown in Figure 1-8 . The troubleshooter is using a troubleshooting method that follows the path of traffic through the network. The troubleshooter examines output from the show cdp neighbor command on routers R1 and R2. Because those routers recognize each other as Cisco Discovery Protocol (CDP) neighbors, the troubleshooter leaps to the conclusion that these two routers see each other as Open Shortest Path First (OSPF) neighbors and have mutually formed OSPF adjacencies. However, the show cdp neighbor output is insufficient to conclude that OSPF adjacencies have been formed between routers R1 and R2.

In addition, if time permits, explaining the rationale for your conclusions to a coworker can often help reveal faulty conclusions. As shown by the previous examples, continuing your troubleshooting efforts based on a faulty conclusion can dramatically increase the time required to resolve a problem.

5. Propose an Hypothesis
By eliminating potential causes of a reported problem, as described in the previous process, troubleshooters should be left with one or a few potential causes that they can focus on. At this point, troubleshooters should rank the potential causes from most likely to least likely. Troubleshooters should then focus on the cause they believe is most likely to be the underlying one for the reported problem and propose an hypothesis, as shown in Figure 1-9 . 


Figure 1-9 A Structured Troubleshooting Approach (Propose an Hypothesis)

After proposing an hypothesis, troubleshooters might realize that they are not authorized to access a network device that needs to be accessed to resolve the problem report. In such a situation, a troubleshooter needs to assess whether the problem can wait until authorized personnel have an opportunity to resolve the issue. If the problem is urgent and no authorized administrator is currently available, the troubleshooter might attempt to at least alleviate the symptoms of the problem by creating a temporary workaround. Although this approach does not solve the underlying cause, it might help business operations continue until the main cause of the problem can be appropriately addressed.

6. Verify Hypothesis
After troubleshooters propose what they believe to be the most likely cause of a problem, they need to develop a plan to address the suspected cause and implement it. Alternatively, if troubleshooters decide to implement a workaround, they need to come up with a plan and implement it while noting that a permanent solution is still needed. However, implementing a plan that resolves a network issue often causes temporary network outages for other users or services. Therefore, the troubleshooter must balance the urgency of the problem with the potential overall loss of productivity, which ultimately affects the financial bottom line. There should be a change management procedure in place that helps the troubleshooter determine the most appropriate time to make changes to the production network and the steps required to do so. If the impact on workflow outweighs the urgency of the problem, the troubleshooter might wait until after business hours to execute the plan.

A key (and you should make it mandatory) component in implementing a problem solution is to have the steps documented. Not only does a documented list of steps help ensure the troubleshooter does not skip any, but such a document can serve as a rollback plan if the implemented solution fails to resolve the problem. Therefore, if the problem is not resolved after the troubleshooter implements the plan, or if the execution of the plan resulted in one or more additional problems, the troubleshooter should execute the rollback plan. After the network is returned to its previous state (that is, the state prior to deploying the proposed solution); the troubleshooter can then reevaluate her hypothesis.  Although the troubleshooter might have successfully identified the underlying cause, perhaps the solution failed to resolve that cause. In that case, the troubleshooter could create a different plan to address that cause. Alternatively, if the troubleshooter had identified other causes and ranked them during the propose an hypothesis step, she can focus her attention on the next most likely cause and create an action plan to resolve that cause and implement it.

This process can be repeated until the troubleshooter has exhausted the list of potential causes or is unable to collect information that can point to other causes, as shown in  Figure 1-10 . At that point, a troubleshooter might need to gather additional information or enlist the aid of a coworker or the Cisco Technical Assistance Center (TAC). 


Figure 1-10 A Structured Troubleshooting Approach (Verify Hypothesis)

7. Problem Resolution
This is the final step of the structured approach, as shown in Figure 1-11 . Although this is one of the most important steps, it is often forgotten or overlooked. After the reported problem is resolved, the troubleshooter should make sure that the solution becomes a documented part of the network. This implies that routine network maintenance will maintain the implemented solution. For example, if the solution involves reconfiguring a Cisco IOS router, a backup of that new configuration should be made part of routine network maintenance practices.

As a final task, the troubleshooter should report the problem resolution to the appropriate party or parties. Beyond simply notifying a user that a problem has been resolved, the troubleshooter should get user confirmation that the observed symptoms are now gone. This task confirms that the troubleshooter resolved the specific issue reported in the problem report, rather than a tangential issue. 


Figure 1-11 A Structured Troubleshooting Approach (Problem Resolution)

Introduction to Troubleshooting and Network Maintenance

Introduction to Troubleshooting and Network Maintenance

Business operations, without a doubt, depend on the reliable operation of data networks (which might also carry voice and video traffic). This statement holds true regardless of the business size. A structured and systematic maintenance approach significantly contributes to the uptime for all networks. In addition, having a sound troubleshooting methodology in place helps ensure that when issues arise you are confident and ready to fix them.

Consider a vehicle as an example. Regular maintenance such as oil changes, joint lubrication, and fluid top-offs are performed on a vehicle to ensure that problems do not arise and the life of that vehicle is maximized. However, if an issue does arise, it is taken to a mechanic so that they may troubleshoot the issue using a structured troubleshooting process and ultimately fix the vehicle. Similarly, the number of issues in a network can be reduced by following a maintenance plan, and troubleshooting can be more effective with a structured approach in place.

This chapter discusses the importance of having a structured troubleshooting approach and a solid network maintenance plan. It identifies many popular models, structures, and tasks that should be considered by all organizations. However, as you will see, there is no “one-stop shop for all your needs” when it comes to troubleshooting and network maintenance. It is more of an art that you will master over time.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 1-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 1-1 “Do I Know This Already?” Section-to-Question Mapping



Caution :- The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer that you correctly guess skews your self-assessment results and might provide you with a false sense of security

1. Identify the three steps in a simplified troubleshooting model.

a. Problem replication
b. Problem diagnosis
c. Problem resolution
d. Problem report

2. Which of the following is the best statement to include in a problem report?

a. The network is broken.
b. User A cannot reach the network.
c. User B recently changed his PC’s operating system to Microsoft Windows 7.
d. User C is unable to attach to an internal share resource of \\10.1.1.1\Budget, although he can print to all network printers, and he can reach the Internet.

3. What troubleshooting step should you perform after a problem has been reported and clearly defined?

a. Propose an hypothesis
b. Collect information
c. Eliminate potential causes
d. Examine collected information

4. What are the two primary goals of troubleshooters as they are collecting information?

a. Eliminate potential causes from consideration
b. Identify indicators pointing to the underlying cause of the problem
c. Propose an hypothesis about what is most likely causing the problem
d. Find evidence that can be used to eliminate potential causes

5. When performing the “eliminate potential causes” troubleshooting step, which caution should the troubleshooter be aware of?

a. The danger of drawing an invalid conclusion from the observed data
b. The danger of troubleshooting a network component over which the troubleshooter does not have authority
c. The danger of causing disruptions in workflow by implementing the proposed solution
d. The danger of creating a new problem by implementing the proposed solution

6. A troubleshooter is hypothesizing a cause for an urgent problem, and her hypothesis involves a network device that she is not authorized to configure. The person who is
authorized to configure the network device is unavailable. What should the troubleshooter do?

a. Wait for authorized personnel to address the issue.
b. Attempt to find a temporary workaround for the issue.
c. Override corporate policy, based on the urgency, and configure the network device independently because authorized personnel are not currently available.
d. Instruct the user to report the problem to the proper department that is authorized to resolve the issue.

7. Experienced troubleshooters with in-depth comprehension of a particular network might skip the examine information and eliminate potential causes steps in a structured troubleshooting model, instead relying on their own insight to determine the most likely cause of a problem. This illustrates what approach to network troubleshooting?

a. Ad hoc
b. Shoot from the hip
c. Crystal ball
d. Independent path

8. Which of the following troubleshooting models requires access to a specific application?

a. Bottom-up
b. Divide-and-conquer
c. Comparing configurations
d. Top-down

9. Based on your analysis of a problem report and the data collected, you want to use a troubleshooting model that can quickly eliminate multiple layers of the OSI model as potential sources of the reported problem. Which of the following troubleshooting methods would be most appropriate?

a. Following the traffic path
b. Bottom-up
c. Divide-and-conquer
d. Component swapping

10. Which of the following are considered network maintenance tasks? (Choose the three best answers.)

a. Troubleshooting problem reports
b. Attending training on emerging network technologies
c. Planning for network expansion
d. Hardware installation

11. Network maintenance tasks can be categorized into one of which two categories?

a. Recovery tasks
b. Interrupt-driven tasks
c. Structured tasks
d. Installation tasks

12. Which letter in the FCAPS acronym represents the maintenance area responsible for billing end users?
a. F
b. C
c. A
d. P
e. S

13. The lists of tasks required to maintain a network can vary widely, depending on the goals and characteristics of that network. However, some network maintenance tasks are common to most networks. Which of the following would be considered a common task that should be present in any network maintenance model?

a. Performing database synchronization for a network’s Microsoft Active Directory
b. Making sure that digital certificates used for PKI are renewed in advance of their expiration
c. Using Cisco Prime to dynamically discover network device changes
d. Performing scheduled backups

14. Which of the following statements is true about scheduled maintenance?
a. Scheduled maintenance helps ensure that important maintenance tasks are not overlooked.
b. Scheduled maintenance is not recommended for larger networks, because of the diversity of maintenance needs.
c. Maintenance tasks should only be performed based on a scheduled maintenance schedule, to reduce unexpected workflow interruptions.
d. Scheduled maintenance is more of a reactive approach to network maintenance, as opposed to a proactive approach.

15. Which of the following questions are appropriate when defining your change management policies?

a. What version of operating system is currently running on the device to be upgraded?
b. What is the return on investment (ROI) of an upgrade?
c. What measureable criteria determine the success or failure of a network change?
d. Who is responsible for authorizing various types of network changes?

16. Which three of the following components would you expect to find in a set of network documentation?

a. Logical topology diagram
b. Listing of interconnections
c. Copy of IOS image
d. IP address assignments

17. What is the ideal relationship between network maintenance and troubleshooting?

a. Networking maintenance and troubleshooting efforts should be isolated from one another.
b. Networking maintenance and troubleshooting efforts should complement one another.
c. Networking maintenance and troubleshooting efforts should be conducted by different personnel.
d. Networking maintenance is a subset of network troubleshooting.

18. Which three of the following suggestions can best help troubleshooters keep in mind the need to document their steps?

a. Require documentation
b. Keep documentation in a hidden folder
c. Schedule documentation checks
d. Automate documentation

19. Which three troubleshooting phases require clear communication with end users?
a. Problem report
b. Information collection
c. Hypothesis verification
d. Problem resolution

20. What are two elements of a change management system?

a. Determine when changes can be made
b. Determine potential causes for the problem requiring the change
c. Determine who can authorize a change
d. Determine what change should be made

Monday, August 17, 2015

CCNP Routing and Switching TSHOOT 300-135 Official Study Guide

CCNP Routing and Switching TSHOOT 300-135 Official Study Guide from Cisco Press allows you to succeed on the exam the first time and is the only self-study resource approved by Cisco. Expert instructor Raymond Lacoste shares preparation hints and test-taking tips, helping you identify areas of weakness and improve both your conceptual knowledge and hands-on skills.


This complete, official study package includes

A test-preparation routine proven to help you pass the exam
  • Do I Know This Already? quizzes, which allow you to decide how much time you need to spend on each section
  • Chapter-ending exercises, which help you drill on key concepts you must know thoroughly
  • The powerful Pearson IT Certification Practice Test software, complete with hundreds of exam-realistic questions, customization options, and detailed performance reports
  • More than 60 minutes of personal video mentoring from the author on important exam strategies
  • A trouble ticket chapter that explores ten additional network failures and the approaches you can take to resolve the issues presented
  • A final preparation chapter, which guides you through tools and resources to help you craft your review and test-taking strategies
  • Study plan suggestions and templates to help you organize and optimize your study time
Well-regarded for its level of detail, study plans, assessment features, challenging review questions and exercises, this official study guide helps you master the concepts and techniques that ensure your exam success.

CCNP Routing and Switching TSHOOT 300-135 Official Study Guide is part of a recommended learning path from Cisco that includes simulation and hands-on training from authorized Cisco Learning Partners and self-study products from Cisco Press. To find out more about instructor-led training, e-learning, and hands-on instruction offered by authorized Cisco Learning Partners worldwide, please visit www.cisco.com.

The official study guide helps you master topics on the CCNP Routing and Switching TSHOOT 300-135 exam, including how to troubleshoot:
  • Device performance
  • VLANs, Trunks, and VTP
  • STP and Layer 2 Etherchannel
  • Inter-VLAN routing and Layer 3 Etherchannel
  • Switch security
  • HSRP, VRRP, GLBP
  • IPv4 and IPv6 addressing
  • IPv4/IPv6 routing and GRE tunnels
  • RIPv2, RIPng, EIGRP, and OSPF
  • Route maps, policy-based routing, and route redistribution
  • BGP
  • Management protocols, tools, and access
Companion CD-ROM

The CD-ROM contains more than 200 practice questions for the exam, memory table exercises and answer keys, a study planner tool, and more than 60 minutes of video.

Includes Exclusive Offer for 70% Off Premium Edition eBook and Practice Test Pearson IT Certification Practice Test minimum system requirements:

Windows Vista (SP2), Windows 7, or Windows 8.1; Microsoft .NET Framework 4.5 Client; Pentium class 1GHz processor (or equivalent); 512 MB RAM; 650 MB disc space plus 50 MB for each downloaded practice exam; access to the Internet to register and download exam databases

Cisco 300-135 Exam Training Materials

Pass-4Sure's Cisco 300-135 exam training materials are the necessities of each of candidates who participating in the IT certification. With this training material, you can do a full exam preparation. So that you will have the confidence to win the exam. Pass-4Sure's Cisco 300-135 exam training materials are highly targeted. Not every training materials on the Internet have such high quality. Only Pass-4Sure could be so perfect.

Each IT person is working hard for promotion and salary increases. It is also a reflection of the pressure of modern society. We should use the strength to prove ourselves. Participate in the Cisco 300-135 exam please. In fact, this examination is not so difficult as what you are thinking. You only need to select the appropriate training materials. Pass-4Sure's Cisco 300-135 exam training materials is the best training materials. Select the materials is to choose what you want. In order to enhance your own, do it quickly.

Pass-4Sure Cisco 300-135 exam information is proven. We can provide the questions based on extensive research and experience. Pass-4Sure has more than 10 years experience in IT certification 300-135 exam training, including questions and answers. On the Internet, you can find a variety of training tools. Pass-4Sure 300-135 exam questions and answers is the best training materials. We offer the most comprehensive verification questions and answers, you can also get a year of free updates.

Whole Pass-4Sure's pertinence exercises about Cisco certification 300-135 exam is very popular. Pass-4Sure's training materials can not only let you obtain IT expertise knowledge and a lot of related experience, but also make you be well prepared for the exam. Although Cisco certification 300-135 exam is difficult, through doing Pass-4Sure's exercises you will be very confident for the exam. Be assured to choose Pass-4Sure efficient exercises right now, and you will do a full preparation for Cisco certification 300-135 exam.

Pass-4Sure's training materials can test your knowledge in preparing for the exam, and can evaluate your performance within a fixed time. The instructions given to you for your weak link, so that you can prepare for the exam better. The Pass-4Sure's Cisco 300-135 exam training materials introduce you many themes that have different logic. So that you can learn the various technologies and subjects. We guarantee that our training materials has tested through the practice. Pass-4Sure have done enough to prepare for your exam. Our material is comprehensive, and the price is reasonable.

To effectively getting ready for Cisco 300-135 test, do you know what tools are worth using? Let me tell you. Pass-4Sure Cisco 300-135 pdf dumps are the most credible. The exam dumps is rare certification training materials which are researched by IT elite. Pass-4Sure 300-135 braindump has a high hit rate. 100% sail through your exam. This is because IT experts can master the question point well, so that all questions the candidates may come across in the actual test are included in Pass-4Sure exam dumps. Is it amazing? But it is true. After you use our dumps, you will believe what I am saying.

Pass-4Sure's 300-135 exam training materials evoke great repercussions in the examinees, and has established a very good reputation, which means that choosing Pass-4Sure 300-135 exam training materials is to choose success. After you buy our 300-135 vce dumps, if you fail to pass the certification exam or there are any problems of learning materials, we will give a full refund. What's more, after you buy our 300-135 exam, we will provide one year free renewal service.