This chapter describes how to plan the installation of your TCP/IP network. It includes information about planning for:

• A Network Interface ( Section 5.1)
• Routing ( Section 5.2)
• BIND ( Section 5.3)
• DHCP or BOOTP ( Section 5.4)
• Serial Lines ( Section 5.5)
• NTP ( Section 5.6)
• SNMP ( Section 5.7)
• User Accounts and Proxy Identities ( Section 5.8)

Refer to the DIGITAL TCP/IP Services for OpenVMS Management guide for details on managing other services.

5.1 Network Interface

The SYS$MANAGER:TCPIP$CONFIG procedure automatically detects the installed network interfaces on the installation system. After displaying a list of the installed network interfaces, TCPIP$CONFIG queries for more information on each interface.

Use the worksheet in Figure 5-1 to record network interface parameter information for your system.

Figure 5-1 Network Interface Configuration Worksheet

Table 5-1 describes the information necessary for configuring a network interface.

Table 5-1 Network Interface Parameters

Parameter	Enter on Worksheet...
Host name	Enter the fully qualified host name assigned to your system. You may have to ask your network manager for a unique host name.
IP address	Enter the Internet Protocol (IP) address. You may have to ask your network manager for an IP address.
Network mask	If your network uses supernet or subnet addressing, enter the network mask for the local subnet. The network mask is the same for all systems on the local subnet.
Broadcast mask	Enter the broadcast address for your local subnet.
Adapter name	Enter the interface name for the communication controller. For example, DE0, EZ0, SL0, or PP0.
Cluster name	Enter the host name to associate with each interface in the cluster.
IP address	Enter the IP address for the cluster.
Network mask	Enter the network mask for the cluster.
Broadcast address	Enter the broadcast address for the cluster.

5.2 Routing

If the hosts on your network need to communicate with computers on other networks, a route through a gateway must be defined. All hosts and gateways on a network store information about routes in routing tables. Routing tables are maintained in both dynamic and permanent memory.

You can define routes manually (static routing), or you can enable routing protocols that exchange information and build routing tables based on the information exchanged (dynamic routing).

5.2.1 Static Routing

Because static routing requires manual configuration, it is most useful when the number of gateways is limited and where routes do not change frequently. For information on manually configuring routing, see the DIGITAL TCP/IP Services for OpenVMS Management manual.

5.2.2 Dynamic Routing

Complex environments require a more flexible approach to routing than a static routing table provides. Routing protocols distribute information that reflects changing network conditions and update the routing table accordingly. Routing protocols can switch to a backup route when a primary route becomes unavailable and can determine the best route to a given destination.

Dynamic routing tables use information received by means of routing protocol updates; when routes change, the routing protocol provides information on the changes.

Routing daemons implement a routing policy, that is, the set of rules that decide which routes go into the routing table. A routing daemon writes routing messages to a routing socket causing the kernel to add a new route, delete an existing route, or modify an existing route.

The TCP/IP Services for OpenVMS product implements two routing daemons: the Routing Daemon (ROUTED) and the Gateway Routing Daemon (GATED). The following sections provide more information.

5.2.2.1 Routing Daemon (ROUTED)

This daemon (pronounced route-dee) supports only the Routing Information Protocol (RIP Version 1). When ROUTED starts, it issues routing update requests then listens for responses. A system configured to supply RIP information responds to the request with an update packet. The update packet contains destination addresses and routing metrics associated with each destination. After receiving a RIP update, ROUTED uses the information to update its routing table.

To configure dynamic routing with ROUTED, see Section 5.2.2.2.

5.2.2.2 Gateway Routing Daemon (GATED)

This daemon (pronounced gate-dee) supports interior and exterior gateway protocols. It obtains information from several routing protocols and selects the best routes based on that information. You can configure GATED to use one or more of the following protocols:

• Routing Information Protocol (RIP) Versions 1 and 2
  RIP is a commonly used interior protocol that selects the route with the lowest metric (hop count) as the best route.
• Open Shortest Path First (OSPF)
  Another interior routing protocol, OSPF is a link-state protocol (shortest path first). Use OSPF in complex networks with many routers.
• Exterior Gateway Protocol (EGP)
  EGP exchanges reachability information between autonomous systems. An autonomous system is usually defined as a set of routers under a single administration, using an interior gateway protocol and common metric to route packets. Autonomous systems use exterior routing protocols to route packets to other autonomous systems.
• Border Gateway Protocol (BGP)
  Like EGP, BGP exchanges reachability information between autonomous systems but supports nonhierarchical topologies. Use BGP to specify path attributes that provide more information about each route. Path attributes can include, for example, administrative preferences based on political, organizational, or security considerations.
• Router Discovery
  Use this protocol to supplement a statically configured default router. Router discovery informs hosts of the availability of local routers.

