Category list

Design Principles

Translating high-level goals into a specific design can be a daunting task. Even if design services are outsourced to a consultant, the network administrator must have a clear understanding of the process to ensure any proposed design will meet requirements. The design process must meet goals in four major areas:

Infrastructure The LAN/WAN connectivity.
Services Both network services (directory services, DNS, and so on) and applications services provided by the server-based computing paradigm.
Access The ways and means employed to actually connect users to applications consistently, reliably, and securely.
Security Designs must protect servers and resources from attack and exploitation, enforce methods to positively identify authorized users and restrict access to only appropriate services and applications, and protect data from disclosure or tampering during transport.

Infrastructure Design

Numerous models exist to aide in planning a network infrastructure, but Cisco Systems' hierarchical enterprise design methodology is the most logical and produces the most consistent results. This approach breaks the design process into manageable blocks so that networks are designed to function within the performance and scale limits of applications, protocols, and network services. The three key elements are Structure (designing to control failure domains); Hierarchy (designing based on a functional approach); and Modularity (designing for incremental expansion and growth).

Hierarchy

Designing around Cisco's three- tier hierarchical structure defines three "layers" of the hierarchy: the core layer, the distribution layer, and the access layer. Access layers typically provide the OSI Layer 2 and Layer 3 connectivity for local LAN segment ( clients ), remote LAN/WAN segments, and the data center server farm. The access layer enforces locally significant policies such as security, Quality of Service (QoS), and addressing. Access layer "modules" usually share common addressing (subnets and gateways) and local LAN segments, common local architectures (all Ethernet or all Token Ring), and common communities of interest (site based or business-unit based). The distribution layer provides concentration points for multiple access layer connections either as routed connections or Layer 3 switched connections. The distribution layer enforces security boundaries (firewalls, access lists) and network policies (rate control, QoS, and so on). In a typical enterprise network, the distribution layer insulates access layer blocks and the core from the overall complexity of the network. In the server-based computing world, the distribution layer aggregates multiple access modes and methods and delivers connections to the network core for consistent performance. For WAN connectivity, the distribution layer is the key to resiliency. Although the core layer can be a WAN or MAN (metropolitan area network) core , this text is primarily concerned with the campus or corporate core that provides connectivity to the server farm. In theory, the server farm would connect to the core via its own access layer and the common distribution layer. In practice for a data center-centric approach, the access and distribution layers are often collapsed directly onto an OSI Layer 3 core switch. The sample network design topologies later in this chapter assign network components to one of these three layers.

Modularity

Modularity in design depends on a functional building block approach. Modular network designs provide several key benefits throughout their life cycle: scalability to ease growth, cost effectiveness by buying blocks of capability as demand grows, streamlined training, simplified troubleshooting, and the capability to distribute network management if required. Treating components as functional building blocks helps define interconnection and interoperability standards. For example, at the top level, a modular design defines a "standard" medium- sized remote office as an access router running OSPF and a 10/100/1000 Ethernet switch. Additional requirements may be specified, but avoid defining end equipment or specific vendors .

Structure

Factoring structure into your network design involves logically dividing the network to control failure domains and both Layer 2 and Layer 3. The term failure domain means engineering the network design such that failures or adverse conditions in a network segment are not propagated to other segments. For example, uncontrolled broadcast storms from a single node in a Layer 2 Ethernet LAN can bring the entire LAN to its knees. Structurally, Virtual LANs bounded by Layer 3 switches or routers can be employed to control the size of the broadcast domain. Similarly, Spanning Tree Protocol (STP) convergence in a large Layer 2 segment can disrupt traffic flow for an unacceptable duration. Since STP is essential in a loop-free redundant Layer 2 design, the size (and hence convergence time) of the STP domain needs to be controlled, and Virtual LANs (VLANs) control this behavior. Other structural elements include multicast domains, the distribution of redundant connections among separate platforms, and IP subnet size. IP subnetting can be critical when trying to control Layer 3 convergence: efficient designs use a hierarchical IP addressing scheme that supports route summarization, reducing individual routing updates and even eliminating the need to update some routes when a failure occurs.

Services Design

From the perspective of an application server in a server farm, critical services provided by the network must be available to "serve" applications to users. These include Directory Services (in a directory-service-enabled environment), name resolution to include Domain Name System (DNS) and Windows Internet Name Service (WINS), and authentication services (logon services, certificate validation, RADIUS, and token or smart cards).

Directory Services

