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:
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
To start and stop the routing server, use the following commands:
UCX> START ROUTING
UCX> STOP ROUTING
UCX> SET CONFIGURATION START ROUTING
By default, the UCX startup procedure automatically sets IP forwarding.
To manually configure your system as an internet gateway, issue the following commands:
UCX> SET PROTOCOL IP /FORWARD
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
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:
Use the following commands to reset the reassembly timer:
UCX> SET PROTOCOL IP /REASSEMBLY_TIMER=n
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
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:
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:
| A | Controller 0 |
| B | Controller 1 |
| C | Controller 2 |
For example, for an OpenVMS Alpha system with two Ethernet controllers --- EZA0 and EZB0 --- you can define the following internet interfaces and pseudo-interfaces:
To extend subnetwork routing, follow these steps:
UCX> SET COMMUNICATION /INTERFACE=30 UCX> SET CONFIGURATION COMMUNICATION /INTERFACE=30
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
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
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>
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:
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
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:
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.
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:
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:
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
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.
| 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 |