# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

A default route is a route used to direct data that is addressed to an unidentifiable network address. To define a default route, use the /DEFAULT qualifier.

Example 5:
The following command sets a default route. NIGHTINGALE is the default gateway.

    UCX> SET ROUTE /DEFAULT /GATEWAY=NIGHTINGALE

To check that your routes are set up correctly, use either the LOOP or PING command.

### 4.2.3.2 Displaying Manually Defined Routes

To display static routes, use the SHOW ROUTE command. To see the permanent database, specify the /PERMANENT qualifier.

The display shows the following types of routes:

- N --- Network route
- H --- Host route
- A --- Active
- P --- Permanent

To display a route that was defined by address, specify either its address or a wildcard.

Example 1:
The following example displays information about all the manually defined routes.

    UCX> SHOW ROUTE /FULL
                                 DYNAMIC database
    Type           Destination               Gateway

    AN   11.111.0.0   destin_host1   11.110.5.118   gate_host
    AH   22.111.4.10  destin_host2   22.110.5.120   gate_host_2

Example 2:
This example displays the permanent static routes that were defined with SET ROUTE /PERMANENT.

    UCX> SHOW ROUTE /PERMANENT
                                 PERMANENT database

    Type           Destination               Gateway

    PN    0.0.0.0                     11.20.208.100   pterodactyl.extinct.com
    PN    1.1.1.1                     22.2.2.2

### 4.2.3.3 Starting and Stopping Routing

To start and stop the routing server, use the following commands:

- To start routing interactively, issue:

      UCX> START ROUTING

- To stop routing interactively, issue:

      UCX> STOP ROUTING

- To start routing upon the next UCX startup, issue:

      UCX> SET CONFIGURATION START ROUTING

# 4.3 Configuring the Gateway Function (IP Forwarding)

By default, the UCX startup procedure automatically sets IP forwarding.

To manually configure your system as an internet gateway, issue the following commands:

- For the current session only:

      UCX> SET PROTOCOL IP /FORWARD

- For every time UCX starts:

      UCX> SET CONFIGURATION PROTOCOL IP /FORWARD

Identify the gateway for each client. For instructions, see the client's product documentation.

To disable the gateway function interactively, issue:

    UCX> SET PROTOCOL IP /NOFORWARD

To disable the gateway upon UCX startup, type:

    UCX> SET CONFIGURATION PROTOCOL IP /NOFORWARD

## 4.3.1 Datagram Reassembly Time

Reassembly is the process of reconstructing a complete data message from received fragments. The reassembly timer determines the length of time allowed for the reassembly process. You can modify the reassembly timer to ensure that IP datagram fragments are optimally reassembled at the destination host.

Consider the following when setting the reassembly timer:

- If the retime expires before the host receives all the fragments, they are discarded.
- An inappropriately small interval might result in too many datagrams being discarded.
- An excessive interval might degrade internet performance.

Use the following commands to reset the reassembly timer:

- For the current session:

      UCX> SET PROTOCOL IP /REASSEMBLY_TIMER=n

- To reset upon the next UCX startup:

      UCX> SET CONFIGURATION PROTOCOL IP /REASSEMBLY_TIMER=n

In the following example, the first command changes the IP reassembly time to 20 seconds on the running system. This new setting remains in effect until the next UCX startup.

The second command makes the change permanent by modifying the configuration database, UCX$CONFIGURATION.DAT.

    UCX> SET PROTOCOL IP /REASSEMBLY_TIMER=20

    UCX> SET CONFIGURATION PROTOCOL IP /REASSEMBLY_TIMER=20

# 4.4 Subnetwork Routing

Subnetwork routing, also called subnetworking, allows you to organize hosts within a network into logical groups. A network can be made up of several subnetworks.

If a gateway connects these networks, a host on another network can access a host on a subnetwork. Data from the host on the other network is routed as follows:

1. Through the gateway to the network
2. Onto the appropriate subnetwork
3. To the destination host

Subnetwork routing lets one network address span multiple physical networks. You can use local gateways and subnetwork addresses to each local physical network to make your network appear to other systems as one network.