Directory Services are integrated into most modern network operating systems. The two major offerings relevant to server-based computing are Novell's eDirectory (an updated, portable version of Novell Directory Services (NDS)) and Microsoft's Active Directory (also updated in Windows Server 2003). Both offerings are loosely based on the original x.500 directory services standard, both offer Lightweight Directory Access Protocol (LDAP) support at varying levels, and both are capable of some "directory integrated application" support. All directory services implementations organize data based on a hierarchical data structure to define types of network resources (users, services, applications, and computers) and their respective properties or attributes. The directory contains both the structure and the unique values assigned to each entity. From a management stand-point, directory services allow data about network entities to be stored as a single instance that is globally accessible. In a directory-enabled network, the directory services must be constantly available to allow normal network activities (file access, logon, application use, and so forth). They must also be extensible, robust, and redundant.

Active Directory is Microsoft's directory services component rolled out in conjunction with Windows 2000. The original implementation was traceable to the directory services functions in Microsoft Exchange. The Windows Server 2003 iteration includes improved LDAP compliance, additional security functionality (cross-Forest authentication and authorization through Forest-level trust relationships), administrative capabilities (most notably, new Group Policy management specific to Terminal Servers and Group Policy modeling), as well as the ability to edit multiple directory objects at once. Active Directory provides very limited integration with other directory services and can only manage Windows 2000 and later platforms.

eDirectory is Novell's directory services module. Built on the basic functions of NDS, eDirectory is more standards compliant than Active Directory, is ported to other operating systems, and allows management of data in other directories from a common interface. eDirectory authentication uses Public Key Infrastructure (PKI) standards while Microsoft employs a modified version of Kerberos.

Metadirectory Services, a "directory of directories," are partially built into eDirectory. Active Directory has no built-in equivalent, so Microsoft offers Microsoft Metadirectory Services (MMS) as an add-on. MMS provides multidirectory integration via " agents " that provide connectivity to network operating systems and directory systems (Microsoft Windows NT, Active Directory, Novell NDS and Bindery, iPlanet Directory, X.500 systems, and Banyan VINES), e-mail systems (Novell GroupWise, Lotus Notes, Domino, cc:Mail, and Microsoft Exchange), applications (PeopleSoft, SAP, ERP, and XML/DSML-based systems), and common database and file-based systems (Microsoft SQL Server, Oracle, LDIF, and so forth).

In a pure Windows environment (Windows 2000/XP/2003), Active Directory meets the needs of server-based computing, and at no additional cost. If a true "enterprise" directory service is required, consider eDirectory or Microsoft's add-on products.

Name Resolution

Both Domain DNS and WINS are essential in most SBC networks. Microsoft's Active Directory relies on viable DNS to locate directory servers and other network service providers (Domain Controllers, LDAP servers, and Global Catalog servers). In a Terminal Services server farm, inability to locate and access DNS results in logon failures and inability to access resources (such as resolving ODBC connections by Fully Qualified Domain Name (FQDN)), and forces administrators to manipulate IP address registrations on multiple machines rather than changing DNS pointers. WINS also remains critical. Even in a "native mode," a Windows network as NetBIOS is still used for down-level clients, and many legacy applications require NT-type NetBIOS-based syntax (\\SERVERNAME\SHARENAME) to locate and connect to resources. Improperly configured or unavailable WINS can lead to inaccessible resources and excessive broadcast traffic from broadcast name resolution.

Authentication Services

Secondary or even tertiary authentication (above and beyond basic Windows authentication) has become commonplace, but designers still tend to overlook the need for redundancy in authentication services. Many network environments (the Department of Defense, health care providers, and R&D activities) require multilevel authentication (two- or three-factor authentication). This may involve SSL certificates, biometrics, smart cards, retina scanners , and RADIUS or other extensible authentication methods. In these cases, the Terminal Server often provides the supplicant, but a valid authentication server must be available to authorize access to the network or application. For example, failure of a single RADIUS server should not deny all users access to production services.

Access Design

The need for users to access the SBC resources from a variety of locations using different access methods, media, and possibly protocols, must be factored in to any design. Logically, designing to meet access requirements consists of two processes: Protocol Selection and Access Method definition. Subsequent sections of this chapter map specific Access Methods to modular, hierarchical Access Layer building blocks.

Protocol Selection

Aside from a multitude of other technical advantages discussed in Chapter 2, the ICA client supports NetBEUI, IPX/SPX, and TCP/IP for MetaFrame, while the RDP client still only supports TCP/IP for Terminal Services. Appendix A contains a more detailed discussion of each protocol, along with advantages and limitations.

