ocess of designing a network, including example spreadsheets, and formulas to help you get it right. The next chapters cover IP address allocation, IP subnetting, Network Time Protocol (NTP), and device failures. Finally, I'll cover some topics you won't find in other technical books, including how to sell your ideas to management, and when to upgrade. This section is composed of the following chapters: Chapter 33, Designing Networks Chapter 34, IP Design Chapter 35, Network Time Protocol Chapter 36, Failures Chapter 37, GAD's Maxims Chapter 38, Avoiding Frustration CHAPTER 33 Designing Networks There are hundreds of books out there that will tell you how to build a three-tier cor- porate network. This is not one of them. Instead, I'm going to show you what you need to do before you build your network. Then I'll show you some real-world examples of network designs. This is not the sort of technical information you get from getting certified. This is information that will help you do your job better. For the most part, this chapter is written with the assumption in mind that you'll be designing a network from scratch. While that's not often the case, the information contained herein is applicable to any network project. Documentation Documentation is the bane of many an engineer's existence. I'm not entirely sure why this is the case, but an engineer who likes to write documentation seems to be a rarity. Writing is hard work (try writing a book!), but the payoffs are enormous. Some engineers seem to believe that if they hoard information, they become irre- placeable. Trust me on this one-you and I are replaceable. In fact, I've made a living by coming in to document networks when "irreplaceable" engineers were fired. Well-written documentation saves time and money. If someone can fix your net- work by reading your documentation, you've done a good job. If no one but you can fix your network, you're not doing a good job. Whenever possible, even on small networks, you should document every detail of your network. Ju