This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: • Change one variable at a time. When under pressure to get a failed sys- tem back online, it is tempting to jump ahead and change many likely vari- ables at once. If you do, and your changes seem to fix the problem, then you will not understand exactly what led to the problem in the first place. Worse, your changes may fix the original problem, but lead to more unintended con- sequences that break other parts of the system. By changing your variables one at a time, you can precisely understand what went wrong in the first place, and be able to see the direct effects of the changes you make. • Do no harm. If you don ¡ t fully understand how a system works, don ¡ t be afraid to call in an expert. If you are not sure if a particular change will damage another part of the system, then either f nd someone with more experience or devise a way to test your change without doing damage. Putting a penny in place of a fuse may solve the immediate problem, but it may also burn down the building. It is unlikely that the people who design your network will be on call twenty- four hours per day to f x problems when they arise. Your troubleshooting team will need to have good troubleshooting skills, but may not be competent enough to con f gure a router from scratch or crimp a piece of LMR-400. It is often much more ef f cient to have a number of backup components on-hand, and train your team to be able to swap out the entire broken part. This could mean having an access point or router pre-con f gured and sitting in a locked cabinet, plainly labeled and stored with backup cables and power supplies. Your team can swap out the failed component, and either send the broken part to an expert for repair, or arrange to have another backup sent in. As- suming that the backups are kept secure and are replaced when used, this can save a lot of time for everyone. Common network problems Often, connectivity problems come from failed components, adverse weather, or simple miscon f guration. Once your network is connected to the Internet or opened up to the general public, considerable threats will come from the network users themselves. These threats can range from the benign to the outright malevolent, but all will have impact on your network if it is not prop- erly con f gured. This section looks at some common problems found once your network is used by actual human beings. Locally hosted websites If a university hosts its website locally, visitors to the website from outside the campus and the rest of the world will compete with the university's staff for Internet bandwidth. This includes automated access from search engines that periodically spider your entire site. One solution to this problem is to use split DNS and mirroring. The university mirrors a copy of its websites to a Chapter 9: Troubleshooting 271 server at, say, a European hosting company, and uses split DNS to direct all users from outside the university network to the mirror site, while users on the university network access the same site locally. the university network access the same site locally....
View Full Document