Troubleshooting and Baseline Assessment

CIS436 Internet Troubleshooting Week 2 Discussion: “Troubleshooting and Baseline Assessment” Please respond to the following:

Imagine that you are a network engineer at a midsized university. Your supervisor has informed you that academic personnel are experiencing problems when they attempt to access the server that contains student information such as grades, attendance, and financial information. You have access to the network devices and the server, but the client devices are located remotely so you will not be able to start from there. Suggest at least two (2) possible troubleshooting approaches to resolve the problems that the academic personnel are experiencing. Explain the primary benefits and drawbacks of each approach. Provide rationales to support your response.

Imagine that you’re a network engineer and you have been tasked with identifying the cause of a network outage. What are the required steps of analyzing a hypothesis? Explain your scenario and describe how you would propose a hypothesis?

Week 2 Discussion Response:

If I were a network engineer at a mid-sized university and my supervisor informed me that academic personnel are experiencing problems, I would employ the structured approach to troubleshooting and examine collected information from the reported problem. When she tells me the issue appears when they attempt to access the server that contains student information such as grades, attendance, and financial information, I would eliminate potential causes and propose a hypothesis. I’ve verified I have access to the network devices and the server, but the client devices are located remotely so I will not be able to start from there. Not being able to start from there suggests I cannot use the bottom-up method of troubleshooting because I don’t have remote access to the client devices at layer 1 the physical layer. The two possible troubleshooting approaches I would choose to resolve the problems that the academic personnel are experiencing are the following the traffic and/or the comparing configuration methods. Since I personally would be a novice network engineer, (new to the job and title) I would use the comparing configuration method because it is often used by less experienced troubleshooters unsure of their knowledge of a network. If I were a seasoned professional network engineer who’d worked within the mid-sized university for years, I would use the following the traffic path method of troubleshooting because I’d either have already diagnosed the problem from network familiarity or trouble familiarity. The primary drawbacks of using each approach is resolution without understanding that fosters problem recurrence and waisted time.

If I were a network engineer and I have been tasked with identifying the cause of a network outage, the required steps of analyzing a hypothesis would be to propose a hypothesis, then verify it. During the verify process, the hypothesis would be tested against problem resolution. If the problem is not resolved, aspects of the structured approach would be revisited. The troubleshooter would either have to reexamine collect information, examine information, and/or propose a hypothesis. A possible scenario would be if the network engineers’ structured approach and choice of traffic path method identified the server as the reason why grades, attendance, and financial information cannot be accessed. If the result of the hypothesis process shows the problem still exists, the engineer must repeat steps of the structured approach to find the solution.

How can PING help you gather facts?

Response: According to our course material, a successful ping confirms that Layer 1, 2, and 3 of the OSI model are functioning. Essentially, a successful ping allows the troubleshooter to focus on higher layers of the OSI model, specifically Layer 4. Alternatively, an unsuccessful ping would suggest the troubleshooter begin troubleshooting at Layer 1. Eliminating Layers 1-3 to begin troubleshooting at Layer 4 simply saves the troubleshooter time and indicates a more specific area of concern.

According to our course material, traceroute provides verified connectivity. A successful traceroute duplicates aspects of the ping command by providing verified Layer 3 connectivity. Traceroute also provides the network path taken to reach connected layers. Essentially, we could use the traceroute command after a failed ping to determine where the ping failed.

Your post helpfully identifies, from obviously an experienced network troubleshooter, that we should obtain two perspectives of the issue from the most technical users. Then you state, “the unfortunate part is that you most likely can’t rely on them for a traceroute as it would be blocked by firewalls and not provide the full path.” An explanation of this statement would improve my novice understanding of network troubleshooting. “Can’t rely on them,” suggests we cannot reply on the users we gathered info from to perform a traceroute. I’m not sure why we would rely on users for a traceroute.