For example, a company has one assigned IP address, even though it has several physical networks. Using local gateways, the network manager assigns a subnetwork address to each local physical network. This makes the company appear to have only one network to outside systems.

Subnetwork routing also works in the reverse case. You can create multiple subnetworks (logical groups) on the same physical network. Use a network interface as a gateway between the multiple subnetworks. Setting up multiple subnets on one physical network has one disadvantage. Because the subnetworks are on the same broadcast medium, they receive broadcasts destined for other subnetworks and these broadcasts must be discarded, except on the gateway.

## 4.4.1 Extending Subnetwork Routing

To use extended subnetwork routing, define pseudo-interfaces. A pseudo-interface is a data structure that extends subnetwork routing. The name of an internet pseudo-interface has the following characteristics:

- It is three characters, followed by from one to five digits for the pseudo-interface unit number.
- The first two characters are the same as the two characters in the internet interface name.
- The third character identifies the controller number that corresponds to the pseudo-interface, following this pattern:

  A | Controller 0
  B | Controller 1
  C | Controller 2

- You can duplicate the character-string part.
- The unit number differentiates interfaces with the same name.
- The maximum unit number is 65535 (because the maximum number of subnetworks allowed by an internet pseudo-interface is 65535).

For example, for an OpenVMS Alpha system with two Ethernet controllers --- EZA0 and EZB0 --- you can define the following internet interfaces and pseudo-interfaces:

- Internet interfaces
  - ZE0
  - ZE1
- Internet pseudo-interfaces (Each has its own IP address, network mask, and broadcast mask.)
  - ZEA0
  - ZEA1
    .
    .
    .
  - ZEA9
  - ZEB1
  - ZEB3
    .
    .
    .

To extend subnetwork routing, follow these steps:

1. Increase the limit of pseudo-interfaces on your host (default=20). Use the SET COMMUNICATION command.
   For example, to set the number of allowed interfaces to 30, issue:

       UCX> SET COMMUNICATION /INTERFACE=30

       UCX> SET CONFIGURATION COMMUNICATION /INTERFACE=30

2. Define the pseudo-interfaces. Use the SET INTERFACE and SET CONFIGURATION INTERFACE commands. Issue:

       UCX> SET NOINTERFACE interface

       UCX> SET INTERFACE interface /HOST=host -
       _UCX> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask

       UCX> SET CONFIGURATION INTERFACE interface /HOST=host -
       _UCX> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask

   For example, to specify the pseudo-interface FFA0 on host KESTREL, with network mask 255.255.0.0 and broadcast mask to 128.30.0.0, issue:

       UCX> SET NOINTERFACE FFA0

       UCX> SET INTERFACE FFA0 /HOST=KESTREL /NETWORK_MASK=255.255.0.0 -
       _UCX> /BROADCAST_MASK=128.30.0.0

       UCX> SET INTERFACE FFA0 /HOST=KESTREL /NETWORK_MASK=255.255.0.0 -
       _UCX> /BROADCAST_MASK=128.30.0.0

3. Enter the same information into the configuration database to set up the interfaces upon UCX startup. Issue:

       UCX> SET CONFIGURATION COMMUNICATION /INTERFACE

To display information about the network interfaces, use the SHOW INTERFACE command. To display general communications parameters and limits, use the SHOW COMMUNICATION and SHOW CONFIGURATION COMMUNICATION commands.

For example,

    UCX> SHOW COMMUNICATION
    Communication Parameters

    Local host:      HERON               Domain:   OCEAN.COM

    Cluster timer:             5
                                   Maximum     Current        Peak
    Interfaces                          10           2           2
    Device_sockets                      60           6           8
    Routes                           65535           3           3
    Services                            60           0           1
    Proxies                             29

    Type:        Ethernet   Free   Maximum   Max Bytes     Minimum   Min Bytes
    Large buffers             10       100      166400          10       16640
    Small buffers             60       330       84480          30        7680
    IRPs                      20       200
    Non UCX buffers           10

    Remote Terminal
    Large buffers:           5
    UCBs:                    4
    Virtual term:     disabled
    UCX>