Use the worksheet in Figure 5-2 to record routing parameter information for your system.

Figure 5-2 Routing Configuration Worksheet

Table 5-2 describes the routing parameters.

Table 5-2 Routing Parameters

Parameter	Enter on Worksheet...
Routing type	Check the type of routing: STATIC or DYNAMIC.
Default route	If using STATIC routing, enter a default route (mandatory). You will need to add this by using the TCPIP SET ROUTE command.
Router	If using dynamic routing, check either ROUTED or GATED.
ROUTED:
Supply dynamic routing	If using ROUTED, check YES if you want the installation system to send dynamic routing information to peers.
GATED:
Configuration file name	If using GATED, enter the name, location, and date of the current GATED configuration file.
Interior/Exterior Protocol	Check one or more routing protocols to be configured on the installation system.

5.3 BIND

This section describes planning steps for implementing a BIND server on a DIGITAL TCP/IP Services for OpenVMS host:

Consider configuring your network to use the BIND service if you have:

• A small configuration with incoming connections from the Internet.
• A large configuration connected to the Internet.
• Any configuration that requires frequent and highly reliable access to remote hosts.

If you have a small local network that requires infrequent access to remote hosts or is not connected to the Internet, consider using a local host database instead of a BIND server.

5.3.1 Planning a Domain Hierarchy Strategy

The effectiveness of your BIND service depends on careful planning of your domain hierarchy. As you plan the domain hierarchy, you need to do the following:

