er how inconsequential they may seem. Check the Physical Layer First! My boss taught me this rule when I worked at an ISP. He used to teach troubleshoot- ing to telecom field engineers for one of the RBOCs. The idea here is that most failures are caused by physical faults. Cabling or hardware should be suspected first, and, between the two, look at the cabling first. Once you plant this idea in your mind, you'll be amazed how often it's borne out. To this day, I can hear him barking "Physical layer first!" at me during outages. Assume Nothing; Prove Everything When you assume something, it will return to bite you. As soon as you hear someone (including yourself) say, "It can't be that because...,' set out to prove that statement true or false. During outages, there seems to be a tendency for engineers to convince themselves that something must be true because they think it is. Don't assume anything is true unless you've proven it. Chapter 36: Failures Isolate the Problem Problems are often represented by multiple symptoms. Problems are also sometimes caused by other problems. For example, you may think you have a complex routing problem because packets are flowing in a way you think is wrong. However, the problem might be caused by an interface failure. You could spend hours trying to figure out a routing problem in a complex network, while the root cause is a simple interface failure. Try to isolate problems to root causes. Though compound failures can and do happen, single failures are far more common. Rule things out systemati- cally and logically, and you should eventually discover the root cause. Don't Look for Zebras once had a doctor who told me, "If you hear thundering hooves, don't assume they're zebras." This statement is similar to Occam's Razor, which is usually para- phrased as, "With all things being equal, the simplest answer is usually the correct answer." Just because I was getting a lot of headaches didn't mean I had a brain tumor. The same principle can be applied to any problem you're trying t