## 4.4.2 Interface Routes

If you have a configuration in which multiple networks or subnetworks share the same physical LAN, you can communicate directly with hosts in other networks without the need of a pseudo-interface for each network.

You can use a broadcast address to designate an interface route, also called a metric 0 route.

To create interface routes, follow these steps:

1. List, as the gateway for the route, either one of the host's own address or the broadcast address associated with an interface.
   UCX recognizes this route as an interface route.
2. Configure the hosts in the other network to recognize that your network is present on their LAN.

For example, network 99.0.0.0 is on the same cable as network 192.199.199.0. On the host with IP address 99.1.2.3, specify network 192.199.199.0 as directly reachable:

    UCX> SET ROUTE 192.199.199.0 /NETWORK /GATEWAY=99.1.2.3

On the hosts in network 192.199.199.0, issue:

    UCX> SET ROUTE 99.0.0.0 /NETWORK /GATEWAY=192.199.199.255

# Part 2
Configuring Services

In Part 1, you completed the basic configuration tasks needed to run TCP/IP Services for OpenVMS. Part 2 describes how to set up and manage the network services that, while not required, make the network more useful.

Chapter 5 describes how to configure and manage the UCX implementation of the Berkeley Internet Name Domain (BIND) software. This chapter describes how to complete the BIND configuration (started by UCX$CONFIG). Topics include:

- How to configure the BIND resolver---software your host uses to obtain information from a name server.
- How to configure the BIND name server---software that responds to queries from the resolver or from other hosts.
- Using BIND for cluster load balancing.
- Using NSLOOKUP, an interactive tool for debugging your implementation or for interactively retrieving information from remote name servers.

Chapter 6 describes how to configure the BOOTP server and TFTP so your host can answer bootstrap requests from diskless workstations and other network devices.

Chapter 7 describes how to configure the portmapper service, a service that registers server programs written using RPCs (remote procedure calls). You must run the portmapper service if you intend to run NFS or any customer-developed RPC programs.

Chapter 8 describes how to configure and manage NTP (Network Time Protocol), allowing your host to synchronize its time with that of other internet hosts also running NTP.

Chapter 9 describes how to configure your host so it can answer SNMP (Simple Network Management Protocol) requests from remote SNMP management stations.

# Chapter 5
Configuring and Managing BIND

The Domain Name Service (DNS) is an Internet service that maintains and distributes information about Internet hosts. DNS consists of several databases that store host names and host IP addresses. With DNS, there is no central storage of data --- no one server knows everything about all the Internet domains.

In UNIX environments, DNS is implemented by the Berkeley Internet Name Domain (BIND) software. DIGITAL TCP/IP Services for OpenVMS implements a BIND server based on the Cambridge Research Associates (CRA) BIND Release 4.8.3.

In addition to standard BIND features, the DIGITAL TCP/IP Services for OpenVMS product provides cluster load balancing and round-robin scheduling.

This chapter reviews key concepts and provides guidelines for configuring and managing BIND on your OpenVMS host.

# 5.1 Reviewing Key Concepts

This section serves as a review only and assumes you are familiar with the InterNIC, applied for an IP address, and registered your domain name. You should also be familiar with BIND terminology and have completed your preconfiguration planning before using this chapter to configure and manage the BIND software.

If you are not familiar with DNS and BIND, see the DIGITAL TCP/IP Services for OpenVMS Concepts and Planning guide. If you need more in-depth knowledge, see O'Reilly's DNS and BIND.

## 5.1.1 The Resolver and Name Server Work Together

BIND is conceptually divided into two components --- a resolver and a name server. The resolver is software that queries a name server; the name server is the software process that responds to a resolver query.

Under BIND, all computers use resolver code but not all computers run the name server process.

The BIND name server runs as a distinct process called UCX$BIND_SERVER. (On UNIX systems, the name server is called named (pronounced name-de).) Name servers are typically classified as primary, secondary, and caching-only servers, depending on how they are configured. The following section describes the common BIND configurations.