1. Understand the existing domain hierarchy in your organization or company. Contact your system administrator to find the person responsible for the existing domains. If you want your domain on the public network, you need to get the correct domain registration from the InterNIC Registration Services (see the InterNIC web site. http://internic.net/ ).
2. If you plan to join an existing domain, negotiate with the administrator of the upper-level domain to ensure that you create an acceptable hierarchy.
3. If you plan to administer zones for your hosts and servers, identify the owners of the parent zone to which you will be a subzone.

When designing your domain hierarchy, select the scheme that suits the needs and preferences of your organization. A common design strategy is to base the domain hierarchy on functional areas of an organization or on geographic areas of a network. For example, you could divide your domain hierarchy into geographic zones used mainly by a group of users concentrated in geographic areas. Similarly, you could create a functional zone with names used mainly by users in a particular branch of an organization.

Table 5-3 describes some of the benefits of using each hierarchy scheme.

Table 5-3 Functional and Geographic Hierarchies

Consider This Hierarchy:	If You Have:	To Implement:
Functional	An organization consisting of: A well-established and stable functional structure. Several independently functioning units with their own resources.	Use your company's organizational chart as a template for designing this hierarchy.
Geographic	Hosts that are: Organized and managed by site or geographic area. Grouped in a specific geographic area together with other hosts that usually communicate with each other.	Use a map as an aid in naming servers. Place slave servers in the same geographic area. Off-site slave servers have availability benefits.

5.3.1.1 Finding Existing BIND Service Information

When planning your domain hierarchy, it may be useful to look at information for existing domains and name servers. The TCP/IP Services for OpenVMS product supports the TCPIP$NSLOOKUP utility, which allows you to retrieve the following information:

• Host names and addresses on the local domain
• Host names and addresses on remote domains
• Host names that have mail exchanger (MX) records
• Name servers for a specific zone

Consider the following domain hierarchy guidelines:

• Limit creation of domains to three or four levels.
  In very large networks, users at individual sites create and own lower-level domains used mainly by a specific group of local users. In such cases, users create as many levels of domains as they deem necessary and convenient to manage.
• You can divide your domain hierarchy into several zones. Compaq recommends that you divide your domain hierarchy into multiple zones if your network is large and growing. Multiple zones offer the following management advantages over a single zone structure:
  • Creates a greater opportunity to distribute information in the network, decreasing the processing load on any one system.
  • Decreases the probability of duplicate names (for example,
    aero.sales.compaq.com and aero.dev.compaq.com are unique).
  • Eases the delegation of administrative responsibility for domains, subdomains, and zones.
• Limit domains and zones to a manageable size.
  Zones require additional network resources to administer. Also, long domain names are difficult to remember.
  Domains and zones have a practical size limit based on manageability. Factors to consider include the following:
  • Identify how widely zone information must be copied.
    A zone containing many domain names may need several slave servers in different places to locate the names close to users. Propagating updates to slave servers adds overhead, especially across WAN links. For example, if you have three sites and 100,000 domain names and all of the sites need those domain names, keep them in one zone. Conversely, if specific domain names are mostly used at one site, save overhead by locating those domain names in a zone for that site.
  • Anticipate growth.
    Design a domain that allows horizontal expansion (more subdomains directly under the upper-level domain) and avoids vertical expansion (more levels of subdomains). This design helps limit the number of subdomain levels and makes the domain easier to manage, even as it grows.

Table 5-4 lists some criteria to use when deciding if you want to create new zones.

Table 5-4 Joining or Creating a Zone

Consider:	If:
Joining an existing zone	A suitable zone already exists in the domain space.
	You plan to manage a small number of hosts.
	You expect little change or growth in your domain space.
	You expect a low demand for host and address lookups.
	The current domain administrator is willing to accept the extra work.
Creating new zones	You are creating the initial domain hierarchy in your organization.
	You want control over your domain space.
	You plan to manage a large number of hosts.
	You expect a lot of change or growth in your domain space.
	You expect a high demand for host and address lookups.

Whether you decide to join an existing zone or create a new one, identify the proper parent zone and get the owner's agreement to your approach.

If you decide to create zones, you need to:

• Decide which hosts you want in a particular zone.
• Select the servers for the zone.

After you decide how to structure your domain hierarchy, establish domain naming conventions. Table 5-5 lists domain naming conventions and their supporting reasons.

Table 5-5 Domain Naming Conventions

Convention:	Supporting Reasons:	Example:
Use domain names that match the BIND hierarchy.	Your naming policy and the BIND hierarchy are likely to evolve at the same time.	If you have existing host names (such as: host1, warrick, and marcom), you may want to give them geographic domain names (such as: albany, warrick, hartford) or functional department names (such as: eng, prodmgt, marcom).
Choose domain names that are not likely to change.	Creates a more stable naming hierarchy because it is difficult to change existing labels, especially at higher domain levels. Also, a change in a domain name affects all applications that use the name as well as users who memorized the name of a resource or created an abbreviation.	If you use a functional model, derive domain names from business functions, not current titles. For example, consider using sales.compaq.com, admin.compaq.com , and eng.compaq.com to store names used by Compaq's sales, administrative, and engineering groups.
Use a multilevel domain naming strategy to manage large domains.	Creates a complex, but more manageable domain than a large, single-level domain.	If you have a large domain, you could name upper-level domains after cities such as, nyc.compaq.com, paris.compaq.com , and geneva.compaq.com , and lower-level domains based on site codes or some other more specific geographic name.
Select domain names that are short and describe the resource represented.	These names are easier to remember.	For example, you could use ftp.aero.dev.abc.com as the domain name of the FTP access point used by the ABC's aerospace development division.

5.3.2.1 Case Sensitivity

The BIND service preserves the case of names as they are entered. Lookups, however, are case insensitive, so it is not possible to create two names that differ only in their case. For example, requests to look up mynode.lkg.compaq.com, MYNODE.lkg.compaq.com, and MyNode.lkg.compaq.com would all produce the same result. If someone attempted to create entries in the zone database files for all three domain names, you would have multiple records for the same name.

5.3.2.2 Planning Domain Names for Reverse Lookups

The IN-ADDR.ARPA domain names include up to four domain labels in addition to the IN-ADDR.ARPA suffix. Each label represents one octet of an Internet address, in reverse order. For example, if your host has Internet address 37.20.16.08, its domain name for reverse translation would be: 08.16.20.37.IN-ADDR.ARPA.

Use the following guidelines:

• Make sure that each address has a record in the zone file that provides the canonical name of the host (this is the PTR record). Some applications do not function properly unless they can find a host name.
• When you receive a block of addresses to use, ask the organization that supplied them to you about any required actions you need to take regarding reverse translation domain servers.
• If you use a small number of addresses and part of a set of addresses that are owned by a service provider, the service provider typically ensures that reverse translations will be handled properly.
• If you receive a block of addresses from the InterNIC, you are responsible for ensuring reverse translation servers exist.

Deciding which domain names and hosts belong in a zone is a simple task if you planned your domain hierarchy carefully. Your zone will contain domain names, hosts, and servers. The master zone file, maintained on master servers, contains all the information for the zone.

If you decide to create zones, consider an overall administration scheme. Your plan for who will use and manage names can have a strong influence on zone structure. For example, the upper-level domains should be stable, widely known, and limited in content. Only a few trusted users should be able to create or modify their contents.

Typically, someone acts as the technical/zone contact for zones. This contact is concerned with the technical aspects of maintaining the BIND server and resolver software and the data files. The technical/zone contact keeps the BIND server running and interacts with technical users in other domains and zones to solve problems affecting the local domain.

5.3.4 Selecting Servers

Your main goals in choosing hosts for servers should be to achieve availability of data, reliability, and optimum performance. If you create your own zones, you must configure at least one master and one slave server for each zone.

Consider configuring servers even if you are not creating your own zones. If you configure a slave server for the zones (forward and reverse) where your hosts are members and point your hosts to that slave server, the BIND service will continue to work for local names even if you lose your link to the outside world.