From an architectural standpoint, TCP/IP is the preferred protocol. Aside from its technical advantage (the entire Internet is based on TCP/IP), IPX/SPX and NetBEUI should only be considered as integrating technologies to bring legacy systems into your new network, and then only until they can be migrated to TCP/IP. As a general rule, multiprotocol bindings to support a legacy LAN (IPX/SP and NetBEUI) should be eliminated as rapidly as possible.

Access Method

Defining required access methods is really an exercise in identifying the user community and the locations or environments from which they need to connect. In all cases, bandwidth requirements per method must be evaluated to "close the loop" and ensure that every required means of access (local, remote, dedicated media, dial-up, virtual private network (VPN), and so on) is afforded adequate bandwidth to support the number of concurrent connections expected. In most cases, enumerating the applications available to a user may be via direct client connection (Program Neighborhood) or Web-based front end (Citrix NFuse Classic). The following are common access methods based on user environments and locations:

Traditional LAN access Local user community with direct high-speed deterministic bandwidth and little need for encryption.
Wireless LAN (WLAN) access Similar to a traditional LAN, but with a greater need for security due to the lack of defined physical boundaries. Usually requires secondary authentication (like a dial-up user) as well as some level of encryption.
Branch office, dedicated media The classic distributed branch office environment. Connection to the SBC core is via dedicated, deterministic WAN media (T1, Frame Relay, ATM, and so on) and supports both SBC connectivity and other network services. Dedicated access for remote branch offices is essential when Quality of Service (QoS) for packetized voice or video is required.
Branch office, VPN access Similar to the dedicated media paradigm, but site-to-site bandwidth is non-deterministic . The branch office is connected to the SBC core network via a branch-to-branch VPN and all site-to-site traffic traverses the VPN. Typically used for smaller branch offices or to international sites or offices where dedicated access is cost prohibitive. Traffic inside the VPN tunnel can be controlled and managed, but the tunnel itself traverses the Internet and no QoS guarantees are possible.
Remote user Internet access (applications only) Connection is via non-deterministic bandwidth over the public Internet. Usually requires some level of encryption and may require multifactor authentication. Users access only SBC resources, no direct LAN access. This method may include wireless data over mobile phones (second (2G) or third (3G)) technologies.
Remote user Internet access (applications and LAN) Connection uses a VPN over non-deterministic bandwidth via the public Internet. Usually requires increased levels of encryption and multifactor authentication to protect the LAN environment. Users access SBC resources and directly access the local LAN for drive mapping, printing, or "fat client" applications. The most common example is roaming executives or sales staff that need SBC applications and the ability to synchronize handheld devices with corporate mail servers (for example, Palm Pilot users). This may also include IT Staff that need to access and manage LAN resources and servers.
Direct dial access Used for direct connection to the SBC core via any of several remote access methods. May be either via direct dial to an SBC member server as an asynchronous serial connection or through a remote access concentrator (RAS services on a server or hardware concentrator). Dial-up media may be either analog (typical modem) or digital (ISDN, BRI, or PRI). Analog access is limited to 33.6 Kbps while digital access can provide up to 56 Kbps for analog modem users and multiples of 64 Kbps (64, 128, 192, 256, and so on) for ISDN users. Direct dial access usually does not require strong encryption but does require multilevel or multifactor authentication.

Security Design

An SBC network differs little from a traditional network when it comes to security considerations; basic network security mechanisms must be in place.

Network security Designs should include firewalls, access lists on routers and Layer 3 switches, and intrusion detection systems (IDSs).
User security Authentication, authorization, and access (AAA) mechanisms must be tailored to the environment and access method. Internal "wired" users are generally considered trusted and are subject to normal security policies and principles. Remote or non-wired users must be positively identified before being granted access to SBC or other network resources. Beyond normal logon (username and password) authentication, common methods include Remote Access Dial-in User Service (RADIUS), tokens or smart cards (RSA's SecurID, Secure Computing's Safeword), and biometric authenticators ( fingerprint or retina scanners).
Data security Although the actual data for a thin-client connection is a stream of video data and input device data (pointing device and keyboard), the data must still be protected from intercept and exploitation. This is particularly true of credentials used to access the session. There are two common methods of protecting this data. The first method is Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption based on certificates and Public Key Infrastructure (PKI). The second method is IP Security (IPSec) using the Digital Encryption Standard (DES) or Advanced Encryption Standard (AES). Other mechanisms may be used in specialized cases, for example, NSA's FORTEZZA (SKIPJACK) encryption cards or Wireless Equivalent Privacy (WEP) for WLANs.