## 5.1.2 Common BIND Server Configurations

You can configure the BIND server in several different ways. The most common configurations are resolver-only systems, primary servers, secondary servers, forwarder servers, and caching-only servers. A server may be any of these configurations or may combine elements of these configurations.

A group of database files containing BIND statements and resource records are used to configure servers. Section 5.3 describes how to configure BIND servers.

### 5.1.2.1 Primary Servers

A primary server is the server from which all data about a domain is derived. Primary servers are authoritative, meaning they have complete information about their domain and their responses are always accurate. There should only be one primary server for a domain.

To provide central control of host name information, the primary server loads the domain's information directly from a disk file created by the domain administrator. When a new system is added to the network, only the database located on the primary server needs to be modified.

A primary server requires a complete set of configuration files: zone, reverse domain, boot file, cache file, and loopback file. (See Table 5-1 for more information about these files.)

### 5.1.2.2 Secondary Servers

Secondary servers transfer the entire domain database from the primary server. A particular domain's database file is called a zone file and copying this file to a secondary server is called a zone file transfer. A secondary server assures that it has current information about a domain by periodically transferring the domain's zone file. Secondary servers are also authoritative for their domain.

Secondary servers require a boot file, a cache file, and a loopback file.

### 5.1.2.3 Caching-Only Servers

Caching-only servers get the answers to all name service queries from other name servers. Once a caching server receives an answer to a query, it saves the information and uses it in the future to answer queries itself. Most name servers cache answers and use them in this way but a caching-only server depends on this for all its server information. It does not keep name server database files as other servers do. Caching-only servers are non-authoritative, meaning that their information is secondhand and may be incomplete.

Caching-only servers require a cache file and loopback file.

### 5.1.2.4 Forwarder Servers

A forwarder server specifies a particular host to which requests outside the local zone are sent. This is a form of Internet courtesy so that only a limited number of hosts actually communicate with the root servers listed in NAMED.CA.

## 5.1.3 Configuring BIND

You must use the post-installation configuration procedure to configure the BIND resolver and to partially configure the BIND name server. In addition to the post-installation configuration procedure, DIGITAL TCP/IP Services for OpenVMS provides an automated configuration tool called SYS$MANAGER:UCX$BINDSETUP.COM you can use to configure your name server. You can also configure your BIND server using SET CONFIGURATION BIND commands.

# 5.2 Configuring the BIND Resolver

Your host uses the BIND resolver to obtain information from a name server. When a request for name translation arrives, the resolver first searches the local host database for the host information. If not found, the resolver then queries the BIND name server for host information.

The local host can be used as a default name server. If a name server is not specified, the local host is assumed to be running the BIND server. If it doesn't respond, the request eventually times out.

If there are other name servers specified in addition to the local host, the resolver queries the local host first, then queries other servers in the order in which they were configured.

The resolver is automatically configured by UCX$CONFIG when you choose "Option 1---Core Environment." To display your resolver configuration, issue the following command:

    UCX> SHOW NAME_SERVICE

The following displays:

    BIND Resolver Parameters

     Local domain: ucx.ern.sea.com

     System

      State:     Started, Enabled

      Transport: UDP
      Domain:    ucx.ern.sea.com
      Retry:     4
      Timeout:   4
      Servers:   lark

     Process

      State:     Enabled

      Transport:
      Domain:
      Retry:
      Timeout:
      Servers:

Here, host LARK in the current domain is used as the default name server. To add records to the local host database, use SET commands. For example, the following command adds host birdy to the local host database. (See the DIGITAL TCP/IP Services for OpenVMS Command Reference manual for more information on issuing SET commands.)

    UCX> SET HOST birdy /ADDRESS=9.20.208.47

To delete server entries from the configuration database (or to add new entries), use the following command:

    UCX> SET NAME_SERVICE /NOSERVER=LARK /SYSTEM

