Previous Table of Contents Next


Security

Security is one of the overlooked components of network design. Typically, the security procedures and equipment are added to the network well into the implementation phase. This usually results in a less-secure configuration that demands compromises. For example, access lists are one component of network security. Assuming a hierarchical design, if the network designers were to use bit boundaries to define security domains, a single access-list wildcard mask could be used in different areas of the network. In addition, extranet (non-internal) connections could be placed in a secure, centralized location, freeing greater bandwidth for the rest of the enterprise. This design contrasts with installations where these connections are distributed throughout the network. While centralization may lead to more significant outages, it is often easier to administer resources in a protected, central location close to the support organization.

Consider for a moment a fairly benign network design decision. A company elects to deploy an ATM WAN for a new network upgrade. The network requires some security, because the data is privileged and involves financial information. Rather than isolating extranet connections, the company decides to place these less-secure links on the same physical interface as their internal connections. While this setup can work, think about the limitations that such a design would impose on security. The designer would be unable to restrict the PVC before the circuit entered the core router, thus making the only line of defense a subinterface access list. Denial-of-service attacks and other intrusion techniques would be much more likely than if the extranet PVC were isolated from the enterprise network by a separate router and a firewall.

Having identified security as a design consideration, the designer must evaluate the role of the network in the security model. There is little question that firewalls and bastion hosts (a bastion host is a secure public presence— it may be the firewall itself or a server in the transition area between the public and private networks, also called a DMZ) are part of the network, but some schools of thought argue that the network, in and of itself, is not a security device. While there are compelling arguments to support the stance that the network is not a security solution, most designers take a simpler view of security. In practical terms, anything that can protect the data in the network—be it a lock on a door, an access list, or the use of fiber instead of copper—is part of an overall solution and should be considered in the design of the network.

Some of the tools available to the network architect are:

  Fiber links
  Firewalls
  Access lists
  Bastion hosts
  Encryption
  Authentication, including CHAP (Challenge Handshake Authentication Protocol)
  Accounting
  Secure physical media, including data rooms and cables
  Auditing tools

All available tools should be considered when formulating a design. By including them in the initial phases, appropriate budgetary and technology allocations may be made.

A complete presentation of network security and design considerations for architects is presented in Chapter 11.

Addressing

Addressing issues frequently involve the IP protocol, which uses user-defined addresses. Many networks evolved without regard to the strategic importance of the infrastructure. In addition, corporations occasionally acquire another organization, resulting in the duplication of network addresses even with careful planning. Whatever the cause, readdressing IP addresses is a significant process in the life of the network. And while DHCP, NAT, and dynamic DNS can reduce the impact, there will likely be a point where some determined effort is necessary.

Subsequent chapters will discuss the art of network readdressing; however, there are a few points that should be presented here. First, plan for connectivity to other companies and the Internet. Second, consider the impact of readdressing on the corporation’s servers and workstations and have a plan in mind on how to deploy any remedial effort. Third, know the limitations of the various tools that would be used in readdressing, including the fact that NAT cannot cope with NetBIOS traffic—an important function of the Windows and OS/2 operating systems. Chapter 7 presents the NetBIOS protocol in detail. In addition, designers will need to consider the use of RFC 1918 addresses—a collection of addresses specifically reserved from appearing on the Internet. Finally, consider the impact of the classful network address and the routing protocols that you might need.


Don’t be concerned if some of the issues presented here are new. In later chapters they will be presented in greater detail.

Bandwidth

There are two schools of thought regarding bandwidth in network design. The first believes that the network is built to withstand peaks and then some. Historically, this has resulted in throwing bandwidth at poor application behavior and, ultimately, poor network performance. The second school believes in building for the average usage and allows a certain amount of degradation during peak times—the morning login, for example. As shown in Figure 1.12, the typical network experiences peaks between 8:00 and 9:00 A.M. and 1:00 and 2:00 P.M. Another peak may occur in the evening as backups and other automated processes start.


FIGURE 1.12  A typical network load curve

Fortunately, the two schools of thought on this subject are coming together. Designers should avoid the temptation to add bandwidth for no reason and not keep a network so close to the edge of the performance curve that it cannot handle any changes. This balance will compel programmers and server administrators to consider the far-reaching impact of poor application programming and will preserve the network budget for new services and value-added initiatives.

As a final point, careful consideration of the network backbone is critical to the health of the network. This is one area where excess bandwidth may be the perfect solution, but only if consideration is given to cost and over-head. For example, many companies jumped on the ATM LANE (LAN Emulation) platform for backbone technology in the late 1990s. While a good solution, LANE greatly adds to the cost of the network and the over-head associated with it. Gigabit Ethernet and other technologies may provide better solutions, equal or greater bandwidth, and lower cost. Of course, if voice and other services geared toward ATM are needed, the effort may be warranted.


Previous Table of Contents Next