This command modifies the volatile database. To make changes permanent, also issue a SET CONFIGURATION NAME_SERVICE command to add the change to the permanent database. Issue another SHOW NAME_SERVICE command to view the results.

    UCX> SHOW NAME_SERVICE
    BIND Resolver Parameters

     Local domain: ucx.ern.sea.com

     System

      State:     Started, Disabled

      Transport: UDP
      Domain:    ucx.ern.sea.com
      Retry:     4
      Timeout:   4
      Servers:   No servers defined

     Process

      State:     Disabled

      Transport:
      Domain:
      Retry:
      Timeout:
      Servers:

## 5.2.1 Changing the Default Configuration

To add a new server and enable the BIND resolver, issue:

    UCX> SET NAME_SERVICE /SERVER=host /ENABLE

For host, specify the host name or IP address of the BIND server or servers that the BIND resolver will query.

To specify multiple hosts, list them by request preference. The BIND resolver sends the first lookup request to the first host on the list.

If you define a server list and then issue another SET NAME_SERVICE /SERVER command, UCX appends the new servers to the end of the list.

SET commands affect the UCX volatile database. To save your changes to the permanent database, issue SET CONFIGURATION commands. Changes you make with the SET CONFIGURATION commands take affect the next time UCX starts up. For example, issue:

    UCX> SET CONFIGURATION NAME_SERVICE /SERVER=host /ENABLE

    UCX> SHOW NAME_SERVICE
    BIND Resolver Parameters

     Local domain: ucx.ern.sea.com

     System

      State:     Started, Enabled

      Transport: UDP
      Domain:    ucx.ern.sea.com
      Retry:     4
      Timeout:   4
      Servers:   chickadee

     Process

      State:     Enabled

      Transport:
      Domain:
      Retry:
      Timeout:
      Servers:

## 5.2.2 Examples

The following command defines hosts PARROT, sora, and jaçana as systemwide BIND servers and enables the BIND resolver.

    PARROT> UCX
    UCX> SET NAME_SERVICE /SERVER=(PARROT,SORA,JACANA) /SYSTEM /ENABLE

The following example defines, for the current login session, host OSPREY as the BIND server. As a result, the servers that are defined systemwide will not be queried.

    UCX> SET NAME_SERVICE /SERVER=OSPREY

# 5.3 Configuring the Name Server

In a UNIX environment, server characteristics are defined in a boot file called named.boot. A boot file points the BIND server to its database files and holds configuration information for the host to function as a BIND server.

UCX uses the UCX$CONFIGURATION.DAT file to establish the equivalent of a boot file for the BIND server. (This file is created when you run UCX$CONFIG.)

All boot file entries are a series of statements as described below.

Statement | Description
--- | ---
Primary | Declares this server as primary for a specified zone
Secondary | Declares this server as secondary for the specified zone
Cache | Points to the cache file
Forwarders | Lists servers to which queries are forwarded
Slave | Forces the server to only use the forwarders

In addition to UCX$CONFIGURATION.DAT, UCX$CONFIG creates several database files that are used to configure the name server. These additional files are located in SYS$SPECIFIC:[UCX$BIND].

Table 5-1 summarizes the databases used to configure BIND on a UCX host.

Table 5-1 BIND Server Databases
Database File | Description | UNIX Equivalent
--- | --- | ---
NAMED.LOCAL | Loopback file. Allows the server to refer to itself by means of the loopback address. This is needed for applications such as NSLOOKUP. | named.local
NAMED.CA | Cache file. Points to the root name servers | named.ca
domain_name.DB | The zone file that maps host names to IP addresses | named.hosts
address.DB | Reverse domain file. The zone file that maps IP address to host names (reverse mapping). | named.rev
UCX$CONFIGURATION.DAT | Boot file created by UCX$CONFIG. Sets characteristics for the server such as operating mode, which domain and IP network it serves, and where to look for the database files. | named.boot
UCX$HOST.DAT | Located in SYS$COMMON:[SYSEXE], contains host table used to build the database files. ¹ | /etc/hosts

1 UCX$CONFIG creates this empty file. It is used primarily by the BIND resolver and is populated by converting a UNIX hosts database file with the CONVERT/ULTRIX BIND command or by issuing SET commands.

Previous | Next | Contents