HP TCPIP Services for OpenVMS Management AA-LU50M

HP TCPIP Services for OpenVMS Management AA-LU50M
HP TCP/IP Services for
OpenVMS
Management
Order Number: AA–LU50M–TE
September 2003
This manual describes how to configure and manage the TCP/IP Services
product.
Revision/Update Information:
This manual supersedes Compaq
TCP/IP Services for OpenVMS
Management, Version 5.1.
Software Version:
HP TCP/IP Services for OpenVMS
Version 5.4
Operating System:
HP OpenVMS Alpha Versions 7.3-1
and 7.3-2
Hewlett-Packard Company
Palo Alto, California
© 2003 Hewlett-Packard Development Company, L.P.
UNIX® is a registered trademark of The Open Group.
Microsoft, Windows® and Windows NT® are US registered trademarks of Microsoft Corporation.
The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such products
and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
Proprietary computer software. Valid license from HP required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government
under vendor’s standard commercial license.
ZK6526
The HP TCP/IP Services for OpenVMS documentation is available on CD-ROM.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxv
Part 1 Connecting to the Network
1 Managing TCP/IP Services
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting and Stopping the Software . . . . . . . . . . . . . . . . . . . . . .
Editing Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling PATHWORKS/Advanced Server and DECnet-over-TCP/IP
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
Starting and Stopping the PWIP Driver . . . . . . . . . . . . . . . . . .
1.3
Setting Up User Accounts and Proxy Identities . . . . . . . . . . . . . . . .
1.4
Configuring a TCP/IP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1
Setting Up an ARP-Based Cluster . . . . . . . . . . . . . . . . . . . . . . .
1.5
Auxiliary Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1
How the Auxiliary Server Works . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1.1
Rejecting Client Requests . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1.2
Configuring the Auxiliary Server . . . . . . . . . . . . . . . . . . . . .
1.6
Enabling Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1
Setting Up Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1–1
1–2
1–2
1–3
1–3
1–5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1–6
1–6
1–6
1–7
1–8
1–8
1–8
1–9
1–9
1–10
1–10
2 Configuring Interfaces
2.1
2.2
2.3
2.3.1
2.3.2
2.3.3
Key Concepts . . . . . . . . . . . . . . . . . . . .
Configuring Network Controllers . . . . .
Configuring Network Interfaces . . . . . .
Specifying the Interface . . . . . . . . .
Specifying the Network Mask . . . .
Specifying Additional IP Addresses
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2–1
2–1
2–2
2–2
2–3
2–3
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PPP and SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assigning an IP Address to Your PPP or SLIP Interface
Serial Line Internet Protocol . . . . . . . . . . . . . . . . . . . . .
Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up a PPP Interface (Alpha Only) . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3–1
3–1
3–2
3–2
3–3
3–3
3 Configuring and Managing Serial Lines
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
iii
3.2.1
Setting Up Your Host for PPP Connections . . . . . . .
3.2.1.1
Installing the Terminal Driver . . . . . . . . . . . . . .
3.2.1.2
Configuring the Modem . . . . . . . . . . . . . . . . . . .
3.2.1.3
Setting Up an Asynchronous Port . . . . . . . . . . .
3.2.1.4
Configuring a PPP Interface . . . . . . . . . . . . . . .
3.2.1.5
Enabling IP Forwarding (Dialup Provider Only)
3.2.1.6
Initiating a PPP Connection . . . . . . . . . . . . . . .
3.2.2
Removing the PPP Configuration . . . . . . . . . . . . . . .
3.3
Setting Up a SLIP Interface . . . . . . . . . . . . . . . . . . . . .
3.3.1
Setting Up Hard-Wired SLIP Lines . . . . . . . . . . . . .
3.3.2
Setting Up SLIP Dialup Lines . . . . . . . . . . . . . . . . .
3.3.3
Setting Up Your Host as a SLIP Dialup Provider . .
3.3.4
Connecting a Host to the LAN . . . . . . . . . . . . . . . . .
3.3.5
Setting Up a SLIP Gateway with Proxy ARP . . . . .
3.3.6
Shutting Down SLIP . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Solving Serial Line Problems . . . . . . . . . . . . . . . . . . . . .
3.4.1
Solving PPP Problems . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3–4
3–4
3–5
3–6
3–7
3–7
3–8
3–9
3–10
3–11
3–11
3–13
3–14
3–14
3–15
3–15
3–16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4–1
4–1
4–1
4–2
4–2
4–3
4–3
4–3
4–4
4–5
4–6
4–6
4–7
4–7
4–8
4–9
4–10
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring failSAFE IP . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring failSAFE IP Manually . . . . . . . . . . . . . .
Modifying the failSAFE IP Configuration Parameters
Creating and Displaying Home Interfaces . . . . . . . . .
Managing failSAFE IP . . . . . . . . . . . . . . . . . . . . . . . . . . .
failSAFE IP Logical Names . . . . . . . . . . . . . . . . . . . .
Customizing failSAFE IP . . . . . . . . . . . . . . . . . . . . . .
Reestablishing Static and Dynamic Routing . . . . . . .
Displaying the Status of Interfaces . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5–1
5–2
5–2
5–3
5–4
5–5
5–5
5–6
5–6
5–7
4 Configuring and Managing Routing
4.1
4.1.1
4.1.2
4.1.2.1
4.1.2.2
4.2
4.2.1
4.2.2
4.2.2.1
4.2.3
4.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static Routing . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Routing . . . . . . . . . . . . . . . . . . . . .
Routing Daemon (ROUTED) . . . . . . . . .
Gateway Routing Daemon (GATED) . . .
Configuring Static Routes . . . . . . . . . . . . . . . . .
Creating a Default Route . . . . . . . . . . . . . . .
Manually Defining Static Routes . . . . . . . . .
Examples . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Manually Defined Routes . . . . . .
Enabling and Disabling Dynamic Routing . . . . .
Configuring GATED . . . . . . . . . . . . . . . . . . . . . .
Datagram Reassembly Time . . . . . . . . . . . .
Enabling Forwarding . . . . . . . . . . . . . . . . . .
Extending Routing . . . . . . . . . . . . . . . . . . . .
Interface Routes . . . . . . . . . . . . . . . . . . . . . .
Manually Configuring a Hardware Address .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Configuring and Managing failSAFE IP
5.1
5.2
5.2.1
5.2.2
5.2.3
5.3
5.3.1
5.3.2
5.3.3
5.3.4
iv
.
.
.
.
.
5–7
5–7
5–8
5–9
5–9
......
5–9
6.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1
How the Resolver and Name Server Work Together . . . . . . . . . . . . . .
6.1.2
Common BIND Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.1
Master Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.2
Slave Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.3
Caching-Only Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.4
Forwarder Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2
Dynamic Update Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3
TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4
TKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5
SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.6
DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
Migrating from BIND Version 4 to BIND Version 9 . . . . . . . . . . . . . . . . . .
6.3.1
Navigating Two Different BIND Environments . . . . . . . . . . . . . . . . . .
6.4
BIND Service Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5
Configuring the BIND Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1
Configuration File Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.2
Address Match Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3
Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.1
The ACL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.2
The CONTROLS Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.3
The INCLUDE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.4
The KEY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.5
The LOGGING Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.5.1
The Channel Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.5.2
The Category Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6
The OPTIONS Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.1
Boolean Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.2
Forwarding Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.3
Access Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.4
Interfaces Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.5
The Query Address Options . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.6
Zone Transfer Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.7
Server Resource Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.8
Periodic Task Intervals Options . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.9
The TOPOLOGY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.10
The SORTLIST Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.11
RRset Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.12
Synthetic IPv6 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.6.13
Tuning Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6–1
6–2
6–2
6–2
6–3
6–3
6–3
6–4
6–4
6–5
6–5
6–7
6–8
6–8
6–10
6–10
6–11
6–11
6–12
6–13
6–14
6–16
6–16
6–17
6–18
6–18
6–19
6–20
6–22
6–25
6–28
6–29
6–30
6–31
6–32
6–33
6–34
6–34
6–35
6–36
6–37
6–37
5.3.5
5.3.5.1
5.3.5.2
5.3.5.3
5.3.5.4
5.3.5.5
Guidelines for Configuring failSAFE IP . . . . . . . . . . . . . . . . . .
Validating failSAFE IP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Failover Time . . . . . . . . . . . . . . . . . . . . . . . . .
Avoiding Phantom Failures . . . . . . . . . . . . . . . . . . . . . . . .
Creating IP Addresses with Home Interfaces . . . . . . . . . . .
Private Addresses Should Not Have Clusterwide Standby
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Part 2 BIND
6 Configuring and Managing BIND Version 9
v
6.5.3.6.14
The Statistics File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.7
The SERVER Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.8
The TRUSTED-KEYS Statement . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.9
The VIEW Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.10
The ZONE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.10.1
Type of Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.10.2
The Zone Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3.10.3
Zone Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.4
IPv6 Support in BIND Version 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.4.1
Address Lookups Using AAAA Records . . . . . . . . . . . . . . . . . . . . .
6.5.4.2
Address-to-Name Lookups Using Nibble Format . . . . . . . . . . . . . .
6.5.5
DNS Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.6
Incremental Zone Transfers (IXFR) . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.7
Dynamic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.7.1
The Journal File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.7.2
Dynamic Update Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.7.3
Creating Updates Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.8
Configuring Cluster Failover and Redundancy . . . . . . . . . . . . . . . . . . .
6.5.8.1
Changing the BIND Database . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6
Populating the BIND Server Databases . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1
Using Existing Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.2
Manually Editing Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.2.1
Setting TTLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.2.2
Zone File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.3
Saving Backup Copies of Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4
Sample Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4.1
Local Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4.2
Hint File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4.3
Forward Translation File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4.4
Reverse Translation File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7
Examining Name Server Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8
Configuring BIND with the SET CONFIGURATION Command . . . . . . . .
6.8.1
Setting Up a Master Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.2
Setting Up a Secondary (Slave) Name Server . . . . . . . . . . . . . . . . . . .
6.8.3
Setting Up a Cache-Only Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.4
Setting Up a Forwarder Name Server . . . . . . . . . . . . . . . . . . . . . . . . .
6.9
Configuring the BIND Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9.1
Changing the Default Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9.2
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9.3
Resolver Default Search Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9.4
Resolver Search Behavior in Earlier Releases . . . . . . . . . . . . . . . . . . .
6.9.5
Setting the Resolver’s Domain Search List . . . . . . . . . . . . . . . . . . . . .
6.10
BIND Server Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bind_checkconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bind_checkzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dnssec_keygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dnssec_makekeyset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dnssec_signkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dnssec_signzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rndc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rndc_confgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nsupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11
Solving Bind Server Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
6–38
6–39
6–40
6–41
6–43
6–44
6–45
6–45
6–47
6–48
6–48
6–48
6–48
6–48
6–49
6–49
6–50
6–51
6–52
6–52
6–53
6–54
6–55
6–55
6–56
6–56
6–56
6–57
6–58
6–60
6–60
6–61
6–61
6–62
6–62
6–62
6–62
6–63
6–64
6–64
6–65
6–65
6–66
6–68
6–69
6–70
6–73
6–75
6–77
6–80
6–84
6–86
6–90
BIND Server Diagnostic Tools . . . . . . . . . . .
dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11.2
Using NSLOOKUP to Query a Name Server
6.11.3
Solving Specific Name Server Problems . . . .
6.11.3.1
Server Not Responding . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6–90
6–91
6–98
6–100
6–100
6–100
DNS Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Round-Robin Scheduling . . . . . . . . . . . . . . . . . . . . . . . .
Disabling Round-Robin Scheduling . . . . . . . . . . . . .
Load Broker Concepts . . . . . . . . . . . . . . . . . . . . . . . . . .
How the Load Broker Works . . . . . . . . . . . . . . . . . .
Managing the Load Broker in an OpenVMS Cluster
How the Metric Server Calculates Load . . . . . . . . .
Load Broker Startup and Shutdown . . . . . . . . . . . . . . .
Configuring the Load Broker . . . . . . . . . . . . . . . . . . . . .
Enabling the Load Broker . . . . . . . . . . . . . . . . . . . .
Load Broker Logical Names . . . . . . . . . . . . . . . . . . .
Metric Server Logical Names . . . . . . . . . . . . . . . . . .
Metric Server Startup and Shutdown . . . . . . . . . . . . . .
Solving Load Broker Problems . . . . . . . . . . . . . . . . . . . .
Metricview Utility . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Diagnostic Messages . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7–1
7–1
7–3
7–3
7–4
7–5
7–5
7–6
7–6
7–8
7–9
7–9
7–10
7–10
7–10
7–11
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How DHCP Operates . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How DHCP Allocates IP Addresses . . . . . . . . . . . . . . . . . .
Relationship Between DHCP and BOOTP . . . . . . . . . . . . .
Client ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executable Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Configuration Parameter . . . . . . . . . . . . . . . . . .
Network Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netmask Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NamePool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.DDNSKEYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Server Startup and Shutdown . . . . . . . . . . . . . . . . . . .
Stopping the DHCP Server Process . . . . . . . . . . . . . . . . . .
Configuring the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . .
Configuring DHCP and DNS/BIND to Assign Host Names
Dynamically Assigning Host Names . . . . . . . . . . . . . .
Statically Assigning Host Names . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8–1
8–2
8–2
8–3
8–4
8–4
8–4
8–5
8–6
8–10
8–12
8–13
8–14
8–16
8–16
8–17
8–18
8–18
8–18
8–19
8–19
8–20
8–20
8–21
6.11.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Using DNS to Balance Work Load
7.1
7.2
7.2.1
7.3
7.3.1
7.3.2
7.3.3
7.4
7.5
7.5.1
7.5.2
7.5.3
7.6
7.7
7.7.1
7.7.2
Part 3 Configuring Services
8 Configuring and Managing the DHCP Server
8.1
8.1.1
8.1.2
8.1.3
8.1.4
8.2
8.2.1
8.2.2
8.2.2.1
8.2.2.2
8.2.2.3
8.2.2.4
8.2.2.5
8.2.2.6
8.2.3
8.2.4
8.2.5
8.3
8.3.1
8.4
8.4.1
8.4.2
8.4.2.1
8.4.2.2
vii
8.4.3
Signaling the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.4
Returning to the BOOTP-Only Configuration . . . . . . . . . . . . . . . . . . .
8.4.5
Setting Up a DHCP Cluster Failover Environment . . . . . . . . . . . . . . .
8.4.6
Methods to Configure DHCP Parameters . . . . . . . . . . . . . . . . . . . . . . .
8.5
Using DHCP GUI to Configure DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1.1
Saving Information in a Record . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1.2
Adding New Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2
Configuring Server and Security Parameters . . . . . . . . . . . . . . . . . . . .
8.5.2.1
Server/Security Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2.2
Configuring IP Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2.3
Configuring Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2.3.1
Host Name List Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2.4
Active IP Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2.5
Preload MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3
Configuring Parameters for Clients . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.1
The Subnets Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.1.1
Configuring a Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.1.2
Removing a Subnet Record . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.2
The Nodes Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.2.1
Configuring a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.2.2
Removing a node record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.3
The Groups Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.3.1
Using group parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.3.2
Defining a group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.3.3
Removing a group record . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4
Nodes, Subnets, Group Parameters . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.1
Name/ID parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.2
Key Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.3
BOOTP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.4
IP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.5
Lease parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.6
Link Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.7
NetBIOS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.8
Network Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.9
TCP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.10
Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.4.11
X Window Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6
Configuring DHCP/BOOTP IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.1
Static IP Addressing for BOOTP Clients . . . . . . . . . . . . . . . . . . . . . . .
8.6.2
Static IP Addressing for DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . .
8.7
Configuring DHCP Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.1
Tasks Involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.2
Modifying the Client Configuration Parameters File . . . . . . . . . . . . . .
8.7.2.1
DHCPCAP Configuration Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.2.2
DHCPCAP Configuration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.2.3
DHCPCAP Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . .
8.7.2.4
Symbol Value Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.2.5
DHCP Configuration Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7.3
Reinitializing the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8
Supporting Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.1
DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW Utilities . . .
8.8.2
DHCPDBMOD Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.3
DHCPDBREG Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
8–21
8–22
8–22
8–24
8–24
8–25
8–26
8–26
8–26
8–26
8–32
8–33
8–33
8–34
8–35
8–36
8–36
8–37
8–37
8–38
8–38
8–39
8–39
8–39
8–39
8–40
8–40
8–41
8–41
8–42
8–44
8–46
8–47
8–47
8–48
8–48
8–49
8–49
8–49
8–50
8–50
8–51
8–51
8–52
8–52
8–52
8–53
8–53
8–54
8–62
8–62
8–63
8–65
8–66
8.9
Solving DHCP Server Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8–66
9 Configuring and Managing the DHCP Client
9.1
9.1.1
9.1.2
9.1.3
9.1.4
9.2
9.2.1
9.2.2
9.2.2.1
9.2.2.2
9.2.2.3
9.2.2.4
9.2.3
9.2.4
9.2.5
9.3
9.4
9.4.1
9.4.1.1
9.4.1.2
9.4.2
9.4.3
9.4.4
9.5
9.5.1
9.5.2
9.6
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Designating the Primary Interface . . . . . . . . . . . . . . . . . . . . . . . .
Requesting a Lease . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requesting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding How the DHCP Client Operates . . . . . . . . . . . . .
DHCP Client Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executable Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Host Name File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The DHCPTAGS. File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Logicals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Client Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Putting Interfaces under DHCP Control . . . . . . . . . . . . . . . . . . .
Using Autoconfigure for a New TCP/IP Installation . . . . . . . .
Using TCPIP$CONFIG to Configure an Existing Installation
Configuring the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Cluster Environment . . . . . . . . . . . . . . . . . . . . . . .
Signaling the DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporarily Configuring Interfaces . . . . . . . . . . . . . . . . . . . . . . .
Permanently Configuring Interfaces . . . . . . . . . . . . . . . . . . . . . .
Using the SHOWDHC Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9–1
9–2
9–3
9–3
9–3
9–4
9–4
9–5
9–5
9–9
9–10
9–10
9–11
9–11
9–11
9–12
9–12
9–12
9–12
9–13
9–14
9–15
9–15
9–16
9–16
9–16
9–17
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Planning and Preconfiguration Tasks . . . . . . . . . . . . . . . . . . . . . .
Network Configuration Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Service Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the BOOTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing the BOOTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling and Disabling BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a BOOTP Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Populating the BOOTP Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Converting UNIX Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Individual Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying and Deleting Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solving BOOTP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10–1
10–2
10–2
10–2
10–3
10–3
10–4
10–4
10–5
10–5
10–5
10–6
10–6
10–7
10–8
10–8
10–8
10 Configuring and Managing BOOTP
10.1
10.2
10.2.1
10.2.2
10.2.3
10.3
10.4
10.4.1
10.4.2
10.4.3
10.4.4
10.5
10.5.1
10.5.2
10.5.3
10.5.4
10.6
ix
11 Configuring and Managing TFTP
11.1
11.2
11.2.1
11.2.2
11.2.3
11.2.4
11.2.5
11.3
11.4
Key Concepts . . . . . . . . . . . . . . . . . . . . .
Setting up the TFTP Service . . . . . . . . .
Transferring Data to the TFTP Host
TFTP Management Commands . . . .
TFTP Logical Names . . . . . . . . . . . .
TFTP Startup and Shutdown . . . . . .
Enabling and Disabling TFTP . . . . .
TFTP Security . . . . . . . . . . . . . . . . . . . .
Solving TFTP Problems . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11–1
11–1
11–2
11–2
11–2
11–3
11–3
11–4
11–5
Configuring Services to Use the Portmapper . . . . . . . . . . . . . . . . . . . . . . .
Portmapper Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Portmapper Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12–1
12–2
12–2
12 Configuring and Managing the Portmapper
12.1
12.2
12.3
13 Configuring and Managing NTP
13.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.1
Time Distributed Through a Hierarchy of Servers . . . . . . . . . . . . . . . .
13.1.2
How Hosts Negotiate Synchronization . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.3
How the OpenVMS System Maintains the System Clock . . . . . . . . . . .
13.1.4
How NTP Makes Adjustments to System Time . . . . . . . . . . . . . . . . . .
13.1.5
Configuring the Local Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2
NTP Service Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3
Configuring Your NTP Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1
Creating the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2
Configuration Statements and Options . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2.1
NTP Monitoring Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2.2
Access Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2.2.1
The Kiss-of-Death Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2.2.2
Access Control Statements and Flags . . . . . . . . . . . . . . . . . . .
13.3.2.3
Sample NTP Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.3
Using NTP with Another Time Service . . . . . . . . . . . . . . . . . . . . . . . .
13.4
Configuring NTP as Backup Time Server . . . . . . . . . . . . . . . . . . . . . . . . .
13.5
NTP Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.1
Sample NTP Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.6
NTP Authentication Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.6.1
NTP Authentication Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.6.2
Authentication Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.7
NTP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.7.1
Setting the Date and Time with NTPDATE . . . . . . . . . . . . . . . . . . . . .
13.7.2
Tracing a Time Source with NTPTRACE . . . . . . . . . . . . . . . . . . . . . . .
13.7.3
Making Run-Time Requests with NTPDC . . . . . . . . . . . . . . . . . . . . . .
13.7.3.1
NTPDC Interactive Commands . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.7.3.2
NTPDC Control Message Commands . . . . . . . . . . . . . . . . . . . . . . .
13.7.3.3
NTPDC Request Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.7.4
Querying the NTP Server with NTPQ . . . . . . . . . . . . . . . . . . . . . . . . .
13.7.4.1
NTPQ Control Message Commands . . . . . . . . . . . . . . . . . . . . . . . .
13.7.5
Generating Random Keys with NTP_GENKEYS . . . . . . . . . . . . . . . . .
13.8
Solving NTP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
13–1
13–2
13–2
13–3
13–3
13–3
13–5
13–6
13–6
13–7
13–11
13–12
13–13
13–13
13–15
13–16
13–16
13–17
13–18
13–19
13–20
13–21
13–21
13–22
13–23
13–24
13–24
13–25
13–27
13–28
13–30
13–33
13–33
.
.
.
.
.
13–34
13–34
13–34
13–37
13–37
14.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1.1
Understanding How SNMP Operates . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1.2
Ensuring Access to Mounted Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.2
Managing the SNMP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.3
Verifying the SNMP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.3.1
SNMP Executable and Command Files . . . . . . . . . . . . . . . . . . . . . . . .
14.4
Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4.1
Initial SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4.2
Displaying the Current SNMP Configuration . . . . . . . . . . . . . . . . . . .
14.4.3
SNMP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4.3.1
Using Logical Names to Configure SNMP . . . . . . . . . . . . . . . . . . .
14.4.3.2
Dynamic Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4.3.3
Modifying the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4.3.4
SNMP Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.5
SNMP Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6
Solving SNMP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.1
Multiple SNMP Processes Displayed for SHOW SYSTEM
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.2
Problems Starting and Stopping SNMP Processes . . . . . . . . . . . . . . . .
14.6.3
Restarting MIB Subagent Processes . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.4
Obtaining Trace Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.5
Processing Set Requests and Traps . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.5.1
Enabling Set Request Processing and Authentication Traps . . . . .
14.6.5.2
Displaying Configuration Information . . . . . . . . . . . . . . . . . . . . . .
14.6.5.2.1
Specifying Location and Contact Information . . . . . . . . . . . . .
14.6.5.2.2
Verifying Community Information . . . . . . . . . . . . . . . . . . . . . .
14.6.5.3
Enabling SNMP Version 1 Traps . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6.6
Solving Management Client Response Problems . . . . . . . . . . . . . . . . .
14.6.6.1
Solving Timeout Problems with SNMP Subagents . . . . . . . . . . . . .
14.6.7
Disabling SNMP OPCOM Messages . . . . . . . . . . . . . . . . . . . . . . . . . .
14–1
14–2
14–3
14–4
14–4
14–5
14–6
14–6
14–8
14–9
14–9
14–9
14–10
14–10
14–20
14–21
13.8.1
13.8.1.1
13.8.1.2
13.8.1.3
13.8.1.4
NTP Debugging Techniques . . .
Initial Startup . . . . . . . . . .
Verifying Correct Operation
Special Problems . . . . . . . .
Debugging Checklist . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14 Configuring and Managing SNMP
14–21
14–22
14–22
14–22
14–23
14–24
14–24
14–25
14–26
14–26
14–27
14–29
14–29
Part 4 Configuring Network Applications
15 Configuring and Managing TELNET
15.1
Managing TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.1
TELNET Startup and Shutdown . . . . . . . . . . . . . . . . . . . .
15.1.2
Managing TELNET with Logical Names . . . . . . . . . . . . . .
15.1.3
Setting Up User Accounts . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.4
Creating and Deleting Sessions . . . . . . . . . . . . . . . . . . . . .
15.1.5
Displaying Login Messages . . . . . . . . . . . . . . . . . . . . . . . .
15.1.6
TELNET Client (TN3270) . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.7
Configuring and Managing the Kerberos TELNET Server .
15.1.7.1
Configuring the Kerberos TELNET Server . . . . . . . . .
15.1.7.2
Connecting to the Kerberos TELNET Server . . . . . . . .
15.1.8
Kerberos Principal Names . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15–1
15–1
15–2
15–2
15–2
15–3
15–3
15–3
15–4
15–4
15–4
xi
15.2
Solving TELNET Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.2.1
TELNET Characteristics That Affect Performance . . . . . . . . . . . . . . .
15.2.2
Requests That Cannot Be Satisfied . . . . . . . . . . . . . . . . . . . . . . . . . . .
15–5
15–5
15–6
16 Configuring and Managing FTP
16.1
Managing FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.1
Enabling and Disabling FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.2
FTP Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.3
Configuring Anonymous FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.3.1
Concealed File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.3.2
Setting Up Anonymous FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.4
Managing FTP with Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.4.1
FTP Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2
Solving FTP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.1
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.1.1
Buffer Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.1.2
File Allocation and Extension Sizes . . . . . . . . . . . . . . . . . . . . . . . .
16.2.1.3
Inactivity Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16–1
16–1
16–2
16–2
16–3
16–3
16–4
16–7
16–8
16–8
16–8
16–8
16–9
17 Remote (R) Commands
.
.
.
.
.
.
.
.
.
.
.
.
17–1
17–2
17–2
17–2
17–3
17–3
17–4
17–4
17–4
17–4
17–5
17–6
18.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.1.1
How SMTP Clients and Servers Communicate . . . . . . . . . . . . . . . . . .
18.1.2
Understanding the SMTP Control File . . . . . . . . . . . . . . . . . . . . . . . .
18.1.3
Understanding OpenVMS Sender Headers . . . . . . . . . . . . . . . . . . . . .
18.1.4
Understanding SMTP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.1.5
How SMTP Routes Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.1.5.1
Using MX Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.1.5.2
Using SMTP Zones and Alternate Gateways . . . . . . . . . . . . . . . . .
18.2
Configuring SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.2.1
Mail Utility Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.2.2
Creating a Postmaster Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3
Creating a Local Alias File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4
Managing SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.1
Displaying Mail Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.2
Changing the Number of Mail Queues . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.3
Displaying SMTP Routing Information . . . . . . . . . . . . . . . . . . . . . . . .
18.4.4
SMTP Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18–1
18–2
18–3
18–3
18–4
18–4
18–4
18–5
18–6
18–6
18–7
18–7
18–8
18–9
18–9
18–9
18–9
17.1
17.2
17.2.1
17.2.2
17.3
17.3.1
17.3.2
17.4
17.5
17.5.1
17.5.2
17.5.3
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing the R Command Servers . . . . . . . . . . . . . . . . . .
R Command Server Startup and Shutdown . . . . . . . . .
Managing RLOGIN with Logical Names . . . . . . . . . . .
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registering Remote Users . . . . . . . . . . . . . . . . . . . . . .
Case-Sensitivity Flag . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Welcome Message . . . . . . . . . . . . . . . . . . . . . . .
Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)
Preparing Drives for Remote Mounts . . . . . . . . . . . . . .
Client Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18 Configuring and Managing SMTP
xii
18.4.5
Starting and Stopping SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5
Modifying the SMTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.1
Defining SMTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.2
SMTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6
Configuring SMTP Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.1
Enabling and Managing SMTP Antispam . . . . . . . . . . . . . . . . . . . . . .
18.6.1.1
SMTP Antispam Field Names . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2
Preventing Spam Route-Through . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2.1
Specifying the Good-Clients List . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2.2
Processing DNS Entries in the Good-Clients List . . . . . . . . . . . . .
18.6.2.3
Mail Relay to MX Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2.4
Specifying the Relay-Zones List . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2.5
Examples of Specifying Good-Clients and Relay-Zones . . . . . . . . .
18.6.3
Blocking Mail from Specified Clients . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.3.1
Resolving Conflicts between Bad-Clients and Good-Clients . . . . . .
18.6.4
Real-Time Black Hole Lists (RBL) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.5
Translating Client IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.6
Blocking Mail from Specified Senders . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.7
Specifying Handling of Spam Events . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.7.1
Reporting Spam Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.7.2
Configuring Spam Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.7.3
Specifying the Spam Rejection Text . . . . . . . . . . . . . . . . . . . . . . . .
18.7
Managing SMTP Send-From-File (SFF) . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.1
SFF Security Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.2
Invoking SFF from an Application . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.3
Invoking SFF from DCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.8
Disabling SMTP Outbound Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.9
Solving SMTP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.9.1
Verifying SMTP Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.9.2
Slow Antispam Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18–10
18–10
18–11
18–11
18–16
18–16
18–16
18–19
18–20
18–21
18–21
18–22
18–22
18–23
18–23
18–23
18–23
18–24
18–25
18–25
18–25
18–26
18–26
18–27
18–27
18–27
18–28
18–28
18–28
18–29
19 Configuring and Managing the POP Server
19.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.1
POP Server Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.2
How to Access Mail Messages from the POP Server . . . . . . . . . . . . . .
19.1.3
How the POP Server Initiates and Manages a TCP Connection . . . . .
19.1.4
How the POP Server Handles Foreign Message Formats . . . . . . . . . .
19.1.5
How the POP Server Authorizes Users . . . . . . . . . . . . . . . . . . . . . . . .
19.1.6
Understanding POP Message Headers . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.6.1
How POP Rebuilds the OpenVMS Mail From: Field . . . . . . . . . . .
19.1.6.1.1
SMTP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.6.1.2
DECnet Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.6.1.3
User Name-Only Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.6.1.4
DECnet Address That Contains Quotation Marks . . . . . . . . . .
19.1.6.1.5
Cluster-Forwarding SMTP Address . . . . . . . . . . . . . . . . . . . . .
19.1.6.1.6
All Other Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2
POP Server Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3
Modifying POP Server Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4
Enabling MIME Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5
Secure POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.1
Installing SSL Shareable Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.2
Starting SSL before TCP/IP Services . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.3
Controlling Secure POP With Logical Names . . . . . . . . . . . . . . . . . . . .
19–1
19–2
19–2
19–2
19–3
19–3
19–4
19–4
19–5
19–5
19–6
19–6
19–7
19–7
19–7
19–8
19–12
19–13
19–13
19–13
19–13
xiii
19.5.4
Specifying Certificate and Key Files . . . . . . . . .
19.5.5
Security Recommendations for the SSL Key File
19.5.6
Encrypted Private Keys . . . . . . . . . . . . . . . . . . .
19.6
Solving POP Problems . . . . . . . . . . . . . . . . . . . . . . .
19.6.1
POP Server Messages . . . . . . . . . . . . . . . . . . . .
19.6.2
Using POP Extension Commands . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19–14
19–15
19–15
19–15
19–15
19–16
20 Configuring and Managing the IMAP Server
20.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.1.1
IMAP Server Process . . . . . . . . . . . . . . . . . .
20.2
IMAP Server Control . . . . . . . . . . . . . . . . . . . . .
20.2.1
Starting Up and Shutting Down the Server .
20.2.2
Viewing Server Event Log Files . . . . . . . . . .
20.2.3
Modifying IMAP Server Characteristics . . . .
20.2.4
Tuning the Server . . . . . . . . . . . . . . . . . . . .
20.2.4.1
Tuning Issues . . . . . . . . . . . . . . . . . . . . .
20.2.4.2
Tuning Options . . . . . . . . . . . . . . . . . . .
20.3
Enabling MIME Mail . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20–1
20–1
20–2
20–2
20–2
20–2
20–6
20–6
20–7
20–8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21–1
21–2
21–2
21–2
21–3
21–5
21–6
21–6
21–7
21–7
21–8
21–8
21–9
22.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.1
Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.2
NFS File Systems on OpenVMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.2.1
Selecting a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.2.2
Understanding the Container File System . . . . . . . . . . . . . . . . . . .
22.1.2.3
NFS Support for Extended File Specifications . . . . . . . . . . . . . . . .
22.1.3
How the Server Grants Access to Users and Hosts . . . . . . . . . . . . . . .
22.1.4
How the Server Maps User Identities . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.5
Mapping the Default User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.6
Mapping a Remote Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.7
How OpenVMS and the NFS Server Grant File Access . . . . . . . . . . . .
22.1.8
Understanding the Client’s Role in Granting Access . . . . . . . . . . . . . .
22.1.9
Granting Access to PC-NFS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.2
NFS Server Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22–1
22–2
22–2
22–2
22–3
22–3
22–4
22–4
22–5
22–6
22–6
22–6
22–7
22–7
21 Configuring XDMCP-Compatible X Displays
21.1
21.2
21.3
21.3.1
21.3.2
21.3.3
21.3.4
21.3.5
21.4
21.5
21.6
21.7
21.8
Key Concepts . . . . . . . . . . . . . . . . . . . . .
XDMCP Queries . . . . . . . . . . . . . . . . . . .
XDM Configuration Files . . . . . . . . . . . .
Master Configuration File . . . . . . . .
XACCESS.TXT File . . . . . . . . . . . . .
XSERVERS.TXT File . . . . . . . . . . . .
XDM_KEYS.TXT File . . . . . . . . . . .
XDM_XSESSION.COM File . . . . . . .
XDM Log Files . . . . . . . . . . . . . . . . . . . .
XDM Server Startup and Shutdown . . .
Configuring the XDM Server . . . . . . . . .
Ensuring XDM Is Enabled and Running
Configuring Other X Displays . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Part 5 Network File Services
22 Configuring and Managing the NFS Server
xiv
22.3
Running the NFS Server on an OpenVMS Cluster System . . . . . . . . . . . .
22.4
Setting Up PC-NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.5
Managing the MOUNT Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.6
Registering Users and Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.6.1
Adding Proxy Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.6.2
Adding Entries to the Export Database . . . . . . . . . . . . . . . . . . . . . . . .
22.7
Backing Up a File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.8
Setting Up and Exporting an OpenVMS File System . . . . . . . . . . . . . . . . .
22.9
Setting Up and Exporting a Container File System . . . . . . . . . . . . . . . . . .
22.10 Maintaining a Container File System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.10.1
Displaying Directory Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.10.2
Copying Files into a Container File System . . . . . . . . . . . . . . . . . . . . .
22.10.3
Removing Links to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.10.4
Removing Links to a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.10.5
Deleting a Container File System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.10.6
Verifying the Integrity of a Container File System . . . . . . . . . . . . . . .
22.10.7
Restoring a Container File System . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.11 Setting Up NFS Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.12 Modifying NFS Server Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.13 Modifying File System Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.14 File Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.14.1
File Locking Service Startup and Shutdown . . . . . . . . . . . . . . . . . . . .
22.15 Improving NFS Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.15.1
Displaying NFS Server Performance Information . . . . . . . . . . . . . . . .
22.15.2
Increasing the Number of Active Threads . . . . . . . . . . . . . . . . . . . . . .
22.15.3
Managing the File Name Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.15.4
OpenVMS SYSGEN Parameters That Affect Performance . . . . . . . . . .
22–8
22–8
22–8
22–9
22–10
22–10
22–11
22–11
22–12
22–13
22–14
22–14
22–14
22–14
22–15
22–15
22–16
22–16
22–17
22–18
22–19
22–20
22–20
22–21
22–21
22–21
22–23
23 Configuring and Managing the NFS Client
23.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.1
NFS Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.2
Storing File Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.2.1
Using Default ADFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.2.2
How the Client Uses ADFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.2.3
Creating Customized Default ADFs . . . . . . . . . . . . . . . . . . . . . . . .
23.1.3
NFS Client Support for Extended File Specifications . . . . . . . . . . . . . .
23.1.4
How the NFS Client Authenticates Users . . . . . . . . . . . . . . . . . . . . . .
23.1.5
How the NFS Client Maps User Identities . . . . . . . . . . . . . . . . . . . . . .
23.1.6
NFS Client Default User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.7
How the NFS Client Maps UNIX Permissions to OpenVMS
Protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1.8
Guidelines for Working with DNFS Devices . . . . . . . . . . . . . . . . . . . . .
23.1.9
How NFS Converts File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.2
NFS Client Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.3
Registering Users in the Proxy Database . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4
Mounting Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4.1
User-Level Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4.2
Automounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4.3
Background Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4.4
Overmounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.4.5
Occluded Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23–1
23–1
23–2
23–2
23–2
23–3
23–3
23–4
23–4
23–5
23–5
23–5
23–6
23–6
23–6
23–8
23–9
23–11
23–11
23–12
23–12
xv
Part 6 Configuring Printing Services
24 Setting Up and Managing the LPR/LPD Print Service
24.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.2
Configuring LPR/LPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.3
LPD Server Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.4
Configuring Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.4.1
Printer Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.4.1.1
Setting Up Print Spool Directories . . . . . . . . . . . . . . . . . . . . . . . . .
24.4.1.2
Setting Up Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.4.1.3
Support for PrintServer Extensions . . . . . . . . . . . . . . . . . . . . . . . .
24.5
LPD Server Cluster Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.5.1
Creating LPD Utility Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.5.2
Using Clusterwide Print Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.5.3
Configuring a High-Availability LPD Server . . . . . . . . . . . . . . . . . . . .
24.6
Managing LPD Server Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.7
Defining the LPD Spooler Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.8
Controlling Access to Local Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.9
Receiving LPR/LPD OPCOM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.10 Using OpenVMS Flag Page Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.11 Solving LPD Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24–1
24–2
24–5
24–5
24–8
24–9
24–9
24–10
24–10
24–10
24–11
24–11
24–11
24–12
24–12
24–12
24–13
24–13
25 Setting Up and Managing TELNETSYM
25.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.1.1
TELNETSYM Process Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.1.2
TELNETSYM Modifications to the Output Stream . . . . . . . . . . . . . . .
25.2
TELNETSYM Service Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . .
25.3
Setting Up Print Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.4
Setting Up Relay Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.5
Managing and Customizing Your Print Queues . . . . . . . . . . . . . . . . . . . . .
25.5.1
Controlling the Print Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.5.2
Setting Up Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.5.3
Controlling Characteristics of the TCP/IP Link . . . . . . . . . . . . . . . . . .
25.5.4
Establishing a TELNETSYM Link . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.5.5
Releasing a TELNETSYM Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.5.6
Setting the Number of Execution Queues . . . . . . . . . . . . . . . . . . . . . .
25.6
Solving TELNETSYM Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.6.1
Using TCPIP$TELNETSYM for the First Time . . . . . . . . . . . . . . . . . .
25.6.2
Printing to Terminal Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.6.3
Stalled Print Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.6.4
Solving Formatting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.6.4.1
Controlling Form Feed Suppression . . . . . . . . . . . . . . . . . . . . . . . .
25.6.4.2
Buffer Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25–1
25–1
25–1
25–2
25–3
25–3
25–3
25–4
25–4
25–5
25–7
25–7
25–7
25–8
25–8
25–8
25–8
25–8
25–9
25–10
26 Setting Up PC-NFS
26.1
26.2
26.3
26.4
xvi
PC-NFS Startup and Shutdown . .
Providing PC-NFS Print Services .
Managing PC-NFS Print Queues .
PC-NFS Authentication . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26–1
26–2
26–2
26–2
Part 7 Appendixes
A Gateway Routing Daemon (GATED) Configuration Reference
A.1
The GATED Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2
Configuration File Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3
Statement Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4
Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5
Creating the GATED Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6
Defining Preferences and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6.1
Assigning Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6.2
Sample Preference Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7
Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7.1
Global Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7.2
Packet Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.8
Directive Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.9
Options Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.10
Interface Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.10.1
Interface Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.10.1.1
Example of Current Define Statements for GATED . . . . . . . . . . . .
A.10.2
IP Interface Addresses and Routes . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11
Definition Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11.1
Autonomous System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11.2
Router ID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11.3
Martian Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11.4
Sample Definition Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12
Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.1
Interior Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.2
Exterior Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.3
Router Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.4
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.5
Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.6
Kernel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.12.7
Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.13
The ICMP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.13.1
Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.14
Redirect Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.15
The Router Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.15.1
The Router Discovery Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.15.2
The Router Discovery Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.15.3
Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16
The Kernel Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.1
Forwarding Tables and Routing Tables . . . . . . . . . . . . . . . . . . . . . . . .
A.16.2
Updating the Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.2.1
Updating the Forwarding Table with the ioctl Interface . . . . . . . .
A.16.2.2
Updating the Forwarding Table with the Routing Socket
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.3
Reading the Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.4
Reading the Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.5
Reading Interface Physical Addresses . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.6
Reading Kernel Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.7
Special Route Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.8
Kernel Configuration Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16.9
Kernel Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A–1
A–1
A–2
A–2
A–3
A–4
A–5
A–6
A–6
A–7
A–8
A–9
A–9
A–10
A–13
A–13
A–14
A–15
A–15
A–15
A–15
A–15
A–16
A–16
A–16
A–17
A–17
A–17
A–18
A–18
A–18
A–18
A–19
A–20
A–20
A–22
A–23
A–23
A–24
A–24
A–24
A–25
A–25
A–26
A–27
A–27
A–27
A–28
A–29
xvii
A.17
Static Routes Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18
Control Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.1
Route Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.2
Matching AS Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.2.1
AS Path-Matching Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.2.2
AS Path Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.2.3
AS Path Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.2.4
AS Path Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.3
The Import Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.3.1
Specifying Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.3.2
Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.3.3
Importing Routes from BGP and EGP . . . . . . . . . . . . . . . . . . . . . .
A.18.3.4
Importing Routes from RIP and Redirects . . . . . . . . . . . . . . . . . . .
A.18.3.5
Importing Routes from OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.4
The Export Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.4.1
Specifying Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.4.2
Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.4.3
Specifying the Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.5
Specifying the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.6
Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.18.6.1
Aggregation and Generation Syntax . . . . . . . . . . . . . . . . . . . . . . .
A.19
Sample Host Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.19.1
Sample RIP and EGP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .
A.19.2
Sample BGP and OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . .
A.20
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A–30
A–32
A–32
A–33
A–33
A–34
A–34
A–34
A–35
A–35
A–35
A–35
A–36
A–37
A–37
A–37
A–38
A–38
A–40
A–41
A–42
A–43
A–44
A–46
A–47
B EBCDIC/DMCS Translation Tables
B.1
B.2
B.3
Macros for Modifying the Translation Tables . . . . . . . . . . . . . . . . . . . . . .
Building Translation Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of Modifying Translation Tables . . . . . . . . . . . . . . . . . . . . . . . . .
B–1
B–2
B–2
C How NFS Converts File Names
D Configuring and Managing BIND Version 8
D.1
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1
How the Resolver and Name Server Work Together
D.1.2
Common BIND Configurations . . . . . . . . . . . . . . . . .
D.1.2.1
Master Servers . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.2.2
Slave Servers . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.2.3
Caching-Only Servers . . . . . . . . . . . . . . . . . . . .
D.1.2.4
Forwarder Servers . . . . . . . . . . . . . . . . . . . . . . .
D.2
Migrating to BIND 8.1 . . . . . . . . . . . . . . . . . . . . . . . . . .
D.2.1
Navigating Two Different BIND Environments . . . .
D.3
Configuring the BIND Server (BIND 8.1) . . . . . . . . . . .
D.3.1
BIND Configuration Logging Statement . . . . . . . . .
D.3.1.1
Channel Phrase . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.1.2
Category Phrase . . . . . . . . . . . . . . . . . . . . . . . . .
xviii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D–2
D–2
D–2
D–3
D–3
D–3
D–3
D–4
D–4
D–5
D–7
D–8
D–9
D.3.2
BIND Configuration Options Statement . . . . . . . . . . . . . . . .
D.3.2.1
Path Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.2
Boolean Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.3
Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.4
Name Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.5
Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.6
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.7
Query Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.8
Zone Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.9
Periodic Task Intervals . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.2.10
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.3
BIND Configuration Server Statement . . . . . . . . . . . . . . . . .
D.3.3.1
Limiting the Number of Transfers . . . . . . . . . . . . . . . . . .
D.3.3.2
Efficient Zone Transfers . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.4
BIND Configuration Zone Statement . . . . . . . . . . . . . . . . . . .
D.3.5
Address Match Lists and ACLs . . . . . . . . . . . . . . . . . . . . . . .
D.3.6
Dynamic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.6.1
Preserving the Zone File . . . . . . . . . . . . . . . . . . . . . . . . .
D.3.6.2
Manually Creating Updates . . . . . . . . . . . . . . . . . . . . . . .
D.3.7
Configuring Cluster Failover and Redundancy . . . . . . . . . . . .
D.3.7.1
Changing the BIND Database . . . . . . . . . . . . . . . . . . . . .
D.4
Populating the BIND Server Databases . . . . . . . . . . . . . . . . . . . .
D.4.1
Using Existing Databases . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.2
Manually Editing Zone Files . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.3
Saving Backup Copies of Zone Data . . . . . . . . . . . . . . . . . . . .
D.4.4
Sample Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.4.1
Local Loopback: Forward and Reverse Translation Files .
D.4.4.2
Hint File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.4.3
Forward Translation File . . . . . . . . . . . . . . . . . . . . . . . . .
D.4.4.4
Reverse Translation File . . . . . . . . . . . . . . . . . . . . . . . . .
D.5
Examining Name Server Statistics . . . . . . . . . . . . . . . . . . . . . . .
D.6
Configuring BIND with SET CONFIGURATION Commands . . .
D.6.1
Setting Up a Master Name Server . . . . . . . . . . . . . . . . . . . . .
D.6.2
Setting Up a Secondary (Slave) Name Server . . . . . . . . . . . .
D.6.3
Setting Up a Cache-Only Server . . . . . . . . . . . . . . . . . . . . . .
D.6.4
Setting Up a Forwarder Name Server . . . . . . . . . . . . . . . . . .
D.7
Configuring the BIND Resolver . . . . . . . . . . . . . . . . . . . . . . . . . .
D.7.1
Changing the Default Configuration . . . . . . . . . . . . . . . . . . .
D.7.2
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.7.3
Resolver Default Search Behavior . . . . . . . . . . . . . . . . . . . . .
D.7.4
Resolver Search Behavior in Earlier Releases . . . . . . . . . . . .
D.7.5
Setting the Resolver’s Domain Search List . . . . . . . . . . . . . .
D.8
Using NSLOOKUP to Query a Name Server . . . . . . . . . . . . . . . .
D.8.1
Invoking NSLOOKUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.2
Obtaining Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.3
NSLOOKUP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.4
Default Option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5
Query Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5.1
A Query Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5.2
PTR Query Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5.3
MX Query Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5.4
SOA Query Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.5.5
NS Query Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.8.6
Changing the Default Server . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D–10
D–11
D–12
D–13
D–14
D–15
D–15
D–16
D–16
D–17
D–17
D–18
D–18
D–18
D–19
D–19
D–20
D–21
D–21
D–23
D–24
D–25
D–25
D–26
D–27
D–27
D–27
D–28
D–29
D–30
D–30
D–31
D–32
D–32
D–32
D–32
D–33
D–34
D–34
D–34
D–35
D–35
D–37
D–37
D–38
D–38
D–39
D–43
D–43
D–43
D–44
D–44
D–44
D–45
xix
D.8.7
D.9
D.9.1
D.9.2
Listing Domain Information .
Solving Bind Server Problems . .
Server Not Responding . . . .
Serial Number Mismatch . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D–45
D–47
D–48
D–48
Sample SERVER.PCY File . . . . . . . . . . . . . . . . . . . . . . . .
Sample DHCPCAP. File . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample NETS. File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NETS Entries with IP Ranges for Two Networks . . . . . .
Sample NETMASKS. File . . . . . . . . . . . . . . . . . . . . . . . .
Sample NAMEPOOL. File . . . . . . . . . . . . . . . . . . . . . . . .
NAMEPOOL Entries Showing the Use of a Name Prefix .
Sample Single-Host DHCPCAP File Entry . . . . . . . . . . .
Sample Single Host DHCPCAP Entry . . . . . . . . . . . . . .
Sample Subnet DHCPCAP Entry . . . . . . . . . . . . . . . . . .
Sample DHCPDBMOD Entry . . . . . . . . . . . . . . . . . . . . .
Client Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SHOWDHC Sample Output . . . . . . . . . . . . . . . . . . . . . . .
XDM_CONFIG.TEMPLATE File . . . . . . . . . . . . . . . . . . .
XACCESS.TXT File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XSERVERS.TXT File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XDM_KEYS.TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Path Name Options . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Boolean Options . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Forwarding Options . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Name Checking Options . . . . . . . . . . . . . . . . . .
BIND 8 - Access Control Options . . . . . . . . . . . . . . . . . . .
BIND 8 - Zone Transfer Options . . . . . . . . . . . . . . . . . . .
BIND 8 - Server Statement . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Server Statement . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Reading Database Files . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8–6
8–11
8–12
8–13
8–14
8–15
8–15
8–52
8–53
8–53
8–65
9–6
9–17
21–3
21–4
21–5
21–6
D–12
D–13
D–14
D–15
D–15
D–17
D–18
D–18
D–32
TCPIP$TELNETSYM_SUPPRESS_FORMFEED Level 2 Setting . . . .
TCPIP$TELNETSYM_SUPPRESS_FORMFEED Level 1 Setting . . . .
25–10
25–10
Index
Examples
8–1
8–2
8–3
8–4
8–5
8–6
8–7
8–8
8–9
8–10
8–11
9–1
9–2
21–1
21–2
21–3
21–4
D–1
D–2
D–3
D–4
D–5
D–6
D–7
D–8
D–9
Figures
25–1
25–2
xx
Tables
1
1–1
3–1
3–2
3–3
4–1
5–1
5–2
5–3
6–1
6–2
6–3
6–4
6–5
6–6
6–7
6–8
6–9
6–10
6–11
6–12
6–13
6–14
6–15
6–16
6–17
6–18
6–19
6–20
6–21
7–1
7–2
7–3
8–1
8–2
8–3
8–4
8–5
8–6
8–7
8–8
8–9
8–10
TCP/IP Services Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring PPP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set Up Tasks Required for an OpenVMS Alpha PPP Dialup Provider
or Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Qualifiers Used for Configuring SLIP . . . . . . . . . . . . . . . . .
GATED Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ifconfig Options for failSAFE IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
failSAFE IP Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . .
failSAFE IP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UCX BIND and BIND Version 9 Differences . . . . . . . . . . . . . . . . . . . .
Name Server Configuration File Elements . . . . . . . . . . . . . . . . . . . . . .
BIND Name Server Configuration Statements . . . . . . . . . . . . . . . . . . .
Key Statement Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logging Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND Server Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND Server Boolean Configuration Options . . . . . . . . . . . . . . . . . . . .
Forwarding Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Access Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Query Address Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zone Transfer Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Resource Limit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Periodic Task Intervals Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tuning Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Statement Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View Statement Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zone Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zone Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Resource Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid Cluster Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load Broker Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metric Server Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP IP Address Allocation Methods . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Executable Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Server Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Server Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Type Symbol and Number . . . . . . . . . . . . . . . . . . . . . . . . . . .
NetBIOS Node Type and Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP/DHCP Configuration File Symbols . . . . . . . . . . . . . . . . . . . . .
Vendor Specific Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Utility Commands Associated with Databases . . . . . . . . . . . . .
xxvi
1–1
3–3
3–4
3–10
4–2
5–3
5–3
5–5
6–11
6–12
6–14
6–18
6–21
6–23
6–25
6–29
6–29
6–30
6–31
6–32
6–34
6–34
6–37
6–39
6–39
6–41
6–44
6–45
6–54
7–7
7–9
7–9
8–3
8–5
8–5
8–16
8–17
8–39
8–47
8–54
8–61
8–63
xxi
8–11
8–12
9–1
9–2
9–3
9–4
9–5
10–1
10–2
11–1
11–2
13–1
13–2
13–3
13–4
13–5
13–6
13–7
13–8
14–1
14–2
14–3
14–4
14–5
14–6
14–7
15–1
16–1
17–1
17–2
18–1
18–2
18–3
18–4
18–5
19–1
19–2
19–3
20–1
21–1
22–1
22–2
22–3
22–4
23–1
24–1
xxii
DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW Command
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCPDBMOD Command Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported Request Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Client Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Client System Logicals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Signal Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP and TFTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . .
TFTP Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TFTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restrict Statement Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NTP Log File Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NTPDATE Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NTPTRACE Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NTPDC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Peer State Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NTPQ Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SNMP Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SNMP Executable, Command, and Data Files . . . . . . . . . . . . . . . . . .
SNMP Logging Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SNMP Operation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing and Timeout Handling Options . . . . . . . . . . . . . . . . . . . . . . .
Testing and Troubleshooting Options . . . . . . . . . . . . . . . . . . . . . . . . .
Backward-Compatibility Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TELNET Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RLOGIN Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RMT Magtape Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SMTP Client Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default SMTP Utility Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SMTP Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SMTP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antispam Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .
POP User Authorization Methods . . . . . . . . . . . . . . . . . . . . . . . . . . .
POP Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
POP Extension (XTND) Commands . . . . . . . . . . . . . . . . . . . . . . . . . .
IMAP Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XDM Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOUNT Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Container File System Components Analyzed . . . . . . . . . . . . . . . . . .
Modifying NFS Server Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . .
File System Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Required Fields for NFS Proxy Entries . . . . . . . . . . . . . . . . . . . . . . .
LPD Configuration Options and Descriptions . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8–64
8–66
9–6
9–9
9–11
9–11
9–16
10–5
10–5
11–2
11–2
13–13
13–17
13–20
13–22
13–23
13–28
13–31
13–33
14–2
14–5
14–11
14–12
14–14
14–18
14–19
15–2
16–4
17–3
17–5
18–2
18–6
18–8
18–12
18–17
19–3
19–9
19–16
20–3
21–7
22–9
22–16
22–17
22–18
23–7
24–2
24–2
24–3
A–1
A–2
A–3
A–4
A–5
B–1
C–1
C–2
D–1
D–2
D–3
D–4
D–5
D–6
D–7
D–8
D–9
D–10
D–11
D–12
D–13
D–14
D–15
LPRSETUP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Printcap Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GATED Configuration Statements . . . . . . . . . . . . . . . . . . . . . .
Default Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Global Significance Options . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Significance Options . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifications to Translation Tables . . . . . . . . . . . . . . . . . . . . .
NFS Server to OpenVMS Client File Name Conversion Rules .
NFS Client Name Conversion . . . . . . . . . . . . . . . . . . . . . . . . .
UCX BIND and BIND 8.1 Differences . . . . . . . . . . . . . . . . . . .
BIND 8 - Name Server Configuration Statements . . . . . . . . . .
BIND 8 - Path Name Options . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Boolean Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Forwarding Options . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Name Checking Options . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Access Control Options . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Zone Transfer Options . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Periodic Task Options . . . . . . . . . . . . . . . . . . . . . . . .
NSUPDATE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 8 - Standard Resource Record Types . . . . . . . . . . . . . . .
Starting and Stopping NSLOOKUP . . . . . . . . . . . . . . . . . . . . .
NSLOOKUP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options to the NSLOOKUP set Command . . . . . . . . . . . . . . .
Options to the NSLOOKUP ls Command . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24–6
24–8
A–2
A–5
A–7
A–7
A–7
B–3
C–1
C–2
D–4
D–5
D–11
D–12
D–14
D–14
D–15
D–16
D–17
D–22
D–26
D–37
D–39
D–40
D–46
xxiii
Preface
The HP TCP/IP Services for OpenVMS product is the HP implementation of the
TCP/IP networking protocol suite and internet services for OpenVMS Alpha and
OpenVMS VAX systems.
TCP/IP Services provides a comprehensive suite of functions and applications that
support industry-standard protocols for heterogeneous network communications
and resource sharing.
This manual provides system and network managers with information
needed for the day-to-day management of the TCP/IP Services
software product. This manual is best used in conjunction with the
HP TCP/IP Services for OpenVMS Management Command Reference manual.
See the HP TCP/IP Services for OpenVMS Installation and Configuration manual
for information about installing, configuring, and starting this product.
Intended Audience
This manual is for experienced OpenVMS and UNIX system managers and
assumes a working knowledge of OpenVMS system management, TCP/IP
networking, and TCP/IP terminology.
Document Structure
This manual contains seven parts, as follows:
Part 1
Describes how to configure network interfaces, how to set up serial lines, and
how to configure and manage routing.
Part 2
Describes how to set up and manage the BIND server, resolver, and load broker
components.
Part 3
Describes how to set up the following network services:
DHCP server
DHCP client
BOOTP and TFTP
Portmapper
Network Time Protocol (NTP)
SNMP
xxv
Part 4
Describes how to configure network applications that let users send and receive
electronic mail from the internet, establish login sessions with a remote host,
and transfer files. These network applications include:
TELNET
FTP
Remote (R) commands
SMTP and POP
XDM-compatible X displays
Part 5
Describes how to configure, use, and manage the components that enable
transparent network file sharing, including the NFS server and NFS client.
Part 6
Describes how to configure and manage network printing services, including
LPD/LPR, TELNETSYM, and PC-NFS.
Part 7
Provides appendixes that:
•
Explain how to configure GATED.
•
Provide EBCDIC/DMCS translation tables.
•
Describe how NFS converts UNIX file names to OpenVMS files names.
•
List the acronyms related to TCP/IP networking.
Related Documents
Table 1 lists the documents available with this version of TCP/IP Services.
Table 1 TCP/IP Services Documentation
Manual
Contents
Compaq TCP/IP Services for OpenVMS
Concepts and Planning
This manual provides conceptual information about TCP/IP
networking on OpenVMS systems, including general planning
issues to consider before configuring your system to use the
TCP/IP Services software.
This manual also describes the manuals in the TCP/IP Services
documentation set and provides a glossary of terms and
acronyms for the TCP/IP Services software product.
HP TCP/IP Services for OpenVMS
Release Notes
The release notes provide version-specific information that
supersedes the information in the documentation set. The
features, restrictions, and corrections in this version of the
software are described in the release notes. Always read the
release notes before installing the software.
HP TCP/IP Services for OpenVMS
Installation and Configuration
This manual explains how to install and configure the TCP/IP
Services product.
HP TCP/IP Services for OpenVMS
User’s Guide
This manual describes how to use the applications available with
TCP/IP Services such as remote file operations, email, TELNET,
TN3270, and network printing. This manual explains how to use
these services to communicate with systems on private internets
or on the worldwide Internet.
HP TCP/IP Services for OpenVMS
Management
This manual describes how to configure and manage the TCP/IP
Services product.
Use this manual with the HP TCP/IP Services for OpenVMS
Management Command Reference manual.
(continued on next page)
xxvi
Table 1 (Cont.) TCP/IP Services Documentation
Manual
Contents
HP TCP/IP Services for OpenVMS
Management Command Reference
This manual describes the TCP/IP Services management
commands.
Use this manual with the HP TCP/IP Services for OpenVMS
Management manual.
HP TCP/IP Services for OpenVMS
Management Command Quick
Reference Card
This reference card lists the TCP/IP management commands by
component and describes the purpose of each command.
HP TCP/IP Services for OpenVMS
UNIX Command Equivalents Reference
Card
This reference card contains information about commonly
performed network management tasks and their corresponding
TCP/IP management and Tru64 UNIX command formats.
Compaq TCP/IP Services for OpenVMS
ONC RPC Programming
This manual presents an overview of high-level programming
using open network computing remote procedure calls (ONC
RPC). This manual also describes the RPC programming
interface and how to use the RPCGEN protocol compiler to
create applications.
Compaq TCP/IP Services for OpenVMS
Sockets API and System Services
Programming
This manual describes how to use the Sockets API and OpenVMS
system services to develop network applications.
Compaq TCP/IP Services for OpenVMS
SNMP Programming and Reference
This manual describes the Simple Network Management Protocol
(SNMP) and the SNMP application programming interface
(eSNMP). It describes the subagents provided with TCP/IP
Services, utilities provided for managing subagents, and how to
build your own subagents.
HP TCP/IP Services for OpenVMS
Tuning and Troubleshooting
This manual provides information about how to isolate the
causes of network problems and how to tune the TCP/IP Services
software for the best performance.
HP TCP/IP Services for OpenVMS
Guide to SSH
This manual describes how to configure, set up, use, and manage
the SSH for OpenVMS software.
HP TCP/IP Services for OpenVMS
Guide to IPv6
This manual describes the IPv6 environment, the roles of
systems in this environment, the types and function of the
different IPv6 addresses, and how to configure TCP/IP Services
to access the 6bone network.
For additional information about HP OpenVMS products and services, visit the
following World Wide Web address:
http://www.hp.com/go/openvms
For a comprehensive overview of the TCP/IP protocol suite, you might find the
book Internetworking with TCP/IP: Principles, Protocols, and Architecture, by
Douglas Comer, useful.
Reader’s Comments
HP welcomes your comments on this manual. Please send comments to either of
the following addresses:
Internet
openvmsdoc@hp.com
xxvii
Postal Mail
Hewlett-Packard Company
OSSG Documentation Group, ZKO3-4/U08
110 Spit Brook Rd.
Nashua, NH 03062-2698
How to Order Additional Documentation
For information about how to order additional documentation, visit the following
World Wide Web address:
http://www.hp.com/go/openvms/doc/order
Conventions
The name TCP/IP Services means both:
•
HP TCP/IP Services for OpenVMS Alpha
•
HP TCP/IP Services for OpenVMS VAX
The name UNIX refers to the HP Tru64 UNIX operating system.
The following conventions are used in this manual. In addition, please note that
all IP addresses are fictitious.
Ctrl/x
A sequence such as Ctrl/x indicates that you must hold down
the key labeled Ctrl while you press another key or a pointing
device button.
PF1 x
A sequence such as PF1 x indicates that you must first press
and release the key labeled PF1 and then press and release
another key or a pointing device button.
Return
In examples, a key name enclosed in a box indicates that
you press a key on the keyboard. (In text, a key name is not
enclosed in a box.)
In the HTML version of this document, this convention appears
as brackets, rather than a box.
...
xxviii
A horizontal ellipsis in examples indicates one of the following
possibilities:
•
Additional optional arguments in a statement have been
omitted.
•
The preceding item or items can be repeated one or more
times.
•
Additional parameters, values, or other information can be
entered.
.
.
.
A vertical ellipsis indicates the omission of items from a code
example or command format; the items are omitted because
they are not important to the topic being discussed.
()
In command format descriptions, parentheses indicate that you
must enclose choices in parentheses if you specify more than
one.
[]
In command format descriptions, brackets indicate optional
choices. You can choose one or more items or no items.
Do not type the brackets on the command line. However,
you must include the brackets in the syntax for OpenVMS
directory specifications and for a substring specification in an
assignment statement.
|
In command format descriptions, vertical bars separate choices
within brackets or braces. Within brackets, the choices are
optional; within braces, at least one choice is required. Do not
type the vertical bars on the command line.
{}
In command format descriptions, braces indicate required
choices; you must choose at least one of the items listed. Do
not type the braces on the command line.
bold type
Bold type represents the introduction of a new term. It also
represents the name of an argument, an attribute, or a reason.
italic type
Italic type indicates important information, complete titles
of manuals, or variables. Variables include information that
varies in system output (Internal error number), in command
lines (/PRODUCER=name), and in command parameters in
text (where dd represents the predefined code for the device
type).
UPPERCASE TYPE
Uppercase type indicates a command, the name of a routine,
the name of a file, or the abbreviation for a system privilege.
Example
This typeface indicates code examples, command examples, and
interactive screen displays. In text, this type also identifies
URLs, UNIX commands and pathnames, PC-based commands
and folders, and certain elements of the C programming
language.
-
A hyphen at the end of a command format description,
command line, or code line indicates that the command or
statement continues on the following line.
numbers
All numbers in text are assumed to be decimal unless
otherwise noted. Nondecimal radixes—binary, octal, or
hexadecimal—are explicitly indicated.
xxix
Part 1
Connecting to the Network
Part 1 provides the information on how to get started after installing and
configuring the TCP/IP Services software.
Part 1 includes the following chapters:
•
Chapter 1, Managing TCP/IP Services, describes the management control
interfaces that allow you to configure and manage TCP/IP Services.
•
Chapter 2, Configuring Interfaces, describes how to set up network interfaces.
•
Chapter 3, Configuring and Managing Serial Lines, explains how to set up
serial lines.
•
Chapter 4, Configuring and Managing Routing, discusses how to configure
and manage network routing.
•
Chapter 5, Configuring and Managing failSAFE IP, describes how to set up
and manage the failSAFE IP service.
1
Managing TCP/IP Services
This chapter reviews information you need to get started with the TCP/IP
Services software. Topics include:
•
Reviewing pertinent databases, logical names, and configuration guidelines
(Section 1.1).
•
Enabling support for DECnet over TCP/IP, and PATHWORKS (Advanced
Server) (Section 1.2).
•
Creating user accounts and proxy identities (Section 1.3).
•
Configuring TCP/IP Services on an OpenVMS cluster (Section 1.4).
•
Starting services with the auxiliary server (Section 1.5).
1.1 Getting Started
This manual assumes you installed and configured TCP/IP Services software with
the configuration procedure SYS$MANAGER:TCPIP$CONFIG.COM, as described
in the HP TCP/IP Services for OpenVMS Installation and Configuration manual.
This menu-driven procedure configures the software components you select or all
of the TCP/IP Services software components. The ‘‘out-of-the-box’’ defaults are
designed to get your system up and running as an internet host with minimal
effort.
TCPIP$CONFIG creates the database files listed in Table 1–1.
Table 1–1 Configuration Databases
Database
File Name
BOOTP database
SYS$COMMON:[SYSEXE]TCPIP$BOOTP.DAT1
Configuration database
SYS$COMMON:[SYSEXE]TCPIP$CONFIGURATION.DAT
Export database
SYS$COMMON:[SYSEXE]TCPIP$EXPORT.DAT
Hosts database
SYS$COMMON:[SYSEXE]TCPIP$HOST.DAT
Networks database
SYS$COMMON:[SYSEXE]TCPIP$NETWORK.DAT
Proxy database
SYS$COMMON:[SYSEXE]TCPIP$PROXY.DAT
Routes database
SYS$COMMON:[SYSEXE]TCPIP$ROUTE.DAT
Services database
SYS$COMMON:[SYSEXE]TCPIP$SERVICE.DAT
1 If
the BOOTP service is configured.
Managing TCP/IP Services 1–1
Managing TCP/IP Services
1.1 Getting Started
1.1.1 Logical Names
Logical names allow you to customize or modify component behavior. Logical
names also point to directories, database files, and log files.
TCPIP$CONFIG defines the following logical names for the databases listed in
Table 1–1:
•
TCPIP$BOOTP (if the BOOTP service is configured)
•
TCPIP$CONFIGURATION
•
TCPIP$EXPORT
•
TCPIP$HOST
•
TCPIP$NETWORK
•
TCPIP$PROXY
•
TCPIP$ROUTE
•
TCPIP$SERVICE
See individual component chapters in this manual for information on how specific
components use logical names.
1.1.2 Modifying Your Configuration
After the initial configuration, you may want to reconfigure existing components
or configure new ones, disable and re-enable components, add hosts, reconfigure
routing, and so forth.
When making any configuration modifications, HP recommends that you run the
configuration procedure TCPIP$CONFIG again.
Note
You cannot use TCPIP$CONFIG to set up SLIP or PPP lines. See
Chapter 3 for more information.
In some instances, TCPIP$CONFIG only partially configures a component (for
example, when configuring a BIND name server). You may need to run additional
setup programs or enter management commands to complete the configuration
and fine-tune your environment.
Component-specific chapters in this manual describe additional configuration
tasks and explain how to configure and manage specific components. These tasks
may include:
•
Manually adding information, such as database records, that the
configuration procedure cannot handle
•
Temporarily enabling or disabling a service
•
Configuring customized applications
•
Tuning performance
•
Troubleshooting
1–2 Managing TCP/IP Services
Managing TCP/IP Services
1.1 Getting Started
1.1.3 Saving Changes
The configuration procedure TCPIP$CONFIG saves configuration and
initialization information in the file TCPIP$CONFIGURATION.DAT. You can
modify the configuration dynamically or permanently, as follows:
•
SET commands modify the software dynamically, as it is running. Changes
made in this manner are not saved permanently and are overwritten if they
differ from settings in the permanent configuration database.
•
SET CONFIGURATION commands modify the permanent database but do
not take effect until the next time the product starts up.
To make changes take effect immediately and modify permanent settings, enter
both the interactive SET and permanent SET CONFIGURATION commands.
The following commands permanently modify the configuration database:
•
SET CONFIGURATION [NO]BIND
•
SET CONFIGURATION COMMUNICATION
•
SET CONFIGURATION ENABLE [NO]SERVICE
•
SET CONFIGURATION [NO]INTERFACE
•
SET CONFIGURATION [NO]NAME_SERVICE
•
SET CONFIGURATION NOMAP
•
SET CONFIGURATION PROTOCOL
•
SET CONFIGURATION SMTP
•
SET CONFIGURATION SNMP
•
SET CONFIGURATION START ROUTING
Note
Throughout this manual, all commands are assumed to be TCP/IP
management commands. Any DCL commands that are mentioned are
identified as such.
For a full description of the TCP/IP management commands and a
discussion of how to use them, see the HP TCP/IP Services for OpenVMS
Management Command Reference manual.
1.1.4 Starting and Stopping the Software
To start TCP/IP Services manually, enter the following command:
$ @SYS$STARTUP:TCPIP$STARTUP
The startup procedure enables the configured services and initializes the
configured network interfaces.
To stop (shut down) the product manually, enter the following command:
$ @SYS$STARTUP:TCPIP$SHUTDOWN
The shutdown procedure does the following:
1. Stops network communication
2. Disables active services
Managing TCP/IP Services 1–3
Managing TCP/IP Services
1.1 Getting Started
3. Deletes the network interface definitions
4. Deassigns defined logical names
5. Deletes installed images
To start TCP/IP Services automatically, add the following command to the system
startup file:
$ @SYS$STARTUP:TCPIP$STARTUP.COM
To maintain site-specific startup and shutdown commands and settings, create
the following files:
•
SYS$STARTUP:TCPIP$SYSTARTUP.COM
•
SYS$STARTUP:TCPIP$SYSHUTDOWN.COM
The site-specific startup procedure is invoked after all the TCP/IP services have
been started. These files are not overwritten when you install a new version of
TCP/IP Services.
HP recommends that you use the TCPIP$CONFIG configuration procedure to
stop and start services. However, startup and shutdown files are provided for
individual services, allowing you to stop and start individual components without
impacting the operation of the remaining TCP/IP Services software.
This feature allows you to modify a service configuration without restarting the
TCP/IP Services product. For example, you can shut down the LPD service,
change its configuration parameters, and then restart it, without interrupting the
other TCP/IP services that are running on the system.
Each service is provided with its own startup and shutdown command procedures,
as follows:
•
SYS$STARTUP:TCPIP$service_STARTUP.COM, a supplied command
procedure that ensures the environment is configured appropriately and
starts up the component specified by service.
•
SYS$STARTUP:TCPIP$service_SHUTDOWN.COM, a supplied command
procedure that shuts down a specific service component without affecting the
other services that are running.
To preserve site-specific parameter settings and commands for a specific service,
create the following files, specifying the service or component name for service.
These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$service_SYSTARTUP.COM can be used to store
site-specific startup commands.
This procedure is invoked by the appropriate service-specific startup
procedure prior to running the service. Use the *_SYSTARTUP procedure to
modify the behavior of the service each time the service or TCP/IP Services
is restarted. For example, to enable debugging mode for DHCP, define
the logical TCPIP$DHCP_DEBUG in the SYS$STARTUP:TCPIP$DHCP_
SYSTARTUP.COM file. When DHCP next starts, it will run in debug mode.
•
SYS$STARTUP:TCPIP$service_SYSHUTDOWN.COM can be used to store
site-specific shutdown commands.
Service-specific startup and shutdown procedures, as well as configuration
parameters, are described in the later chapters of this manual.
1–4 Managing TCP/IP Services
Managing TCP/IP Services
1.1 Getting Started
1.1.5 Editing Configuration Files
Several facilities can be managed using configuration options in a facility-specific
configuration file. The following facilities support configuration files:
•
LPD/LPR
•
SMTP
•
IMAP
A configuration file is an ASCII text file consisting of one or more lines formatted
as follows:
Field1: Value1
Field2: Value2
.
.
.
In this format:
•
Field names start in column 1, are terminated with a colon (:), and are not
case sensitive.
•
Values vary depending on the field.
If a value consists of a list of items, specify them on multiple lines by
pressing the Tab key before continuing the value on the subsequent lines. For
example:
Field1: Item1,
Tab Item2,
Tab Item3
Field2: Value2
Or specify each value as a separate instance of the same field. For example:
Field1: Item1
Field1: Item2
Field1: Item3
An alternative format is:
Field1: Item1, Item2, Item3
The maximum number of characters in a value is 500. Unless otherwise
noted, a field’s value is not case sensitive.
Fields described as Boolean have the following legal values:
To turn the feature on
To turn the feature off
ON
OFF
TRUE
FALSE
1
0
YES
NO
To comment out a line, type an exclamation point (!) in column 1.
Managing TCP/IP Services 1–5
Managing TCP/IP Services
1.2 Enabling PATHWORKS/Advanced Server and DECnet-over-TCP/IP Support
1.2 Enabling PATHWORKS/Advanced Server and
DECnet-over-TCP/IP Support
TCP/IP Services software includes the PATHWORKS Internet Protocol (PWIP)
driver and the PWIP ancillary control process (PWIP_ACP).
The PWIP driver allows OpenVMS systems that are running both the
HP PATHWORKS/Advanced Server and the TCP/IP Services software to
communicate with personal computers running PATHWORKS client software.
It also enables the DECnet-over-TCP/IP feature, which is included with the
DECnet-Plus for OpenVMS Version 6.0 and later software. For more information
about DECnet over TCP/IP, see the DECnet-Plus for OpenVMS documentation.
1.2.1 Starting and Stopping the PWIP Driver
The PWIP driver can be shut down and started independently. The following files
are provided:
•
SYS$STARTUP:TCPIP$PWIP_DRIVER_STARTUP.COM allows you to start
up the PWIP driver.
•
SYS$STARTUP:TCPIP$PWIP_DRIVER_SHUTDOWN.COM allows you to
shut down the PWIP driver.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services.
•
SYS$STARTUP:TCPIP$PWIP_DRIVER_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
PWIP driver is started.
•
SYS$STARTUP:TCPIP$PWIP_DRIVER_SYSHUTDOWN.COM can be used
as a repository for site-specific definitions and parameters to be invoked when
the PWIP driver is shut down.
To start the PWIP driver, run TCPIP$CONFIG or enter the following command:
$ @SYS$STARTUP:TCPIP$PWIP_DRIVER_STARTUP.COM
To shut down the connection to the PWIP driver, enter the following command:
$ @SYS$STARTUP:TCPIP$PWIP_DRIVER_SHUTDOWN.COM
1.3 Setting Up User Accounts and Proxy Identities
You will need to set up accounts for local users, coordinate the establishment of
corresponding accounts on remote systems, and create accounts for remote users
who will be accessing server components on the local host.
When creating accounts for remote users, you can create one account for all
remote users, an account for groups of remote users, or accounts for individual
users. The strategy you use depends on your organization, system resources, and
security needs.
Certain product components (for example, LPD, RSH, RLOGIN, and NFS) act as
servers for remote clients. You control access to your system and to these services
by giving remote users proxy identities. A proxy identity maps a user account on
one host to an account on another host. The information you provide with each
entry, along with the privileges you set for the account, lets you specifically grant
or deny access to your system.
1–6 Managing TCP/IP Services
Managing TCP/IP Services
1.3 Setting Up User Accounts and Proxy Identities
The configuration procedure TCPIP$CONFIG creates a proxy database file
called TCPIP$PROXY. You add proxies to this database with the ADD PROXY
command. The TCP/IP Services product allows the following two types of proxies:
•
Communication proxy
A communication proxy provides an identity for remote users of RSH,
RLOGIN, RMT/RCD, and LPD. For each host, be sure to define the host
name and any aliases. Proxy entries are case sensitive. Be sure to use the
appropriate case when adding entries for remote users. Enter the ADD
PROXY command as follows:
TCPIP> ADD PROXY user /HOST=host /REMOTE_USER=user
You can use wildcards when adding proxy entries for users on remote
systems. For example, the following command provides the identity STAFF to
any user on the remote host STAR:
TCPIP> ADD PROXY STAFF /HOST=STAR /REMOTE_USER=*
•
NFS proxy
NFS proxies provide identities for users of NFS client, NFS server, and
PC-NFS. In addition to host and user information, NFS proxies provide UNIX
identities with UID/GID pairs. NFS proxies can specify access to the NFS
client or the NFS server, or both.
For example, the following command provides the OpenVMS identity
CHESTER for a local NFS client user with the UID/GID pair 23/34.
TCPIP> ADD PROXY CHESTER /NFS=OUTGOING /UID=23 /GID=34 /HOST="orbit"
This user can access remote files from the NFS server orbit.
See the HP TCP/IP Services for OpenVMS Management Command Reference
manual for a complete description of the ADD PROXY command. For a more
complete discussion about UNIX style identities and how the NFS server and
client use the proxy database, see Chapter 22.
1.4 Configuring a TCP/IP Cluster
If your host is part of an OpenVMS Cluster, you can use a cluster alias to
represent the entire cluster or selected host members. In this case, the network
sees the cluster as a single system with one name. Alternatively, you can
configure clustering using a DNS alias, as described in Appendix D.
Incoming requests are switched among the cluster hosts at the end of each cluster
time interval (specified with the SET COMMUNICATION command).
Note
The cluster name is not switched from a host if there are any active TCP
connections to the cluster interface on that host.
A remote host can use the cluster alias to address the cluster as a single host or
the host name of the cluster member to address a cluster member individually.
All of the TCP/IP services support automatic failover and can be run on multiple
nodes in an OpenVMS Cluster. For example, if more than one host in the cluster
is running the NFS server, the cluster can appear to the NFS client as a single
Managing TCP/IP Services 1–7
Managing TCP/IP Services
1.4 Configuring a TCP/IP Cluster
host. For more information about configuring a specific service for cluster failover,
refer to the chapter in this manual that discusses the particular service.
1.4.1 Setting Up an ARP-Based Cluster
HP strongly recommends using the configuration procedure TCPIP$CONFIG
to configure a TCP/IP cluster. If you cannot run TCPIP$CONFIG, configure a
TCP/IP cluster by completing the following steps:
1. Create the interfaces for all cluster members.
2. Interactively specify an ARP-based cluster alias (for example, ALLOFUS).
Enter:
TCPIP> SET INTERFACE QE0 /CLUSTER=ALLOFUS /C_NETWORK=255.255.0.0 _TCPIP> /C_BROADCAST=128.44.55.0
3. Make these settings permanent in the configuration database. Enter:
TCPIP> SET CONFIGURATION INTERFACE QE0 /CLUSTER=ALLOFUS _TCPIP> /C_NETWORK=255.255.0.0 /C_BROADCAST=128.44.55.0
The interface changes take effect the next time the product starts up.
4. Add the cluster host name or the cluster IP address to the database of
the host. Enter the same information you use with the SET INTERFACE
command.
5. Change the interface parameters (specified with the SET INTERFACE
command) only after deleting and re-creating an interface.
1.5 Auxiliary Server
The auxiliary server is the TCP/IP Services implementation of the UNIX internet
daemon (inetd). In addition to standard inetd functions, the auxiliary server
provides access control and event logging.
The auxiliary server listens continuously for incoming requests and acts as a
master server for programs specified in its configuration file. The auxiliary server
reduces the load on the system by invoking services only as they are needed.
1.5.1 How the Auxiliary Server Works
The auxiliary server listens for connections on the internet addresses of the
services that its configuration file (TCPIP$SERVICES.DAT) specifies. When a
connection is found, it invokes the server daemon for the service requested. Once
a server is finished, the auxiliary server continues to listen on the socket.
When it receives a request, the auxiliary server dynamically creates a network
process, obtaining user account information from one or all of the following
sources:
•
TCP/IP Services proxy account
•
Services database
•
Remote client
•
Local OpenVMS user authorization file (UAF)
In addition, users requesting services at the client can include their user account
information as part of the command line.
1–8 Managing TCP/IP Services
Managing TCP/IP Services
1.5 Auxiliary Server
Once a process is created, the auxiliary server starts the requested service. All
services except RLOGIN and TELNET must have access to their default device
and directories and to the command procedures within them.
1.5.1.1 Rejecting Client Requests
The auxiliary server rejects client requests for the following reasons:
•
The maximum number of simultaneous processes for the requested service
has been reached.
•
The request is from a host that is marked for rejection.
•
There is a problem with the target account or directory.
1.5.1.2 Configuring the Auxiliary Server
The postinstallation configuration procedure, TCPIP$CONFIG, creates an entry
in the services database (TCPIP$SERVICE.DAT) for each service you configure.
If you need to modify your initial configuration, run TCPIP$CONFIG or use the
SET SERVICE command.
The configuration file TCPIP$SERVICE.DAT includes information about the
service name, the socket and protocol type associated with the service, the user
name under which the service should run, and any special options for the service
program.
Before you activate a service manually, configure the auxiliary server as follows:
1. Use the OpenVMS Authorize utility to create a restricted user account for the
process. Use the following qualifiers when creating the account:
•
/NOINTERACTIVE
•
/NOBATCH
•
/NOREMOTE
•
/FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE)
For more information about creating restricted accounts, see the OpenVMS
system security documentation.
2. Provide user account information that can be used when the network process
is created. Plan your requirements carefully before setting privileges, quotas,
and priorities to user accounts.
3. Provide the network process name.
The auxiliary server builds the network process name from the character
string in the services database. Enter this string with the SET SERVICE
command:
TCPIP> SET SERVICE service /PROCESS_NAME=process
Note
For TELNET and RLOGIN, the process name is set by either the system
or users.
Managing TCP/IP Services 1–9
Managing TCP/IP Services
1.5 Auxiliary Server
4. Set the maximum number of server processes that can run simultaneously.
This number should not exceed the maximum number of sockets allowed on
the system. To set the maximum number of processes that can connect to a
service at the same time, enter the following TCP/IP management command:
TCPIP> SET SERVICE service-name /LIMIT=n
In this command, service-name is the name of the service to which the
connections will be limited, and n is the number of connections that will
be accepted by the service at one time.
To activate the change, disable the service using the DISABLE SERVICE
command, and then enable it using the ENABLE SERVICE command.
5. Make sure that the protections in the systemwide SYLOGIN.COM file are set
appropriately. If they are not, enter the following DCL command:
$ SET PROTECTION=(W:RE) SYS$MANAGER:SYLOGIN.COM
6. To ensure that the services database has an entry for each service offered,
enter the SHOW SERVICE command.
1.6 Enabling Services
The services you configured are enabled during the TCP/IP Services startup
procedure. Afterwards, to initialize (enable) a service, enter the following
command:
TCPIP> ENABLE SERVICE
The ENABLE SERVICE command immediately changes the running system. The
SET CONFIGURATION ENABLE SERVICE command causes the services to be
enabled the next time TCP/IP Services starts up.
To specify the type of socket, include the /PROTOCOL qualifier on the SET
SERVICE command line. For example, to specify stream sockets, enter
/PROTOCOL=TCP. To specify datagram sockets, enter /PROTOCOL=UDP.
The auxiliary server can set socket options for a requested service either before
or during data communications. Some available options are:
•
KEEPALIVE (for TCP communications)
•
BROADCAST (for UDP communications)
To set the socket options, include the /SOCKET_OPTIONS qualifier on the SET
SERVICE command.
1.6.1 Setting Up Event Logging
Event logging can help you manage the software. By default, user-defined
services do not log events, but you can enable event logging for all or selected
configured services. You can configure the product to log events to the operator’s
console, a log file, or both. To set up event logging, enter the following command:
TCPIP> SET SERVICE service-name /LOG_OPTIONS=ALL
For a list of all the logging options, see the SET SERVICE command description
in the HP TCP/IP Services for OpenVMS Management Command Reference
manual.
Some product components provide additional event logging capabilities. See
individual component chapters for more information.
1–10 Managing TCP/IP Services
2
Configuring Interfaces
OpenVMS systems running TCP/IP Services communicate with other internet
hosts over a variety of physical media. Because TCP/IP is independent of the
underlying physical network, IP addresses are implemented in the network
software, not the network hardware. (See the HP TCP/IP Services for OpenVMS
Software Product Description for a complete list of supported media.)
This chapter reviews key concepts and describes:
•
How to configure network controllers (Section 2.2)
•
How to configure network interfaces (Section 2.3)
2.1 Key Concepts
A network controller is the hardware connection between a computer system
and a physical network. Controllers perform the packet channeling to and from
the physical medium of your network, usually a cable.
The network interface is a logical network controller — a software component
that communicates with your network software and the network controller.
For each interface, you can enable or disable the interface, set the subnet mask,
and assign IP and broadcast addresses.
2.2 Configuring Network Controllers
TCP/IP Services automatically recognizes network controllers at startup. If
you need to change the configuration (remove, modify, or add new network
controllers to your system) after installing and configuring the product, follow the
installation and configuration instructions that come with your hardware; then
run TCPIP$CONFIG again. The TCP/IP Services software recognizes the new
controller immediately, and creates new interfaces the next time the software
starts up.
Note
Hardware installation and configuration instructions are specific for the
various network controllers. Be sure to read the instructions provided
with your new hardware before installing.
Configuring Interfaces 2–1
Configuring Interfaces
2.3 Configuring Network Interfaces
2.3 Configuring Network Interfaces
The TCP/IP Services product supports one local software interface for loopbacks
and one or more physical network interfaces for each physical network controller.
The configuration procedure initially configures your network interfaces. Use the
following commands if you need to redefine an interface or configure serial lines.
See Chapter 3 for more information about configuring serial lines.
•
SET INTERFACE
•
SET NOINTERFACE
•
SET CONFIGURATION INTERFACE
•
SET CONFIGURATION NOINTERFACE
To display information, use the SHOW INTERFACE command; to disable an
interface, use the SET NOINTERFACE command.
Note
If you are redefining an existing interface, enter the SET NOINTERFACE
command before you enter the SET INTERFACE command.
2.3.1 Specifying the Interface
Interface names include the following information:
•
One letter indicating the interface type
Interface types indicate the type of controller. The following table shows the
letters you can use to indicate each type of controller:
For this
controller
•
Use this interface type
ATM
I, L
Ethernet
B, C, D, F, I, N, O, Q, R, S, W, X, Z
FDDI
A, C, F, Q, R, W
Token Ring
C, R
PPP/SLIP
S
Local (loopback)
L
One letter indicating the interface class
For this
controller
Use this interface class
ATM
F
Ethernet
E
FDDI
F
Token Ring
T
PPP
P
Serial
L
2–2 Configuring Interfaces
Configuring Interfaces
2.3 Configuring Network Interfaces
•
For this
controller
Use this interface class
X25
X
Local (loopback)
O
An integer indicating the controller number. Controller numbers are decimal
numbers in the range of 0 through 25, corresponding to OpenVMS hardware
controller letters A through Z. The default is 0.
Primary interfaces for Ethernet controllers have names in the range SE, SE0,
SE1, SE2, . . . SE24, SE25.
Interfaces for PPP controllers have names in the range PP, PP0, PP1, . . . PP998,
PP999.
Interfaces for local (loopback) controllers have names in the range LO, LO0,
LO1, . . . L08, L09
Note
OpenVMS network devices are always template devices and are
enumerated as FWA0, FWB0, FWC0, . . . FWY0, FWZ0.
If the system has multiple interfaces, you can configure failSAFE IP to provide
automatic failover from one interface to the next. This is useful if an interface
goes offline or fails. For more information, see Chapter 5.
2.3.2 Specifying the Network Mask
An IP address consists of a network number and a host number. The network
mask is the part of the host field of the IP address the identifies the network.
Every host on the same network must have the same network mask. To specify
the network mask, use the /NETWORK_MASK qualifier.
TCP/IP Services calculates the default by setting:
•
The bits representing the network fields to 1
•
The bits representing the host field to 0
You can also divide the host field into a site-specific network and host field.
2.3.3 Specifying Additional IP Addresses
To establish an additional IP address for an interface, define a network alias.
This can be useful when changing network numbers and you want to continue
to accept packets addressed to the old interface, or for setting up a host with a
single interface to act as a router between subnets. Network aliases can be added
in two functionally identical ways:
•
Associate multiple addresses to an existing interface.
You can use the ifconfig utility to associate multiple addresses with an
existing interface. There is no limit to the number of aliases that can be
created, and ranges of network addresses can be easily created. You should
include the ifconfig command in SYS$STARTUP:TCPIP$SYSTARTUP.COM
to ensure the network aliases are re-created whenever TCP/IP Services is
restarted.
Configuring Interfaces 2–3
Configuring Interfaces
2.3 Configuring Network Interfaces
For example, assume interface WF0 exists with a network address of
10.10.1.100 and a 24-bit subnet mask. To add an alias with an address
of 10.10.2.100 with a 24-bit subnet mask, follow these steps:
1. Define foreign commands:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
2. Display the current interfaces. Use quotation marks to preserve case. For
example:
$ netstat -n "-I" wf0
Name Mtu Network
WF0 4470 <Link>
WF0 4470 10.10.1
Address
0:0:f8:bd:bc:22
10.10.1.100
Ipkts Ierrs
Opkts Oerrs Coll
3049700
0 2976912 0
0
3049700
0 2976912 0
0
3. Add the network alias:
$ ifconfig wf0 alias 10.10.2.100/24
4. Display the current interfaces. For example:
$ netstat -n "-I" wf0
Name Mtu Network
WF0 4470 <Link>
WF0 4470 10.10.1
WF0 4470 10.10.2
Address
0:0:f8:bd:bc:22
10.10.1.100
10.10.2.100
Ipkts Ierrs
Opkts Oerrs Coll
3049700
0 2976912 0
0
3049700
0 2976912 0
0
3049700
0 2976912 0
0
A range of network addresses can be associated with an interface by using
the aliaslist parameter to the ifconfig command. For more information,
enter the following command:
TCPIP> HELP IFCONFIG PARAMETERS
•
Configure a pseudo-interface.
A pseudo-interface can be created to associate another network address with
the same physical interface also. Use the SET INTERFACE TCP/IP Services
management command to create a pseudo-interface. See Section 4.4.3 for
more information.
2–4 Configuring Interfaces
3
Configuring and Managing Serial Lines
A serial connection is made between two systems using modems and telephone
lines or other serial lines. TCP/IP Services supports serial connections using the
PPP (Point-to-Point Protocol) and SLIP (Serial Line IP) protocols. SLIP includes
CSLIP (compressed SLIP). You can use any standard OpenVMS terminal device
as a PPP or SLIP line. (PPP is available for OpenVMS Alpha systems only.)
This chapter reviews key concepts and describes:
•
How to set up a PPP interface (Section 3.2)
•
How to set up a SLIP interface (Section 3.3)
•
How to solve serial line problems (Section 3.4)
3.1 Key Concepts
If your OpenVMS system is part of a large network, you will probably use both
PPP and SLIP for your serial connections. As an Internet standard, PPP is often
preferred because it ensures interoperability between systems from a wide variety
of vendors. PPP provides a way for your OpenVMS Alpha system to establish a
dynamic IP network connection over a serial line without an additional router or
additional server hardware.
SLIP has been in use for a longer period of time and is available for most
terminal servers and in most PC implementations of TCP/IP. Because SLIP and
PPP do not communicate with each other, hosts wanting to communicate must
use the same protocol. For example, if your terminal server supports only SLIP,
remote hosts that connect through this server must also use SLIP.
3.1.1 PPP and SLIP
One of the largest applications for IP over serial lines is dialup access. With
this type of configuration, the OpenVMS host answers calls and establishes a
connection initiated by a user on a client host. The client host can be another
OpenVMS system, a UNIX system, or a PC. Or users on the host can originate
the dialup connection to a remote host or terminal server running the same
protocol.
Dedicated serial lines running PPP or SLIP can also be used to connect separate
LANs into a single WAN. In such a configuration, the host at each end of the
serial connection is always the same; no other hosts are allowed to connect to
either serial device.
Configuring and Managing Serial Lines 3–1
Configuring and Managing Serial Lines
3.1 Key Concepts
3.1.2 Assigning an IP Address to Your PPP or SLIP Interface
Every network interface must have its own unique IP address. Interfaces cannot
share IP addresses.
If you configure PPP interfaces for multiple remote hosts, the remote hosts can
obtain their individual IP addresses from your host when they connect. Similarly,
you can configure a PPP interface on your system without knowing your own IP
address and obtain it when you connect to a remote system.
Before establishing SLIP communication with a remote host, however, you must
obtain the IP address for the host’s serial interface and assign IP addresses for
each interface you configure on the local host.
When using SLIP, consider placing each serial line in a separate subnetwork. You
accomplish this by assigning the same subnet mask for the interfaces at either
end of the link.
If you need to use an address in the same subnetwork as your site LAN, use the
proxy Address Resolution Protocol (ARP) feature (see Section 3.3.4).
3.1.3 Serial Line Internet Protocol
SLIP sends a datagram across the serial line as a series of bytes. It uses the
following characters to determine when a series of bytes should be grouped
together:
Character
Function
Hex Value
Decimal Values
END
Marks the end of the datagram.
When the receiving SLIP
encounters the END character,
it knows that it has a complete
datagram.
C0
192
ESC
Indicates the end of the SLIP
control characters.
DB
219
The SLIP starts by sending an END character. If END is encountered within
the datagram as data, the SLIP inserts an escape character, sending the twocharacter sequence DB DC instead. If the ESC character appears within the
datagram as data, it is replaced with the two-character sequence DB DD. The
datagram ends with the END character after the last byte in the packet is
transmitted.
There is neither a standard SLIP specification nor a defined maximum packet
size for the SLIP. The TCP/IP Services implementation of SLIP accepts 1006-byte
datagrams and does not send more than 1006 bytes in a datagram.
Compressed SLIP provides header compression that is beneficial for small packets
and low-speed serial links. Header compression improves packet throughput. You
can enable the CSLIP by means of the /COMPRESS qualifier when you enter a
SET INTERFACE command. See Table 3–3 for more information.
3–2 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.1 Key Concepts
3.1.4 Point-to-Point Protocol
PPP uses a frame format that includes a protocol field. The protocol field
identifies the protocol (for example, IP, DECnet, or OSI) to be used for
communication between the two hosts. The PPP defines the network frame
in a 5-byte header and 3-byte trailer. A PPP frame starts and ends with the
control byte 7E hex (126 decimal). The address and control bytes are constant.
The 2-byte protocol field indicates the contents of the PPP frame.
3.2 Setting Up a PPP Interface (Alpha Only)
Use the following commands to configure a PPP interface on an OpenVMS Alpha
system:
•
SET INTERFACE PPn, where n is the number of the interface, takes effect
immediately and stays in effect until the next TCP/IP Services shutdown.
•
SET CONFIGURATION INTERFACE PPn, where n is the number of the
interface, makes the change part of the permanent configuration and takes
effect at the next TCP/IP Services startup.
Note
Specifying PP without the interface number is equivalent to specifying
PP0.
If you enter a SHOW INTERFACE command, the address does not appear
until a PPP connection is actually established.
Table 3–1 shows the command qualifiers used for configuring PPP interfaces.
Table 3–1 Configuring PPP Interfaces
Qualifier
Description
/COMPRESS=[ON | OFF | AUTOMATIC]
Optional. The default is ON. Use to negotiate header
compression.
/DESTINATION=[host_name | IP_address]
Optional. The default is no destination host. If you do
not specify the client host’s address, the PPP obtains
the correct address from the client host.
If the host is used as a dialup provider, use this
command to specify a unique IP address for a client.
In this case, you must also specify your host address
with the /HOST qualifier.
/HOST=[host_name | IP_address]
Required when setting up a host as a dialup provider;
otherwise optional. Host name or IP address using
the interface. If your host is multihomed, specify the
unique IP address if the two IP addresses map to the
same host name.
/NETWORK_MASK=IP_address
Optional. The subnet mask of the local PPP interface
in dotted-decimal notation.
/SERIAL_DEVICE=device
Required for hard-wired or dedicated modem
connections. Identifies the OpenVMS device name
assigned to the PPP interface, for example, TTA1.
Configuring and Managing Serial Lines 3–3
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
3.2.1 Setting Up Your Host for PPP Connections
In the client/server model for PPP connections, a host can function as a server, or
dialup provider, to respond to incoming PPP connection requests. A host can
also function as a client dialing in to a dialup provider.
•
A PPP dialup provider answers modem calls from PPP clients, assigns IP
addresses, and establishes PPP connections initiated by client hosts.
Typically, a PPP dialup provider is permanently connected to the network
through an interface such as Ethernet. The dialup provider services PPP
clients that initiate temporary, dialup connections because they do not have
permanent connections.
•
A PPP client establishes a temporary PPP connection to a dialup provider or
a terminal server.
Note
For information about establishing a PPP client connection from a UNIX
system, refer to the UNIX documentation. For a connection from a
PC, refer to the PC’s dialup networking instructions. You will need to
configure your modem correctly as outlined in the Section 3.2.1.2.
Setting up an OpenVMS Alpha host as a PPP dialup provider or client involves
a series of tasks. These tasks are listed in Table 3–2 in the order you should
complete them, and are explained in Sections 3.2.1.1 through 3.2.1.6.
Table 3–2 Set Up Tasks Required for an OpenVMS Alpha PPP Dialup Provider
or Client
OpenVMS
Dialup Provider
OpenVMS
Client
Step
Task
1
Install the correct terminal driver.
Yes
Yes
2
Configure your modem.
Yes
Yes
3
Set up an asynchronous port for modem
connections.
Yes
Yes
4
Configure an interface for a serial PPP
connection.
Yes
Optional
5
Enable IP forwarding and dynamic routing, as
appropriate.
Yes
No
6
Initiate a PPP connection. NETMBX and OPER
privileges required.
No
Yes
3.2.1.1 Installing the Terminal Driver
Confirm that the
virtual terminal driver SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE is
installed on your host. If it is not installed, run the System Management utility
(SYSMAN), connect the device, and load the driver, as shown in the following
example:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> IO CONNECT VTA0 /NOADAPTER /DRIVER=SYS$TTDRIVER
SYSMAN> EXIT
3–4 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
After you run SYSMAN, confirm that the VTA0 device was created. For more
information about SYSMAN and its parameters, see the HP OpenVMS System
Management Utilities Reference Manual: M-Z.
For OpenVMS Alpha Version 7.1, you must also install the ASNDRIVER remedial
kit to prevent the system from crashing. To obtain the driver and associated
corrections, access a remedial kit and accompanying cover letter from:
http://ftp.service.digital.com/public/vms/axp/v7.1/alppppd01_071.A-DCX_AXPEXE
http://ftp.service.digital.com/public/vms/axp/v7.1/alppppd01_071.CVRLET_TXT
3.2.1.2 Configuring the Modem
To configure the modem, follow these steps:
1. Make sure the serial port and modem cable support modem control signals.
(HP’s BC22F cable is an example of such a cable.)
2. Determine whether there are any baud rate restrictions associated with your
phone line or on your connecting cable (when using a null modem or modem
eliminator).
3. Adjust the settings on your modem to enable AT commands, as appropriate
for your modem. Some modems require you to set DIP switches, while others
require you to specify software settings.
Sample DIP switch configuration settings for U.S. Robotics Courier modems
are as follows. Note the following designations in these samples:
X = setting on (although different settings might work)
X** = setting on (required)
Dialup provider settings:
DTR normal
Verbal result codes
Suppress result codes
Echo offline commands
Auto answer on ring
Normal carrier detect
Display all results codes
Disable AT command set
Disconnect with +++
Load NVRAM defaults
X**
X
X**
X
X**
X**
X
X
DTR always on
Numeric results codes
Display result codes
No echo offline commands
Suppress auto answer
Carrier detect override
Result codes orig. mode only
Enable AT command set
X
No disconnect with +++
X
Load &FO settings
Client settings (defaults):
DTR normal
Verbal result codes
Suppress result codes
Echo offline commands
Auto answer on ring
Normal carrier detect
Display all results codes
Disable AT command set
Disconnect with +++
Load NVRAM defaults
X
X
X
X
X
X
X
DTR always on
Numeric results codes
Display result codes
X
No echo offline commands
Suppress auto answer
X
Carrier detect override
Result codes orig. mode only
Enable AT command set
X**
No disconnect with +++
Load &FO settings
4. If possible, also configure the modem so that it does not assert the Data
Terminal Ready (DTR) signal until it asserts the Carrier Detect (CD) signal.
This configuration ensures that the terminal driver does not drop the DTR
signal prematurely.
Configuring and Managing Serial Lines 3–5
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
3.2.1.3 Setting Up an Asynchronous Port
Use the DCL command SET TERMINAL and applicable qualifiers to set up an
asynchronous port for use with the modem.
•
Setting up the PPP dialup provider
Enter the SET TERMINAL command and qualifiers appropriate for your
modem connection. (Note that some qualifiers require LOG_IO or PHY_IO
privilege, or both.) For example:
$ SET TERMINAL TTA0: /ALTYPEAHD /AUTOBAUD /DIALUP /DISCONNECT /EIGHTBIT _$ /MODEM /NOHANGUP /NOHOSTSYNC /NOPASTHRU /NOREADSYNCH /NOTTSYNCH _$ /PERMANENT /TYPE_AHEAD
Where:
/ALTYPEAHD
Creates a permanent, alternate type-ahead buffer. (The system
parameter TTY_ALTYPADH determines the size of the typeahead buffer.) Helpful when transferring larger files. This
qualifier is required.
/AUTOBAUD
Detects the incoming baud rate.
/DIALUP
Specifies that the terminal is a dialup terminal. This qualifier is
required.
/DISCONNECT
Ensures that the process is disconnected if the line detects a
hangup.
/EIGHTBIT
Sets the terminal to use the 8-bit ASCII format. This qualifier is
required.
/MODEM
Specifies the use of a modem. This qualifier is required.
/NOHANGUP
Does not hang up the modem when the client logs off. This is the
default. This qualifier is required.
/NOHOSTSYNC
Does not allow the use of Ctrl/S or Ctrl/Q functions from the
terminal to stop or resume transmission when the input buffer is
full or empty. This is the default.
/PASTHRU
The terminal passes format-type data, such as carriage returns
and tabs, to an application program as binary data. This is the
default.
/NOREADSYNCH
Does not allow the use of Ctrl/S or Ctrl/Q functions to
synchronize data transmitted from the terminal. This is the
default.
/NOTTSYNCH
Does not allow transmission to be stopped or resumed by entering
Ctrl/S or Ctrl/Q, respectively.
/PERMANENT
Saves the settings.
/TYPE_AHEAD
Enables remote modems. Must be set. The terminal accepts
unsolicited input to the limit of the type-ahead buffer. This is the
default.
For detailed information about these and other SET TERMINAL qualifiers,
see the HP OpenVMS DCL Dictionary: N-Z.
•
Setting up the PPP client (OpenVMS Alpha only)
Enter the SET TERMINAL command and qualifiers appropriate for
your connection, as listed for the dialup provider, with the exception of
/AUTOBAUD.
Set the baud rates using the /SPEED=(input-rate,output-rate) qualifier. If the
rates are the same, specify /SPEED=rate (for example, /SPEED=9600).
3–6 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
3.2.1.4 Configuring a PPP Interface
•
Configuring the PPP dialup provider
Use the SET INTERFACE command and qualifiers to configure the interface
for a serial PPP connection and assign a host name, IP address, network
mask, and IP address for the client host, as applicable:
TCPIP> SET INTERFACE PPn /SERIAL_DEVICE=TTn: /HOST=IP_address _TCPIP> /NETWORK_MASK=IP_address /DESTINATION=IP_address /COMPRESS=AUTO
In this command:
•
–
n is the controller name and unit number.
–
The /HOST address is the IP address.
–
The /NETWORK_MASK IP address is required if your network uses
subnets.
–
The /DESTINATION address is the IP address assigned to the client host
making a connection request. This address always overrides the client’s
own IP address, if the client has one.
–
/COMPRESS=AUTO turns off IP header compression unless the client
uses it.
Configuring the PPP client (OpenVMS Alpha only) (Optional)
Use the SET INTERFACE command and /HOST qualifier to assign an IP
address:
TCPIP> SET INTERFACE PPn /SERIAL_DEVICE=TTn: /HOST=IP_address
In this command, n is the interface number. If you omit the interface number,
PP0 is used.
If you do not specify your host’s IP address using SET INTERFACE, the
dialup provider or terminal server provides an IP address after the connection
is established.
Note
If the connecting client host has only a loopback and tunnel interface
defined:
1. A default route to the PPP interface is added to the routing table
when the connection is established.
2. The IP address of the PPP interface is assigned to the logical
names TCPIP$INET_HOSTADDR and UCX$INET_HOSTADDR
(for backward compatibility).
3.2.1.5 Enabling IP Forwarding (Dialup Provider Only)
Enter the following command to enable IP forwarding:
TCPIP> SET PROTOCOL IP/FORWARD
To enable IP forwarding in the configuration database, enter the following
command:
TCPIP> SET CONFIGURATION PROTOCOL IP/FORWARD
Configuring and Managing Serial Lines 3–7
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
Alternatively, use the sysconfig utility. First, define the TCP/IP Services foreign
commands:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
Enter the following sysconfig commands:
$ sysconfig -r inet ipforwarding=1
$ sysconfig -r inet ipgateway=1
$ sysconfig -q inet
Note
These changes affect the running system only. To make permanent
changes to the system, modify the [TCPIP$ETC]SYSCONFIGTAB.DAT
database as described in the HP TCP/IP Services for OpenVMS Tuning
and Troubleshooting guide.
To send notifications automatically on all connected LANs when new hosts or
networks become reachable, use dynamic routing with the /SUPPLY option. For
example, every time a PPP link is set up to a new subnetwork, RIP (Routing
Information Protocol) advertises a corresponding route.
For example, enter the following commands:
TCPIP> START ROUTING /SUPPLY
TCPIP> SET CONFIGURATION START ROUTING /SUPPLY
If your PPP and Ethernet interfaces are in the same network, a route is created
automatically for the client hosts and an ARP proxy is advertised.
3.2.1.6 Initiating a PPP Connection
You use the OpenVMS PPP utility (PPPD) and associated commands to establish
and manage a temporary PPP connection from an OpenVMS Alpha client host
to an OpenVMS dialup provider or terminal server. Note that NETMBX and
OPER privileges are required to establish a successful connection and to display
OPCOM messages.
To invoke PPPD, enter the DCL command PPPD. The PPPD commands are
summarized in the following table. For detailed information about PPPD
commands and qualifiers, enter the HELP command.
Command
Function
CONNECT
Establishes a network connection through the current physical port or a
specified remote port.
DIAL_OUT
Allows direct access to a device in order to dial out over a modem or link
to an external device.
DISCONNECT
Terminates the network connection and returns control to the terminal
driver.
EXIT
Leaves the utility and returns you to the DCL command prompt ($).
HELP
Displays help text for PPPD commands.
SET
Determines the device and line characteristics for the specified terminal.
SHOW
Displays the device and line characteristics of the specified terminal.
3–8 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.2 Setting Up a PPP Interface (Alpha Only)
To initiate a PPP connection from an OpenVMS Alpha client to an OpenVMS
dialup provider or terminal server, follow these steps.
1. Confirm that you have NETMBX and OPER privileges.
2. Use the PPPD command DIAL_OUT and specify the terminal device. After
the atdt command, enter the telephone number of the dialup provider or
terminal server. (With some modems, you might need to type the number
again until dialing begins.)
For example:
$ PPPD
PPPD> DIAL_OUT TTA0
Type control-~ to send a break
control-\ to disconnect
control-@ to switch to a Point-to-Point connection.
atdt 8671234
3. If you are connecting to another OpenVMS system, log in to the system after
you dial up, and enter the following commands to establish the connection:
$ PPPD
PPPD> CONNECT
To end the connection, enter the DISCONNECT TTn command at the PPPD>
prompt and log out.
4. If you are connecting to a terminal server, enter the CONNECT PPP prompt
at the LOCAL> prompt. An informational message will confirm the PPP
connection:
LOCAL> CONNECT PPP
Local -561- Starting SLIP or PPP datalink session
%PPPD-I-CONNECTTERM, converting connection on device _TTA0: to a
Point-to-Point connection
To end the connection, enter DISCONNECT TTn at the PPPD> prompt. After
the connection is terminated, an OPCOM message is displayed. For example:
%%%%%%%%%%% OPCOM 23-APR-1998 15:44:32.10 %%%%%%%%%%%
Message from user XYZnet on JONES
%TCPIP-S-PPPDISCONN, Disconnected PPP Interface PP1 on TTA0
3.2.2 Removing the PPP Configuration
To remove the PPP configuration, follow these steps:
1. If you created a PPP interface, return the associated terminal port to general
use. Enter:
TCPIP> SET NOINTERFACE PPn
In this example, n is the number of the interface. If you omit the interface
number, PP0 is assumed.
2. If you added special route and proxy entries with the PPP line, remove them.
3. If you changed any terminal settings in preparation for PPP, restore them.
Enter the DCL command SET TERMINAL, and wait for the modem to reset
and free the port and phone line.
Configuring and Managing Serial Lines 3–9
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
3.3 Setting Up a SLIP Interface
Configuring the network interface for SLIP is the same as configuring the
interface for Ethernet connections. In this case, the network interface is the
modem connection. Remember that before you can configure a SLIP line, you
must choose an IP address for the interface at each end of the line and establish
a physical connection.
Use the following commands to set up the SLIP interface:
•
SET INTERFACE SLn, where n is the number of the interface. If you
omit the interface number, SL0 is assumed. This command takes effect
immediately and stays in effect until the next TCP/IP Services shutdown.
•
SET CONFIGURATION INTERFACE SLn, where n is the number of the
interface. If you omit the interface number, SL0 is assumed. This command
makes the change part of the permanent configuration. The change takes
effect at the next product startup.
Table 3–3 describes the command qualifiers used for configuring SLIP interfaces.
Table 3–3 Command Qualifiers Used for Configuring SLIP
Qualifier
Description
/[NO]AUTO_START
Optional. The default is /AUTO_START.
Automatically creates the interface on startup.
/COMPRESS=[ON | OFF | AUTOMATIC]
Optional. The default is no compression.
Enables or disables TCP header compression
(CSLIP). With /COMPRESS=AUTOMATIC,
compression remains off unless the remote
host begins to use it.
/[NO]FLOWCONTROL
Optional. The default is No flow control.
Enables the special handling of XON and
XOFF characters to work properly with
modems that are configured to interpret
these characters locally.
Specify /FLOWCONTROL only if the host
at the other end of the line is another host
running TCP/IP Services. If you cannot use
/FLOWCONTROL, configure your modem
to pass all the XON and XOFF characters
through transparently.
/HOST=(host_name, IP_address)
Required. Host name or IP address of the
local host. If your host is multihomed, you
must specify an address in dotted-decimal
notation.
/NETWORK_MASK=subnet_address
Required. The subnet mask of the local SLIP
interface in dotted-decimal notation.
/SERIAL_DEVICE=device
Required for hard-wired or dedicated
modem connections. Optional for dynamic
connections.
Identifies the OpenVMS device name assigned
to the SLIP interface, for example, TTA1.
For example, the following command configures SLIP interface SL5, using
the local IP address assigned to host CROW, with a subnetwork mask of
255.255.255.0. The interface uses the terminal device TTA3:. The /COMPRESS
3–10 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
qualifier enables TCP header compression (CSLIP). The /FLOWCONTROL
qualifier enables special handling of XON and XOFF characters.
TCPIP> SET INTERFACE SL5 /HOST=CROW /NETWORK_MASK=255.255.255.0 _TCPIP> /SERIAL_DEVICE=TTA3 /COMPRESS=ON /FLOWCONTROL
3.3.1 Setting Up Hard-Wired SLIP Lines
To configure SLIP with hard-wired lines, follow these steps:
1. Establish a physical connection. Plug in a serial cable between the two host
systems or ensure that they are both cabled to opposite ends of a leased line.
2. Obtain an IP address if necessary.
3. Configure the SLIP interface. Enter the SET INTERFACE command with the
/HOST and /SERIAL_DEVICE qualifiers, which are required.
3.3.2 Setting Up SLIP Dialup Lines
You can configure either a terminal server port or an OpenVMS system to answer
dialin calls.
Follow these steps:
1. Configure the appropriate settings for the terminal port to which you will
connect. Begin a dialog of dialing (or answering) commands with your
modem. The specific required commands depend on the type of modem you
are using.
For example, to prevent the modem from hanging up when you exit the DTE
session to bring up the SLIP line, enter the following command:
$ SET TERMINAL TTA2 /PERMANENT /MODEM /NOHANGUP
To disable interactive logins on the line, enter the following command:
$ SET TERMINAL TTA2 /PERMANENT /NOTYPEAHEAD
Any SLIP data that arrives before you enter the SET INTERFACE command
is ignored. Otherwise, this command triggers the creation of a new interactive
login process.
To enable interactive logins after a user sends a Break, enter the following
command:
$ SET TERMINAL TTA2 /PERMANENT /NOAUTOBAUD /SECURE_SERVER
2. Configure the modem. Enter the appropriate commands to dial the telephone
and establish communication.
3. Unless you are setting up a SLIP line between two hosts running TCP/IP
Services and plan to use the /FLOWCONTROL qualifier at both ends, disable
modem recognition of XON and XOFF characters. (If SLIP packets have
Ctrl/S and Ctrl/Q characters embedded in them as data, you must prevent the
modem from trying to interpret these characters.)
Either use hardware flow control or disable flow control entirely. The
following examples disable all flow control.
•
With a DECmodem V32 in AT command mode, set the following values:
AT%F0 — No speed buffering flow control
AT%M0 — Disable speed buffering (optional)
Configuring and Managing Serial Lines 3–11
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
•
With a DECmodem V32 in DMCL mode, set the following values:
SET P2/SBU
SET P1/SBU
prompts appropriate_answers
•
With a U.S. Robotics Sportster modem, set the following values:
AT&B0 — Variable, follows connection rate (optional)
AT&H0 — Flow control disabled
AT&I0 — Software flow control disabled
4. Obtain IP addresses if necessary.
5. To dial in, follow these steps:
a. Enter the SET HOST /DTE command:
$ SET HOST /DTE TTnx
b. Type the telephone number. For example:
atdt telephone_number
c. The connected system displays its interactive (command mode) prompt.
You are talking to the terminal server and can now make the connection.
The following example shows a user named SLIP-USER at a PC named ROBIN
with a 9600-baud modem, using terminal device TTA2 and connecting it to the
port of a terminal server. In this example:
•
The terminal server is a DECserver 700 terminal server.
•
The user directs the modem to dial the telephone number 222-2222.
•
The password prompt of the terminal server is #.
•
The terminal server’s current login password is hootowl.
•
The terminal server’s prompt is Local>.
•
The user types Ctrl/\ (Ctrl key plus backslash) to escape from the terminal
server to the SLIP host.
•
The user defines interface SL2 and identifies it as SLIP device TTA1: with IP
address 1.2.3.4. Communication on this line will use CSLIP.
3–12 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
$ SET HOST /DTE TTA2
%REM-I-TOQUIT, connection established
Press Ctrl/\ to quit, Ctrl/@ for command mode
atdt 2222222
CONNECT 9600
# hootowl (not echoed)
Network Access SW V1.5 for DS700-16
(c) Copyright 1994, Digital Equipment Corporation - All Rights Reserved
Please type HELP if you need assistance
Enter username>SLIP-USER
Local> CONNECT SLIP
Ctrl/\
TCPIP> SET INTERFACE SL2 /HOST=1.2.3.4 /NETWORK_MASK=255.255.255.0 _TCPIP> /SERIAL_DEVICE=TTA1: /COMPRESS=ON
3.3.3 Setting Up Your Host as a SLIP Dialup Provider
You can configure your host to answer calls and establish connections initiated by
users on remote hosts.
To set up your host as a SLIP provider:
1. Over the line you will define as a SLIP line, dial in to the host.
2. Log in to the remote host.
3. Enter an appropriate SET INTERFACE command with the /SERIAL_DEVICE
qualifier to turn the line into a SLIP line.
For example, the following command creates a SLIP interface named SL5,
using the terminal device associated with the session where the command is
entered.
TCPIP> SET INTERFACE SL5 /HOST=192.208.35.5 /SERIAL_DEVICE=TT
4. Log out.
As soon as you log out, your terminal port becomes a SLIP interface. Without
causing the modem to hang up, start SLIP on the remote system.
To facilitate connection setup for end users, create a dedicated user name for each
remote host that dials in. These users need to have a LOGIN.COM procedure
that invokes appropriate SET TERMINAL commands and TCP/IP management
SET INTERFACE commands, terminating with a LOGOUT command. Every
user should specify a different SLIP interface name and host name (or IP
address). These users require the OPER privilege to create interfaces.
You can enable IP forwarding on the SLIP provider host and start dynamic
routing. For example, enter the following commands:
TCPIP> SET PROTOCOL IP /FORWARD
TCPIP> SET CONFIGURATION PROTOCOL IP /FORWARD
To send notifications automatically on all connected LANs when new hosts or
networks become reachable, use dynamic routing with the /SUPPLY option. For
example, every time a SLIP connection is set up to a new remote subnetwork, RIP
(Routing Information Protocol) advertises a corresponding route. For example,
enter the following commands:
Configuring and Managing Serial Lines 3–13
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
TCPIP> START ROUTING /SUPPLY
TCPIP> SET CONFIGURATION START ROUTING /SUPPLY
3.3.4 Connecting a Host to the LAN
You can make your SLIP-connected host appear as if it were directly connected to
the LAN. This is possible using a proxy ARP server (usually the same host that
is acting as a SLIP gateway into the LAN).
To use proxy ARP (Address Resolution Protocol), assign to the remote host an IP
address in the same subnetwork as the LAN. As other hosts on the LAN attempt
to communicate with the remote host, the SLIP gateway answers ARP queries
for the remote host by giving its own LAN address. The gateway then forwards
packets across the SLIP line.
Many DECserver terminal server products support SLIP connections and
implement proxy ARP. If you dial in from an OpenVMS host to a terminal
server, the terminal server automatically detects your IP address and begins
responding to ARP queries, forwarding packets as necessary.
To use proxy ARP with a DECserver terminal server, assign an IP address in the
same subnetwork as the terminal server.
At the terminal server, enter the TCP/IP management command SHOW PORT
SLIP. Verify that:
•
An IP address has not already been associated with your port.
•
Header compression is available, if you plan to use it.
3.3.5 Setting Up a SLIP Gateway with Proxy ARP
It is also possible to set up your host as a SLIP gateway with proxy ARP. You
might prefer this approach if your dialin modems are attached directly to an
OpenVMS system rather than to a terminal server.
Follow these steps on the host to become a SLIP gateway:
1. Create a SLIP interface in another network or subnetwork, for example:
$ TCPIP SET INTERFACE SL0 /HOST=10.1.2.3 /SERIAL_DEVICE=TTA2
2. Add a host route for the remote system. For example:
$ TCPIP SET ROUTE FINCH /GATEWAY=10.1.2.3
3. Configure an ARP entry for the remote host, listing your own Ethernet
address (as shown in TCPIP SHOW INTERFACE /FULL). For example:
$ TCPIP SET ARP 08-00-2B-2C-4F-46 FINCH /PUBLIC
4. Enable IP packet forwarding, if not already done. Enter:
$ TCPIP SET PROTOCOL IP /FORWARD
When your host is set up as a SLIP gateway, create an interface on the
remote host at the other end of the serial line. Specify an address in the same
subnetwork as the LAN.
Although the two ends of the SLIP line are in different subnetworks, traffic
can flow properly due to the interface route you added with the SET ROUTE
command.
3–14 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.3 Setting Up a SLIP Interface
3.3.6 Shutting Down SLIP
To terminate a SLIP connection, follow these steps:
1. Return the associated terminal port to general use. Enter:
$ TCPIP SET NOINTERFACE interface
2. If you added special route and proxy entries in conjunction with the SLIP
line, remove them.
3. If you changed any terminal settings in preparation for SLIP, restore them
using the SET TERMINAL command.
3.4 Solving Serial Line Problems
If you have problems dialing in to an OpenVMS system using SLIP or PPP after
following the instructions in this chapter, perform the following steps to isolate
the cause of the problem:
1. Check the equipment used by both the client and the dialin provider:
•
Do the cables work?
•
Are the modems configured properly?
•
Are the DIP switches on the modems set correctly?
•
Are the modem software settings correct? Make sure that flow control is
disabled.
•
Are all clients and dialup providers using unique addresses?
After a software upgrade, be sure to reboot and restart TCP/IP Services.
2. Make sure the SET HOST attempts have not exceeded the OpenVMS security
level. To check and then delete, if necessary, any information about these
attempts, enter the following commands. Note that SECURITY privilege
must be enabled to use these commands.
$ SHOW INTRUSION
$ DELETE/INTRUSION_RECORD source
3. Make sure that IP forwarding is enabled using the following command:
TCPIP> SHOW PROTOCOL IP/FORWARD
4. Make sure the terminal characteristics for the terminal device associated
with the interface are set up as follows:
$ SET TERMINAL TTnx /ALTYPEAHD /AUTOBAUD /DIALUP _$ /DISCONNECT /EIGHTBIT /MODEM /NOHANGUP /NOHOSTSYNC /NOPASTHRU _$ /NOREADSYNCH /NOTTYSYNCH /PERMANENT /TYPE_AHEAD
Make sure you specify the /TYPE_AHEAD qualifier when you enter the SET
TERMINAL command to set up an asynchronous port.
5. Enter the SET HOST/DTE command to make sure you can log in to the
system:
$ SET HOST/DTE TTnx
If you cannot log in to or communicate with the system, you may be using the
wrong terminal device name (TTnx).
6. Set up OPCOM to receive messages using the DCL command
REPLY/ENABLE. You need OPER privileges to use OPCOM.
Configuring and Managing Serial Lines 3–15
Configuring and Managing Serial Lines
3.4 Solving Serial Line Problems
7. You need NETMBX and OPER privileges to establish a successful connection.
If these privileges are not enabled when you enter the CONNECT command,
you will see messages similar to the following:
$ PPPD
PPPD> CONNECT
\}‘}"}(}"6~ <CTRL/@>
%PPPD-I-CONNECTTERM, converting connection on device _TTA0: to a
Point-to-Point connection
%PPPD-E-CALLBACKERR, error calling network callback
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%PPPD-F-ABORT, fatal error encountered; operation terminated
Note that the extraneous data in this sample is an ASCII representation of IP
packets transmitted over the open line.
PPP sets up a default route on the client if one did not exist. Typically, a
default route exists if another interface exists on the client.
8. Attempt to ping the remote system:
TCPIP> PING host-name
Watch the modem’s LED display as you attempt to communicate using the
PING command.
You might not be able to ping the system if the serial line is tied up with a
large FTP operation.
9. Use the TCPTRACE command to see packets going in and out of the local
system. For information about using TCPTRACE, enter:
$ HELP TCPTRACE
10. Display a count of the packets being sent and received on the problem
interface, in full screen format, updated every second. For a SLIP problem,
enter:
TCPIP> SHOW INTERFACE SLn
To display the packet counts for PPP problem, enter:
TCPIP> SHOW INTERFACE PPn
In these commands, n is the interface number.
3.4.1 Solving PPP Problems
Keep the following in mind for PPP-specific problems:
•
If the virtual terminal software has not been loaded, the following error will
be displayed when you try to connect:
%PPPD-E-NEEDVIRTTERM, point-to-point connection on device _TTB0: must
be done on a virtual terminal
Correct this problem by entering the following commands before you dial out:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> IO
CONNECT VT/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE
SYSMAN> EXIT
3–16 Configuring and Managing Serial Lines
Configuring and Managing Serial Lines
3.4 Solving Serial Line Problems
To make this permanent, add the following commands to the
SYS$MANAGER:SYSTARTUP_VMS.COM file:
$ SET PROCESS/PRIVILEGE=CMKRNL
$ SYSMANIO = "SYSMAN IO"
$ SYSMANIO CONNECT VT/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE
Be sure to terminate any old virtual terminal sessions.
•
If you are trying to use OpenVMS as a PPP client to your ISP (Internet
service provider), check where the ISP uses an authentication protocol,
such as CHAP, PAP, or RADIUS. These protocols are not supported and will
prevent a connection to OpenVMS.
Configuring and Managing Serial Lines 3–17
4
Configuring and Managing Routing
Routing allows traffic from your local network to reach its destination elsewhere
on the internet. Hosts and gateways on a network use routing protocols to
exchange and store routing information. Routing is the act of forwarding
datagrams based on information stored in a routing table.
The TCP/IP Services product provides two types of routing: static and dynamic.
This chapter reviews key routing concepts and describes:
•
How to configure static routes (Section 4.2)
•
How to enable and disable dynamic routing (Section 4.3)
•
How to configure GATED (Section 4.4)
4.1 Key Concepts
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. With TCP/IP
Services, 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).
4.1.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 Section 4.2.
4.1.2 Dynamic Routing
Complex environments require a more flexible approach to routing than a static
routing table provides. Routing protocols distribute information that reflect
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 about the
changes.
Routing daemons implement a routing policy, that is, the set of rules that
specify 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 kernel also generates routing messages that can be read by any routing
socket when events occur that may be of interest to the process, for example, the
interface has gone down or a redirect has been received.
Configuring and Managing Routing 4–1
Configuring and Managing Routing
4.1 Key Concepts
TCP/IP Services implements two routing daemons: the Routing Daemon
(ROUTED) and the Gateway Routing Daemon (GATED). The following sections
provide more information.
4.1.2.1 Routing Daemon (ROUTED)
This daemon (pronounced route-dee) supports the Routing Information Protocol
(RIP). 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,
the ROUTED uses the information to update its routing table.
To configure dynamic routing with ROUTED, see Section 4.3.
4.1.2.2 Gateway Routing Daemon (GATED)
This daemon (pronounced gate-de) 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 protocols described in Table 4–1.
Table 4–1 GATED Routing Protocols
Protocol
RFC
Description
Routing Information
Protocol (RIP) Versions
1 and 2
RFC 1058, RFC 1723
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) Version 2
RFC 1583
Another interior routing protocol, OSPF is a linkstate protocol (shortest path first) and better suited
than RIP for use in complex networks with many
routers.
Exterior Gateway
Protocol (EGP)
RFC 904
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)
RFCs 1163, 1267, 1771
Like EGP, BGP exchanges reachability information
between autonomous systems but supports
nonhierarchical topologies. BGP uses path
attributes to provide more information about each
route. Path attributes can include, for example,
administrative preferences based on political,
organizational, or security considerations.
Router Discovery
RFC 1256
This protocol is used to inform hosts of the
availability of routers that it can send packets
to, and to supplement a statically configured default
router.
These routing protocols are configured in the GATED configuration file
TCPIP$GATED.CONF. This file contains statements that control tracing options,
select routing protocols, manage routing information, and manage independent
system routing.
For information on configuring dynamic routing with GATED, see Section 4.4.
4–2 Configuring and Managing Routing
Configuring and Managing Routing
4.2 Configuring Static Routes
4.2 Configuring Static Routes
The first time you run the configuration procedure, TCPIP$CONFIG.COM, static
routing is configured automatically. To manually configure static routing, use the
CREATE ROUTE command to create an empty routes database file.
The default file name is SYS$COMMON:[SYSEXE]TCPIP$ROUTE.DAT. To
specify a different name, define the systemwide logical name TCPIP$ROUTE.
Note
Do not enter the CREATE ROUTE command unless you intend to
reconfigure your entire cluster.
4.2.1 Creating a Default Route
When TCP/IP is sending a packet, it consults the routing table to determine
which interface is connected to the destination network. If the packet has a
destination network address that is unknown, the packet is sent to the default
router. The default route points at the default router. For example, if a router
with address 16.20.0.173 is designated to route all packets between the local
network and the rest of the world, then the default route can be set with the
following command:
$ TCPIP SET ROUTE /DEFAULT /GATEWAY=16.20.0.173
If TCP/IP Services is active, this affects the active routes database. To ensure this
default route is available next time TCP/IP Services is started, the /PERMANENT
qualifier must be used. For example:
$ TCPIP SET ROUTE /DEFAULT /GATEWAY=16.20.0.173 /PERMANENT
Use the SET NOROUTE command to remove a route.
Or you can define the default route using the route UNIX command. In this case,
to ensure the default route is recreated next time TCP/IP Services is started,
add the command to SYS$STARTUP:TCPIP$SYSTARTUP.COM. For example,
to create the same default route as defined above, use the following UNIX style
command:
$ route add default 16.20.0.173
To remove the route, enter the following command:
$ route delete default 16.20.0.173
4.2.2 Manually Defining Static Routes
To create a static route, use the SET ROUTE command. The command has the
following effects:
•
If TCP/IP Services is not active, SET ROUTE modifies the permanent
database.
•
If TCP/IP Services is active, SET ROUTE modifies the volatile database.
•
If TCP/IP Services is active, SET ROUTE/PERMANENT updates the
permanent database.
The SET ROUTE command requires the following information:
•
The IP address or domain name of the destination host or network
Configuring and Managing Routing 4–3
Configuring and Managing Routing
4.2 Configuring Static Routes
•
The IP address or host name of a gateway that can reach the destination host
HP strongly recommends that you do not specify alias names with the destination
parameter or the /GATEWAY=host qualifier.
To define a route to any host on a specific network, enter:
TCPIP> SET ROUTE network_IP_address /GATEWAY="gateway" /NETWORK
To define a route to a specific host on a specific network, enter:
TCPIP> SET ROUTE remote_host /GATEWAY="gateway"
4.2.2.1 Examples
1. In the following example, the network is active. The SET ROUTE command
adds a route to the volatile routes database. TCPIP starts directing
communication for flamingo through gateway francolin.
TCPIP> SET ROUTE "flamingo" /GATEWAY="francolin"
2. In the following example, the network is active. The SET ROUTE command
defines a routing path in the volatile routes database. The command
specifies that traffic for the network with IP address 128.30.0.0 uses gateway
francolin.
TCPIP> SET ROUTE 128.30.0.0 /NETWORK /GATEWAY="francolin"
3. In the following example, the network is not active. The SET ROUTE
command adds the new route to the permanent routes database. The next
time the product starts up, packets for NENE will go through a gateway
called bird.of.paradise.
TCPIP> SET ROUTE NENE /GATEWAY="bird.of.paradise"
At startup, the information in the permanent routes database, if any exists,
is loaded into the volatile routes database. You can add permanent routes
while the product is stopped or while it is running. If it is running, use the
/PERMANENT qualifier.
4. The following command permanently sets routing for host albatross to go
through gateway birdygate.
TCPIP> SET ROUTE "albatross" /GATEWAY="birdygate" /PERMANENT
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.
5. The following command sets a default route. NIGHTINGALE is the default
gateway.
TCPIP> SET ROUTE /DEFAULT /GATEWAY=NIGHTINGALE
To check that your routes are set up correctly, use either the LOOP or PING
command.
4–4 Configuring and Managing Routing
Configuring and Managing Routing
4.2 Configuring Static Routes
4.2.3 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:
•
A — Active route (A route that was created manually or associated with an
interface.)
•
D — Dynamic route. (A route that was dynamically created by the ROUTED
or GATED routing daemon.)
•
H — Host route (A route to a host.)
•
N — Network route (A route to a network.)
•
P — Permanent route (A route from the route database.)
To display a route that was defined by an address, specify either its address or a
wildcard.
Some examples of displaying routes are listed below.
1. The following example displays information about all the manually defined
routes.
TCPIP> SHOW ROUTE /FULL
DYNAMIC
Type
AN
AH
Destination
Gateway
11.111.0.0 destin_host1
22.111.4.10 destin_host2
11.110.5.118
22.110.5.120
gate_host
gate_host_2
2. The following example displays the permanent static routes that were defined
with SET ROUTE/PERMANENT.
TCPIP> SHOW ROUTE /PERMANENT
PERMANENT
Type
PN
PN
Destination
0.0.0.0
1.1.1.1
Gateway
11.20.208.100
22.2.2.2
pterodactyl.extinct.com
Another way to display route information is by using the netstat UNIX
command. For example, to display the routes, and suppress conversion of
network numbers to names, enter the following commands:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
$ netstat -rn
Routing tables
Destination
Gateway
Flags
Refs
Use Interface
Route Tree for Protocol Family 26:
Route Tree for Protocol Family 2:
default
16.20.0.173
default
16.20.0.173
16.20/16
16.20.208.161
16.20/16
16.20.208.160
16.20.208.160
16.20.208.160
16.20.208.161
16.20.208.161
127.0.0.1
127.0.0.1
UG
UG
U
U
UHL
UHL
UHL
0
0
2
1
0
0
1
0
0
56
9
0
0
1
WE1
WE0
WE1
WE0
WE0
WE1
LO0
Configuring and Managing Routing 4–5
Configuring and Managing Routing
4.2 Configuring Static Routes
This example shows a multihomed host with two interface adapters. For more
information about the netstat utility, enter the following command:
TCPIP> HELP NETSTAT
4.3 Enabling and Disabling Dynamic Routing
Use the configuration procedure TCPIP$CONFIG to enable dynamic routing and
configure your host to receive routing protocol messages as follows:
1. Select the Routing option from the Core Environment menu.
2. Answer ‘‘Yes’’ to the question "Do you want to configure dynamic ROUTED or
GATED routing [NO]:"
3. You are asked whether you want to enable GATED.
Do you want to enable GATED routing configuration?
If you answer ‘‘Yes’’ to this question, GATED will be enabled. If you answer
‘‘No,’’ ROUTED will be enabled.
4. If you choose to enable ROUTED, indicate whether you want your host to
supply RIP updates to other hosts on the network (in addition to receiving
RIP updates) and the default network route.
5. If you choose to enable GATED, you must also configure the routing protocols
in the GATED configuration file TCPIP$GATED.CONF. See Section 4.4 for
more information about configuring GATED.
To disable dynamic routing:
1. Select the ‘‘Routing’’ option from the CORE ENVIRONMENT menu.
2. Answer ‘‘Yes’’ to the following questions:
Do you want to reconfigure dynamic ROUTED or GATED routing [NO]: Y
Do you want to disable dynamic ROUTED or GATED routing configuration
[NO]: Y
Alternatively, enter the TCP/IP management command STOP ROUTING.
When you disable GATED routing, the GATED routes are preserved. To disable
GATED and remove all GATED routes from the routing table, enter the command
STOP ROUTING/GATED.
4.4 Configuring GATED
You must configure the GATED protocols before starting GATED routing.
Edit a copy of the sample file TCPIP$GATED.TEMPLATE (located in the
SYS$SYSDEVICE:[TCPIP$GATED] directory) to add statements that select
routing protocols, manage routing information, manage independent system
routing, and control tracing options.
1. Use TCPIP$CONFIG to enable GATED.
2. Edit the TCPIP$GATED.TEMPLATE file.
3. Save the file TCPIP$GATED.CONF in the
SYS$SYSDEVICE:[TCPIP$GATED] directory.
4. If GATED is already running, stop it by entering the command
STOP ROUTING/GATED.
4–6 Configuring and Managing Routing
Configuring and Managing Routing
4.4 Configuring GATED
5. Start GATED by entering the command START ROUTING/GATED.
See the HP TCP/IP Services for OpenVMS Management Command
Reference manual for detailed descriptions of the SET GATED and START
ROUTING/GATED commands.
If you do not format the configuration file correctly, GATED terminates.
For specific information about how to edit the GATED configuration file, see
Appendix A.
4.4.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 timer 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.
Enter the following commands to reset the reassembly timer:
•
For the current session:
TCPIP> SET PROTOCOL IP /REASSEMBLY_TIMER=n
•
To reset at the next TCP/IP Services startup:
TCPIP> 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 TCP/IP Services startup.
The second command makes the change permanent by modifying the
configuration database, TCPIP$CONFIGURATION.DAT.
TCPIP> SET PROTOCOL IP /REASSEMBLY_TIMER=20
TCPIP> SET CONFIGURATION PROTOCOL IP /REASSEMBLY_TIMER=20
4.4.2 Enabling Forwarding
To enable packet forwarding between networks, enter the following TCP/IP
management command:
TCPIP> SET PROTOCOL IP /FORWARD
To ensure this is set up the next time TCP/IP Services is restarted, enter the
following command:
TCPIP> SET CONFIGURATION PROTOCOL IP /FORWARD
Display the setting using the following command:
TCPIP> SHOW PROTOCOL /PARAMETERS
Configuring and Managing Routing 4–7
Configuring and Managing Routing
4.4 Configuring GATED
Or use the sysconfig utility to enable forwarding. First, define foreign
commands:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
Enter the following sysconfig command:
$ sysconfig -r inet ipforwarding=1 ipgateway=1
To make sure forwarding is enabled after restarting TCP/IP Services, add the
command to TCPIP$SYSTARTUP.COM.
To view the setting, use the following command:
$ sysconfig -q inet ipforwarding ipgateway
When multiple networks share the same physical media and the host has just
one interface, it is still possible to forward packets between these networks by
creating a network alias, as described in Section 2.3.3.
For example, consider a network in which two networks have network addresses
of 16.20.1/24 and 16.20.2/24, and the host address is 180. If the host has a single
ethernet interface, WE0, create the interface and pseudointerfaces as follows:
TCPIP> SET CONFIGURATION INTERFACE WE0 /HOST=16.20.1.180 _TCPIP> /NETWORK_MASK=255.255.255.0 /BROADCAST_MASK=16.20.1.255
TCPIP> SET CONFIGURATION INTERFACE WEA0 /HOST=16.20.2.180 _TCPIP> /NETWORK_MASK=255.255.255.0 /BROADCAST_MASK=16.20.2.255
TCPIP> SET CONFIGURATION PROTOCOL IP /FORWARD
When TCP/IP Services is restarted, the host will forward packets between these
networks.
Alternatively, you can add the following commands to TCPIP$SYSTARTUP.COM
and then restart TCP/IP Services:
$ ifconfig we0 aliaslist 16.20.1-2.180/24
$ sysconfig -r inet ipforwarding=1 ipgateway=1
4.4.3 Extending Routing
To use extended routing, define pseudointerfaces. A pseudointerface is a
data structure that extends routing. Like an interface, the name of an internet
pseudointerface is three alphabetic characters, followed by the pseudointerface
unit number in the range of 0 through 255.
The first two characters are the same as the two characters in the internet
interface name (interface type and interface class). See Section 2.3.1 for more
information about interface names.
The third character identifies the controller letter that corresponds to the
OpenVMS hardware controller.
For example, for an OpenVMS Alpha system with two Ethernet controllers, EZA0
and EZB0, you can define the following internet interfaces and pseudointerfaces:
•
Internet interfaces:
ZE0
ZE1
4–8 Configuring and Managing Routing
Configuring and Managing Routing
4.4 Configuring GATED
•
Internet pseudointerfaces, each with its own IP address, network mask, and
broadcast mask:
SEA
SEA0
SEA1
.
.
.
SEA254
SEB255
To extend routing, follow these steps:
1. Define the pseudointerfaces using the SET INTERFACE and SET
CONFIGURATION INTERFACE commands:
TCPIP> SET NOINTERFACE interface
TCPIP> SET INTERFACE interface /HOST=host _TCPIP> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask
TCPIP> SET CONFIGURATION INTERFACE interface /HOST=host _TCPIP> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask
For example, to specify the pseudointerface FFA0 on host KESTREL, with
network mask 255.255.0.0 and broadcast mask to 128.30.0.0, enter:
TCPIP> SET NOINTERFACE FFA0
TCPIP> SET INTERFACE FFA0 /HOST=KESTREL /NETWORK_MASK=255.255.0.0 _TCPIP> /BROADCAST_MASK=128.30.0.0
2. Enter the same information into the configuration database to set up the
interfaces at startup. For example:
TCPIP> SET CONFIGURATION INTERFACE FFA0 /HOST=KESTREL _TCPIP> /NETWORK_MASK=255.255.0.0 /BROADCAST_MASK=128.30.0.0
To display information about the network interfaces, use the SHOW
INTERFACE command. To remove the interface from the configuration
database, use the SET CONFIGURATION NOINTERFACE command.
4.4.4 Interface Routes
If you have a configuration in which multiple networks share the same physical
LAN, you can communicate directly with hosts in other networks without the
need of a pseudointerface 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. As the gateway for the route, enter either one of the host’s own addresses or
the broadcast address associated with an interface.
TCP/IP Services 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.
Configuring and Managing Routing 4–9
Configuring and Managing Routing
4.4 Configuring GATED
For example, network 99.0.0.0 is on the same cable as network 192.199.199.0. On
host 99.1.2.3, specify network 192.199.199.0 as directly reachable:
TCPIP> SET ROUTE 192.199.199.0 /NETWORK /GATEWAY=99.1.2.3
On the hosts in network 192.199.199.0, enter:
TCPIP> SET ROUTE 99.0.0.0 /NETWORK /GATEWAY=192.199.199.255
4.4.5 Manually Configuring a Hardware Address
Network hosts require manual configuration of a hardware address for a remote
IP address under the following conditions:
•
The remote host does not support the Address Resolution Protocol (ARP). You
need static mapping of IP addresses to hardware addresses.
•
The remote host is running ARP, but a change was made to the internet
interface on that host.
To notify your system about the change, flush the address mapping tables.
Use the SET NOARP command to do this.
For example, to map the Ethernet address AA-02-04-05-06-07 of host ROOK, add
the hardware address to the ARP table by entering the following command:
TCPIP> SET ARP AA-02-04-05-06-07 ROOK
4–10 Configuring and Managing Routing
5
Configuring and Managing failSAFE IP
failSAFE IP is an optional service provided by TCP/IP Services to allow IP
addresses to fail over when interfaces cease functioning on a system where
multiple interfaces have been configured. When the same IP address is
configured on multiple interfaces, network connections can be maintained when:
•
The network interface card (NIC) fails.
•
A cable is disconnected or broken.
•
A switch for a port fails.
•
The node or the TCP/IP Services software is shut down.
This chapter reviews key concepts and describes:
•
How to configure failSAFE IP (Section 5.2)
•
How to manage failSAFE IP (Section 5.3)
5.1 Key Concepts
The failSAFE service monitors an interface and takes appropriate action
upon detecting interface failure or recovery. failSAFE IP provides IP address
redundancy by requiring the same IP address to be configured on multiple
interfaces. Only one instance of each IP address is active at any time; the other
duplicate IP addresses are in standby mode.
Standby IP addresses can be configured on multiple interfaces within the same
node or across an OpenVMS Cluster. The interfaces are monitored by the
failSAFE IP service. When an interface fails, each active IP address on the failed
interface is removed and the standby IP address becomes active. If an address
is not preconfigured with a standby, then the address is removed from the failed
interface until it recovers.
Static routes on the failed interface are also removed and are configured on any
interface where their network is reachable.
When an interface recovers, it can request that its IP addresses be returned
to it when the interface is configured as the home interface for one or more
addresses. When the home interface recovers, it requests that the current holder
of the address give it up. (For more information about home interfaces, see
Section 5.2.3.)
The current holder of an address does not release an address if this action will
result in dropped connections, or if the current holder is also designated as a
home interface for that address.
Management intervention can be taken to force the removal of an address.
Configuring and Managing failSAFE IP 5–1
Configuring and Managing failSAFE IP
5.2 Configuring failSAFE IP
5.2 Configuring failSAFE IP
Configuring failSAFE IP requires two steps:
1. Assign the same IP address to multiple interfaces. Only one instance of
that address is active; all other instances are in standby mode. For simple
configurations, use the TCPIP$CONFIG Core Interface menu to assign an IP
address to multiple interfaces. Alternatively, use the ifconfig utility, which
provides a greater degree of management control. For more information, see
Section 5.2.1.
2. Use the TCPIP$CONFIG.COM command procedure to enable the failSAFE IP
service, which monitors the health of interfaces and takes appropriate action
when it detects interface failure or recovery. This service is available from
the Optional Components menu.
5.2.1 Configuring failSAFE IP Manually
A failSAFE IP address can be configured by using the TCPIP$CONFIG.COM
command procedure, or manually by using the TCP/IP management command
SET INTERFACE.
For instance, to create an IP address of 10.10.10.1 on interface IE0 and a
standby alias address on interface IE1 (pseudointerface IEB0), use the following
commands:
$ TCPIP
TCPIP> SET INTERFACE IE0/HOST=10.10.10.1
TCPIP> SET INTERFACE IEB0/HOST=10.10.10.1
Alternatively, you can use the ifconfig utility to configure an interface manually.
For example:
$ ifconfig ie0 10.10.10.1
$ ifconfig ie1 alias 10.10.10.1
To view the standby addresses, use the ifconfig utility. For example:
$ ifconfig -a
IE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
*inet 10.10.10.1 netmask ff000000 broadcast 10.255.255.255
IE1: flags=c03<UP,BROADCAST,MULTICAST,SIMPLEX>
failSAFE IP Addresses:
inet 10.10.10.1 netmask ff000000 broadcast 10.255.255.255 (on HUFFLE IE0)
In this example, interface IE1 displays a failSAFE IP address that is active on
node HUFFLE, interface IE0.
Note
In an OpenVMS Cluster, an IP address with active connections cannot be
reassigned to another node in the cluster. Therefore, you should always
configure a standby interface on the same node as the home interface.
DNS-controlled primary addresses should be placed under the control of the
BIND/DNS load broker to make sure that the DNS alias continues to be available.
5–2 Configuring and Managing failSAFE IP
Configuring and Managing failSAFE IP
5.2 Configuring failSAFE IP
The ifconfig utility provides greater control of failSAFE IP addresses. Table 5–1
describes the ifconfig options that support failSAFE IP.
Table 5–1 ifconfig Options for failSAFE IP
Option
Description
[-]fail
Forces an interface to fail. You can recover the interface using the
-fail command.
[-]home
Forces an alias address to be created with a home interface. This
option is used used when creating IP addresses. By default, all
primary IP addresses are created with a home interface.
[-]fs
Creates an address that is not managed by failSAFE IP. All IP
addresses are created as failSAFE addresses by default, except for
addresses assigned to the loopback interface LO0 (for instance, the
local host address 127.0.0.1).
5.2.2 Modifying the failSAFE IP Configuration Parameters
By default, the failSAFE IP service monitors all TCP/IP interfaces on a system,
periodically polling each interface using default polling intervals. You can
override the defaults by editing the configuration file. To change the name or
location of the configuration file, define the logical name TCPIP$FAILSAFE. By
default, the configuration file name and location are:
SYS$SYSDEVICE:[TCPIP$FSAFE]TCPIP$FAILSAFE.CONF
Table 5–2 describes the configuration parameters.
Table 5–2 failSAFE IP Configuration Parameters
Parameter
Description
Default
INTERFACE_LIST
The list of interfaces that failSAFE
monitors.
All interfaces
INFO_POLL
Specifies the polling interval used when
the interface is known to be functional.
It requires two INFO_POLL timeouts
to determine that an interface is not
responding, at which time the polling
frequency is set to the WARN_POLL period.
3 seconds
WARN_POLL
Specifies the polling interval used when
the interface first stops responding. It will
continue polling the interface for RETRY_
WARN attempts before the interface is
deemed to be malfunctioning, at which time
the polling frequency is set to ERROR_
POLL and failover occurs.
2 seconds
RETRY_WARN
Specifies the number of warning polls before
the interface is deemed to be malfunctioning
and the IP addresses associated with it are
removed. A value of zero skips the WARN_
POLL cycle.
1 retry
(continued on next page)
Configuring and Managing failSAFE IP 5–3
Configuring and Managing failSAFE IP
5.2 Configuring failSAFE IP
Table 5–2 (Cont.) failSAFE IP Configuration Parameters
Parameter
Description
Default
ERROR_POLL
Specifies the polling interval used when the
interface is deemed to be malfunctioning.
failSAFE monitors a malfunctioning
interface at this frequency until it
determines that the interface has recovered,
at which time the polling frequency is set
back to the INFO_POLL period.
15 seconds
5.2.3 Creating and Displaying Home Interfaces
failSAFE IP addresses can be created with a designated home interface. By
default, all primary IP addresses are created with a home interface. A home
interface provides a preferential failover and recovery target in an effort to
always migrate IP addresses to their home interface, thereby limiting the
disruption to users.
You can use the ifconfig utility to create and display addresses configured with
home interfaces. For example, to create three addresses, enter the following
commands:
$ ifconfig ie0 10.10.10.1
! primary has home interface by default
$ ifconfig ie0 alias 10.10.10.2
! alias does not
$ ifconfig ie0 home alias 10.10.10.3 ! create alias with home interface
Although the TCP/IP management command SET INTERFACE can be used to
create primary and alias addresses, it does not allow you to create the home alias
address. You must use the ifconfig utility to do this.
When addresses are displayed by the ifconfig utility, those addresses with a
home interface are marked with an asterisk (*). For example:
$ ifconfig ie0
IE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
*inet 10.10.10.1 netmask ff000000 broadcast 10.255.255.255
inet 10.10.10.2 netmask ff000000 broadcast 10.255.255.255
*inet 10.10.10.3 netmask ff000000 broadcast 10.255.255.255
The asterisk indicates that the addresses 10.10.10.1 and 10.10.10.3 have a home
interface of IE0.
Note
The TCP/IP management command SHOW INTERFACE does not identify
addresses with a home interface.
Creating IP addresses with home interfaces spreads the IP addresses across
multiple interfaces. This is useful for load-balancing and gaining higher
aggregate throughput. If a home interface recovers after a failure, the addresses
may return to their recovered home interface, thus maintaining the spread of
addresses across the available interfaces.
Note
The IP address will not migrate toward a home interface while that
address has active connections.
5–4 Configuring and Managing failSAFE IP
Configuring and Managing failSAFE IP
5.2 Configuring failSAFE IP
5.3 Managing failSAFE IP
The failSAFE IP service monitors the state of interfaces and, upon detecting a
failure or recovery, takes the appropriate action. To start and stop the failSAFE
IP service, run the following command procedures:
•
SYS$STARTUP:TCPIP$FAILSAFE_STARTUP.COM
•
SYS$STARTUP:TCPIP$FAILSAFE_SHUTDOWN.COM
The failSAFE IP service performs the following actions:
1. Monitors the state of interfaces by periodically reading their Bytes Received
counter.
2. When required, marks an interface as failed or recovered.
3. Maintains static routes to ensure they are preserved after interface failure or
recovery.
4. Logs all messages to TCPIP$FAILSAFE_RUN.LOG. Important events are
additionally sent to OPCOM.
5. Invokes a site-specific command procedure. For more information about the
site-specific command procedures, see Section 22.1.1.
6. Generates traffic to help avoid phantom failures, as described in
Section 5.3.5.3.
If the failSAFE IP service is not enabled, configuring a failSAFE IP address
across nodes provides identical functionality to the IP cluster alias, as described
in Section 1.4.
5.3.1 failSAFE IP Logical Names
You can use logical names to customize the operating environment of failSAFE
IP. The logical names must be defined in the LNM$SYSTEM_TABLE for them to
take effect.
Table 5–3 describes the failSAFE IP logical names.
Table 5–3 failSAFE IP Logical Names
Logical Name
Description
TCPIP$FAILSAFE
Specifies the configuration file that is read by
TCPIP$FAILSAFE during startup. This logical
must be defined prior to starting the failSAFE
IP service. The default file specification is
SYS$SYSDEVICE:TCPIP$FAILSAFE.CONF.
TCPIP$FAILSAFE_FAILED_ifname
Simulates a failure for the named interface
(ifname). This logical name is translated each
time failSAFE IP reads the LAN counters.
To determine the interface name, use the TCP/IP
management command SHOW INTERFACE.
(continued on next page)
Configuring and Managing failSAFE IP 5–5
Configuring and Managing failSAFE IP
5.3 Managing failSAFE IP
Table 5–3 (Cont.) failSAFE IP Logical Names
Logical Name
Description
TCPIP$SYFAILSAFE
Specifies the name of a site-specific command
procedure that is invoked when one of three
conditions occurs: interface failure, retry failure,
or interface recovery. The default file specification
is SYS$MANAGER:TCPIP$SYFAILSAFE.COM.
TCPIP$FAILSAFE_LOG_LEVEL
Controls the volume of log messages sent to
OPCOM and the log file. This logical is translated
each time failSAFE IP logs a message. The
default value is 0.
TCPIP$FSACP_LOG_LEVEL
Controls the volume of log messages sent to
OPCOM by the ACP. This logical should be used
only when directed by customer support. The
default value is 0.
5.3.2 Customizing failSAFE IP
You can create a site-specific command procedure to be invoked under specified
circumstances, such as when an interface fails. You can customize the command
procedure to handle the following circumstances:
•
When the interface first appears to have stopped responding. This is the first
warning that a problem may exist, but no action to failover IP addresses has
been taken yet.
•
When an attempt to generate traffic on the interface fails. After the retry
limit is reached, the interface is deemed as malfunctioning, and IP addresses
are removed from the interface. Failover occurs.
•
When the interface recovers.
The default site-specific command procedure is:
SYS$MANAGER:TCPIP$SYFAILSAFE.COM
To modify the location or file name, define the logical name TCPIP$SYFAILSAFE.
Use the following text strings as parameters to the command procedure:
•
P1 is the interface name (for example, IE0)
•
P2 is the state. The states are:
INFO_STATE
WARN_STATE
ERROR_STATE
5.3.3 Reestablishing Static and Dynamic Routing
When an interface fails, failSAFE IP removes all addresses and static routes from
the failed interface. The static routes are reestablished on every interface where
the route’s network is reachable. This action can result in the creation of a static
route on multiple interfaces and is most often observed with the default route.
You may need to restart dynamic routing to ensure that the dynamic routing
protocol remains current with changes in the interface availability. If this is
necessary, restart the routing process using the following TCP/IP management
commands:
5–6 Configuring and Managing failSAFE IP
Configuring and Managing failSAFE IP
5.3 Managing failSAFE IP
TCPIP> STOP ROUTING /GATED
TCPIP> START ROUTING /GATED
For GATED, failSAFE IP can be configured to scan the interfaces periodically for
any changes. Use the GATED configuration option scaninterval. You can scan
the interfaces manually using the following TCP/IP management command:
$ TCPIP SET GATED/CHECK_INTERFACES
For more information about routing protocols, see Chapter 4.
5.3.4 Displaying the Status of Interfaces
The failSAFE IP service periodically reads the network interface card (NIC) Bytes
Received counter to determine the status of an interface. You can display the
Bytes Received counter using the LANCP utility. For example, to view the Bytes
Received counters for all interfaces, enter the following command:
$ pipe mcr lancp show device/count | search sys$pipe "Bytes received"/exact
The types of events that prevents the Bytes Received counter from changing
include:
•
Failing interface hardware
•
Disconnected physical link
•
Shutting the interface down using TCP/IP management commands
•
Shutting down TCP/IP Services
•
Shutting down a node
5.3.5 Guidelines for Configuring failSAFE IP
This section describes guidelines that can help avoid common pitfalls in
configuring failSAFE IP.
5.3.5.1 Validating failSAFE IP
Most contemporary networks are highly stable and rarely suffer from the
problems that require failSAFE IP. Consequently, on the few occasions where
failSAFE IP is required, it is critical that the service be validated in the
environment where it is being deployed. Failure to do this can result in
unexpected problems at the critical moment.
Since real failures are rare and sometimes difficult to simulate, the logical name
TCPIP$FAILSAFE_FAILED_ifname is provided. After configuring failSAFE IP
addresses and starting the failSAFE IP service, validate the configuration using
the following procedure:
1. Establish connections and generate IP traffic.
Using TELNET or FTP, create incoming and outgoing TCP connections to
the multihomed host from inside and outside the subnet. Verify that these
connections are established by using the following commands:
$
$
$
$
@SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
ifconfig -a ! Check the interface addresses
netstat -nr ! Check the routing table
netstat -n ! identify which interfaces are being used
2. Simulate a failure and observe.
Configuring and Managing failSAFE IP 5–7
Configuring and Managing failSAFE IP
5.3 Managing failSAFE IP
Simulate a failure and observe OPCOM and log file messages. Use the
following command to simulate a failure:
$ DEFINE/SYSTEM TCPIP$FAILSAFE_FAILED_ifname 1 ! or disconnect the cable
Wait long enough for failover to occur, which is signaled by OPCOM messages.
Then observe the effects of failover and verify that TCP connections are still
established and can transfer data. For example, TELNET sessions should
respond to keyboard input.
Use the following commands to see how IP addresses and routing have
changed:
$ ifconfig -a ! Observe how the addresses have migrated
$ netstat -nr ! Observe how the routing table has changed
3. Recover from the simulated failure and observe the OPCOM messages.
$ DEASSIGN/SYSTEM TCPIP$FAILSAFE_FAILED_ifname ! or reconnect the cable
$ ifconfig -a ! Observe how the addresses have migrated
$ netstat -nr ! Observe how the routing table has changed
Again, ensure that TCP connections are still established and can transfer
data.
Note
Simulating a failure with the logical name TCPIP$FAILSAFE_FAILED_
ifname does not disrupt physical connections and therefore is not an
accurate indicator of whether the services will survive a real failover
situation. Consequently, this procedure should be repeated by physically
removing a network cable from one or more of the interfaces. Since this
action might be disruptive to network services, it should be scheduled
during a maintenance period, when disruption can be tolerated.
5.3.5.2 Configuring Failover Time
The key concern for configuring the failSAFE IP service is the time it takes to
detect a failure and for the standby IP address to become active. One goal of
a failSAFE IP configuration is to avoid disrupting existing connections, so the
failover time must be within the connection timeout.
The minimum failover time is calculated as:
INFO_POLL + (WARN_POLL * RETRY)
The maximum failover time is calculated as:
(2 * INFO_POLL) + (WARN_POLL * RETRY)
For explanations of the variables, see Table 5–2. The default values (INFO_
POLL=3, WARN_POLL=2, RETRY=1) result in a failover range of 5 to 8 seconds.
Note that this does not take into account the system load.
The recovery time will be less than the ERROR_POLL period, which is, by
default, 30 seconds.
5–8 Configuring and Managing failSAFE IP
Configuring and Managing failSAFE IP
5.3 Managing failSAFE IP
5.3.5.3 Avoiding Phantom Failures
The health of a NIC is determined by monitoring the NIC’s Bytes Received
counter. This provides a protocol-independent view of the NIC counters. However,
in a quiet network, there may be insufficient traffic to keep the Bytes Received
counter changing within the failover detection time, thus causing a phantom
failure. To counteract this, the failSAFE service attempts to generate MAC-layer
broadcast messages, which are received on every interface on the LAN except for
the sending interface.
Consequently, in a quiet network with only two interfaces being monitored by
the failSAFE IP service, a single NIC failure can also result in a phantom failure
of the other NIC, since the surviving NIC is not able to increase its own Bytes
Received counter.
You can reduce phantom failures in a quiet network by configuring the failSAFE
IP service for at least three interfaces on the LAN. If one interface fails, the
surviving interfaces continue to maintain one another’s Bytes Received counters.
5.3.5.4 Creating IP Addresses with Home Interfaces
By default, the interface on which a primary IP address is created is its home
interface, whereas an IP alias address is created without a home interface. To
create an alias address with a home interface, use the ifconfig command, which
should be added to the SYS$STARTUP:TCPIP$SYSTARTUP.COM procedure. For
example, use the following command to create an alias address of 10.10.10.3 on
interface IE0 and to designate IE0 as its home interface:
$ ifconfig ie0 home alias 10.10.10.3/24
5.3.5.5 Private Addresses Should Not Have Clusterwide Standby Interfaces
Private addresses are those that are used for network administration and are
not published as well-known addresses for well-known services. A standby
interface for a private address should be configured on the same node as the
home interface. This avoids a situation in which a node cannot assign any
addresses to its interfaces if they have active connections on another node in the
cluster.
If you want to associate the list of private addresses with a public DNS alias
name, you should use the load broker to provide high availability of the DNS
alias. The load broker is described in Chapter 7.
Configuring and Managing failSAFE IP 5–9
Part 2
BIND
Part 2 provides information on configuring and managing the TCP/IP Services
name server and includes the following chapters:
•
Chapter 6, Configuring and Managing BIND Version 9, describes how to
configure and manage the TCP/IP Services implementation of the Berkeley
Internet Name Domain (BIND) software. Note that BIND Version 9 is not
supported on VAX systems. For information about configuring BIND Version
8 (which runs on both VAX and Alpha systems), see Appendix D.
•
Chapter 7, Using DNS to Balance Work Load, describes how to use BIND’s
round-robin scheduling or the load broker for cluster load balancing.
6
Configuring and Managing BIND Version 9
The Domain Name System (DNS) maintains and distributes information about
Internet hosts. DNS consists of a heirarchical database containing the names of
entities on the Internet, the rules for delegating authority over names, and mail
routing information; and the system implementation that maps the names to
Internet addresses.
In OpenVMS environments, DNS is implemented by the Berkeley Internet Name
Domain (BIND) software. HP TCP/IP Services for OpenVMS implements a BIND
server based on the Internet Software Consortium’s (ISC) BIND Version 9.
Note
The BIND Version 9 server is not supported on VAX systems. For
information about the BIND Version 8 server, which runs on both VAX
and Alpha systems, see Appendix D.
This chapter contains the following topics:
•
How to migrate your existing BIND 4 environment to BIND 9 (Section 6.3)
•
How to configure BIND using the BIND configuration file (Section 6.5),
including:
How to configure dynamic updates (Section 6.5.7)
How to configure a DNS cluster failover and redundancy environment
(Section 6.5.8)
•
How to populate the BIND server databases (Section 6.6)
•
How to examine name server statistics (Section 6.7)
•
How to configure BIND using SET CONFIGURATION BIND commands
(Section 6.8)
•
How to configure the BIND resolver (Section 6.9)
•
How to use the BIND server administrative tools (Section 6.10)
•
How to troubleshoot BIND server problems (Section 6.11)
6.1 Key Concepts
This section serves as a review only and assumes you are acquainted with the
InterNIC, that you applied for an IP address, and that you registered your
domain name. You should also be familiar with BIND terminology, and you
should have completed your preconfiguration planning before using this chapter
to configure and manage the BIND software.
Configuring and Managing BIND Version 9 6–1
Configuring and Managing BIND Version 9
6.1 Key Concepts
If you are not familiar with DNS and BIND, see the Compaq TCP/IP Services for
OpenVMS Concepts and Planning guide. If you need more in-depth knowledge,
see O’Reilly’s DNS and BIND, Fourth Edition. You can find the BIND 9
Adminstrator Reference Manual at http://www.isc.org/.
6.1.1 How the Resolver and Name Server Work Together
BIND is divided conceptually 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 TCPIP$BIND. On UNIX
systems, the name server is called named (pronounced name-dee). Name servers
are typically classified as master (previously called primary), slave (previously
called secondary), and caching-only servers, depending on their configurations.
6.1.2 Common BIND Configurations
You can configure BIND in several different ways. The most common
configurations are resolver-only systems, master servers, slave servers, forwarder
servers, and caching-only servers. A server can be any of these configurations or
can combine elements of these configurations.
Servers use a group of database files containing BIND statements and resource
records. These files include:
•
The forward translation file, domain_name.DB
This file maps host names to IP addresses.
•
The reverse translation file, address.DB
This file maps the address back to the host names. This address name lookup
is called reverse mapping. Each domain has its own reverse mapping file.
•
Local loopback forward and reverse translation files, LOCALHOST.DB,
127_0_0.DB, and 0_0_0_0_0_0_IP6.ARPA (for IPv6).
These local host databases provide forward and reverse translation for
the widely used LOCALHOST name. The LOCALHOST name is always
associated with IPv4 address 127.0.0.1 and IPv6 address ::1, and is used for
loopback traffic.
•
The hint file, ROOT.HINT
This file contains the list of root name servers.
A configuration file, TCPIP$BIND.CONF, contains statements that pull all the
database files together and governs the behavior of the BIND server.
6.1.2.1 Master Servers
A master server is the server from which all data about a domain is derived.
Master servers are authoritative, which means they have complete information
about their domain and that their responses are always accurate.
To provide central control of host name information, the master 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 on
the master server needs to be modified.
6–2 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.1 Key Concepts
A master server requires a complete set of configuration files: forward
translation, reverse translation, configuration, hint, and loopback files.
6.1.2.2 Slave Servers
Slave servers receive authority and their database from the master server.
A particular domain’s database file is called a zone file; copying this file to a slave
server is called a zone file transfer . A slave server assures that it has current
information about a domain by periodically transferring the domain’s zone file
from the master. Slave servers are also authoritative for their domains.
Configuring a slave server is similar to configuring a master server. The only
difference is that, for the slave server, you need to provide the name of the master
server from which to transfer zone data.
Note
If you create a master, slave, or forwarder server for the same domain on
which your local host resides, you should reconfigure your BIND resolver
so that it uses this system (LOCALHOST) as its name server.
Slave servers require a configuration file, a hint file, and loopback files.
6.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 nonauthoritative, which means that
their information is secondhand and can be incomplete.
Caching-only servers require a hint file and loopback files.
6.1.2.4 Forwarder Servers
The forwarding facility can be used to create a large, sitewide cache on a few
servers, thereby reducing traffic over links to external name servers. Forwarder
servers process requests that slave servers cannot resolve locally (for example,
because they do not have access to the Internet).
Forwarding occurs on only those queries for which the server is not authoritative
and for which it does not have the answer in its cache.
A master or slave server specifies a particular host to which requests outside the
local zone are sent. This is a form of Internet courtesy that limits the number of
hosts that actually communicate with the root servers listed in the ROOT.HINT
file.
If you configure a forwarder server, you must provide the name of the host to
which requests outside your zones of authority are forwarded.
Configuring and Managing BIND Version 9 6–3
Configuring and Managing BIND Version 9
6.2 Security Considerations
6.2 Security Considerations
BIND Version 9 provides the following security enhancements:
•
Access control lists allow you to control access to the name server. See
Section 6.2.1 for more information.
•
Dynamic Update Security controls access to the dynamic update facility. See
Section 6.2.2 for more information.
•
Transaction Signatures (TSIG) provide key-based access to the dynamic
update facility. See Section 6.2.3 for more information.
•
TKEY automatically generates a shared secret between two hosts. See
Section 6.2.4 for more information.
•
SIG(0) is another method for signing transactions. See Section 6.2.5 for more
information.
•
DNSSEC provides cryptographic authentication of DNS information. See
Section 6.2.6 for more information.
6.2.1 Access Control Lists
Access control lists (ACLs) are address match lists that you can set up and name
for use in configuring the following options:
•
allow-notify
•
allow-query
•
allow-recursion
•
blackhole
•
allow-transfer
Using ACLs, you can control who can access your name server without cluttering
your configuration files with huge lists of IP addresses.
It is a good idea to use ACLs and to control access to your server. Limiting access
to your server by outside parties can help prevent unwanted use of your server.
Here is an example of how to apply ACLs properly:
// Set up an ACL named "bogusnets" that will block RFC1918 space,
// which is commonly used in spoofing attacks.
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};
// Set up an ACL called our-nets. Replace this with the real IP numbers.
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
...
...
allow-query { our-nets; };
allow-recursion { our-nets; };
...
blackhole { bogusnets; };
...
};
zone "example.com" {
type master;
file "example_com.db";
allow-query { any; };
};
6–4 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.2 Security Considerations
This example allows recursive queries of the server from the outside, unless
recursion has been previously disabled. For more information about how to use
ACLs to protect your server, see Section 6.5.2.
6.2.2 Dynamic Update Security
Access to the dynamic update facility should be strictly limited. In earlier
versions of BIND, the only way to do this was to include an IP address or
network prefix in the allow-update zone option. This method is insecure because
the source address of the update UDP packet is easily forged. Also, if the IP
addresses allowed by the allow-update option include the address of a slave
server that performs forwarding of dynamic updates, the master can be trivially
attacked by sending the update to the slave, which will forward it to the master
with its own source IP address. This causes the master to approve the update
without question.
For these reasons, updates should be authenticated cryptographically by means of
transaction signatures (TSIG). That is, the allow-update option should list only
TSIG key names, not IP addresses or network prefixes. Alternatively, you can use
the new update-policy option.
Some sites choose to keep all dynamically updated DNS data in a subdomain
and to delegate that subdomain to a separate zone. This way, the top-level zone
containing critical data, such as the IP addresses of public web and mail servers,
need not allow dynamic updates at all.
For information about setting up dynamic updates, see Section 6.5.7.
6.2.3 TSIG
This section describes how to set up Transaction Signatures (TSIG) transaction
security in BIND. It describes changes to the configuration file as well as the
changes that are required for different features, including the process of creating
transaction keys and how to use transaction signatures with BIND.
BIND primarily supports TSIG for server-to-server communication. This includes
zone transfer, notify, and recursive query messages.
TSIG is useful for dynamic updating. A primary server for a dynamic zone should
use access control to control updates, but IP-based access control is insufficient.
Key-based access control is far superior. To use TSIG with the nsupdate utility,
specify either the -k or -y option on the NSUPDATE command line. For more
information about using the nsupdate utility, see Section 6.5.7.3.
Use the following procedure to implement TSIG:
1. Generate shared keys for each pair of hosts.
You can generate shared keys automatically, or you can specify them
manually. In the example that follows, a shared secret is generated to be
shared between HOST1 and HOST2. The key name is host1-host2. The key
name must be the same on both hosts.
Longer keys are better, but shorter keys are easier to read. The maximum
key length is 512 bits; keys longer than that will be digested with MD5
to produce a 128-bit key. Use the dnssec-keygen utility to generate keys
automatically.
The following command generates a 128-bit (16-byte) HMAC-MD5 key:
$ dnssec_keygen -a hmac-md5 -b 128 -n HOST host1-host2.
Configuring and Managing BIND Version 9 6–5
Configuring and Managing BIND Version 9
6.2 Security Considerations
In this example, the key is in the file KHOST1-HOST2.157-00000_PRIVATE.
Nothing uses this file directly, but the base-64 encoded string following
Key: can be extracted from the file and can be used as a shared secret. For
example:
Key: La/E5CjG9O+os1jq0a2jdA==
The string La/E5CjG9O+os1jq0a2jdA= = can be used as the shared secret.
Keys can also be specified manually. The shared secret is a random sequence
of bits, encoded in base-64. Most ASCII strings are valid base-64 strings
(assuming the length is a multiple of 4 and that only valid characters are
used).
2. Copy the shared secret to both hosts.
Use a secure transport mechanism like a floppy disk, or a physically secure
network, to copy the shared secret between hosts.
3. Inform the servers of the key’s existence.
In the following example, HOST1 and HOST2 are both servers. Add the
following to each server’s TCPIP$BIND.CONF file:
key host1-host2. {
algorithm hmac-md5;
secret "La/E5CjG9O+os1jq0a2jdA==";
};
The HMAC-MD5 algorithm is the only one supported by BIND. It is
recommended that either TCPIP$BIND.CONF not be world readable, or
that the key statement be added to a nonworld readable file that is included
by TCPIP$BIND.CONF. For information about the key statement, see
Section 6.5.3.4.
Once the configuration file is reloaded, the key is recognized. This means that
if the server receives a message signed by this key, it can verify the signature.
If the signature succeeds, the response is signed by the same key.
4. Instruct the server to use the key.
Because keys are shared only between two hosts, the server must be told
when keys are to be used. Add the following to the TCPIP$BIND.CONF file
for HOST1. The IP address of HOST2 is 10.1.2.3.
server 10.1.2.3 {
keys { host1-host2. ;};
};
Multiple keys can be present, but only the first is used. This statement does
not contain any secrets, so you can include it in a world-readable file.
If HOST1 sends a message that is a request to that address, the message will
be signed with the specified key. HOST1 will expect any responses to signed
messages to be signed with the same key.
A similar statement must be present in HOST2’s configuration file (with
HOST1’s address) for HOST2 to sign request messages to HOST1.
5. Implement TSIG key-based access control.
You can specify TSIG keys in ACL definitions and in the following
configuration options:
•
allow-query
•
allow-transfer
6–6 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.2 Security Considerations
•
allow-update
For the key named HOST1-HOST2., specify the following allow-update
option:
allow-update { key host1-host2. ;};
This statement allows dynamic updates to succeed only if the request was
signed by a key named HOST1-HOST2.
6. Reload the configuration file.
Changes to the configuration file will not take effect until the configuration
file is reloaded. You can use one of several methods to reload the configuration
file:
The rndc utility
The TCP/IP management command SET NAME/INITIALIZE
Stopping and restarting the BIND server
7. Handle any errors.
The processing of TSIG-signed messages can result in several types of
errors. If a signed message is sent to a non-TSIG aware server, an error
is returned because the server will not understand the record. This is a
result of misconfiguration; the server must be configured explicitly to send a
TSIG-signed message to a specific server.
If a TSIG-aware server receives a message signed by an unknown key, the
response is unsigned and an error is returned.
If a TSIG-aware server receives a message with a signature that is not
validated, the response is unsigned and an error is returned.
If a TSIG aware server receives a message with a time outside of the allowed
range, the response is signed, an error is returned, and the time values are
adjusted so that the response can be successfully verified.
6.2.4 TKEY
TKEY is a mechanism for automatically generating a shared secret between two
hosts. There are several modes of TKEY that specify how the key is generated or
assigned. BIND implements only the Diffie-Hellman key exchange. Both hosts
are required to have a Diffie-Hellman KEY record (although this record is not
required to be present in a zone). The TKEY process must use messages signed
either by TSIG or SIG(0). The result of TKEY is a shared secret that can be used
to sign messages with TSIG. TKEY can also be used to delete shared secrets that
it had previously generated.
The TKEY process is initiated by a client or server by sending a signed TKEY
query (including any appropriate KEYs) to a TKEY-aware server. The server
response, if it indicates success, contains a TKEY record and any appropriate
keys. After this exchange, both participants have enough information to
determine the shared secret. When Diffie-Hellman keys are exchanged, the
shared secret is derived by both participants.
Configuring and Managing BIND Version 9 6–7
Configuring and Managing BIND Version 9
6.2 Security Considerations
6.2.5 SIG(0)
BIND Version 9 partially supports DNSSEC SIG(0) transaction signatures (as
specified in RFC 2535).
SIG(0) uses public and private keys to authenticate messages. Access control is
performed in the same manner as TSIG keys; privileges can be granted or denied
based on the key name. When a SIG(0) signed message is received, it is verified
only if the key is known and trusted by the server; the server does not attempt to
locate and validate the key.
SIG(0) signing of multiple-message TCP streams is not supported. BIND Version
9 does not include any tools that generate SIG(0) signed messages.
6.2.6 DNSSEC
Cryptographic authentication of DNS information is implemented using the DNS
Security (DNSSEC) extensions (defined in RFC 2535). This section describes how
to create and use DNSSEC signed zones.
BIND Version 9 provides several tools that are used in the process of creating and
using DNSSEC signed zones. These tools include:
•
The dnssec_keygen utility, which generates keys for DNSSEC (secure DNS)
and TSIG (transaction signatures).
•
The dnssec_makekeyset utility, which generates a key set.
•
The dnssec_signkey utility, which signs a key set.
•
The dnssec_signzone utility, which signs a zone.
For detailed information about these utilities, see Section 6.10. In all cases, the
-h option displays a full list of parameters. Note that the DNSSEC tools require
the keyset and signedkey files to be in the working directory.
Administrators of the parent and child zones must agree on keys and signatures.
A zone’s security status must be indicated by the parent zone for a DNSSECcapable resolver to trust its data.
For other servers to trust data in this zone, they must be statically configured
either with this zone’s zone key or with the zone key of another zone above this
one in the DNS tree.
Use the following procedure to set up DNSSEC secure zones:
1. Generate keys.
To generate keys, use the dnssec_keygen program.
A secure zone must contain one or more zone keys. The zone keys sign all
other records in the zone, as well as the zone keys of any secure delegated
zones. Zone keys must have the same name as the zone, must have a name
type of ZONE, and must be usable for authentication.
The following command generates a 768-bit DSA key for the child.example
zone:
$ dnssec_keygen -a DSA -b 768 -n ZONE child.example.
Two output files are produced: KCHILD_EXAMPLE.003-12345_KEY and
KCHILD_EXAMPLE.003-12345_PRIVATE (where 12345 is the key tag). The
key file names contain the key name (child_example.), the algorithm (3 is
DSA, 1 is RSA), and the key tag (12345, in this case). The private key (in
6–8 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.2 Security Considerations
the _PRIVATE file) is used to generate signatures, and the public key (in the
_KEY file) is used verify signatures.
To generate another key with the same properties (but with a different key
tag), repeat the preceding command.
Insert the public keys into the zone file using $INCLUDE statements that
specify the _KEY files.
2. Create a key set.
To create a key set from one or more keys, use the dnssec_makekeyset utility.
After the zone keys are generated, a key set must be built for transmission
to the administrator of the parent zone, so that the parent zone can sign the
keys with its own zone key and indicate correctly the security status of this
zone. When building a key set, the list of keys to be included and the TTL
value of the set must be specified; the desired signature validity period of the
parent’s signature can also be specified.
The list of keys to be inserted into the key set can also include nonzone keys
present at the top of the zone.
The following command generates a key set containing the key generated in
the preceding example and another key similarly generated, with a TTL of
3600 and a signature validity period of 10 days starting from now:
$ dnssec_makekeyset -t 3600 -e +864000 KCHILD_EXAMPLE.003-12345 _$ KCHILD_EXAMPLE.003-23456
One output file is produced: KEYSET-CHILD_EXAMPLE.DAT. This file
should be transmitted to the parent to be signed. It includes the keys as well
as signatures covering keys. The signatures prove that you have the private
key that corresponds to the public key. The signatures also have the validity
period encoded in them.
3. Sign the child’s keyset.
To sign one child’s keyset, use the dnssec_signkey utility.
If the child.example zone has any delegations which are secure (for example,
grand.child.example), the child.example administrator should receive
keyset files for each secure subzone. These keys must be signed by this zone’s
zone keys.
The following command signs the child’s key set with the zone keys:
$ dnssec_signkey KEYSET-GRAND_CHILD_EXAMPLE.DAT KCHILD_EXAMPLE.003-12345 _$ KCHILD_EXAMPLE.003-23456
One output file is produced: SIGNEDKEY-GRAND_CHILD_EXAMPLE.DAT.
This file should be both transmitted back to the child and retained. It
includes all keys (the child’s keys) from the keyset file and signatures
generated by this zone’s zone keys.
4. Sign the zone.
To sign a zone, use the dnssec_signzone utility.
Any signed key files corresponding to secure subzones should be present, as
well as a signed key file for this zone generated by the parent (if there is one).
The zone signer generates NXT and SIG records for the zone, incorporates
the zone key signature from the parent, and indicates the security status at
all delegation points.
Configuring and Managing BIND Version 9 6–9
Configuring and Managing BIND Version 9
6.2 Security Considerations
Before signing the zone, add the KEY record to the zone database file using
the $INCLUDE statement. For example:
$INCLUDE KCHILD_EXAMPLE.003-12345_KEY
The following command signs the zone, assuming it is in a file called ZONE_
CHILD_EXAMPLE.DB. By default, all zone keys that have an available
private key are used to generate signatures.
$ dnssec_signzone -o child.example ZONE_CHILD_EXAMPLE.DB
One output file is produced: ZONE_CHILD_EXAMPLE.DB_SIGNED. This
file should be referenced by TCPIP$BIND.CONF as the input file for the zone.
5. Configure the servers.
Unlike BIND Version 8, data is not verified when the BIND Version 9
software is loaded. Therefore, zone keys for authoritative zones do not need
to be specified in the configuration file. The public key for any security
root must be present in the configuration file’s trusted-keys statement, as
described in Section 6.5.
6.3 Migrating from BIND Version 4 to BIND Version 9
If you set up your BIND environment using an old version of the TCP/IP Services
product, you must convert the UCX databases and configuration information to
the BIND Version 9 format.
To convert your BIND configuration, enter the following command:
TCPIP> CONVERT/CONFIGURATION BIND
This command extracts the BIND-specific configuration information from
UCX$CONFIGURATION.DAT and creates the BIND Version 9 configuration file
TCPIP$BIND.CONF. It renames your BIND databases, where necessary.
You can continue to use the SET CONFIGURATION BIND commands to make
changes to your configuration (see Section 6.8), or you can make changes by
editing the text file TCPIP$BIND.CONF (see Section 6.5). If you continue to
use the SET CONFIGURATION BIND commands, you must also enter the
CONVERT/CONFIGURATION BIND command in order for your changes to take
effect.
6.3.1 Navigating Two Different BIND Environments
This section summarizes the differences between the UCX BIND implementation
and BIND Version 9.
Remember that, in BIND Version 9, name servers are configured by editing a text
configuration file. The use of this file is described in Section 6.5. HP recommends,
but does not require, that you use the configuration file to set up BIND. You can
continue using the TCPIP$CONFIG and the SET CONFIGURATION BIND
commands to set up your BIND environment, as you did with previous releases
of this product. The term UCX BIND in Table 6–1 describes the previous
configuration method even though this method is still valid in the current release.
Table 6–1 describes changes to the database and configuration file names.
6–10 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.3 Migrating from BIND Version 4 to BIND Version 9
Table 6–1 UCX BIND and BIND Version 9 Differences
Database/File Names
UCX BIND
BIND Version 9
Configuration information
UCX$CONFIGURATION.DAT
TCPIP$BIND.CONF
Local loopback files
NAMED.LOCAL
LOCALHOST.DB,
127_0_0.DB
Forward lookup file
domain_name.DB
domain_name.DB
Reverse lookup file
address.DB
address.DB
Cache file
NAMED.CA
ROOT.HINT
Note
You must be consistent when making changes to your BIND environment.
If you make changes by editing the configuration file, you should continue
to make changes in that manner.
If you revert to the UCX BIND configuration method (SET
CONFIGURATION BIND and CONVERT/CONFIGURATION
BIND commands), any changes you made to the configuration file
(TCPIP$BIND.CONF) are lost.
If you continue to use the SET CONFIGURATION BIND commands, you
must always enter the CONVERT/CONFIGURATION BIND command in
order for your changes to take effect.
6.4 BIND Service Startup and Shutdown
The BIND service can be shut down and started independently of TCP/IP
Services. The following files are provided for this purpose:
•
SYS$STARTUP:TCPIP$BIND_STARTUP.COM allows you to start the BIND
service.
•
SYS$STARTUP:TCPIP$BIND_SHUTDOWN.COM allows you to shut down
the BIND service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services.
•
SYS$STARTUP:TCPIP$BIND_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when the BIND
service is started.
•
SYS$STARTUP:TCPIP$BIND_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
BIND service is shut down.
6.5 Configuring the BIND Server
This section describes how to configure the BIND name server on your local host.
BIND Version 9 configuration is broadly similar to BIND Version 8; however,
there are a few new areas of configuration, such as views. BIND Version 8
configuration files should work with few alterations in BIND Version 9, although
you should review more complex configurations to see whether they can be
implemented more efficiently using the new features in BIND Version 9.
Configuring and Managing BIND Version 9 6–11
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
BIND Version 9 stores configuration information in a text file called
TCPIP$BIND.CONF. The TCP/IP Services product provides a template for
this file in the SYS$SPECIFIC:[TCPIP$BIND] directory. Before starting BIND,
edit this template to reflect your site-specific configuration requirements.
6.5.1 Configuration File Elements
Table 6–2 lists the elements used throughout the BIND Version 9 configuration
file documentation.
Table 6–2 Name Server Configuration File Elements
Element
Description
acl_name
The name of an address_match_list as defined by the
statement.
address_match_list
A list of one or more of the following elements:
•
ip_addr
•
ip_prefix
•
key_id
•
acl_name
acl
See Section 6.5.2 for more information.
domain_name
A quoted string that will be used as a DNS name. For
example:
"my.test.domain"
dotted_decimal
One or more integers valued 0 through 255 and separated
by dots, such as 123, 45.67 or 89.123.45.67.
ip4_addr
An IPv4 address with exactly four elements in dotted
decimal notation.
ip6_addr
ip_addr
ip_port
An IPv6 address, such as
ip_prefix
An IP network specified as an ip_addr, followed by a
slash (/) and then the number of bits in the netmask.
Trailing zeros in an ip_addr can be omitted. For
example, 127/8 is the network 127.0.0.0 with netmask
255.0.0.0 and 1.2.3.0/28 is network 1.2.3.0 with netmask
255.255.255.240.
key_id
A domain name representing the name of a shared key, to
be used for transaction security.
key_list
A list of one or more key_ids, separated by semicolons and
ending with a semicolon.
number
A nonnegative integer with an entire range limited by the
range of a C language signed integer (2,147,483,647 on a
machine with 32-bit integers). Its acceptable value might
be limited further by the context in which it is used.
fe80::200:f8ff:fe01:9742.
An ip4_addr or ip6_addr.
An IP port number from 0 to 65535. Values below 1024
are restricted to well-known processes. In some cases, an
asterisk (*) character can be used as a placeholder to select
a random high-numbered port.
(continued on next page)
6–12 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–2 (Cont.) Name Server Configuration File Elements
Element
Description
path_name
A quoted string that will be used as a path name. For
example:
"SYS$SPECIFIC:[TCPIP$BIND]"
size_spec
A number, the word unlimited, or the word default.
The maximum value of size_spec is that of unsigned
long integers on the machine. An unlimited size_spec
requests unlimited use, or the maximum available amount.
A default size_spec uses the limit that was in force
when the server was started. A number can optionally be
followed by a scaling factor:
•
K (or k) for kilobytes, which scales by 1024
•
M (or m) for megabytes, which scales by 1024*1024
•
G (or g) for gigabytes, which scales by 1024*1024*1024
Integer storage overflow is silently ignored during
conversion of scaled values, resulting in values less than
intended, possibly even negative. Using the unlimited
keyword is the best way to safely set a really large number.
yes_or_no
Either yes or no. The words true and
accepted, as are the numbers 1 and 0.
dialup_option
One of the following:
•
yes
•
no
•
notify
•
notify-passive
•
refresh
•
passive
false are also
When used in a zone, notify-passive, refresh, and
passive are restricted to slave and stub zones.
6.5.2 Address Match Lists
Address match lists are used primarily to determine access control for server
operations. They are also used to define priorities for querying other name
servers and to set the addresses on which the BIND server listens for queries.
The following example shows the syntax of the address match list:
address_match_list = address_match_list_element ;
[ address_match_list_element; ... ]
address_match_list_element = [ ! ] (ip_address [/length] |
key key_id | acl_name | { address_match_list } )
The elements that constitute an address match list can be any of the following:
•
An IP address (IPv4 or IPv6)
•
An IP prefix (in the / notation)
•
A key ID, as defined by the key statement
•
The name of an address match list previously defined with the acl statement
Configuring and Managing BIND Version 9 6–13
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
•
A nested address match list enclosed in braces
Elements can be negated with a leading exclamation mark (!). The match list
names any, none, localhost, and localnets are predefined. More information
on those names can be found in the description of the acl statement (see
Section 6.5.3.1).
When a given IP address or prefix is compared to an address match list, the list
is traversed in order until an element matches. The interpretation of a match
depends on whether the list is being used for access control, defining listen-on
ports, or as a topology, and whether the element was negated. Specifically:
•
When used as an access control list, a non-negated match allows access and
a negated match denies access. If there is no match, access is denied. The
following options use address match lists for this purpose:
allow-notify
allow-query
allow-transfer
allow-update
blackhole
The listen-on option causes the server not to accept queries on any of the
machine’s addresses that do not match the list.
•
When used with the topology statement, a nonnegated match returns a
distance based on its position on the list; the closer the match is to the start
of the list, the shorter the distance between it and the server. A negated
match is assigned the maximum distance from the server. If there is no
match, the address gets a distance that is further than any nonnegated list
element and closer than any negated element.
Because of the first-match aspect of the algorithm, an element that defines a
subset of another element in the list should come before the broader element,
regardless of whether either is negated. For example, in 1.2.3/24; ! 1.2.3.13;,
the 1.2.3.13 element is ignored, because the algorithm will match any lookup
for 1.2.3.13 to the 1.2.3/24 element. Using ! 1.2.3.13; 1.2.3/24 corrects that
problem by having 1.2.3.13 blocked by the negation, while all other 1.2.3.* hosts
fall through.
6.5.3 Configuration File Format
A BIND configuration file consists of statements and comments. Statements end
with a semicolon. Many statements contain a block of substatements that also
end with a semicolon. Table 6–3 describes the configuration statements.
Table 6–3 BIND Name Server Configuration Statements
Statement
Description
acl
Specifies a named IP address matching list, for access
control and other uses.
controls
include
Declares control channels to be used by the
rndc utility.
Includes a file.
(continued on next page)
6–14 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–3 (Cont.) BIND Name Server Configuration Statements
Statement
Description
key
Specifies key information for use in authentication and
authorization using TSIG. See Section 6.2.3 for more
information.
logging
Specifies what the server logs, and where the log messages
are sent.
options
Controls global server configuration options and sets
defaults for other statements.
server
Sets configuration options, and sets defaults for other
statements.
trusted-keys
view
zone
Specifies trusted DNSSEC keys.
Specifies a view.
Specifies a zone.
The following sample is a configuration file for a master server:
options {
directory "SYS$SPECIFIC:[TCPIP$BIND]";
};
zone "FRED.PARROT.BIRD.COM" in {
type master;
file "FRED_PARROT_BIRD_COM.DB";
};
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "127_0_0.DB";
};
zone "LOCALHOST" in {
type master;
file "LOCALHOST.DB";
};
zone "208.20.16.IN-ADDR.ARPA" in {
type master;
file "208_20_16_IN-ADDR_ARPA.DB";
};
zone "." in {
type hint;
file "ROOT.HINT";
};
The following comment styles are valid in a BIND configuration file. Comments
can appear anywhere in the file.
•
C-style comments that start with /* and end with */
•
C++ style comments that start with // and continue to the end of the physical
line
•
Shell or Perl-style comments that start with # and continue to the end of the
physical line
Configuring and Managing BIND Version 9 6–15
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Note
Do not use a semicolon (;) as a comment character in your configuration
file. The semicolon indicates the end of a configuration statement;
whatever follows is interpreted as the start of the next statement.
6.5.3.1 The ACL Statement
The acl statement assigns a symbolic name to an address match list. It gets its
name from a primary use of address match lists: access control lists (ACLs).
Note
The access control lists used by the BIND service and OpenVMS ACLs
are different structures with different purposes.
The acl statement is formatted as follows:
acl acl-name {
address_match_list
};
Note that the address match list must be defined with acl before it can be used
elsewhere; forward references are not allowed.
The following ACLs are created automatically:
ACL
Matches
any
none
localhost
localnets
All hosts
No hosts
The IPv4 addresses of all interfaces on the system
Any host on an IPv4 network for which the system has an
interface
The ACLs localhost and localnets do not support IPv6. The ACL localhost
does not match the host’s IPv6 addresses, and the ACL localnets does not match
the host’s attached IPv6 networks. This limitation is due to the fact that there is
no standard method for determining the complete set of local IPv6 addresses for
a host.
6.5.3.2 The CONTROLS Statement
The controls statement declares control channels to be used by system
administrators to affect the operation of the local name server. These control
channels are used by the rndc utility to send commands to, and retrieve non-DNS
results from, a name server. The controls statement is formatted as follows:
controls {
inet ( ip_addr | * ) [ port ip_port ] allow { address_match_list }
keys { key_list };
[ inet ...; ]
};
6–16 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
An inet control channel is a TCP/IP socket listening at the specified ip_port on
the specified ip_addr, which can be either an IPv4 or IPv6 address. The asterisk
character (*) is interpreted as the IPv4 wildcard address; connections are accepted
on any of the system’s IPv4 addresses. To listen on the IPv6 wildcard address,
use :: for the ip_addr. If you use the rndc utility only on the local host, use the
local loopback address (127.0.0.1, or ::) for maximum security.
The ability to issue commands over the control channel is restricted by the
allow and keys clauses. Connections to the control channel are permitted based
on the address permissions in the address match list. key_id members of the
address match list are ignored, and instead are interpreted independently based
the key_list. Each key_id in the key_list is used to authenticate commands
and responses given over the control channel, by digitally signing each message
between the server and a command client. In order to be honored, all commands
to the control channel must be signed by one of its specified keys.
If no controls statement is present, the BIND server will set up a default control
channel listening on the loopback address 127.0.0.1 and its IPv6 counterpart ::1.
In this case, and also when the controls statement is present but does not have
a keys clause, the BIND server attempts to load the command channel key from
the file RNDC.KEY in TCPIP$ETC. To create a RNDC.KEY file, use the following
command:
rndc_confgen -a
See Section 6.10 for more information about using the rndc utility.
The RNDC.KEY feature eases the transition of systems from BIND Version 8,
which did not have digital signatures on its command channel messages and
thus did not have a keys clause. You can use an existing BIND Version 8
configuration file in BIND Version 9 unchanged, and rndc will work the same
way that ndc worked in BIND Version 8.
Because the RNDC.KEY feature is only intended to allow the backwardcompatible usage of BIND Version 8 configuration files, this feature does not
have a high degree of configurability. You cannot easily change the key name or
the size of the secret. You should make a RNDC.CONF file with your own key if
you wish to change those things.
The UNIX control channel type of BIND Version 8 is not supported in BIND
Version 9 and is not expected to be added in future releases. If it is present in the
controls statement from a BIND Version 8 configuration file, it is ignored and a
warning is logged.
To disable the command channel, use an empty controller statement. For
example:
controls { };
6.5.3.3 The INCLUDE Statement
The include statement inserts the specified file at the point that the include
statement is encountered. The include statement facilitates the administration
of configuration files by permitting the reading or writing of some things but not
others. For example, the statement could include private keys that are readable
only by a name server. The following example shows the format of the include
statement:
include filename;
Configuring and Managing BIND Version 9 6–17
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
6.5.3.4 The KEY Statement
The key statement defines a shared secret key for use with TSIG (see
Section 6.2.3). The following example shows the format of the key statement:
key key_id {
algorithm algorithm-id;
secret secret-string;
};
The key statement can occur at the top level of the configuration file or inside
a view statement. Keys defined in top-level key statements can be used in all
views. Keys intended for use in a controls statement must be defined at the top
level.
Table 6–4 describes the elements of the key statement.
Table 6–4 Key Statement Elements
Element
Description
key_id
Specifies a domain name that uniquely identifies the key
(also known as the key name). It can be used in a server
statement to cause requests sent to that server to be signed
with this key, or in address match lists to verify that
incoming requests have been signed with a key matching
this name, algorithm, and secret.
algorithm-id
Specifies an authentication algorithm. The only algorithm
currently supported with TSIG authentication is HMACMD5.
secret-string
Specifies the secret to be used by the algorithm; treated as
a Base-64 encoded string.
6.5.3.5 The LOGGING Statement
The logging statement configures a wide variety of logging options for the name
server. Its channel phrase associates output methods, format options and severity
levels with a name that can then be used with the category phrase to select the
way each class of message is logged. The following example shows the format of
the logging statement:
logging {
[ channel channel_name {
( file path_name
[size size_spec]
| syslog | stderr | null );
[ severity (critical | error | warning | notice |
info | debug [ level ] | dynamic ); ]
[ print-category yes_or_no; ]
[ print-severity yes_or_no; ]
[ print-time yes_or_no; ]
}; ]
[ category category_name {
channel_name ; [ channel_name ; ... ]
}; ]
...
};
6–18 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Use one logging statement to define as many channels and categories as you
want. If there is no logging statement, the logging configuration defaults to the
following:
logging {
category "unmatched" { "null"; };
category "default" { "default_syslog"; "default_debug"; };
};
In BIND Version 9, the logging configuration is only established after the entire
configuration file has been parsed. In BIND Version 8, it was established as soon
as the logging statement was parsed. When the server is starting up, all logging
messages regarding syntax errors in the configuration file go to the default
channels.
6.5.3.5.1 The Channel Phrase All log output goes to one or more channels; you
can make as many of them as you want. Every channel definition must include
a destination clause that says whether messages selected for the channel go to
a file (by default, TCPIP$BIND_RUN.LOG), or are discarded. It can optionally
also limit the message severity level that is accepted by the channel (the default
is info); and can specify whether to include a time stamp, the category name and
severity level (the default is not to include any).
The null destination clause causes all messages sent to the channel to be
discarded; in that case, other options for the channel are meaningless.
The file destination clause directs the channel to a disk file. The size option
for files is used to limit log file growth. The parameter (size_spec) is specified
in bytes, but shorthand notation can be used (for example, 100K, or 2M for 2
MB). If the file exceeds the size, the BIND server stops writing to the file; no file
version rollover occurs. After that, no data is written to the file until the server is
restarted, reloaded, or until the file is truncated manually.
On OpenVMS, the syslog and stderr destination clauses direct the channel to
the TCPIP$BIND_RUN.LOG file.
The severity clause allows you to specify the level of diagnostic messages to be
logged.
The server can supply extensive debugging information when it is in debugging
mode. If the server’s global debug level is greater than zero, then debugging
mode is activated. The global debug level is set by one of the following:
•
Starting the BIND server with the -d flag followed by a positive integer.
•
Entering the trace command with the rndc utility. To set the global debug
level to zero and turn off debugging mode, enter the the notrace command.
All debugging messages in the server have a debug level; higher debug levels
give more detailed output. Channels that specify a debug severity level get the
specified debugging output and less any time the server is in debugging mode,
regardless of the global debugging level. For example, to produce debugging
output at level 3 and less, enter the following:
channel "specific_debug_level" {
file "foo";
severity debug 3;
};
Channels with dynamic severity use the server’s global level to determine what
messages to display.
Configuring and Managing BIND Version 9 6–19
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
If print-time is turned on, the date and time are logged. If print-category is
requested, then the category of the message is logged as well. Finally, if printseverity is turned on, then the severity level of the message is logged. The
print- options can be used in any combination and are always displayed in the
following order:
1. Time
2. Category
3. Severity
The following example specifies all three print- options:
28-Feb-2000 15:05:32.863 general: notice: running
Four predefined channels are used for the BIND server’s default logging, as
shown in the following example. Section D.3.1.2 describes how these channels are
used.
channel "default_syslog" {
syslog daemon;
severity info;
// send to TCPIP$BIND_RUN.LOG
// only send priority info
// and higher
};
channel "default_debug" {
file "TCPIP$BIND_RUN.LOG";
severity dynamic;
// write to the TCPIP$BIND_RUN.LOG
// log at the server’s
// current debug level
};
channel "default_stderr" {
stderr;
severity info;
// write to TCPIP$BIND_RUN.LOG
// only send priority info
// and higher
};
channel "null" {
null;
// discard anything sent to
// this channel
};
The default_debug channel only produces output when the server’s debug level
is not zero. By default, the BIND server writes to the TCPIP$BIND_RUN.LOG
file.
Once a channel is defined, it cannot be redefined. Thus, you cannot alter the
built-in channels directly, but you can modify the default logging by pointing
categories at channels you have defined.
6.5.3.5.2 The Category Phrase There are many categories, so you can send the
logs you want to see anywhere, without seeing logs you do not want. If you do not
specify a list of channels for a category, then log messages in that category are
sent to the default category instead. If you do not specify a default category, the
following definition is used:
category default { default_syslog; default_debug; };
6–20 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
For example, if you want to log security events to a file but you also want to
preserve the default logging behavior, specify the following:
channel my_security_channel {
file "my_security_file";
severity info;
};
category security {
"my_security_channel";
default_syslog;
default_debug;
};
To discard all messages in a category, specify the null channel:
category lame-servers { null; };
category cname { null; };
Table 6–5 describes the logging categories.
Table 6–5 Logging Categories
Category
Meaning
default
The logging options for those categories where no specific configuration
has been defined.
general
database
The default category for messages that are not classified.
security
config
resolver
Approval and denial of requests.
xfer-in
xfer-out
notify
client
unmatched
Zone transfers the server is receiving.
network
update
queries
dispatch
Network operations.
dnssec
lame-servers
DNSSEC and TSIG protocol processing.
Messages relating to the databases used internally by the name server
to store zone and cache data.
Configuration file parsing and processing.
DNS resolution, such as the recursive lookups performed on behalf of
clients by a caching name server.
Zone transfers the server is sending.
The NOTIFY protocol.
Processing of client requests.
Messages for which the BIND server was unable to determine the
class, or for which there was no matching view. A one-line summary is
also logged to the client category.
Dynamic updates.
Queries. Using this category enables query logging.
Dispatching of incoming packets to the server modules where they are
to be processed.
Lame servers (misconfigurations in remote servers, discovered by BIND
9 when trying to query those servers during resolution).
Configuring and Managing BIND Version 9 6–21
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
6.5.3.6 The OPTIONS Statement
The options statement sets up global options to be used by BIND. This statement
should appear only once in a configuration file. If more than one occurrence is
found, the first occurrence determines the actual options used, and a warning is
generated. If there is no options statement, an options block with each option
set to its default is used.
The options statement has the following syntax:
options {
[ version version_string; ]
[ directory path_name; ]
[ named-xfer path_name; ]
[ tkey-domain domainname; ]
[ tkey-dhkey key_name key_tag; ]
[ dump-file path_name; ]
[ memstatistics-file path_name; ]
[ pid-file path_name; ]
[ statistics-file path_name; ]
[ zone-statistics yes_or_no; ]
[ auth-nxdomain yes_or_no; ]
[ deallocate-on-exit yes_or_no; ]
[ dialup dialup_option; ]
[ fake-iquery yes_or_no; ]
[ fetch-glue yes_or_no; ]
[ has-old-clients yes_or_no; ]
[ host-statistics yes_or_no; ]
[ minimal-responses yes_or_no; ]
[ multiple-cnames yes_or_no; ]
[ notify yes_or_no | explicit; ]
[ recursion yes_or_no; ]
[ rfc2308-type1 yes_or_no; ]
[ use-id-pool yes_or_no; ]
[ maintain-ixfr-base yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ check-names ( master | slave | response )( warn | fail | ignore ); ]
[ allow-notify { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ allow-recursion { address_match_list }; ]
[ allow-v6-synthesis { address_match_list }; ]
[ blackhole { address_match_list }; ]
[ listen-on [ port ip_port ] { address_match_list }; ]
[ listen-on-v6 [ port ip_port ] { address_match_list }; ]
[ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
[ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
[ max-transfer-time-in number; ]
[ max-transfer-time-out number; ]
[ max-transfer-idle-in number; ]
[ max-transfer-idle-out number; ]
[ tcp-clients number; ]
[ recursive-clients number; ]
[ serial-query-rate number; ]
[ serial-queries number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ transfers-in number; ]
[ transfers-out number; ]
[ transfers-per-ns number; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ notify-source (ip4_addr | *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
6–22 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
max-ixfr-log-size number; ]
cleaning-interval number; ]
heartbeat-interval number; ]
interface-interval number; ]
statistics-interval number; ]
topology { address_match_list }];
sortlist { address_match_list }];
rrset-order { order_spec ; [ order_spec ; ... ] ] };
lame-ttl number; ]
max-ncache-ttl number; ]
max-cache-ttl number; ]
sig-validity-interval number ; ]
min-roots number; ]
use-ixfr yes_or_no ; ]
treat-cr-as-space yes_or_no ; ]
min-refresh-time number ; ]
max-refresh-time number ; ]
min-retry-time number ; ]
max-retry-time number ; ]
port ip_port; ]
additional-from-auth yes_or_no ; ]
additional-from-cache yes_or_no ; ]
random-device path_name ; ]
max-cache-size size_spec ; ]
match-mapped-addresses yes_or_no; ]
};
Table 6–6 through Table 6–14 describe the BIND server configuration options.
Table 6–6 BIND Server Configuration Options
Option
Description
version
The version the server should report using a query of name
version.bind in class CHAOS. The default is the real
version number of this server.
directory
The working directory of the server. Any nonabsolute
path names in the configuration file is assumed to be
relative to this directory. The default location for the server
output file (TCPIP$BIND_RUN.LOG) is this directory. If
a directory is not specified, the working directory defaults
to SYS$SPECIFIC:[TCPIP$BIND]. If you are configuring
a BIND failover environment in an OpenVMS Cluster, the
working directory is defined by the logical TCPIP$BIND_
COMMON.
named-xfer
This option is obsolete. It was used in BIND 8 to specify
the path name to the named-xfer program. In BIND 9, no
separate named-xfer program is needed; its functionality
is built into the name server.
(continued on next page)
Configuring and Managing BIND Version 9 6–23
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–6 (Cont.) BIND Server Configuration Options
Option
Description
tkey-domain
The domain appended to the names of all shared keys
generated with TKEY. When a client requests a TKEY
exchange, it may or may not specify the desired name for
the key. If present, the name of the shared key is formatted
as follows:
"client specified part" + "tkey-domain"
If it is not present, the name of the shared key is formatted
as follows:
"random hex digits" + "tkey-domain"
In most cases, the domain name should be the server’s
domain name.
tkey-dhkey
The Diffie-Hellman key used by the server to generate
shared keys with clients using the Diffie-Hellman mode
of TKEY. The server must be able to load the public and
private keys from files in the working directory. In most
cases, the key name should be the server’s host name.
dump-file
The path name of the file the server dumps the database to
when instructed to do so with the rndc dumpdb command.
If not specified, the default is TCPIP$BIND_DUMP.DB.
memstatistics-file
The path name of the file the server writes memory
usage statistics to on exit. If not specified, the default
is TCPIP$BIND.MEMSTATS.
This option is not yet implemented.
pid-file
The path name of the file in which the server writes its
process ID. If the path name is not specified, the default is
TCPIP$BIND.PID. The PID file is used by programs that
want to send signals to the running name server.
statistics-file
The path name of the file to which the server appends
statistics when instructed to do so with the rndc
stats command. If not specified, the default is
TCPIP$BIND.STATS in the server’s current directory.
The format of the file is described in Section 6.5.3.6.14.
port
The UDP/TCP port number the server uses for receiving
and sending DNS protocol traffic. The default is 53. This
option is intended mainly for server testing; a server using
a port other than 53 cannot communicate with the global
DNS. The port option should be placed at the beginning of
the options block, before any other options that take port
numbers or IP addresses, to ensure that the port value
takes effect for all addresses used by the server.
random-device
The source of entropy to be used by the server. Entropy
is needed primarily for DNSSEC operations, such as
TKEY transactions and dynamic update of signed zones.
This option specifies the file from which to read entropy.
Operations requiring entropy fail when the file has been
exhausted. If this option is not specified, entropy does not
take place.
The random-device option takes effect during the initial
configuration load at server startup time and is ignored on
subsequent reloads.
6–24 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–7 describes the Boolean BIND server
6.5.3.6.1 Boolean Options
configuration options.
Table 6–7 BIND Server Boolean Configuration Options
Option
Description
auth-nxdomain
If YES, then the AA bit is always set on NXDOMAIN
responses, even if the server is not actually authoritative.
The default is NO. This is a change from BIND Version 8.
If you are upgrading from old software, you might need to
set this option to YES.
deallocate-on-exit
This option was used in BIND Version 8 to enable checking
for memory leaks on exit. BIND Version 9 ignores this
option and always performs the checks.
dialup
If YES, then the server treats all zones as if they are doing
zone transfers across a dial-on-demand dialup link, which
can be brought up by traffic originating from this server.
This has different effects according to zone type, and it
concentrates the zone maintenance so that it all happens
in a short interval, once every heartbeat-interval and
during the one call. It also suppresses some of the normal
zone maintenance traffic. The default is NO.
The dialup option can also be specified in the view and
zone statements. In these cases, it overrides the global
dialup option.
If the zone is a master zone, the server sends out a NOTIFY
request to all the slaves. This triggers the zone serial
number check in the slave (providing it supports NOTIFY),
allowing the slave to verify the zone while the connection is
active. If the zone is a slave or stub zone, then the server
suppresses the regular ‘‘zone up to date’’ (refresh) queries
and performs them only when the heartbeat-interval
expires, in addition to sending NOTIFY requests.
Finer control can be achieved by using the following
options:
•
notify, which sends only NOTIFY messages.
•
notify-passive, which sends NOTIFY messages and
suppresses the normal refresh queries.
•
refresh, which suppresses normal refresh processing
and sends refresh queries when the heartbeatinterval expires.
•
passive, which disables normal refresh processing.
fake-iquery
In BIND Version 8, this option was used to enable
simulating the obsolete DNS query type IQUERY. BIND
Version 9 never does IQUERY simulation.
fetch-glue
This option is obsolete. In BIND Version 8, this option
caused the server to attempt to fetch glue resource records
it lacked when constructing the additional data section of a
response. In BIND Version 9, the server does not fetch glue
resource records.
(continued on next page)
Configuring and Managing BIND Version 9 6–25
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–7 (Cont.) BIND Server Boolean Configuration Options
Option
Description
has-old-clients
This option was incorrectly implemented in BIND Version 8
and is ignored by BIND Version 9.
host-statistics
In BIND Version 8, this option enabled the keeping of
statistics for every host with which the name server
interacts. This option is not implemented in BIND Version
9.
maintain-ixfr-base
This option is obsolete. It was used in BIND Version
8 to determine whether a transaction log was kept for
incremental zone transfers. BIND Version 9 maintains
a transaction log whenever possible. To disable outgoing
incremental zone transfers, set the provide-ixfr option
to NO. See Section 6.5.3.7 for more information.
minimal-responses
Specifies that when the server generates responses, it adds
records to the authority and additional data sections only
when they are required (for example, for delegations and
negative responses). This might improve the performance
of the server. The default is NO.
multiple-cnames
This option was used in BIND Version 8 to allow a domain
name to allow multiple CNAME records in violation of
the DNS standards. BIND Version 9 strictly enforces the
CNAME rules, both in master files and dynamic updates.
notify
Sends DNS NOTIFY messages when a zone changes for
which the server is authoritative (see Section 6.5.5). The
messages are sent to the servers listed in the zone’s NS
records (except the master server identified in the SOA
MNAME field) and to any servers listed in the alsonotify option. If this option is explicitly set (the default),
notifications are sent only to servers explicitly listed using
also-notify. If it is set to NO, notifications are not sent.
The notify option can also be specified in the zone
statement. This overrides the notify option in the
options statement.
recursion
When a DNS query requests recursion, specifies that
the server will attempt to do all the work required to
answer the query. If the recursion option is off and the
server does not already know the answer, it returns a
referral response. The default is YES. Note that setting
the recursion option to NO does not prevent clients
from getting data from the server’s cache; it only prevents
new data from being cached as an effect of client queries.
Caching can still occur as an effect of the server’s internal
operation, such as NOTIFY address lookups.
rfc2308-type1
Setting this option to YES causes the server to send NS
records along with the SOA record for negative answers.
The default is NO.
This option is not yet implemented.
use-id-pool
This option is obsolete. BIND Version 9 always allocates
query IDs from a pool.
(continued on next page)
6–26 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–7 (Cont.) BIND Server Boolean Configuration Options
Option
Description
zone-statistics
Collects statistical data on all zones in the server. These
statistics can be accessed using the rndc stats command,
which dumps them to the file listed in the statisticsfile option. See Section 6.10 for more information.
use-ixfr
This option is obsolete. If you need to disable IXFR to a
particular server, see the information about the provideixfr option in Section 6.5.3.7.
treat-cr-as-space
This option was used in BIND 8 to make the server treat
carriage return characters the same way as a space or tab
character—to facilitate loading of zone files. In BIND 9,
these characters are always accepted and the option is
ignored.
(continued on next page)
Configuring and Managing BIND Version 9 6–27
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–7 (Cont.) BIND Server Boolean Configuration Options
Option
Description
additional-from-auth
additional-from-cache
These options control the behavior of an authoritative
server when answering queries that have additional data or
when following CNAME and DNAME chains.
When both of these options are set to YES (the default)
and a query is being answered from authoritative data
(a zone configured into the server), the additional data
section of the reply is filled in using data from other
authoritative zones and from the cache. In some situations
this is undesirable, such as when there is concern over the
correctness of the cache, or in servers where slave zones
can be added and modified by untrusted third parties.
Also, avoiding the search for this additional data speeds
up server operations at the possible expense of additional
queries to resolve what otherwise would be provided in the
additional section.
For example, if a query asks for an MX record for host
FOO.EXAMPLE.COM, the following record is found:
MX 10 mail.example.net
The address records (A and AAAA) for
MAIL.EXAMPLE.NET are provided as well, if they are
known.
Setting these options to NO disables this behavior.
These options are intended for use in authoritative-only
servers or in authoritative-only views. If you attempt to set
these options to NO without also specifying recursion no,
the server ignores the options and log a warning message.
Specifying additional-from-cache no disables the
use of the cache not only for additional data lookups, but
also when looking up the answer. This is usually the
desired behavior in an authoritative-only server where the
correctness of the cached data is an issue.
When a name server is nonrecursively queried for a name
that is not below the apex of any served zone, it normally
answers with an ‘‘upward referral’’ to the root servers or
to the servers of some other known parent of the query
name. Because the data in an upward referral comes from
the cache, the server cannot provide upward referrals when
additional-from-cache no has been specified. Instead,
the server responds to such queries with ‘‘REFUSED.’’ This
should not cause any problems, because upward referrals
are not required for the resolution process.
match-mapped-addresses
When this option is set, an IPv4-mapped IPv6 address
matches any address match list entries that match the
corresponding IPv4 address. Use of this option is not
necessary on OpenVMS systems.
6.5.3.6.2 Forwarding Options The forwarding facility helps you create a large,
sitewide cache on a few servers, thereby reducing traffic over links to external
name servers. It can also be used to allow queries by servers that do not have
direct access to the Internet but that want to look up exterior names anyway.
Forwarding occurs only on those queries for which the server is not authoritative
and does not have the answer in its cache.
6–28 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–8 describes the forwarding options.
Table 6–8 Forwarding Options
Option
Description
forward
Meaningful only if the forwarders list is not empty. A
value of first (the default) causes the server to query the
forwarders first, and if that does not answer the question,
the server then looks for the answer itself. If only is
specified, the server queries only the forwarders.
forwarders
Specifies the IP addresses to be used for forwarding. The
default is the empty list (no forwarding).
Forwarding can also be configured on a per-domain basis, allowing for the global
forwarding options to be overridden in a variety of ways. You can set particular
domains to use different forwarders, or have a different forward only/first
behavior, or not to forward at all. See Section 6.5.3.10 for more information.
6.5.3.6.3 Access Control Options Access to the server can be restricted based
on the IP address of the requesting system. See Section 6.5.2 for details on how
to specify IP address lists.
Table 6–9 describes the access control options.
Table 6–9 Access Control Options
Option
Description
allow-notify
Specifies which hosts are allowed to notify slaves of a zone
change in addition to the zone masters. The allow-notify
option can also be specified in the zone statement; in this
case, it overrides the allow-notify option in the options
statement. The allow-notify option is meaningful only
for a slave zone. If this option is not specified, the default
is to process notify messages from only a zone’s master.
allow-query
Specifies which hosts are allowed to ask ordinary questions.
The allow-query option can also be specified in the zone
statement; in this case, it overrides the allow-query
option in the options statement. If this option is not
specified, the default is to allow queries from all hosts.
allow-recursion
Specifies which hosts are allowed to make recursive queries
through this server. If this option is not specified, the
default is to allow recursive queries from all hosts. Note
that disallowing recursive queries for a host does not
prevent the host from retrieving data that is already in the
server’s cache.
allow-v6-synthesis
Specifies which hosts are to receive synthetic responses to
IPv6 queries, as described in Section 6.5.3.6.12.
(continued on next page)
Configuring and Managing BIND Version 9 6–29
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–9 (Cont.) Access Control Options
Option
Description
allow-transfer
Specifies which hosts are allowed to receive zone transfers
from the server. The allow-transfer option can also be
specified in the zone statement; in this case, it overrides
the allow-transfer statement in the options statment.
If this option is not specified, the default is to allow
transfers to all hosts.
blackhole
Specifies a list of addresses from which the server will not
accept queries or will not use to resolve a query. The server
will not respond queries from these addresses. The default
is NONE.
6.5.3.6.4 Interfaces Options The interfaces and ports from which the server
answers queries can be specified using the listen-on options. Table 6–10
describes the listen-on options.
Table 6–10 Interfaces Options
Option
Description
listen-on
Specifies the port for listening for queries sent using IPv4
addresses.
The listen-on option takes an optional port number
and an address_match_list. The server listens on all
interfaces allowed by the address match list. If a port is not
specified, port 53 is used.
Multiple
listen-on statements are allowed. For example:
listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
These statements enable the name server on port 53 for the
IP address 5.6.7.8, and on port 1234 of an address on the
machine in net 1.2 that is not 1.2.3.4.
If the listen-on option is not specified, the server listens
on port 53 on all interfaces.
(continued on next page)
6–30 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–10 (Cont.) Interfaces Options
Option
Description
listen-on-v6
Specifies the ports on which the server listens for incoming
queries sent using IPv6. The server does not bind a
separate socket to each IPv6 interface address as it
does for IPv4. Instead, it always listens on the IPv6
wildcard address. Therefore, the values allowed for the
address_match_list argument to the listen-on-v6
option are:
•
any
•
none
Multiple listen-on-v6 options can be used to listen on
multiple ports. For example:
listen-on-v6 port 53 { any; };
listen-on-v6 port 1234 { any; };
To make the server not listen on any IPv6 address, specify
the following:
listen-on-v6 { none; };
If the listen-on-v6 option is not specified, the server
does not listen on any IPv6 address.
6.5.3.6.5 The Query Address Options If the server does not know the answer
to a question, it queries other name servers. The query address options allow you
to specify the address and port for these queries.
Table 6–11 describes the query address options.
Table 6–11 Query Address Options
Option
Description
query-source
Specifies the IPv4 address and port used for such queries.
If the address is a wildcard character or is omitted, a
wildcard IP address (INADDR_ANY) is used. If the port is
a wildcard character or is omitted, a random unprivileged
port is used. The default is:
query-source address * port *;
query-source-v6
Specifies the IPv6 address and port used for such queries.
The default is:
query-source-v6 address * port *
The address specified in the query-source option is used for both UDP and TCP
queries, but the port applies only to UDP queries. TCP queries always use a
random, unprivileged port.
Configuring and Managing BIND Version 9 6–31
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
6.5.3.6.6 Zone Transfer Options BIND includes mechanisms to facilitate zone
transfers and to limit the amount of load that transfers place on the system.
Table 6–12 describes the zone transfer options.
Table 6–12 Zone Transfer Options
Option
Description
also-notify
Defines a global list of IP addresses of name servers that
are also sent NOTIFY messages whenever a fresh copy
of the zone is loaded, in addition to the servers listed in
the zone’s NS records. This helps to ensure that copies
of the zones will quickly converge on stealth servers. If
an also-notify list is given in a zone statement, that
list overrides the also-notify options in the options
statement. When a zone notify statement is set to NO,
the IP addresses in the global also-notify list are not
sent NOTIFY messages for that zone. The default is the
empty list (no global notification list).
max-transfer-time-in
Inbound zone transfers running longer than this many
minutes are terminated. The default is 120 minutes.
max-transfer-idle-in
Inbound zone transfers making no progress in this many
minutes are terminated. The default is 60 minutes.
max-transfer-time-out
Outbound zone transfers running longer than this many
minutes are terminated. The default is 120 minutes.
max-transfer-idle-out
Outbound zone transfers making no progress in this many
minutes are terminated. The default is 60 minutes.
serial-query-rate
Slave servers periodically query master servers to find out
whether zone serial numbers have changed. Each such
query uses a minute amount of the slave server’s network
bandwidth. To limit the amount of bandwidth used, BIND
9 limits the rate at which queries are sent. The value of
the serial-query-rate option is the maximum number
of queries sent per second. The default is 20.
serial-queries
In BIND 8, this option set the maximum number of
concurrent serial number queries allowed to be outstanding
at any given time. BIND 9 does not limit the number
of outstanding serial queries and ignores the serialqueries option. Instead, it limits the rate at which the
queries are sent as defined by the serial-query-rate
option.
transfer-format
Specifies whether zone transfers are sent using the
one-answer format or the many-answers format. The
transfer-format option is used on the master server to
determine which format it sends. When set to one-answer,
it uses one DNS message per resource record transferred.
When set to many-answers, it packs as many resource
records as possible into a message. many-answers is more
efficient, but it is supported only by relatively new slave
servers, such as BIND Version 9, BIND Version 8, and later
versions of BIND Version 4. The default is many-answers.
The transfer-format option can be overridden on a
per-server basis by using the server statement.
(continued on next page)
6–32 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–12 (Cont.) Zone Transfer Options
Option
Description
transfers-in
Specifies the maximum number of inbound zone transfers
that can be running concurrently. The default value is 10.
Increasing the transfers-in value might speed up the
convergence of slave zones, but it also might increase the
load on the local system.
transfers-out
Specifies the maximum number of outbound zone transfers
that can be running concurrently. Zone transfer requests in
excess of the limit are refused. The default value is 10.
transfers-per-ns
Specifies the maximum number of inbound zone transfers
that can be concurrently transferring from a given remote
name server. The default value is 2. Increasing the value
of the transfers-per-ns option might speed up the
convergence of slave zones, but it also might increase
the load on the remote name server. This option can be
overridden on a per-server basis by using the transfers
phrase of the server statement.
transfer-source
Determines which local address is bound to IPv4 TCP
connections used to fetch zones transferred inbound by the
server. It also determines the source IPv4 address and,
optionally, the UDP port used for the refresh queries and
forwarded dynamic updates. If not set, this option defaults
to a system-controlled value, which is usually the address
of the interface closest to the remote end. This address
must appear in the remote end’s allow-transfer option
for the zone being transferred, if one is specified. This
statement sets the transfer source for all zones, but it can
be overridden on a per-view or per-zone basis by including
a transfer-source statement within the view or zone
statement in the configuration file.
transfer-source-v6
Determines which local address is bound to IPv6 TCP
connections used to fetch zones transferred inbound by the
server. This is the same as the transfer-source option,
except zone transfers are performed using IPv6.
notify-source
Determines which local source address and, optionally, UDP
port is used to send NOTIFY messages. This address must
appear in the slave server’s masters clause in the zone
statement or in an allow-notify clause.
This statement sets the notify-source for all zones, but
it can be overridden on a per-zone or per-view basis by
including a notify-source statement within the zone or
view statement in the configuration file.
notify-source-v6
Determines which local source address and, optionally,
UDP port is used to send NOTIFY messages. This option
is identical to notify-source, but it applies to NOTIFY
messages sent to IPv6 addresses.
6.5.3.6.7 Server Resource Limits Table 6–13 describes options that limit the
server’s resource consumption and are enforced internally by the server rather
than by the operating system.
Configuring and Managing BIND Version 9 6–33
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–13 Server Resource Limit Options
Option
Description
max-ixfr-log-size
recursive-clients
This option is obsolete; it is accepted and ignored.
tcp-clients
Specifies the maximum number of simultaneous client TCP
connections that the server accepts. The default is 100.
max-cache-size
Specifies the maximum amount of memory (in bytes) to
use for the server’s cache. When the amount of data in
the cache reaches this limit, the server causes records to
expire prematurely so that the limit is not exceeded. In
a server with multiple views, the limit applies separately
to the cache of each view. The default is unlimited, which
means that records are purged from the cache only when
their TTL (time-to-live) values expire.
Specifies the maximum number of simultaneous recursive
lookups the server performs on behalf of clients. The
default is 1000. Because each recursing client uses about
20 kilobytes of memory, the value of the recursiveclients option might have to be decreased on hosts with
limited memory.
6.5.3.6.8 Periodic Task Intervals Options
control the intervals for periodic tasks.
Table 6–14 describes the options that
Table 6–14 Periodic Task Intervals Options
Option
Description
cleaning-interval
The server removes expired resource records from the cache
every cleaning-interval minutes. The default is 60
minutes. If set to 0, periodic cleaning does not occur.
heartbeat-interval
The server performs zone maintenance tasks for all dialup
zones whenever this interval expires. The default is 60
minutes.
The maximum value is one day (1440 minutes). If this
option is set to 0, zone maintenance for these zones does
not occur.
interface-interval
The server scans the network interface list every
interface-interval minutes. The default is 60 minutes.
If this option is set to 0, interface scanning occurs only
when the configuration file is loaded. After the scan,
listeners are started on any new interfaces (provided they
are allowed by the listen-on configuration). Listeners on
interfaces that have gone away are cleaned up.
statistics-interval
Name server statistics are logged every statisticsinterval minutes. The default is 60. If set to 0, statistics
are not logged.
This option is not yet implemented.
6.5.3.6.9 The TOPOLOGY Statement When the server chooses a name server
to query from a list of name servers, it prefers the one that is topologically closest
to itself. The topology statement takes an address match list and interprets it
in a special way. Each top-level list element is assigned a distance. Nonnegated
elements get a distance based on their position in the list; the closer the match
is to the start of the list, the shorter the distance between it and the server. A
negated match is assigned the maximum distance from the server. If there is
6–34 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
no match, the address gets a distance that is further than any nonnegated list
element and closer than any negated element. For example:
topology {
10/8;
!1.2.3/24;
{ 1.2/16; 3/8; };
};
The example configuration prefers servers on network 10 the most, followed by
hosts on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception
of hosts on network 1.2.3 (netmask 255.255.255.0), which is the least preferred.
The default topology is:
topology { localhost; localnets; };
Note
The topology statement is not implemented in BIND Version 9.
6.5.3.6.10 The SORTLIST Statement The response to a DNS query can consist
of multiple resource records (RRs) forming a resource record set (RRset). The
name server normally returns the RRs within the RRset in an indeterminate
order. (See Section 6.5.3.6.11.)
The client resolver code should rearrange the RRs as appropriate, that is, by
using any addresses on the local network in preference to other addresses.
However, not all resolvers can do this or are correctly configured. When a client
is using a local server the sorting can be performed in the server, based on the
client’s address. This requires configuring only the name servers, not all the
clients.
The sortlist statement takes an address match list and interprets it even more
specifically than the topology statement does (see Section 6.5.3.6.9). Each toplevel statement in the sortlist must itself be an explicit address match list with
one or two elements. The first element (which can be an IP address, an IP prefix,
an ACL name, or a nested address match list) of each top-level list is checked
against the source address of the query until a match is found.
Once the source address of the query is matched, if the top-level statement
contains only one element, the actual primitive element that matched the source
address is used to select the address in the response to move to the beginning of
the response. If the statement is a list of two elements, then the second element
is treated the same as the address match list in a topology statement. Each
top-level element is assigned a distance and the address in the response with the
minimum distance is moved to the beginning of the response.
Example 1
In the following example, any queries received from any of the addresses of the
host itself gets responses that prefer addresses on any of the locally connected
networks. The next-most-preferred are addresses on the 192.168.1/24 network,
and after that either the 192.168.2/24 or 192.168.3/24 network with no preference
shown between these two networks. Queries received from a host on the
192.168.1/24 network prefers other addresses on that network to the 192.168.2/24
and 192.168.3/24 networks. Queries received from a host on the 192.168.4/24 or
the 192.168.5/24 network prefer only other addresses on their directly connected
networks.
Configuring and Managing BIND Version 9 6–35
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
sortlist {
{ localhost;
// IF the local host
{ localnets;
// THEN first fit on the
192.168.1/24;
// following nets
{ 192.168.2/24; 192.168.3/24; }; }; };
{ 192.168.1/24;
// IF on class C 192.168.1
{ 192.168.1/24;
// THEN use .1, or .2 or .3
{ 192.168.2/24; 192.168.3/24; }; }; };
{ 192.168.2/24;
// IF on class C 192.168.2
{ 192.168.2/24;
// THEN use .2, or .1 or .3
{ 192.168.1/24; 192.168.3/24; }; }; };
{ 192.168.3/24;
// IF on class C 192.168.3
{ 192.168.3/24;
// THEN use .3, or .1 or .2
{ 192.168.1/24; 192.168.2/24; }; }; };
{ { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
};
};
Example 2
The following example illustrates reasonable behavior for the local host and for
hosts on directly connected networks. This behavior is similar to that of the
address sort in BIND Version 4. Responses sent to queries from the local host
favor any of the directly connected networks. Responses sent to queries from
any other hosts on a directly connected network prefer addresses on that same
network. Responses to other queries are not sorted.
sortlist {
{ localhost; localnets; };
{ localnets; };
};
6.5.3.6.11 RRset Ordering When multiple records are returned in an answer,
it might be useful to configure the order of the records placed into the response.
The rrset-order statement permits configuration of the ordering of the records
in a multiple-record response.
An order_spec is defined as follows:
[ class class_name ][ type type_name ][ name "domain_name"]
order ordering
If no class is specified, the default is ANY. If no type is specified, the default is
ANY. If no name is specified, the default is wildcard.
The legal values for ordering are:
•
fixed (Records are returned in the order they are defined in the zone file.)
•
random (Records are returned in random order.)
•
cyclic (Records are returned in round-robin order.)
For example:
rrset-order {
class IN type A name "host.example.com" order random;
order cyclic;
};
This example causes any responses for type A records in class IN that have
host.example.com as a suffix to always be returned in random order. All other
records are returned in cyclic order.
6–36 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
If multiple rrset-order statements appear, they are not combined; the last one
applies.
Note
The rrset-order statement is not yet implemented. BIND currently
supports only ‘‘random-cyclic’’ ordering, in which the server randomly
chooses a starting point within the RRset and returns the records in order
starting at that point, wrapping around the end of the RRset if necessary.
6.5.3.6.12 Synthetic IPv6 Responses Many existing stub resolvers support
IPv6 DNS lookups as defined in RFC 1886, using AAAA records for forward
lookups and nibble labels in the ip6.int domain for reverse lookups. They do not
support RFC 2874 lookups (using A6 records and binary labels in the ip6.arpa
domain).
To continue to use such stub resolvers, BIND Version 9 provides a way to
automatically convert RFC 1886 lookups into RFC 2874 lookups and to return the
results as ‘‘synthetic’’ AAAA and PTR records.
This feature is disabled by default and can be enabled on a per-client basis by
adding the following clause to the to the options or view statement:
allow-v6-synthesis { address_match_list };
When this feature is enabled, recursive AAAA queries cause the server first to try
an A6 lookup and then, if that fails, an AAAA lookup. Regardless of which one
succeeds, the results are returned as a set of synthetic AAAA records. Similarly,
recursive PTR queries in ip6.int cause a lookup in ip6.arpa using binary labels
and, if that fails, another lookup in ip6.int. The results are returned as a
synthetic PTR record in ip6.int.
The synthetic records have a TTL value of 0. DNSSEC validation of synthetic
responses is not supported; therefore, responses containing synthetic RRs do not
have the AD flag set.
The allow-v6-synthesis option is performed only for clients that are supplied
recursive services.
Table 6–15 describes the options provided for tuning
6.5.3.6.13 Tuning Options
the BIND server.
Table 6–15 Tuning Options
Options
Description
lame-ttl
Sets the number of seconds to cache a lame server
indication. A value of zero disables caching. (This is
not recommended.) The default is 600 (10 minutes); the
maximum value is 1800 (30 minutes).
(continued on next page)
Configuring and Managing BIND Version 9 6–37
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–15 (Cont.) Tuning Options
Options
Description
max-ncache-ttl
To reduce network traffic and increase performance, the
server stores negative answers. The max-ncache-ttl
option is used to set a maximum retention time for these
answers in the server in seconds. The default is 10800
seconds (3 hours). The value of max-ncache-ttl cannot
exceed 7 days and is silently truncated to 7 days if set to a
greater value.
max-cache-ttl
Sets the maximum time for which the server caches
ordinary (positive) answers. The default is one week (7
days).
min-roots
The minimum number of root servers that is required for a
request for the root servers to be accepted. The default is 2.
This option is not yet implemented.
sig-validity-interval
Specifies the number of days into the future when
DNSSEC signatures automatically generated as a result
of dynamic updates will expire. (See Section 6.5.7 for
more information.) The default is 30 days. The signature
inception time is unconditionally set to one hour before the
current time to allow for a limited amount of clock skew.
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
Controls the server’s behavior when refreshing a zone
(querying for SOA changes) or when retrying failed
transfers. Usually the SOA values for the zone are used,
but these values are set by the master, giving slave server
administrators little control over their contents.
These options allow the administrator to set a minimum
and maximum refresh and retry time either per-zone, perview, or globally. These options are valid for slave and stub
zones, and clamp the SOA refresh and retry times to the
specified values.
6.5.3.6.14 The Statistics File The statistics file generated by BIND 9 is similar,
but not identical, to that generated by BIND 8.
The statistics dump begins with the following line:
+++ Statistics Dump +++ (973798949)
The number in parentheses is a standard UNIX time stamp, measured as seconds
since January 1, 1970. Following that line are a series of lines containing a
counter type, the value of the counter, a zone name (optional), and a view name
(optional). The lines without view and zone listed are global statistics for the
entire server. Lines with a zone and view name apply to the given view and zone
(the view name is omitted for the default view). The statistics dump ends with
the following line:
--- Statistics Dump --- (973798949)
The time stamp is identical to the one in the beginning line.
Table 6–16 describes the statistics counters that are maintained.
6–38 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–16 Statistics Counters
Counter
Description
success
The number of successful queries made to the server or
zone. A successful query is defined as query that returns a
NOERROR response other than a referral response.
referral
nxrrset
The number of queries that resulted in referral responses.
nxdomain
The number of queries that resulted in NXDOMAIN
responses.
recursion
The number of queries that caused the server to perform
recursion in order to find the final answer.
failure
The number of queries that resulted in a failure response
other than those described in the preceding counters.
The number of queries that resulted in NOERROR
responses with no data.
6.5.3.7 The SERVER Statement
The server statement defines characteristics to be associated with a remote name
server. The server statement has the following syntax:
server ip_addr {
[ bogus yes_or_no ; ]
[ provide-ixfr yes_or_no ; ]
[ request-ixfr yes_or_no ; ]
[ edns yes_or_no ; ]
[ transfers number ; ]
[ transfer-format ( one-answer | many-answers ) ; ]]
[ keys { string ; [ string ; [...]] } ; ]
};
The server statement can occur at the top level of the configuration file or inside
a view statement. If a view statement contains one or more server statements,
only those apply to the view, and any top-level ones are ignored. If a view
contains no server statements, any top-level server statements are used as
defaults.
Table 6–17 describes the clauses in the server statement.
Table 6–17 Server Statement Clauses
Clause
Description
bogus
If you discover that a remote server is giving out bad data,
marking it as bogus prevents further queries to it. The
default value of bogus is NO.
provide-ixfr
Determines whether the local server, acting as master,
responds with an incremental zone transfer when the
given remote server, a slave, requests it. If this option
is set to YES, incremental transfer is provided whenever
possible. If set to NO, all transfers to the remote server
are nonincremental. If not set, the value of the provideixfr option in the global options statement is used as a
default.
(continued on next page)
Configuring and Managing BIND Version 9 6–39
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–17 (Cont.) Server Statement Clauses
Clause
Description
request-ixfr
Determines whether the local server, acting as a slave,
requests incremental zone transfers from the given remote
server, a master. If this option is not set, the value of the
request-ixfr option in the global options statement is
used as a default.
IXFR requests to servers that do not support IXFR
automatically falls back to AXFR. Therefore, you do not
need to list manually which servers support IXFR and
which ones do not; the global default of YES should always
work. The purpose of the provide-ixfr and requestixfr clauses is to make it possible to disable the use of
IXFR, even when both master and slave claim to support it;
for example, if one of the servers crashes or corrupts data
when IXFR is used. See Section 6.5.6 for more information.
edns
Determines whether the local server attempts to use EDNS
when communicating with the remote server. The default
is YES.
transfer-format
Specifies the zone transfer method:
•
one-answer uses one DNS message per resource
record transferred.
•
many-answers packs as many resource records as
possible into a message.
The many-answers mode is more efficient, but it is
understood only by BIND Version 9, BIND Version 8, and
later versions of BIND Version 4. If transfer-format is
not specified, the transfer format specified by the options
statement is used.
transfers
Limits the number of concurrent inbound zone transfers
from the specified server. If no transfers clause is
specified, the limit is set according to the transfersper-ns option, as described in Table 6–12.
keys
Specifies a key_id defined by the key statement, to be
used for transaction security when talking to the remote
server. The key statement must come before the server
statement that references it. When a request is sent to the
remote server, a request signature is generated using the
key specified here and appended to the message. A request
originating from the remote server is not required to be
signed by this key.
Use only one key for each server.
6.5.3.8 The TRUSTED-KEYS Statement
The trusted-keys statement defines DNSSEC security roots. (DNSSEC is
described in Section 6.2.6.)
A security root is defined when the public key for a nonauthoritative zone is
known but cannot be securely obtained through DNS, either because it is the DNS
root zone or because its parent zone is unsigned. Once a key has been configured
as a trusted key, it is treated as if it had been validated and proven secure.
The resolver attempts DNSSEC validation on all DNS data in subdomains of a
security root.
6–40 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
The trusted-keys statement can contain multiple key entries. The trusted-keys
statement has the following syntax:
trusted-keys {
string number number number string ;
[ string number number number string ; [...]]
};
Each statement contains the key’s domain name, flags, protocol, algorithm, and
base-64 representation of the key data.
The base-64 representation of the key data must be enclosed in quotation marks.
6.5.3.9 The VIEW Statement
The view statement allows a name server to answer a DNS query differently,
depending on who is asking. It is particularly useful for implementing split DNS
setups without having to run multiple servers.
The view statement has the following syntax:
view view_name [class] {
match-clients { address_match_list } ;
match-destinations { address_match_list } ;
match-recursive-only yes_or_no ;
[ view_option; ...]
[ zone-statistics yes_or_no ; ]
[ zone_statement; ...]
};
The parameters to the view statement are:
•
view-name, which specifies the name of this view.
•
class, which specifies the class for this view. If no class is given, class IN is
assumed.
Note
All non-IN views must contain a hint zone. Only the IN class has
compiled-in default hints.
Table 6–18 describes the clauses you can include in the view statement.
Table 6–18 View Statement Clauses
Clause
Description
match-clients
match-destinations
Each view statement defines a view of the DNS name
space that is seen by a subset of clients. A client matches
a view if its source IP address matches the address match
list of the view’s match-clients clause and its destination
IP address matches the address match list of the view’s
match-destinations clause. If they are not specified,
both match-clients and match-destinations default
to matching all addresses.
match-recursive-only
Only recursive requests from matching clients match that
view.
(continued on next page)
Configuring and Managing BIND Version 9 6–41
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–18 (Cont.) View Statement Clauses
Clause
Description
view-options
Many of the options given in the options statement can
also be used in a view statement, and then apply only when
resolving queries with that view. When no view statement
value is given, the value in the options statement is used
as the default.
zone-statistics
Specifies whether or not to generate the zone statistics file.
See Section 6.5.3.6.14 for more information.
zone-statement
Specifies the zone information for this view. See
Section 6.5.3.10 for more information.
The order of the view statements is significant. A client request is resolved in the
context of the first view that it matches. Zones defined within a view statement
are accessible only to clients that match the view.
By defining a zone of the same name in multiple views, different zone data can be
given to different clients; for example, internal and external clients in a split DNS
setup. Also, zone statement options can have default values specified in the view
statement; these view-specific defaults take precedence over those in the options
statement.
If there are no view statements in the configuration file, a default view that
matches any client is automatically created in class IN, and any zone statements
specified on the top level of the configuration file are considered to be part of this
default view.
Note
If any explicit view statements are present, all zone statements must
occur inside view statements.
The following example shows a typical split DNS setup implemented using view
statements:
6–42 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
view "internal" {
// This should match our internal networks.
match-clients { 10.0.0.0/8; };
// Provide recursive service to internal clients only.
recursion yes;
// Provide a complete view of the example.com zone
// including addresses of internal hosts.
zone "example.com" {
type master;
file "example-internal.db";
};
};
view "external" {
match-clients { any; };
// Refuse recursive service to external clients.
recursion no;
// Provide a restricted view of the example.com zone
// containing only publicly accessible hosts.
zone "example.com" {
type master;
file "example-external.db";
};
};
6.5.3.10 The ZONE Statement
The zone statement specifies options for a specific zone. Note that if view
statements are included in the configuration file, the zone statements must
be included in view statements.
The zone statement has the following syntax:
zone zone_name [class] [{
type ( master | slave | hint | stub | forward ) ;
[ allow-notify { address_match_list } ; ]
[ allow-query { address_match_list } ; ]
[ allow-transfer { address_match_list } ; ]
[ allow-update { address_match_list } ; ]
[ update-policy { update_policy_rule [...] } ; ]
[ allow-update-forwarding { address_match_list } ; ]
[ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ check-names (warn|fail|ignore) ; ]
[ dialup dialup_option ; ]
[ file string ; ]
[ forward (only|first) ; ]
[ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ ixfr-base string ; ]
[ ixfr-tmp-file string ; ]
[ maintain-ixfr-base yes_or_no ; ]
[ masters [port ip_port] { ip_addr [port ip_port] [key key]; [...] } ; ]
[ max-ixfr-log-size number ; ]
[ max-transfer-idle-in number ; ]
[ max-transfer-idle-out number ; ]
[ max-transfer-time-in number ; ]
[ max-transfer-time-out number ; ]
[ notify yes_or_no | explicit ; ]
[ pubkey number number number string ; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ notify-source (ip4_addr | *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ zone-statistics yes_or_no ; ]
[ sig-validity-interval number ; ]
[ database string ; ]
[ min-refresh-time number ; ]
[ max-refresh-time number ; ]
Configuring and Managing BIND Version 9 6–43
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
[ min-retry-time number ; ]
[ max-retry-time number ; ]
}];
6.5.3.10.1 Type of Zone Table 6–19 describes the types of zones that you can
specify in the type clause.
Table 6–19 Zone Types
Type
Description
master
The server that has a master copy of the data for the zone
and that can provide authoritative answers for it.
slave
A replica of a master zone. The masters option specifies
the IP addresses of one or more master servers that this
slave can contact to update its copy of the zone information.
stub
Similar to a slave zone, except that it replicates only the
NS records of a master zone instead of the entire zone.
Stub zones are not a standard part of the DNS; they are a
feature specific to the BIND implementation.
Stub zones can be used to eliminate the need for glue NS
record in a parent zone at the expense of maintaining a
stub zone entry and a set of name server addresses in
TCPIP$BIND.CONF. This usage is not recommended for
new configurations, and BIND Version 9 supports it only
in a limited way. In BIND Version 4 and BIND Version 8,
zone transfers of a parent zone included the NS records
from stub children of that zone. This made it possible
to configure child stubs only in the master server for the
parent zone. BIND Version 9 never mixes together zone
data from different zones in this way. Therefore, if a BIND
Version 9 master serving a parent zone has child stub
zones, all the slave servers for the parent zone also need to
have the same child stub zones.
Stub zones can also be used as a way of forcing the
resolution of a given domain to use a particular set of
authoritative servers. For example, the caching name
servers on a private network using RFC 2157 addressing
can be configured with stub zones for 10.in-addr.arpa
to use a set of internal name servers as the authoritative
servers for that domain.
(continued on next page)
6–44 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–19 (Cont.) Zone Types
Type
Description
forward
A forward zone allows you to configure forwarding on a
per-domain basis. A zone statement of type forward
can contain forward and forwarders statements, which
applies to queries within the domain specified by the zone
name. If no forwarders statement is present or if an
empty list for forwarders is specified, then forwarding is not
done for the domain, thereby canceling the effects of any
forwarders in the options statement.
If you want to use this type of zone to change the behavior
of the global forward option (using the first value to
specify the zone to which to forward first, or the only value
to specify forwarding to this zone only), and you want to use
the same servers that are set globally, you need to respecify
the global forwarders.
hint
The initial set of root name servers is specified using a hint
zone. When the server starts up, it uses the root hints to
find a root name server and to get the most recent list of
root name servers. If no hint zone is specified for class IN,
the server uses a default set of root servers hints. Classes
other than IN have no built-in defaults hints.
6.5.3.10.2 The Zone Class The zone name can optionally be followed by a class.
If the class is not specified, class IN (for Internet) is assumed. This is correct for
the vast majority of cases.
The hesiod class is named for an information service from MIT’s Project Athena.
It is used to share information about various systems databases, such as users,
groups, printers, and so on. The keyword HS is a synonym for hesiod.
Another MIT development is CHAOSnet, a LAN protocol created in the mid-1970s.
Zone data for CHAOSnet can be specified with the CH class.
6.5.3.10.3 Zone Options
the zone statement.
Table 6–20 describes the options you can include in
Table 6–20 Zone Options
Option
Description
allow-notify
allow-query
allow-transfer
allow-update
See the description of
update-policy
Specifies an update policy, as described in Section 6.5.7.2.
allow-notify in Section 6.5.3.6.3.
See the description of allow-query in Section 6.5.3.6.3.
See the description of allow-transfer in Section 6.5.3.6.3.
Specifies which hosts are allowed to submit dynamic DNS
updates for master zones. The default is to deny updates
from all hosts.
(continued on next page)
Configuring and Managing BIND Version 9 6–45
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–20 (Cont.) Zone Options
Option
Description
allow-updateforwarding
Specifies which hosts are allowed to submit dynamic
updates to slave zones to be forwarded to the master.
The default is NONE, which means that update forwarding
is not performed. To enable update forwarding, specify
ANY. Do not specify any other value; the responsibility for
update access control should rest with the master server,
not with the slaves.
Enabling the update forwarding feature on a slave server
can expose master servers relying on insecure IP-address
based access control to attacks; see Section 6.2.2 for more
details.
also-notify
Meaningful only if notify is active for this zone. The
set of machines that receives a NOTIFY message for this
zone is made up of all the listed name servers (other than
the primary master) for the zone, plus any IP addresses
specified with the also-notify statement. A port can
be specified with each also-notify address to send the
notify messages to a port other than the default of 53.
also-notify is not meaningful for stub zones. The default
is the empty list.
check-names
This option was used in BIND 8 to restrict the character
set of domain names in master files and of DNS responses
received from the network. BIND 9 does not restrict the
character set of domain names and does not implement the
check-names option.
database
Specifies the type of database to be used for storing the
zone data. The string following the database keyword is
interpreted as a list of space-delimited words. The first
word identifies the database type; any subsequent words
are passed as arguments to the database to be interpreted
in a way specific to the database type.
The default is rbt, the native database used by BIND 9.
This database does not take arguments.
dialup
See the description of the
Section 6.5.3.6.1.
dialup option in
forward
Meaningful only if the zone has a forwarders list. The
only keyword causes the lookup to fail after trying the
forwarders and getting no answer. The first keyword
allows attempts at normal lookups.
forwarders
Overrides the list of global forwarders.
If the zone type is not forward, forwarding is not done for
the zone, and the global options are not used.
ixfr-base
This option was used in BIND 8 to specify the name of the
transaction log (journal) file for dynamic update and IXFR.
BIND 9 ignores this option and constructs the name of the
journal file by appending _JNL to the name of the zone file.
ixfr-tmp-file
An undocumented option in BIND 8. Ignored in BIND 9.
(continued on next page)
6–46 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Table 6–20 (Cont.) Zone Options
Option
Description
masters
Specifies one or more IP addresses of master servers that
the slave contacts to update its copy of the zone.
By default, transfers are made from port 53 on the servers;
this can be changed for all servers by specifying a port
number before the list of IP addresses, or on a per-server
basis after the IP address. Authentication to the master
can also be done with per-server TSIG keys. If a file is
specified, then the replica is written to this file whenever
the zone is changed and is reloaded from this file on a
server restart. Use of a file is recommended because it
often speeds server startup and eliminates a waste of
bandwidth.
max-transfer-time-in
See the description of
Section 6.5.3.6.6.
max-transfer-time-in in
max-transfer-idle-in
See the description of
Section 6.5.3.6.6.
max-transfer-idle-in in
max-transfer-time-out
See the description of
Section 6.5.3.6.6.
max-transfer-time-out in
max-transfer-idle-out
See the description of
Section 6.5.3.6.6.
max-transfer-idle-out in
notify
pubkey
See the description of
zone-statistics
If YES, the server keeps statistical information for this
zone, which can be dumped to the statistics file defined in
the server options. See Section 6.5.3.6.
sig-validity-interval
See the description of
Section 6.5.3.6.13.
sig-validity-interval in
transfer-source
See the description of
Section 6.5.3.6.6.
transfer-source in
transfer-source-v6
See the description of
Section 6.5.3.6.6.
transfer-source-v6 in
notify-source
notify-source-v6
See the description of
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
notify in Section 6.5.3.6.
In BIND Version 8, this option was used for specifying a
public zone key for verification of signatures in DNSSECsigned zones when they are loaded from disk. BIND
Version 9 does not verify signatures on loading and ignores
the option.
See the description of
Section 6.5.3.6.6.
notify-source in Section 6.5.3.6.6.
notify-source-v6 in
See the descriptions of these options in Section 6.5.3.6.13.
6.5.4 IPv6 Support in BIND Version 9
BIND supports all forms of IPv6 name-to-address and address-to-name lookups.
It also uses IPv6 addresses to make queries when running on an IPv6-capable
system. For information about configuring the BIND server for IPv6, see the HP
TCP/IP Services for OpenVMS Guide to IPv6.
Configuring and Managing BIND Version 9 6–47
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
The use of AAAA records is recommended because A6 records have been moved
to experimental status. Like most stub resolvers, the resolver in TCP/IP Services
supports only AAAA lookups because of the difficulty of following A6 chains.
For IPv6 lookups, use of the nibble format that is used in the ip6.arpa reverse
mapping zone is recommended because the bitstring format used in the ip6.arpa
reverse mapping zone has been moved to experimental status. Also, the ip6.int
reverse mapping zone (defined in RFC 1886) has been deprecated. For more
information about A6 and the bitstring format, refer to RFC 2874.
6.5.4.1 Address Lookups Using AAAA Records
The AAAA record is a parallel to the IPv4 A record. It specifies the entire address
in a single record. For example:
$ORIGIN example.com.
host
3600
IN
AAAA
3ffe:8050:201:1860:42::1
6.5.4.2 Address-to-Name Lookups Using Nibble Format
As in IPv4, when looking up an address in nibble format, the address components
are simply reversed and ip6.arpa. is appended to the resulting name. For
example, the following provides reverse name lookup for a host with address
3ffe:8050:201:1860:42::1:
$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN
PTR
host.example.com.
6.5.5 DNS Notify
DNS Notify allows master name servers to notify their slave servers of changes to
a zone’s data. In response to a NOTIFY message from a master server, the slave
checks to see whether its version of the zone is the current version. If it is not,
the slave initiates a transfer. For more information, see the description of the
notify option in Table 6–7.
6.5.6 Incremental Zone Transfers (IXFR)
The incremental zone transfer (IXFR) protocol is a way for slave servers to
transfer only changed data instead of having to transfer the entire zone. The
IXFR protocol is documented in RFC 1995.
When acting as a master, BIND Version 9 supports IXFR for those zones in which
the necessary change history information is available. These include master
zones maintained by dynamic update and slave zones whose data was obtained
by IXFR, but not manually maintained master zones and slave zones obtained by
performing a full zone transfer (AXFR). When acting as a slave, BIND attempts
to use IXFR unless it is explicitly disabled. For more information about disabling
IXFR, see the description of the request-ixfr clause of the server statement in
Section 6.5.3.7.
6.5.7 Dynamic Updates
With dynamic updates, the BIND server can add, modify, or delete records or
RRsets in the master zone files.
Dynamic updating is enabled on a zone-by-zone basis by including an allowupdate or update-policy clause in the zone statement. Dynamic updating is
described in RFC 2136.
6–48 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Updating of secure zones (zones using DNSSEC) is presented in RFC 3007.
SIG and NXT records affected by updates are automatically regenerated by the
server using an online zone key. Update authorization is based on transaction
signatures and on an explicit server policy.
6.5.7.1 The Journal File
All changes made to a zone using dynamic update are stored in the zone’s journal
file. This file is automatically created by the server when the first dynamic
update takes place. The name of the journal file is formed by appending _JNL to
the name of the corresponding zone file. The journal file is in a binary format and
should not be edited manually.
The server also occasionally writes (or ‘‘dumps’’) the complete contents of the
updated zone to its zone file. This is not done immediately after each dynamic
update; that would be too slow when a large zone is updated frequently. Instead,
the dump is delayed by 15 minutes, allowing additional updates to take place.
When a server is restarted after a shutdown or failure, it replays the journal file
to incorporate into the zone any updates that took place after the last zone dump.
Changes that result from incoming incremental zone transfers are journaled in a
similar way.
The zone files of dynamic zones should not be edited because they are not
guaranteed to contain the most recent dynamic changes—those are only in
the journal file.
If you have to make changes to a dynamic zone manually, use the following
procedure:
1. Flush any dynamic updates in _JNL files to the master zone files using the
following command:
$ rndc flush-updates
2. Shut down the server using the following command:
$ @SYS$STARTUP:TCPIP$BIND_SHUTDOWN.COM
3. Remove the zone’s _JNL file.
4. Edit the zone file.
5. Restart the server using the following command:
$ @SYS$STARTUP:TCPIP$BIND_STARTUP.COM
Removing the _JNL file is necessary because the manual edits are not present in
the journal, rendering it inconsistent with the contents of the zone file.
6.5.7.2 Dynamic Update Policies
BIND Version 9 supports two methods of granting clients the right to perform
dynamic updates to a zone. You can configure them using either the allowupdate option or the update-policy option.
The allow-update clause works the same way as in previous versions of BIND. It
grants given clients the permission to update any record of any name in the zone.
The update-policy clause is new in BIND 9 and allows more fine-grained control
over what updates are allowed. A set of rules is specified, where each rule either
grants or denies permissions for one or more names to be updated by one or more
identities. The rules apply to master zones only.
Configuring and Managing BIND Version 9 6–49
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
The update-policy statement only examines the signer of a message; the source
address is not relevant. If the dynamic update request message is signed (that
is, it includes either a TSIG or SIG(0) record), the identity of the signer can be
determined.
If an allow-update statement appears when the update-policy statement is
present, a configuration error occurs.
Use the following format to define rules:
( grant | deny ) identity nametype name [ types ]
Each rule grants or denies privileges. Once a message has successfully matched
a rule, the operation is immediately granted or denied and no further rules are
examined. A rule is matched when the signer matches the identity field, the
name matches the name field, and the type is specified in the type field. The rule
definition includes the following fields:
•
•
grant or deny specifies whether to grant or deny privileges.
identity specifies the signer of the message. Use a name or a wildcard in the
identity field.
•
name specifies the name to be updated.
•
nametype specifies one of the following:
name, which matches when the updated name is the same as the name in
the name field.
subdomain, which matches when the updated name is a subdomain of the
name in the name field (including the name itself).
wildcard, which matches an updated name that is a valid expansion of
the wildcard name in the name field.
self, which matches when the updated name is the same as the message
signer. The name field is ignored.
•
types specifies the types of resource records.
If no types are specified, the rule matches all types except SIG, NS, SOA, and
NXT. Types can be specified by name, including ANY. ANY matches all types
except NXT, which can never be updated.
6.5.7.3 Creating Updates Manually
If the name server for the domain is configured to accept dynamic updates, you
can manually create updates to the domain database file using the nsupdate
utility.
Note
Zones that are under dynamic control using nsupdate or a DHCP server
should not be edited by hand. Manual edits could conflict with dynamic
updates and could cause loss of data.
You start the utility using the NSUPDATE command, which is defined when you
run the TCPIP$DEFINE_COMMANDS.COM procedure.
You can enter commands to the nsupdate utility interactively, or you can specify
a file that contains nsupdate commands.
6–50 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
Transaction signatures can be used to authenticate update requests, as described
in Section 6.2.3. Signatures rely on a shared secret that should be known to
only the nsupdate utility and the name server. TSIG uses the HMAC-MD5
encryption algorithm. It is important to specify the encryption algorithm because
additional algorithms will be made available in the future. Use the appropriate
configuration options in the server and key statements in TCPIP$BIND.CONF
to ensure the name server associates the secret key and algorithm with the IP
address of the client application that uses TSIG authentication. The nsupdate
utility does not read the TCPIP$BIND.CONF file.
6.5.8 Configuring Cluster Failover and Redundancy
In the same OpenVMS Cluster, multiple BIND master servers can share a
common database, thereby providing redundancy and a failover mechanism when
one of the servers becomes unavailable.
To configure a DNS cluster failover and redundancy environment, perform the
following steps on each node that acts as a BIND master server.
1. Run the TCPIP$CONFIG command procedure, and from the Servers menu
enable the BIND service.
2. Edit the BIND configuration file,
SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND.CONF.
a. Configure the node as a master server.
b. Add or edit the options statement. The directory substatement should
be as follows:
options {
directory "TCPIP$BIND_COMMON";
};
TCPIP$BIND_COMMON is a logical name defined in the TCPIP$BIND_
COMMON_STARTUP.COM command procedure as a search list. The
search list consists of the SYS$SPECIFIC:[TCPIP$BIND] directory and
the common directory. In the next step, the setup command procedure
prompts you to specify the device on which the common directory is to
reside. If you do not specify a device, the default device and directory
is common_device:[TCPIP$BIND_COMMON], where common_device is
generated automatically in the following manner:
If the SYSUAF logical is defined, the common disk is determined from
its definition.
If the SYSUAF logical is not defined, the system uses
SYS$SYSDEVICE as the default device.
3. Run the SYS$MANAGER:TCPIP$BIND_CLUSTER_SETUP.COM command
procedure.
This procedure creates two other command procedures that manage the
startup and shutdown processes of the BIND component in a cluster
environment:
•
SYS$MANAGER:TCPIP$BIND_COMMON_STARTUP.COM
•
SYS$MANAGER:TCPIP$BIND_COMMON_SHUTDOWN.COM
Configuring and Managing BIND Version 9 6–51
Configuring and Managing BIND Version 9
6.5 Configuring the BIND Server
These files define the BIND system logicals and accounting information.
To remove the failover setup from your system, first shut down the BIND
server by using the TCPIP$BIND_COMMON_SHUTDOWN.COM command
procedure, then delete these two files.
4. Place any database files to be shared in the common directory.
Note
Be careful to remove from SYS$SPECIFIC:[BIND] any databases that
are to be shared. Using the search list logical, BIND will find any
SYS$SPECIFIC:[BIND] databases first and use those. This might not be
the result you want.
5. Start up BIND by entering the following command:
$ @SYS$MANAGER:TCPIP$BIND_STARTUP.COM
Caution
The use of dynamic updates in conjunction with a master BIND server
that is participating in cluster failover and redundancy is not supported
and might cause serious problems.
6.5.8.1 Changing the BIND Database
If multiple master BIND servers are running in a cluster, and a change is made
to the common BIND database, the database must be reloaded on each node
that is running the master BIND server. To reload the BIND database on every
node in the cluster where the master BIND server is running, enter the following
command:
TCPIP> SET NAME_SERVICE /INITIALIZE /CLUSTER=dev:[directory]
The /CLUSTER qualifier takes the directory specification of the common BIND
directory as a value. If you omit the device and directory, they default to:
common_device:[TCPIP$BIND_COMMON]
In this case, common_device is generated automatically in the following manner:
•
If the SYSUAF logical is defined, the the common disk is determined from its
definition.
•
If SYSUAF logical is not defined, the system uses SYS$SYSDEVICE as the
default device.
6.6 Populating the BIND Server Databases
To populate the BIND server database files, use one of the following methods:
•
Convert an existing host database with the CONVERT/UNIX BIND
command.
•
Manually edit the ZONE.DB files.
6–52 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
6.6.1 Using Existing Databases
To populate the BIND server database by copying information from the local hosts
database and other database files, enter the CONVERT/UNIX BIND command.
This command:
•
Creates a BIND server database (if needed).
•
Extracts data from the local hosts database. (The BIND server uses UNIX
style formatted files.)
•
Extracts Mail Exchange (MX) information from the routes database.
•
Populates the BIND server database with the host and MX records.
•
Creates a forward translation file with the following characteristics:
It has address, canonical name, and MX entries.
If a file with the same name as the output file already exists, the serial
number from that file’s start-of-authority (SOA) entry increments and
becomes the serial number of the new output file.
If no previous version of the output file exists, the serial number for the
new file is 1.
When you specify forward translation (by omitting the /DOMAIN qualifier),
any host in the local hosts database that is not qualified with a domain is
included in the target domain. For example, if the local domain is x.y.z., the
CONVERT/UNIX BIND command includes: a, b.x.y.z, c.x.y.z.z but does
not include d.x.y.h.
•
Creates a reverse translation file if you specify /DOMAIN=(domain.name) and
the end of domain.name is IN-ADDR.ARPA.
The created reverse translation file has the following characteristics:
Only records applicable to the domain you specify are placed into the
output file.
The output file has domain name pointer entries.
If a file with the same name as the output file already exists, the serial
number from that file’s SOA entry increments and becomes the serial
number of the new output file.
If no previous version of the output file exists, the serial number for the
new file is 1.
The file selects hosts with IP addresses that match the partial IP address
from domain.name. For example, /DOMAIN=16.99.IN-ADDR.ARPA does
a reverse translation and selects hosts whose addresses begin with 99.16.
If the BIND server’s directory is SYS$SPECIFIC:[TCPIP$BIND] and
you have specified domain abc.def.com, the default output file is named
SYS$SPECIFIC:[TCPIP$BIND]ABC_DEF_COM.DB.
HP suggests that you do not change the default directory name. If you do, the file
is created in your current directory.
On the command line, specify the full OpenVMS file specification. Do not specify
a version number, and do not use wildcards. The following example uses the
domain ucx.ern.sea.com, creates a UCX_ERN_SEA_COM.DB file, creates a
208_20_9_IN-ADDR_ARPA.DB file, and checks the results by displaying directory
listings with the new file.
Configuring and Managing BIND Version 9 6–53
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
TCPIP> CONVERT/UNIX BIND /DOMAIN=UCX.ERN.SEA.COM
TCPIP> CONVERT/UNIX BIND /DOMAIN=208.20.9.IN-ADDR.ARPA
TCPIP> SET DEFAULT SYS$SPECIFIC:[TCPIP$BIND]
$ DIRECTORY
Directory SYS$SPECIFIC:[TCPIP$BIND]
127_0_0.DB;1
208_20_9_IN-ADDR_ARPA.DB;1
LOCALHOST.DB;1
LOGIN.COM;1
ROOT.HINT;1
TCPIP$BIND.CONF;1
TCPIP$BIND_CONF.TEMPLATE;1
TCPIP$BIND_RUN.LOG;4339
TCPIP$BIND_SERVER.PID;1
UCX_ERN_SEA_COM.DB;5
6.6.2 Manually Editing Zone Files
All name server zone files use the same type of records to define domain database
information. HP recommends that you review these resource records before you
edit any BIND files. Table 6–21 describes the standard resource records (RRs).
Table 6–21 Standard Resource Record Types
Record Type
Description
A
A host address.
A6
An IPv6 address.
AAAA
An IPv6 address.
CERT
A digital certificate.
CNAME
The canonical name of an alias.
DNAME
Delegation of reverse addresses. Replaces the domain name specified
with another name to be looked up. (Described in RFC 2672.)
GPOS
The global position. Superseded by LOC.
HINFO
The host’s CPU and operating system.
KEY
A public key associated with a DNS name.
KX
A key exchanger for this DNS name.
MX
A mail exchange for the domain.
NAPTR
A name authority pointer.
NSAP
A network service access point.
NS
The authoritative name server for the domain.
NXT
Used in DNSSEC to securely indicate that RRs with an owner name in
a certain name interval do not exist in a zone and to indicate what RR
types are present for an existing name. For more information, see RFC
2535.
PTR
A pointer to another part of the domain name space.
SIG
A signature. Contains data authenticated in the secure DNS. For more
information, see RFC 2535.
SOA
The start of an authority zone.
SRV
Information about well-known network services. Replaces WKS.
TXT
Text records.
WKS
Information about the well-known network services, such as SMTP,
that a domain supports. Replaced by WKS.
(continued on next page)
6–54 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
Table 6–21 (Cont.) Standard Resource Record Types
Record Type
Description
X25
Representation of X.25 network addresses. Experimental.
The format of DNS records is as follows:
[name] [ttl] IN type data
In this format:
name
Specifies the name of the domain object referenced by a
resource record. The string entered for name is the current
domain unless it ends with a dot. If the name field is blank,
the record applies to the domain object last named.
ttl
Defines the length of time, in seconds, that the information
in this resource record should be kept in cache. Usually, the
time-to-live field is left blank, and the default ttl, set for the
entire zone SOA record, is used.
IN
Identifies the record as an Internet DNS resource record.
type
Identifies what kind of resource record this is. (See
Table 6–21 for the record types you can specify.)
data
Information specific to this type of resource record. For
example, in an A record, this is the field that contains the
actual IP address.
6.6.2.1 Setting TTLs
The time to live (TTL) of the RR field is a 32-bit integer that represents the
number of seconds that an RR can be cached before it should be discarded. The
following types of TTL values are used in a zone file:
•
SOA
The last field in the SOA is the negative caching TTL. This controls how long
other servers cache no-such-domain (NXDOMAIN) responses from you.
The maximum time for negative caching is 3 hours (3h).
•
$TTL
The $TTL directive at the top of the zone file (before the SOA) gives a default
TTL for every RR without a specific TTL set.
•
RR TTLs
Each RR can have a TTL as the second field in the RR, which controls how
long other servers can cache it.
All of these TTLs default to units of seconds, though units can be explicitly
specified (for example, 1h30m for 1 hour and 30 minutes).
6.6.2.2 Zone File Directives
While the master file format itself is class independent, all records in a master
file must be of the same class. The master file directives are described in the
following list:
•
$ORIGIN domain-name [comment ]
Sets the domain name that is appended to any unqualified records. When a
zone is first read, an implicit $ORIGIN zone-name directive is applied.
If domain specified is not absolute, the current $ORIGIN is appended to it.
Configuring and Managing BIND Version 9 6–55
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
For example, the following are interpreted the same way:
$ORIGIN example.com
WWW
CNAME MAIN-SERVER
And:
WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
•
$INCLUDE filename [ origin ] [ comment ]
Reads and processes the specified file as if it were included into the file at
this point. If origin is specified, the file is processed with $ORIGIN set to that
value; otherwise, the current $ORIGIN is used.
Once the file has been read, the origin and the current domain name revert to
the values they had prior to the $INCLUDE.
•
$TTL default-ttl [comment]
Sets the default time to live (TTL) for subsequent records with undefined
TTLs. Valid TTLs are in the range of 0—2147483647 seconds.
6.6.3 Saving Backup Copies of Zone Data
A slave name server saves backup copies of the zone data in
SYS$SPECIFIC:[TCPIP$BIND]. Do not delete these backup copies. When
the master server is down and the slave server is running, the slave server
cannot perform a zone transfer until the master server comes back up. However,
with backup copies, the slave server has some data (though possibly out of date)
to perform its basic tasks.
6.6.4 Sample Database Files
The following sections provide sample BIND database files.
6.6.4.1 Local Loopback
In the LOCALHOST.DB file, the local host address is usually 127.0.0.1. The
following sample LOCALHOST.DB file shows the forward translation for the local
loopback interface:
;
; File name:
LOCALHOST.DB
; Product:
HP TCP/IP Services for OpenVMS
; Version:
V5.4
;
; © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
;
; BIND data file for local loopback interface (forward translation).
;
;
$ORIGIN localhost.
@
1D IN SOA
@ root (
42
;Serial
3H
;Refresh
15M
;Retry
1W
;Expiry
1D )
;Minimum
;
1D IN NS
@
1D IN A
127.0.0.1
6–56 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
The following sample 127_0_0.DB file shows the reverse translation for the local
loopback interface:
;
; File name:
127_0_0.DB
; Product:
HP TCP/IP Services for OpenVMS
; Version:
V5.4
;
; © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
;
;
; BIND data file for local loopback interface (forward translation)
;
$ORIGIN 0.0.127.in-addr.arpa.
@
1D IN SOA
localhost.root.localhost. (
42
;Serial
3H
;Refresh
15M
;Retry
1W
;Expiry
1D )
;Minimum
;
1D IN NS
localhost.
1
1D IN PTR
localhost.
These local host databases provide forward and reverse translation for the widely
used LOCALHOST name. The LOCALHOST name is always associated with the
IP address 127.0.0.1 and is used for local loopback traffic.
6.6.4.2 Hint File
This file contains root name server hints. Any name server running on a host
without direct Internet connectivity should list the internal roots in its hint file.
The following sample shows a ROOT.HINT file. In earlier releases, this file was
called NAMED.CA:
;
; File name:
ROOT.HINT
; Product:
HP TCP/IP Services for OpenVMS
; Version:
V5.4
;
; © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
;
;
; DESCRIPTION:
;
;
Data file for initial cache data for root domain servers.
;
; <<>> DiG 9.2.1 <<>>
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11672
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUESTION SECTION:
;.
IN
NS
Configuring and Managing BIND Version 9 6–57
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
;; ANSWER SECTION:
.
.
.
.
.
.
.
.
.
.
.
.
.
102059
102059
102059
102059
102059
102059
102059
102059
102059
102059
102059
102059
102059
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
188459
188459
188459
188459
188459
188459
188459
188459
188459
188459
188459
188459
188459
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
A
A
A
A
A
A
A
198.41.0.4
128.9.0.107
192.33.4.12
128.8.10.90
192.203.230.10
192.5.5.241
192.112.36.4
128.63.2.53
192.36.148.17
192.58.128.30
193.0.14.129
198.32.64.12
202.12.27.33
;;
;;
;;
;;
Query time: 1069 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Tue May 6 11:06:27 2003
MSG SIZE rcvd: 436
This cache initialization file contains NS records that name root servers and A
records that provide the addresses of root servers.
To create a ROOT.HINT file:
1. Run TCPIP$CONFIG.
2. Select the Server Components menu.
3. Select the BIND server.
4. Enable the BIND server.
This procedure creates the ROOT.HINT file and places the file in the
SYS$SPECIFIC:[TCPIP$BIND] directory.
6.6.4.3 Forward Translation File
The forward translation file, domain_name.DB, stores host-name-to-address
mapping. For example, the database file UCX_ERN_SEA_COM.DB is created for
the domain UCX.ERN.SEA.COM.
The following example shows a domain_name.DB file:
6–58 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
$TTL 86400
$ORIGIN ucx.ern.sea.com.
@
IN
SOA
(
owl.ucx.ern.sea.com. pmaster.owl.ern.sea.com.
23
600
300
172800
43200 )
;
;
;
;
;
Serial
Refresh
Retry
Expire
Minimum
;
;
thrush
condor
birdy
seagull
owl
peacock
redwing
robin
IN
IN
NS
NS
owl.ucx.ern.sea.com.
condor.ucx.ern.sea.com.
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
MX
MX
MX
MX
MX
A
MX
MX
MX
MX
MX
A
MX
MX
MX
MX
MX
A
MX
MX
MX
MX
MX
A
MX
MX
MX
MX
MX
A
A
A
9.20.208.53
9.20.208 or 90
9.20.208.47
10 birdy.ucx.ern.sea.com.
100 inet-gw-1.pa.emu.com.
100 mts-gw.pa.emu.com.
200 crl.emu.com.
300 nester.emu.com.
9.20.208.30
10 seagull.ucx.ern.sea.com.
100 inet-gw-1.pa.emu.com.
100 mts-gw.pa.emu.com.
200 crl.emu.com.
300 nester.emu.com.
9.20.208.72
10 owl.ucx.ern.sea.com.
100 inet-gw-1.pa.emu.com.
100 mts-gw.pa.emu.com.
200 crl.emu.com.
300 nester.emu.com.
9.20.208.73
10 pultdown.ucx.ern.sea.com.
100 inet-gw-1.pa.emu.com.
100 mts-gw.pa.emu.com.
200 crl.emu.com.
300 nester.emu.com.
9.20.208.79
10 redwing.ucx.ern.sea.com.
100 inet-gw-1.pa.emu.com.
100 mts-gw.pa.emu.com.
200 crl.emu.com.
300 nester.emu.com.
9.20.208.47
9.20.208.30
9.20.208.72
This file is created only for the master server. All other servers obtain this
information from the master server. This file contains most of the domain
information and has the following characteristics:
•
Begins with an SOA record and a few NS records that define the domain and
its servers.
•
Maps host names to IP addresses.
•
Contains A, MX, CNAME, and other records.
MX records identify the servers in a domain that are used for forwarding mail.
Use MX records and preference numbers to define the order in which mail servers
are used. The lower the preference number, the more desirable the server.
Configuring and Managing BIND Version 9 6–59
Configuring and Managing BIND Version 9
6.6 Populating the BIND Server Databases
6.6.4.4 Reverse Translation File
The reverse translation file, address.DB, stores address-to-host-name mapping
(reverse mapping) information. For example, the database file 208_20_9_INADDR_ARPA.DB is created for the domain 208.20.9.IN-ADDR.ARPA.
The following example shows an address.DB file:
$TTL 86400
$ORIGIN 208.20.9.in-addr.arpa.
@
IN SOA owl.ucx.ern.sea.com. pmaster.owl.ucx.ern.sea.com.
(
1
; Serial
600
; Refresh
300
; Retry
172800 ; Expire
43200 ) ; Minimum
;
IN
NS
owl.ucx.ern.sea.com.
IN
NS
condor.ucx.ern.sea.com.
;
53
IN
PTR
thrush.ucx.ern.sea.com.
10
IN
PTR
condor.ucx.ern.sea.com.
47
IN
PTR
birdy.ucx.ern.sea.com.
30
IN
PTR
seagull.ucx.ern.sea.com.
72
IN
PTR
owl.ucx.ern.sea.com.
73
IN
PTR
peacock.ucx.ern.sea.com.
79
IN
PTR
redwing.ucx.ern.sea.com.
PTR records predominate in this file because they are used to translate addresses
to host names.
6.7 Examining Name Server Statistics
The BIND server collects statistics that record server activity. To examine BIND
statistics, use one of the following commands:
•
The TCP/IP management command SHOW NAME_SERVICE /STATISTICS
•
The rndc stats command
Statistics are logged to the TCPIP$BIND.STATS file, located in
SYS$SPECIFIC:[TCPIP$BIND].
The following sample shows a statistics log:
+++ Statistics Dump +++ (1004986341)
success 17
referral 0
nxrrset 1
nxdomain 1
recursion 6
failure 0
--- Statistics Dump --- (1004986341)
The statistics dump begins with the line +++ Statistics Dump +++ (973798949).
The number in parentheses is a standard UNIX timestamp, measured as seconds
since January 1, 1970. Following that line are a series of lines containing a
counter type, the value of the counter, a zone name (optional), and a view name
(optional).
The lines without view and zone listed are global statistics for the entire server.
Lines with a zone and view name are for the given view and zone. (The view
name is omitted for the default view.)
6–60 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.7 Examining Name Server Statistics
The statistics dump ends with the line --- Statistics Dump --- (973798949)
The number in parentheses is identical to the number in the beginning line.
The following statistics counters are maintained:
•
success
The number of successful queries made to the server or zone. A successful
query is defined as query that returns a NOERROR response other than a
referral response.
•
referral
The number of queries that resulted in referral responses.
•
nxrrset
The number of queries that resulted in NOERROR responses with no data.
•
nxdomain
The number of queries that resulted in NXDOMAIN responses.
•
recursion
The number of queries that caused the server to perform recursion in order to
find the final answer.
•
failure
The number of queries that resulted in a failure response other than those
described in the previous counters.
6.8 Configuring BIND with the SET CONFIGURATION Command
The following sections describe how to set up BIND servers manually using the
TCP/IP management command SET CONFIGURATION BIND.
Note
This command creates a UCX Version 4.x configuration. If you set up your
BIND name server using this command, you must also use the TCP/IP
management command CONVERT/CONFIGURATION BIND command
to convert the databases to the BIND Version 9 format. If you omit this
step, your changes will not take effect.
6.8.1 Setting Up a Master Name Server
To instruct the master name server to read the appropriate database files
using the information in TCPIP$CONFIGURATION.DAT, use the SET
CONFIGURATION BIND command. Use the SHOW CONFIGURATION
BIND command to display BIND information from the configuration database
(TCPIP$CONFIGURATION.DAT).
The following commands tell the name server to read the appropriate files:
TCPIP> SET CONFIGURATION BIND /CACHE
TCPIP> SET CONFIGURATION BIND _TCPIP> /PRIMARY=(DOMAIN:0.0.127.IN-ADDR.ARPA, FILE:NAMED.LOCAL)
TCPIP> SET CONFIGURATION BIND _TCPIP> /PRIMARY=(DOMAIN:UCX.ERN.SEA.COM, FILE:UCX_ERN_SEA_COM.DB)
Configuring and Managing BIND Version 9 6–61
Configuring and Managing BIND Version 9
6.8 Configuring BIND with the SET CONFIGURATION Command
TCPIP> SET CONFIGURATION BIND _TCPIP> /PRIMARY=(DOMAIN:208.20.9.IN-ADDR.ARPA, FILE:208_20_9_IN-ADDR_ARPA.DB)
To view these settings, use the SHOW CONFIGURATION BIND command.
6.8.2 Setting Up a Secondary (Slave) Name Server
You can configure a secondary server to populate itself by copying the DNS
database files from the master server.
To configure a secondary server, enter the following commands:
TCPIP> SET CONFIGURATION BIND /CACHE
TCPIP> SET CONFIGURATION BIND _TCPIP> /PRIMARY=(DOMAIN:0.0.127.IN-ADDR.ARPA, FILE:NAMED.LOCAL)
TCPIP> SET CONFIGURATION BIND _TCPIP> /SECONDARY=(DOMAIN:UCX.ERN.SEA.COM, _TCPIP> FILE:UCX_ERN_SEA_COM.DB,HOST:OWL)
TCPIP> SET CONFIGURATION BIND _TCPIP> /SECONDARY=(DOMAIN:208.20.9.IN-ADDR.ARPA, _TCPIP> FILE:208_20_9_IN-ADDR_ARPA.DB, _TCPIP> HOST:OWL.UCX.ERN.SEA.COM)
6.8.3 Setting Up a Cache-Only Server
To configure a cache-only server, enter the following command:
TCPIP> SET CONFIGURATION BIND /CACHE
This command points the server to the file NAMED.CA.
6.8.4 Setting Up a Forwarder Name Server
To configure a forwarder server, enter the following command:
TCPIP> SET CONFIGURATION BIND /FORWARDERS=(HOST:host)
In this command, host specifies the forwarding server.
Note
You cannot set up a server to be both a forwarder and a caching server.
6.9 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 the information is not found, the
resolver then queries the BIND name server for host information.
Note
The BIND resolver is based on the BIND Version 8 implementation of
DNS.
6–62 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.9 Configuring the BIND Resolver
The resolver is automatically configured by TCPIP$CONFIG when you choose
Option 1 --- Core Environment. To display your resolver configuration, enter the
following TCP/IP management command:
TCPIP> SHOW NAME_SERVICE
TCP/IP Services displays the following data:
BIND Resolver Parameters
Local domain: ucx.ern.sea.com
System
State:
Started, Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
UDP
ucx.ern.sea.com
4
4
lark
ucx.ern.sea.com,ern.sea.com,sea.com
Process
State:
Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
Here, host LARK in the current domain is the default name server. To add
records to the local hosts database, use the SET HOST command. For example,
the following command adds host birdy to the local hosts database. (For more
information about using SET commands, see the HP TCP/IP Services for
OpenVMS Management Command Reference manual.)
TCPIP> SET HOST birdy /ADDRESS=9.20.208.47
To delete server entries from the configuration database or to add new entries,
enter the following command:
TCPIP> SET NAME_SERVICE /NOSERVER=LARK /SYSTEM
This command modifies the volatile database. To make a change to the
permanent database, enter the SET CONFIGURATION NAME_SERVICE
command.
To view the results, enter the SHOW CONFIGURATION NAME_SERVICE
command.
6.9.1 Changing the Default Configuration
To add a new server and enable the BIND resolver, enter the following command:
TCPIP> SET NAME_SERVICE /SERVER=host /ENABLE /SYSTEM
For host, specify the host name or IP address of the BIND server or servers that
the BIND resolver is to 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.
Configuring and Managing BIND Version 9 6–63
Configuring and Managing BIND Version 9
6.9 Configuring the BIND Resolver
If you define a server list and then add a new server with the
SET NAME_SERVICE /SERVER command, the new server is added to the
end of the list.
SET commands affect the volatile database. To save your changes to the
permanent database, use the SET CONFIGURATION commands. The changes
you make with the SET CONFIGURATION commands take effect the next time
the software starts up. For example:
TCPIP> SET CONFIGURATION NAME_SERVICE /SERVER=host /ENABLE
TCPIP> SHOW CONFIGURATION NAME_SERVICE
BIND Resolver Configuration
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
UDP
ucx.ern.sea.com
4
4
9.20.208.47, 9.20.208.53
No values defined
6.9.2 Examples
The following command defines hosts PARROT, SORA, and JACANA as
systemwide BIND servers and enables the BIND resolver:
PARROT> TCPIP
TCPIP> 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 are not
queried.
TCPIP> SET NAME_SERVICE /SERVER=OSPREY
6.9.3 Resolver Default Search Behavior
By default, if no search list is defined and the host name as you typed it has no
dot (.) in the name, the BIND resolver performs a lookup using the following
forms of the host name (in this order):
1. The host name, with the default domain appended
2. Just the host name
For example, suppose you enter the following command:
TCPIP> SHOW HOST OWL
Assuming that the default domain is ucx.ern.sea.com, the resolver performs
lookups as follows:
1. On the host name and domain owl.ucx.ern.sea.com.
2. If that lookup was unsuccessful, the resolver searches for host owl.
This behavior is different than the resolver lookup behavior in previous releases
(UCX BIND Version 4.x.). The following section provides more information.
6–64 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.9 Configuring the BIND Resolver
6.9.4 Resolver Search Behavior in Earlier Releases
In previous releases, the resolver performed lookups as follows:
1. Appended the default domain to the host name and performed a lookup.
2. If the previous lookup failed, the resolver removed the leftmost label from the
default domain name, appended the result to the host name and performed
the lookup.
3. If that lookup failed, the resolver again removed the leftmost label from the
default domain name, appended the result to the host name, and performed
the lookup.
For each unsuccessful lookup, this procedure was repeated until only two labels
remained in the resulting domain name.
If all these attempts failed, the resolver tried just the host name as typed (as long
as it contained at least one dot).
For example, suppose you entered the following command:
TCPIP> SHOW HOST OWL
Assuming the default domain was ucx.ern.sea.com, the resolver performed
lookups as follows:
1. On owl.ucx.ern.sea.com.
2. If the previous lookup was unsuccessful, the resolver searched for
owl.ern.sea.com.
3. If that lookup was unsuccessful, the resolver searched for owl.sea.com.
4. Finally, if the preceding lookup was unsuccessful, the resolver searched for
owl.
6.9.5 Setting the Resolver’s Domain Search List
The search list is provided to make entering lookup commands easier by not
requiring you to type fully qualified domain names. The search list consists of
domain names that the resolver uses when performing lookups. By default,
the search list consists of only the default domain, which is stored in the
TCPIP$CONFIGURATION.DAT file.
You can change the elements in the search list by entering the
SET NAME_SERVICE command, as shown in the following example:
TCPIP> SET NAME_SERVICE /PATH=(ucx.ern.sea.com,dux.sea.com,mux.ern.sea.com)/SYSTEM
For example, suppose you enter the following command:
TCPIP> SHOW HOST CANARY
The resolver performs lookups as follows:
1. On canary.ucx.ern.sea.com.
2. If the previous lookup was unsuccessful, the resolver searches for
canary.dux.sea.com.
3. If that lookup was unsuccessful, the resolver searches for
canary.mux.ern.sea.com.
4. If that lookup was unsuccessful, the resolver searches for canary.
Configuring and Managing BIND Version 9 6–65
Configuring and Managing BIND Version 9
6.9 Configuring the BIND Resolver
In the following output of the SHOW NAME_SERVICE command, the PATH:
label shows the search list information entered with the SET NAME_SERVICE
/PATH command. This command displays systemwide information and processspecific information (if process-specific information is set).
TCPIP> SHOW NAME_SERVICE
BIND Resolver Parameters
Local domain: ucx.ern.sea.com
System
State:
Started, Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
UDP
ucx.ern.sea.com
4
4
ucx, lemng, 16.99.0.10
ucx.ern.sea.com, dux.ern.sea.com, mux.ern.sea.com
Process
State:
Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
$
Any additions you make are appended to the end of the search list.
To remove an element from the search list, enter the following command:
TCPIP> SET NAME_SERVICE /NOPATH=dux.ern.sea.com /SYSTEM
Note
When you run TCPIP$CONFIG.COM after upgrading from UCX
to TCP/IP Services for OpenVMS, the system creates a domain
search list that is consistent with the UCX default lookup behavior.
TCPIP$CONFIG.COM uses the default domain to create a
search list consisting of each parent domain. For example, if the
default domain is ucx.ern.sea.com, the resulting search list is
ucx.ern.sea.com,ern.sea.com,sea.com. You can modify the current
search list by using the SET CONFIGURATION NAME_SERVER /PATH
command.
6.10 BIND Server Administrative Tools
The following administrative tools play an integral part in the management of a
server.
•
The bind_checkconf utility checks the syntax of the BIND server
configuration file.
•
The bind_checkzone utility checks a zone file for syntax and consistency.
•
The dnssec_keygen generates keys for DNSSEC (secure DNS) and TSIG
(transaction signatures).
6–66 Configuring and Managing BIND Version 9
Configuring and Managing BIND Version 9
6.10 BIND Server Administrative Tools
•
The dnssec_makekeyset utility generates a key set.
•
The dnssec_signkey utility signs a key set.
•
The dnssec_signzone utility signs a zone.
•
The rndc utility allows you to control the operation of a name server.
•
The rndc_confgen utility generates configuration files for the rndc utility.
To use these utilities, you must have system management privileges. Run the
TCPIP$DEFINE_COMMANDS.COM procedure to define the commands described
in the following reference sections.
Configuring and Managing BIND Version 9 6–67
bind_checkconf
bind_checkconf
Checks the syntax of a BIND server configuration file.
Format
bind_checkconf [-v] [-t directory] filename
Description
The bind_checkconf utility checks the syntax, but not the semantics, of a BIND
server configuration file.
Options
-t directory
Looks for filename in the specified directory. The default directory is
SYS$SPECIFIC:[TCPIP$BIND].
-v
Displays only the version number of the bind_checkconf utility and exits.
filename
Specifies the name of the configuration file to be checked. The default file is
SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND.CONF.
6–68 Configuring and Managing BIND Version 9
bind_checkzone
bind_checkzone
Checks a zone file for syntax and consistency.
Format
bind_checkzone [-d] [-q] [-v] [-c class] [-t directory] zonename filename
Description
The bind_checkzone utility checks the syntax and integrity of a zone file. It
performs the same checks as the BIND server does when it loads a zone. This
makes bind_checkzone useful for checking zone files before configuring them into
a name server.
Options
-d
Enables debugging mode.
-q
Enables quiet mode (exit code only).
-v
Displays the version number of bind_checkzone and exits.
-c class
Specifies the class of the zone. If not specified, the default is IN.
-t directory
Looks for the zone in the specified directory. The default directory is
SYS$SYSPECIFIC:[TCPIP$BIND].
zonename
Specifies the name of the zone being checked.
filename
Specifies the name of the zone file.
Configuring and Managing BIND Version 9 6–69
dnssec_keygen
dnssec_keygen
Generates keys for DNSSEC.
Format
dnssec_keygen -a algorithm -b keysize -n nametype [-c class] [-e] [-g generator] [-h]
[-p protocol] [-r randomfile] [-s strength] [-t type] [-v level] name
Description
The dnssec_keygen utility generates keys for DNSSEC, as defined in RFC 2535.
It can also generate keys for use with TSIG (Transaction Signatures), as defined
in RFC 2845.
Parameters
name
Specifies the name of the domain.
Options
-a algorithm
Selects the cryptographic algorithm. The value of algorithm must be one of the
following:
•
RSAMD5
•
RSA
•
DSA
•
DH (Diffie-Hellman)
•
HMAC-MD5
These values are not case sensitive.
-b keysize
Specifies the number of bits in the key. The choice of key size depends on the
algorithm used:
•
RSA keys must be between 512 and 4096 bits.
•
DH keys must be between 128 and 4096 bits.
•
DSA keys must be between 512 and 1024 bits and must be an exact multiple
of 64.
•
HMAC-MD5 keys must be between 1 and 512 bits.
-n nametype
Specifies the owner type of the key. The value of nametype must one of the
following:
•
ZONE (for a DNSSEC zone key)
•
HOST or ENTITY (for a key associated with a host)
•
USER (for a key associated with a user)
These values are not case sensitive.
6–70 Configuring and Managing BIND Version 9
dnssec_keygen
-c class
Indicates that the DNS record containing the key should have the specified class.
If not specified, class IN is used.
-e
If generating an RSA key, specifies the use of a large exponent.
-g generator
If generating a Diffie-Hellman key, specifies the generator. Allowed values for
generator are 2 and 5. If no generator is specified, a known prime from RFC 2539
is used, if possible; otherwise the default is 2.
-h
Displays a short summary of the options and arguments to the dnssec_keygen
command.
-p protocol
Sets the protocol value for the generated key. The value of protocol is a number
between 0 and 255. For keys of type USER, the default is 2 (e-mail). For all other
key types, the default is 3 (DNSSEC). Other possible values for this argument are
listed in RFC 2535 and its successors.
-r randomfile
Specifies the source of randomness. The default source of randomness is keyboard
input. randomfile specifies the name of a file containing random data to be used
instead of the default. The special value keyboard indicates that keyboard input
should be used.
Note
When you use the keyboard to generate random data, you must input a
large amount of data. Input requiring hundreds of lines of data is not
unusual for some algorithms. The string ‘‘stop typing’’ appears when
enough data has been input.
-s strength
Specifies the strength value of the key. The value of strength is a number between
0 and 15. This option is currently not used.
-t type
Indicates the use of the key. The type must be one of the following:
•
AUTHCONF (authenticate and encrypt data)
•
NOAUTHCONF (do not authenticate and do not encrypt data)
•
NOAUTH (do not authenticate data)
•
NOCONF (do not encrypt data)
The default is AUTHCONF.
-v level
Sets the debugging level.
Configuring and Managing BIND Version 9 6–71
dnssec_keygen
Generated Keys
When dnssec_keygen completes successfully, it displays a string of the following
form to standard output:
Knnnn.aaa-iiiii
This is an identification string for the key it has generated. These strings can be
used as arguments to the dnssec_makekeyset utility. The string is interpreted as
follows:
•
nnnn is the key name.
•
aaa is the numeric representation of the algorithm.
•
iiiii is the key identifier (or footprint).
dnssec_keygen creates two files, with names based on the printed string. The
file Knnnn.aaa-iiiii_KEY contains the public key, and Knnnn.aaa-iiiii_PRIVATE
contains the private key.
The _KEY file contains a DNS KEY record that can be inserted into a zone file
(either directly, or using an $INCLUDE statement).
The _PRIVATE file contains algorithm-specific fields. For security reasons, this
file does not have general read permission.
Both _KEY and _PRIVATE files are generated for symmetric encryption
algorithms such as HMAC-MD5, even though the public and private key are
equivalent.
Examples
To generate a 768-bit DSA key for the domain example.com, enter the
following command:
1.
$ dnssec_keygen -a DSA -b 768 -n ZONE example.com
This command displays a string of the form:
Kexample_com.003-26160
In this example, dnssec_keygen creates the files KEXAMPLE_COM.00326160_KEY and KEXAMPLE_COM.003-26160_PRIVATE.
6–72 Configuring and Managing BIND Version 9
dnssec_makekeyset
dnssec_makekeyset
Generates signed key sets for DNSSEC.
Format
dnssec_makekeyset [-a] [-s start-time] [-e end-time] [-h] [-p] [-r randomfile] [-t ttl] [-v level] key...
Description
The dnssec_makekeyset utility generates a key set from one or more keys created
by the dnssec_keygen utility. It creates a file containing a KEY record for each
key, and self-signs the key set with each zone key. The output file is of the form
KEYSET-name.DAT, where name is the zone name.
Options
-a
Verifies all generated signatures.
-s start-time
Specifies the date and time when the generated SIG records become valid. This
can be either an absolute or relative time. An absolute start time is indicated by
a number in YYYYMMDDHHMMSS notation. 20000530144500 denotes 14:45:00
UTC on May 30, 2000. A relative start time is indicated by +N, which is N
seconds from the current time. If no start time is specified, the current time is
used.
-e end-time
Specifies the date and time when the generated SIG records expire. An absolute
end time is indicated in YYYYMMDDHHMMSS notation. A time relative to the
start time is indicated by +N, which is N seconds from the start time. A time
relative to the current time is indicated by now+N. If no end time is specified, 30
days from the start time is used as a default.
-h
Displays a short summary of the options and arguments to the
dnssec_makekeyset command.
-p
Uses pseudorandom data when signing the zone. This is faster, but less secure,
than using real random data. This option is useful when signing large zones or
when the entropy source is limited.
-r randomfile
Specifies the source of randomness. The default source of randomness is keyboard
input. The argument randomfile specifies the name of a file containing random
data to be used instead of the default. The special value keyboard indicates that
keyboard input should be used.
Note
When you use the keyboard to generate random data, you must input a
large amount of data. Input requiring hundreds of lines of data is not
Configuring and Managing BIND Version 9 6–73
dnssec_makekeyset
unusual for some algorithms. The string ‘‘stop typing’’ appears when
enough data has been input.
-t ttl
Specifies the time to live (TTL) value of the KEY and SIG records. The default is
3600 seconds.
-v level
Sets the debugging level.
Parameters
key
Specifies the list of keys to be included in the keyset file. These keys
are expressed in the form Knnnn.aaa-iiiii, which was generated by the
dnssec_keygen utility.
Examples
The following command generates a keyset containing the DSA key for
example.com generated in the dnssec_keygen example.
1.
$ dnssec_makekeyset -t 86400 -s 20000701120000 -e +2592000 _$ Kexample.com.003-26160
In this example, dnssec_makekeyset creates the file KEYSET-EXAMPLE_
COM.DAT. This file contains the specified key and a self-generated signature.
The DNS administrator for example.com could send KEYSET-EXAMPLE_
COM.DAT to the DNS administrator for .com for signing, if the .com zone
is DNSSEC-aware and the administrators of the two zones have some
mechanism for authenticating each other and for exchanging the keys and
signatures securely.
6–74 Configuring and Managing BIND Version 9
dnssec_signkey
dnssec_signkey
Signs keysets for DNSSEC.
Format
dnssec_signkey [-a] [-c class] [-s start-time] [-e end-time] [-h] [-p] [-r randomfile] [-v level] keyset key...
Description
The dnssec_signkey utility signs a keyset. The keyset, generated by the
dnssec_makekeyset utility, is for a child zone. The child zone’s keyset is
signed with the zone keys for its parent zone. The output file is of the form
SIGNEDKEY-name.DAT, where name is the zone name.
Parameters
keyset
Specifies the file containing the child’s keyset.
key...
Specifies the keys used to sign the child’s keyset.
Options
-a
Verifies all generated signatures.
-c class
Specifies the DNS class of the key sets.
-s start-time
Specifies the date and time when the generated SIG records become valid. This
can be either an absolute or relative time. An absolute start time is indicated by
a number in YYYYMMDDHHMMSS notation; 20000530144500 denotes 14:45:00
UTC on May 30, 2000. A relative start time is indicated by +N, which is N
seconds from the current time. If no start time is specified, the current time is
used.
-e end-time
Specifies the date and time when the generated SIG records expire. An absolute
time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start
time is indicated by +N, which is N seconds from the start time. A time relative
to the current time is indicated by now+N. If no end time is specified, 30 days from
the start time is used as a default.
-h
Displays a short summary of the options and arguments to the dnssec_signkey
command.
-p
Use pseudorandom data when signing the zone. This is faster, but less secure,
than using real random data. This option may be useful when signing large zones
or when the entropy source is limited.
Configuring and Managing BIND Version 9 6–75
dnssec_signkey
-r randomfile
Specifies the source of randomness. The default source of randomness is keyboard
input. randomfile specifies the name of a file containing random data to be used
instead of the default. The special value keyboard indicates that keyboard input
should be used.
Note
When you use the keyboard to generate random data, you must input a
large amount of data. Input requiring hundreds of lines of data is not
unusual for some algorithms. The string ‘‘stop typing’’ appears when
enough data has been input.
-v level
Sets the debugging level.
Examples
The DNS administrator for a DNSSEC-aware .com zone would use the
following command to sign the keyset file for example.com created by the
dnssec_makekeyset utility with a key generated by the dnssec_keygen utility:
1.
$ dnssec_signkey keyset-example.com. Kcom.003-51944
In this example, the dnssec_signkey utility creates the file SIGNEDKEYEXAMPLE_COM.DAT, which contains the example.com keys and the
signatures by the .com keys.
6–76 Configuring and Managing BIND Version 9
dnssec_signzone
dnssec_signzone
Signs a zone.
Format
dnssec_signzone [-a] [-c class] [-d directory] [-s start-time] [-e end-time] [-f output-file] [-h] [-i interval]
[-n nthreads] [-o origin] [-p] [-r randomfile] [-t] [-v level] zonefile [key...]
DESCRIPTION
The dnssec_signzone utility signs a zone. It generates NXT and SIG records and
produces a signed version of the zone. If there is a signedkey file from the zone’s
parent, the parent’s signatures are incorporated into the generated signed zone
file. The security status of delegations from the signed zone (that is, whether
or not the child zones are secure) is determined by the presence or absence of a
signedkey file for each child zone.
Before signing the zone, you must add the KEY record to the zone database file by
using the $INCLUDE statement. For example, in the zone file example_com.db,
add:
$INCLUDE Kexample_com.003-26160_KEY
Parameters
zonefile
Specifies the file containing the zone to be signed.
key...
Specifies the keys used to sign the zone. If no keys are specified, the default is all
zone keys that have private key files in the current directory.
Options
-a
Verifies all generated signatures.
-c class
Specifies the DNS class of the zone.
-d directory
Looks for signedkey files in the specified directory.
-s start-time
Specifies the date and time when the generated SIG records become valid. This
can be either an absolute or relative time. An absolute start time is indicated by
a number in YYYYMMDDHHMMSS notation. 20000530144500 denotes 14:45:00
UTC on May 30, 2000. A relative start time is indicated by +N, which is N
seconds from the current time. If no start time is specified, the current time is
used.
-e end-time
Specifies the date and time when the generated SIG records expire. An absolute
time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start
time is indicated by +N, which is N seconds from the start time. A time relative
Configuring and Managing BIND Version 9 6–77
dnssec_signzone
to the current time is indicated by now+N. If no end time is specified, 30 days from
the start time is used as a default.
-f output-file
Specifies the name of the output file containing the signed zone. The default is to
append _SIGNED to the input file name.
-h
Displays a short summary of the options and arguments to the dnssec_signzone
command.
-i interval
When a previously signed zone is passed as input, records may be signed again.
The interval option specifies the cycle interval as an offset from the current
time (in seconds). If a SIG record expires after the cycle interval, it is retained.
Otherwise, it is considered to be expiring soon, and it will be replaced.
The default cycle interval is one quarter of the difference between the signature
end and start times. Therefore, if neither the end time nor the start time is
specified, the dnssec_signzone utility generates signatures that are valid for 30
days, with a cycle interval of 7.5 days. Therefore, if any existing SIG records are
due to expire in less than 7.5 days, they are replaced.
-n nthreads
Specifies the number of threads to use. By default, one thread is started for each
detected CPU.
-o origin
Specifies the zone origin. If this option is not specified, the name of the zone file
is assumed to be the origin.
-p
Uses pseudorandom data when signing the zone. This is faster, but less secure,
than using real random data. This option can be useful when signing large zones
or when the entropy source is limited.
-r randomfile
Specifies the source of randomness. The default source of randomness is keyboard
input. randomfile specifies the name of a file containing random data to be used
instead of the default. The special value keyboard indicates that keyboard input
should be used.
Note
When you use the keyboard to generate random data, you must input a
large amount of data. Input requiring hundreds of lines of data is not
unusual for some algorithms. The string ‘‘stop typing’’ appears when
enough data has been input.
-t
Displays statistics at completion.
-v level
Sets the debugging level.
6–78 Configuring and Managing BIND Version 9
dnssec_signzone
Examples
The following command signs the example.com zone with the DSA key
generated by the dnssec_keygen utility. The zone’s keys must be in the zone.
If there are signedkey files associated with this zone or any child zones, they
must be in the current directory.
1.
$ dnssec_signzone -o example.com example_com.db Kexample_com.003-26160
In this example, dnssec_signzone creates the file EXAMPLE_COM.DB_
SIGNED. This file should be referenced in a zone statement in the
TCPIP$BIND.CONF file. This command displays the following:
example_com.db_signed
Configuring and Managing BIND Version 9 6–79
rndc
rndc
Controls the operation of the BIND server.
Format
rndc [-c config] [-s server] [-p port] ["-V"] [-y key-id] command
Description
The rndc utility controls the operation of a name server. rndc communicates with
the name server over a TCP connection, sending commands authenticated with
digital signatures. The only supported authentication algorithm is HMAC-MD5,
which uses a shared secret on each end of the connection. This provides TSIGstyle authentication for the command request and the name server’s response.
All commands sent over the channel must be signed by a key_id known to the
server.
In BIND Version 9, rndc supports all the commands of the BIND Version 8 ndc
utility except start, restart, and stop. Use the BIND startup and shutdown
command procedures, as described in Section 6.4, to accomplish these tasks.
The rndc utility reads a configuration file to determine how to contact the name
server and to decide what algorithm and key it should use.
A configuration file is required, since all communication with the server is
authenticated with digital signatures that rely on a shared secret. The default
location for the rndc configuration file is TCPIP$ETC:RNDC.CONF, but an
alternate location can be specified with the -c option. If the configuration
file is not found, rndc also looks in TCPIP$ETC:RNDC.KEY. The RNDC.KEY
file is generated by running rndc_confgen -a. This command provides basic
functionality, but it offers less configuration flexibility than modifying the
RNDC.CONF file.
Note
For the BIND server to recognize a newly generated RNDC.KEY file, you
must stop and restart the BIND server.
Format of the RNDC.CONF File
The configuration file for the rndc utility is TCPIP$ETC:RNDC.CONF. The
structure of this file is similar to TCPIP$BIND.CONF. Statements are enclosed
in braces and are terminated with semicolons. Clauses in the statements are also
terminated with semicolons. For example:
options {
default-server
default-key
};
localhost;
samplekey;
server localhost {
key
};
samplekey;
key samplekey {
algorithm
secret
};
hmac-md5
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW";
6–80 Configuring and Managing BIND Version 9
rndc
Three statements are used in the RNDC.CONF file:
•
The options statement contains three clauses:
The default-server clause is followed by the name or address of a name
server. This host is used when the name server is not specified as an
argument to rndc.
The default-key clause is followed by the name of a key, which is
represented by a key statement and is used when the key-id is not
specified on the rndc command line and when no key clause is found in a
matching server statement. This key is used to authenticate the server’s
commands and response.
The default-port clause is followed by the port to connect to on the
remote name server. This port is used if no -p port statement is supplied
on the rndc command line and no port clause is included in a matching
server statement.
•
The server statement specifies a host name or address for a name server.
The statement may include the key clause and the port clause. The key
name must match the name of a key statement in the file. The port number
specifies the port to connect to.
•
The key statement specifies the name of a key. The statement has two
clauses:
algorithm specifies the encryption algorithm for rndc to use (HMACMD5).
A secret clause containing the 64-bit encoding of the algorithm’s
encryption key. The base-64 string is enclosed in quotation marks.
To generate the base-64 string for the secret clause, use the
rndc_confgen utility. For example, enter the following command:
$ rndc_confgen
A complete RNDC.CONF file, including the randomly-generated key,
is automatically generated. The rndc_confgen command also displays
commented key and controls statements for the TCPIP$BIND.CONF
file.
Commands
reload
Reloads configuration file and zones.
reload zone [class [view]]
Reload the given zone.
refresh zone [class [view]]
Schedule zone maintenance for the given zone.
reconfig
Reloads the configuration file and loads new zones, but does not reload existing
zone files even if they have changed. This is faster than a full reload when there
is a large number of zones because it avoids the need to examine the modification
times of the zones files.
Configuring and Managing BIND Version 9 6–81
rndc
stats
Writes server statistics to the statistics file, TCPIP$BIND.STATS.
querylog
Toggles query logging. Query logging can also be enabled by explicitly directing
the queries category to a channel in the logging section of TCPIP$BIND.CONF.
dumpdb
Dumps the server’s caches to the dump file, TCPIP$BIND_DUMP.DB.
trace
Increments the servers debugging level by one.
trace level
Sets the server’s debugging level to an explicit value.
notrace
Sets the server’s debugging level to 0.
flush
Flushes the server’s cache.
flush-updates
Saves any pending dynamic updates being stored in the zone journal (_JNL) files
to the master zone files. (This command is available on OpenVMS systems only.)
status
Displays the status of the server. The number of zones includes the internal /CH
zone, and the default ./IN hint zone if no root zone has been explicitly configured.
Options
-c config-file
Uses config-file as the configuration file instead of the default,
TCPIP$ETC:RNDC.CONF.
-s server
Specifies the name or address of the server which matches a server statement
in the configuration file for rndc. If no server is supplied on the command line,
the host named by the default-server clause in the option statement of the
configuration file is used.
-p port
Send commands to the specified TCP port instead of the default control channel
port, 953.
"-V"
Enables verbose logging. Use quotation marks to preserve uppercase options.
-y keyid
Use the specified keyid from the configuration file specified with the -c option.
If the configuration file was not specified on the command line, the rndc
configuration file, RNDC.CONF, is used. The keyid must be known by the
BIND server with the same algorithm and secret string in order for control
message validation to succeed.
6–82 Configuring and Managing BIND Version 9
rndc
If no keyid is specified, rndc first looks for a key clause in the server statement
of the server being used, or if no server statement is present for that host, then
the default-key clause of the options statement.
Note that the configuration file contains shared secrets that are used to send
authenticated control commands to name servers. Therefore, the file should not
have general read or write access.
Configuring and Managing BIND Version 9 6–83
rndc_confgen
rndc_confgen
Generates the configuration files used by the rndc utility.
Format
rndc_confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address]
Description
The rndc_confgen utility generates configuration files for the rndc utility. It
can be used as a convenient alternative to writing the RNDC.CONF file and
the corresponding controls and key statements in TCPIP$BIND.CONF by hand.
The utility can be run with the -a option to set up an RNDC.KEY file, thereby
avoiding the need for an RNDC.CONF file and a controls statement.
Options
-a
Configures rndc automatically. This option creates the file RNDC.KEY in
TCPIP$ETC that is read by both rndc and the BIND server on startup.
The RNDC.KEY file defines a default command channel and authentication
key, allowing rndc to communicate with the BIND server with no further
configuration.
Using the -a option allows BIND Version 9 and rndc to be used as drop-in
replacements for BIND Version 8 and ndc, with no changes to the existing
TCPIP$BIND.CONF file. For information about BIND Version 8, see Appendix D.
Note
For the BIND server to recognize a newly generated RNDC.KEY file, you
must stop and restart the BIND server.
-b keysize
Specifies the size of the authentication key in bits. Must be between 1 and 512
bits; the default is 128.
-c keyfile
Used with the -a option to specify an alternate location for RNDC.KEY.
-h
Prints a short summary of the options and arguments to rndc_confgen.
-k keyname
Specifies the key name of the rndc authentication key. This must be a valid
domain name. The default is rndc-key.
-p port
Specifies the command channel port where the BIND server listens for
connections from rndc. The default is 953.
6–84 Configuring and Managing BIND Version 9
rndc_confgen
-r randomfile
Specifies a source of random data for generating the authorization. The default
source of randomness is keyboard input. randomfile specifies the name of a file
containing random data to be used instead of the default. The special value
keyboard indicates that keyboard input should be used.
-s address
Specifies the IP address where the BIND server listens for command channel
connections from rndc. The default is the loopback address 127.0.0.1.
Configuring and Managing BIND Version 9 6–85
nsupdate
nsupdate
Updates Domain Name System (DNS) servers interactively.
Format
nsupdate [-d] [-y keyname:secret | -k keyfile] [-v] [file-name]
Description
The nsupdate utility creates dynamic updates, which are sent to a DNS server
to update the zone database. nsupdate uses the DNS resolver library to send
dynamic updates to a DNS server requesting the addition or deletion of resource
records. The zone must be configured to accept dynamic updates for the nsupdate
utility to work.
The nsupdate command can accept either a command or the name of a command
file.
Zones that are under dynamic control (with nsupdate or a DHCP server) should
not be edited by hand. Manual updates could conflict with dynamic updates,
causing data to be lost.
If you use a file to supply the updates, the data in the file must be in the following
format:
category section name ttl type rdata
In this format:
•
category is any one of the following keywords:
update
zone
prereq
•
section is any one of the following keywords:
add
delete
nxdomain
yxdomain
nxrrset
yxrrset
•
name is the name of the entry being added.
•
ttl is the time to live (in seconds) for this entry. After this time period, the
name server no longer serves the entry.
•
type specifies the RR type (for example, A, CNAME, NS, MX, TXT).
•
rdata specifies the data appropriate for the RR type being updated.
Lines beginning with a semicolon are comments and are ignored.
6–86 Configuring and Managing BIND Version 9
nsupdate
Options
-d
Specifies debug mode.
-y keyname:secret
Generates a signature, where keyname specifies the name of the key and secret is
a base-64 encoded secret. This option is not recommended because it displays the
shared secret in plain text. Instead, use the -k option.
-k keyfile
Specifies a file that contains the shared secret. The file name has the following
format:
Kname.157-random_PRIVATE
For historical reasons, the file Kname.157-random_KEY must also be present.
-v
Specifies that nsupdate use the TCP protocol instead of the UDP protocol. By
default, nsupdate sends update requests using UDP.
file-name
Specifies a file that contains nsupdate commands.
If you do not specify the name of a command file, the NSUPDATE command
prompts for a command line. Enter one or more of the following commands.
Commands
server servername [port]
Sends all dynamic update requests to the specified name server. When no name
server is specified, the nsupdate utility sends updates to the master server of
the correct zone. The MNAME field of that zone’s SOA record identifies the
master server for that zone. port is the port number to which the dynamic update
requests are sent on the specified name server. If no port number is specified, the
default DNS port number of 53 is used.
local address [port]
Sends all dynamic update requests using the local address. When no local
address is provided, the nsupdate utility sends updates using an address and port
chosen by the system. Specify port to make requests come from a specific port. If
no port number is specified, the system assigns one.
zone zonename
Specifies that all updates are to be made to the specified zone. If no zone
command is provided, the nsupdate utility attempts to determine the correct zone
to update based on the rest of the input.
key keyname secret
Specifies that all updates are to be TSIG signed, using the specified keyname and
key secret pair.
The key command overrides any key specified on the command line using the -y
or -k options.
Configuring and Managing BIND Version 9 6–87
nsupdate
prereq nxdomain domain-name
Requires that no resource record of any type exist with the specified domain
name.
prereq yxrset domain-name type [data]
Makes the presence of an RR set of the specified type owned by domain-name
a prerequisite to performing the update. This requires that a resource record
of the specified type, class, and domain name must exist. If class is omitted, IN
(Internet) is assumed.
prereq nxrrset domain-name [class] {type}
Makes the nonexistence of an RRset of type owned by domain-name a prerequisite
to performing the update specified in successive update commands. This requires
that no resource record exist of the specified type, class, and domain name. If
class is omitted, IN (Internet) is assumed.
The data from each set of prerequisites of this form sharing a common type, class,
and domain name are combined to form a set of resource records. This set of
resource records must exactly match the set of resource records on the zone at
the given type, class, and domain name. The data is written in the standard text
representation of the resource record’s RDATA.
prereq yxdomain domain-name
Makes the existence of the specified domain-name a prerequisite to performing
the update. This requires that the domain name has at least one resource record
of any type.
update delete domain-name ttl [class] [type] [rdata]
Deletes any resource records with the specified domain name. If type and data
are provided, only matching resource records are removed. If class is omitted,
IN (Internet) is assumed. The ttl value is ignored and is included only for
compatibility.
update add domain-name ttl [class] type data
Adds a new resource record with the specified ttl, class, and data to the zone.
The ttl value, the type, and the data must be included. The class is optional and
defaults to IN.
show
Displays the current message, containing all of the prerequisites and updates
specified since the last send command.
send
Sends the current message. This is equivalent to entering a blank line.
Examples
1.
$ TYPE NSUPD.TXT
update delete www.nads.zn.
update add www.nads.zn. 60 CNAME ivy18.nads.zn
$ NSUPDATE NSUPD.TXT
This example shows how to supply a file (NSUPD.TXT) to the nsupdate
utility.
6–88 Configuring and Managing BIND Version 9
nsupdate
2.
$ NSUPDATE
> update delete oldhost.example.com A
> update add newhost.example.com 86400 A 172.16.1.1
>
This example shows how the nsupdate utility is used interactively to insert
and delete resource records from the example.com zone. Notice that the input
contains an extra blank line so that a group of commands are sent as one
dynamic update request to the master name server for example.com.
Any A records for oldhost.example.com are deleted, and an A record for
newhost.example.com with IP address 172.16.1.1 is added. The newly added
record has a TTL value of 86400 seconds (one day).
3.
$ NSUPDATE
> prereq nxdomain nickname.example.com
> update add nickname.example.com 86400 CNAME somehost.example.com
>
This example tells the BIND server to verify the prerequisite condition that
no resource records of any type exist for nickname.example.com. If any
records exist, the update request fails. If no records with that name exist, a
CNAME is added for it.
This prerequisite condition is an RFC restriction that has been relaxed to
allow for SIG, KEY, and NXT records to exist.
After entering data in interactive mode, press Return (or Enter) on a line
with no data to complete the input. Alternatively, you can issue the SEND
command. The nsupdate utility then processes all update entries in one
operation.
Configuring and Managing BIND Version 9 6–89
Configuring and Managing BIND Version 9
6.11 Solving Bind Server Problems
6.11 Solving Bind Server Problems
To solve BIND server problems, see the following sections:
•
Section 6.11.1, BIND Server Diagnostic Tools
•
Section 6.11.2, Using NSLOOKUP to Query a Name Server
•
Section 6.11.3, Solving Specific Name Server Problems
6.11.1 BIND Server Diagnostic Tools
The TCP/IP Services product provides the following utilities for diagnosing
problems with the BIND server:
•
The dig utility
•
The host utility
•
The nslookup utility
The following sections describe these utilities.
Note
The nslookup utility is no longer recommended. Use the dig utility
instead.
6–90 Configuring and Managing BIND Version 9
dig
dig
Gathers information from the Domain Name System servers.
Format
dig [@server] [-option] [name] [type] [class] [queryopt...]
Description
dig is a flexible tool for interrogating DNS name servers. It performs DNS
lookups and displays the answers that are returned from the name servers that
were queried. Most DNS administrators use dig to troubleshoot DNS problems
because of its flexibility, ease of use and clarity of output. Other lookup tools tend
to have less functionality than dig.
Although dig normally is used with command-line arguments, it also has a batch
mode of operation for reading lookup requests from a file. A brief summary of
its command-line arguments and options is printed when the -h option is given.
Unlike earlier versions of BIND, the BIND Version 9 implementation of dig
allows multiple lookups to be issued from the command line.
Unless it is told to query a specific name server, dig tries each of the servers
listed in your resolver configuration. When no command line arguments or
options are given, dig performs an NS query for "." (the root).
dig has two modes: simple interactive mode, for a single query, and batch mode,
which executes a query for each in a list of several query lines. All query options
are accessible from the command line.
To get online help for the dig utility, enter the -h option on the command line.
For example:
$ dig -h
Parameters
@server
Specifies the name or IP address of the name server to query. This can be either
an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited
notation. When the supplied server argument is a host name, dig resolves that
name before querying that name server. If no server argument is provided, dig
consults your resolver configuration and queries the name servers listed there.
The reply from the name server that responds is displayed.
name
Specifies the name of the resource record to look up.
type
Indicates the type of query required (ANY, A, MX, SIG, and so forth). If the type
parameter is not supplied, dig performs a lookup for an A record.
class
Specifies the DNS query class. The default is class IN (Internet).
Configuring and Managing BIND Version 9 6–91
dig
Options
-b address
Sets the source IP address of the query to address. This must be a valid address
on one of the host’s network interfaces.
-c class
Specifies the query class. class is any valid class, such as HS for hesiod records or
CH for CHAOSnet records. The default query class is IN (Internet).
-f filename
Makes dig operate in batch mode by reading a list of lookup requests to process
from the specified file. The file contains a number of queries, one per line. Each
entry in the file should be organized in the same way that dig queries are
presented using the command-line interface.
-k filename
Allows you to sign the DNS queries sent by dig and their responses using
transaction signatures (TSIG). Specify a TSIG key file for filename.
-p port
Allows you to specify a nonstandard port number. port is the port number that
dig uses to send its queries instead of the standard DNS port number 53. You
can use this option to test a name server that has been configured to listen for
queries on a nonstandard port number.
-t type
Sets the query type to type, which can be any valid query type supported in BIND
Version 9. The default query type is A, unless the -x option is supplied to indicate
a reverse lookup. A zone transfer can be requested by specifying a type of AXFR.
When an incremental zone transfer (IXFR) is required, type is set to ixfr=N. The
incremental zone transfer contains the changes made to the zone since the serial
number in the zone’s SOA record was N.
-x addr
Specifies reverse lookups (mapping addresses to names). addr is either an IPv4
address in dotted-decimal notation or a colon-delimited IPv6 address. This
option eliminates the need to provide the name, class, and type arguments. dig
automatically performs a lookup for a name like 11.12.13.10.in-addr.arpa
and sets the query type and class to PTR and IN, respectively. By default, IPv6
addresses are looked up using the IP6.ARPA domain and binary labels as defined
in RFC 2874. To use the older RFC 1886 method using the IP6.INT domain and
nibble labels, specify the -n (nibble) option.
-y name:key
Allows you to specify the TSIG key itself on the command line. name is the name
of the TSIG key and key is the actual key. The key is a base-64 encoded string,
typically generated by dnssec_keygen. When using TSIG authentication with
dig, the name server that is queried needs to know the key and algorithm that
is being used. In BIND, this is done by providing appropriate key and server
statements in TCPIP$BIND.CONF.
6–92 Configuring and Managing BIND Version 9
dig
Query Options
Each query option is identified by a keyword preceded by a plus sign (+). Some
keywords set or reset an option. These can be preceded by the string no to
negate the meaning of that keyword. Other keywords (like that which sets the
timeout interval) assign values to options. These types of keywords have the form
+keyword=value.
The query options are:
+[no]tcp
Specifies whether to use TCP when querying name servers. The default behavior
is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP
connection is used.
+[no]vc
Specifies whether to use TCP when querying name servers. This alternate syntax
to [no]tcp is provided for backward compatibility. (vc stands for virtual circuit.)
+[no]ignore
Ignores truncation in UDP responses instead of retrying with TCP. By default,
TCP retries are performed.
+domain=name
Sets the search list to contain the single domain name, as if specified in a domain
directive in your resolver configuration. Enables search list processing as if the
search option were specified.
+[no]search
Specifies whether to use the search list defined by the path directive in your
resolver configuration. By default, the search list is not used.
+[no]defname
This deprecated option is treated as a synonym for [no]search.
+[no]aaonly
This option does nothing. It is provided for compatibility with old versions of dig,
in which it set an unimplemented resolver flag.
+[no]adflag
Specifies whether to set the AD (authentic data) bit in the query. The AD bit
currently has a standard meaning only in responses, not in queries, but the
ability to set the bit in the query is provided for completeness.
+[no]cdflag
Specifies whether to set the CD (checking disabled) bit in the query. This requests
the server to not perform DNSSEC validation of responses.
+[no]recursive
Toggles the setting of the RD (recursion desired) bit in the query. This bit is
set by default, which means dig normally sends recursive queries. Recursion is
automatically disabled when the nssearch or trace query options are used.
+[no]nssearch
Attempts to find the authoritative name servers for the zone containing the name
being looked up. Displays the SOA record that each name server has for the zone.
Configuring and Managing BIND Version 9 6–93
dig
+[no]trace
Toggles tracing of the delegation path from the root name servers for the name
being looked up. Tracing is disabled by default. When tracing is enabled, dig
makes iterative queries to resolve the name being looked up, following referrals
from the root servers and showing the answer from each server that was used to
resolve the lookup.
+[no]cmd
Toggles the printing of the initial comment in the output identifying the version
of dig and the query options that have been applied. This comment is printed by
default.
+[no]short
Provides a terse answer. The default is to print the answer in verbose form.
+[no]identify
Specifies whether to show the IP address and port number that supplied the
answer when the +short option is enabled. If terse answers are requested, the
default is not to show the source address and port number of the server that
provided the answer.
+[no]comments
Toggles the display of comment lines in the output. The default is to print
comments.
+[no]stats
Toggles the printing of statistics, such as when the query was made, the size of
the reply, and so on. The default behavior is to print the query statistics.
+[no]qr
Specifies whether to print the query as it is sent. By default, the query is not
printed.
+[no]question
Specifies whether to print the question section of a query when an answer is
returned. The default is to print the question section as a comment.
+[no]answer
Specifies whether to display the answer section of a reply. The default is to
display the answer section.
+[no]authority
Specifies whether to display the authority section of a reply. The default is to
display the authority section.
+[no]additional
Specifies whether to display the additional section of a reply. The default is to
display the additional section.
+[no]all
Specifies whether to set or clear all display flags.
+time=T
Sets the timeout for a query to T seconds. The default timeout is 5 seconds. An
attempt to set T to less than 1 results in a query timeout of 1 second.
6–94 Configuring and Managing BIND Version 9
dig
+tries=A
Sets the number of times to retry UDP queries to the server to A instead of to the
default of 3. If A is less than or equal to zero, the number of retries is silently
rounded up to 1.
+ndots=D
Set the number of dots that have to appear in name to D for it to be considered
absolute. The default value is 1.
Names with fewer dots are interpreted as relative names and are searched
for in the domains listed in the search or domain directive in your resolver
configuration.
+bufsize=B
Set the UDP message buffer size advertised using EDNS0 to B bytes. The
maximum and minimum sizes of this buffer are 65535 and 0, respectively. Values
outside this range are rounded up or down appropriately.
+[no]multiline
Prints records like the SOA records in a verbose multiline format with humanreadable comments. The default is to print each record on a single line, to
facilitate machine parsing of the output.
+[no]fail
Do not try the next server if you receive a SERVFAIL. The default is to not try
the next server which is the reverse of normal stub resolver behaviour.
+[no]besteffort
Attempts to display the contents of messages which are malformed. The default
is to not display malformed answers.
+[no]dnssec
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the
the OPT record in the additional section of the query.
Multiple Queries
The BIND Version 9 implementation of dig supports the specification of multiple
queries on the command line (in addition to supporting the -f batch file option).
Each of those queries can be supplied with its own set of flags, options, and query
options.
Each query argument represent an individual query in the command-line syntax.
Each individual query consists of any of the standard options and flags, the name
to be looked up, an optional query type and class, and any query options that are
needed.
A global set of query options, which should be applied to all queries, can also
be supplied. These global query options must precede the first tuple of name,
class, type, options, flags, and query options supplied on the command line. Any
global query options (except for the +[no]cmd option) can be overridden by a
query-specific set of query options.
Configuring and Managing BIND Version 9 6–95
dig
Examples
The following example shows how to use dig from the command line to make
three lookups:
1. An ANY query for www.isc.org
2. A reverse lookup of 127.0.0.1
3. A query for the NS records of isc.org.
1.
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
; <<>> DiG 9.2.0 <<>> +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION:
;www.isc.org.
IN
ANY
;; ANSWER SECTION:
www.isc.org.
3421
IN
CNAME
isc.org.
;; AUTHORITY SECTION:
isc.org.
isc.org.
isc.org.
isc.org.
isc.org.
3421
3421
3421
3421
3421
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
gns1.nominum.com.
gns2.nominum.com.
ns-ext.vix.com.
ns-int.vix.com.
ns1.gnac.com.
;; ADDITIONAL SECTION:
ns1.gnac.com.
gns1.nominum.com.
gns2.nominum.com.
ns-ext.vix.com.
ns-int.vix.com.
17389
92
68661
2601
828
IN
IN
IN
IN
IN
A
A
A
A
A
209.182.195.77
198.133.199.1
198.133.199.2
204.152.184.64
204.152.184.65
;;
;;
;;
;;
Query time: 134 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Tue Nov 6 13:09:16 2001
MSG SIZE rcvd: 241
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16441
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.
IN
PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 86400
IN
PTR
localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.
86400
IN
NS
localhost.
;; ADDITIONAL SECTION:
localhost.
86400
IN
A
127.0.0.1
;;
;;
;;
;;
Query time: 224 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Tue Nov 6 13:09:16 2001
MSG SIZE rcvd: 93
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9922
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
6–96 Configuring and Managing BIND Version 9
dig
;; QUESTION SECTION:
;isc.org.
IN
NS
;; ANSWER SECTION:
isc.org.
isc.org.
isc.org.
isc.org.
isc.org.
3421
3421
3421
3421
3421
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
ns-ext.vix.com.
ns-int.vix.com.
ns1.gnac.com.
gns1.nominum.com.
gns2.nominum.com.
;; ADDITIONAL SECTION:
ns1.gnac.com.
gns1.nominum.com.
gns2.nominum.com.
ns-ext.vix.com.
ns-int.vix.com.
17389
92
68661
2601
828
IN
IN
IN
IN
IN
A
A
A
A
A
209.182.195.77
198.133.199.1
198.133.199.2
204.152.184.64
204.152.184.65
;;
;;
;;
;;
Query time: 198 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Tue Nov 6 13:09:17 2001
MSG SIZE rcvd: 223
A global query option of +qr is applied so that dig shows the initial query
it made for each lookup. The final query has a local query option of +noqr,
which means that dig will not print the initial query when it looks up the NS
records for isc.org.
The final portion of the output displays the following information:
•
Amount of time the query took
•
Server and port to which the query was sent, in the form server#port
•
Date and time of the query
•
Message size
Configuring and Managing BIND Version 9 6–97
host
host
The host utility allows you to look up Internet host names. By default, the host
utility converts between host names and Internet addresses, but its functionality
can be extended with the use of options.
Format
host [-a"C"dlrTvw] [-c class] [-n] ["-N" ndots] ["-R" number] [-t type] ["-W" wait] name [server]
Note
Use quotation marks to preserve the casing of uppercase options.
Description
The host utility is used to convert names to IP addresses and vice versa. When
no arguments or options are given, the host utility prints a short summary of its
command line arguments and options.
Parameters
name
Specifies the domain name that is to be looked up. It can also be a dotted-decimal
IPv4 address or a colon-delimited IPv6 address, in which cases the host performs
a reverse lookup for that address by default.
[server]
Specifies the name or IP address of the name server that the host utility should
query instead of the server or servers listed in your resolver configuration.
Options
-a
Equivalent to setting the -v option and asking the host utility to make a query of
type ANY.
"-C"
Displays the SOA records for zone name from all the listed authoritative name
servers for that zone. The list of name servers is defined by the NS records that
are found for the zone. The -C option must be enclosed in quotation marks. For
example:
$ host "-C" name
-c class
Makes a DNS query of class class. This can be used to look up hesiod or
CHAOSnet class resource records. The default class is IN (Internet).
-d
Specifies verbose output.
-l
Selects list mode. This makes the host utility perform a zone transfer for zone
name. The argument is provided for compatibility with older implemementations.
This option is equivalent to making a query of type AXFR.
6–98 Configuring and Managing BIND Version 9
host
-n
Specifies that reverse lookups of IPv6 addresses should use the IP6.INT domain
and nibble labels, as defined in RFC 1886. The default is to use IP6.ARPA and
binary labels, as defined in RFC 2874.
"-N" number
Sets the number of dots that have to be in the zone name for it to be considered
absolute. The default value is 1. Names with fewer dots are interpreted as
relative names and are searched for in the domains listed in the search path
defined in the resolver configuration.
"-R" number
Changes the number of UDP retries for a lookup. The value for number indicates
how many times the host utility repeats a query that does not get answered.
The default number of retries is 1. If number is negative or zero, the number of
retries defaults to 1.
-r
Makes nonrecursive queries. Setting this option clears the RD (recursion desired)
bit in the query that the host utility makes. This should mean that the name
server receiving the query does not attempt to resolve name. The -r option
enables host to mimic the behavior of a name server by making nonrecursive
queries and expecting to receive answers to those queries that are usually
referrals to other name servers.
"-T"
Uses a TCP connection when querying the name server. By default, the host
utility uses UDP when making queries.
TCP is automatically selected for queries that require it, such as zone transfer
(AXFR) requests.
-t type
Selects the query type. type can be any recognized query type, such as CNAME,
NS, SOA, SIG, KEY, or AXFR. When no query type is specified, the host utility
automatically selects an appropriate query type. By default, the host utility looks
for A records, but if the -C option is specified, queries are made for SOA records.
If name is a dotted-decimal IPv4 address or a colon-delimited IPv6 address, the
host utility queries for PTR records.
-v
Generates verbose output.
"-W" wait
Makes the host utility wait for the number of seconds specified by wait before
making the query. If wait is less than 1, the wait interval is set to 1 second.
-w
Waits forever for a reply. The time to wait for a response is set to the number of
seconds given by the hardware’s maximum value for an integer quantity.
Configuring and Managing BIND Version 9 6–99
Configuring and Managing BIND Version 9
host
6.11.2 Using NSLOOKUP to Query a Name Server
The nslookup utility is a debugging tool provided with BIND that allows anyone
to directly query a name server and retrieve information. Use NSLOOKUP to
determine whether your local name server is running correctly or to retrieve
information from remote servers.
nslookup makes direct queries to name servers around the world to obtain DNS
information, which includes the following:
•
Host names and addresses on the local domain
•
Host names and addresses on remote domains
•
Host names that serve as Mail Exchange (MX) records
•
Name servers for a specific zone
Note
The nslookup utility is deprecated. HP recommends that you use the dig
utility instead.
For online information about using the nslookup utility, enter the following
command:
$ HELP TCPIP_SERVICES NSLOOKUP
6.11.3 Solving Specific Name Server Problems
The following sections describe some problems commonly encountered with BIND
and how to solve them.
6.11.3.1 Server Not Responding
A missing client name in the BIND server’s database files results in lack of
service to that client. If records that point to the name servers (NS records) in a
domain are missing from your server’s database files, you might see the following
messages:
%TCPIP-W-BIND_NOSERVNAM, Server with address 199.85.8.8 is not responding
%TCPIP-E-BIND_NOSERVERS, Default servers are not available
%TCPIP-W-NORECORD, Information not found
-TCPIP-E-BIND_NOSERVERS, Default servers are not available
When the CONVERT/ULTRIX BIND /DOMAIN command creates the .DB files
from the hosts database, it cannot detect the existence or the names of name
servers in a domain. Therefore, it does not add NS records for the name servers
to the .DB files.
To solve the problem, follow these steps:
1. Stop the BIND server.
2. Manually add NS records for the missing names.
3. Update the start-of-authority (SOA) records by incrementing the serial
number.
4. Restart the BIND server.
6–100 Configuring and Managing BIND Version 9
7
Using DNS to Balance Work Load
This chapter describes how to use DNS to balance the network traffic on a
multihomed host or on network servers when you have multiple systems
providing the same network service.
TCP/IP Services provides two methods for balancing work load using DNS:
•
Load sharing using the default DNS method of round-robin scheduling.
•
Load balancing using the TCP/IP Services load broker. Load broker is a
configurable, calculated, load-balancing mechanism for distributing the work
load among DNS cluster members.
This chapter discusses how to use DNS to balance server work load and includes
the following topics:
•
DNS clusters (Section 7.1)
•
Round-robin scheduling (Section 7.2)
•
Load broker concepts (Section 7.3)
•
Load broker startup and shutdown (Section 7.4)
•
Configuring the load broker (Section 7.5)
•
Metric server startup and shutdown (Section 7.6)
•
Solving load broker problems (Section 7.7)
7.1 DNS Clusters
TCP/IP Services defines the term DNS cluster to refer to several A resource
records for a single host name. This could be the A resource records for a
multihomed host or the A resource records for one or more servers which are to
share a work load.
7.2 Round-Robin Scheduling
Round-robin (or ‘‘cyclic’’) scheduling is the default load-sharing method used by a
DNS server. If multiple resource records satisfy a query, the BIND server returns
them each time in a round-robin order. The round-robin scheme is a simple
rotation where client requests are passed from one cluster member to the next.
The round-robin scheme is also useful for MX records to share mail loads among
multiple equivalent gateways of the same MX preference.
Unlike the traditional load-balancing method, round-robin does not take into
account the current work load on the DNS cluster members and does not know
whether these hosts are up or down.
The following example demonstrates how round-robin load sharing works.
Using DNS to Balance Work Load 7–1
Using DNS to Balance Work Load
7.2 Round-Robin Scheduling
In the example, the DNS cluster alias is defined as robin. When the DNS server
receives queries for robin, it shuffles the A resource records in a round-robin
manner.
;
; TCP/IP DNS cluster load sharing - round robin method
;
DNS cluster alias: "robin"
robin
IN
A
9.20.208.47
IN
A
9.20.208.30
IN
A
9.20.208.72
;
birdy
IN
A
9.20.208.47
seagull
IN
A
9.20.208.30
owl
IN
A
9.20.208.72
;
A user enters the TELNET command, specifying the DNS cluster alias ROBIN.
The first query to the DNS name server results in the following TELNET session:
$ TELNET ROBIN
%TELNET-I-TRYING, Trying ... 9.20.208.47
%TELNET-I-SESSION, Session 01, host birdy, port 23
-TELNET-I-ESCAPE, Escape character is ^]
The TELNET client connects to host birdy at IP address 9.20.208.47, the first
resource record in the list.
The second query to the name server results in the following TELNET session:
$ TELNET ROBIN
%TELNET-I-TRYING, Trying ... 9.20.208.30
%TELNET-I-SESSION, Session 01, host seagull, port 23
-TELNET-I-ESCAPE, Escape character is ^]
The TELNET client connects to host seagull at IP address 9.20.208.30, the next
resource record in the list.
The third query to the name server results in the following TELNET session:
$ TELNET ROBIN
%TELNET-I-TRYING, Trying ... 9.20.208.72
%TELNET-I-SESSION, Session 01, host owl, port 23
-TELNET-I-ESCAPE, Escape character is ^]
TELNET connects to host owl at IP address 9.20.208.72, the next resource record
in the list.
The fourth query to the name server results in the following TELNET session:
$ TELNET ROBIN
%TELNET-I-TRYING, Trying ... 9.20.208.47
%TELNET-I-SESSION, Session 01, host birdy, port 23
-TELNET-I-ESCAPE, Escape character is ^]
TELNET again connects to host birdy at IP address 9.20.208.47. This is the start
of the cycle repeating. The cycle repeats for the subsequent queries.
The SHOW HOST display for this DNS name server shows the shuffling effect
in greater detail. Notice that the output displays the cluster alias name for each
host involved in round-robin scheduling.
7–2 Using DNS to Balance Work Load
Using DNS to Balance Work Load
7.2 Round-Robin Scheduling
TCPIP> SHOW HOST ROBIN
BIND database
Server:
9.20.208.72 owl.ucx.ern.sea.com
Host address
Host name
9.20.208.47 robin.ucx.ern.sea.com
9.20.208.30 robin.ucx.ern.sea.com
9.20.208.72 robin.ucx.ern.sea.com
TCPIP> SHOW HOST ROBIN
BIND database
Server:
9.20.208.72 owl.ucx.ern.sea.com
Host address
Host name
9.20.208.30 robin.ucx.ern.sea.com
9.20.208.72 robin.ucx.ern.sea.com
9.20.208.47 robin.ucx.ern.sea.com
TCPIP> SHOW HOST ROBIN
BIND database
Server:
9.20.208.72 owl.ucx.ern.sea.com
Host address
Host name
9.20.208.72 robin.ucx.ern.sea.com
9.20.208.47 robin.ucx.ern.sea.com
9.20.208.30 robin.ucx.ern.sea.com
TCPIP> SHOW HOST ROBIN
BIND database
Server:
9.20.208.72 owl.ucx.ern.sea.com
Host address
Host name
9.20.208.47 robin.ucx.ern.sea.com
9.20.208.30 robin.ucx.ern.sea.com
9.20.208.72 robin.ucx.ern.sea.com
BIND Version 9 uses random cyclic scheduling, in which the server randomly
chooses a starting point in the RRset and returns the records in order starting at
that point, wrapping around the end of the RRset if necessary.
7.2.1 Disabling Round-Robin Scheduling
BIND Version 9 does not allow you to disable round-robin scheduling.
7.3 Load Broker Concepts
TCP/IP Services provides a configurable, calculated, load-balancing mechanism
called the load broker for distributing the load across systems in a DNS cluster.
Unlike round-robin scheduling (the default method used by most DNS name
servers), the load broker takes into account the load on all DNS cluster
participants. The load broker polls DNS cluster members and updates the
DNS namespace accordingly.
Using DNS to Balance Work Load 7–3
Using DNS to Balance Work Load
7.3 Load Broker Concepts
7.3.1 How the Load Broker Works
When the load broker starts, it reads its configuration file and starts polling
DNS cluster members. The load broker exchanges messages with DNS cluster
members that run the metric server. The metric server (Section 7.3.3) calculates
the current rating and reports it when polled by the load broker. Periodically,
the load broker sorts the list of addresses based on metric rating reports, drops
the systems that are not responding after being polled three times, and takes
a subset of the list and compares it to the name server information. To do the
comparison, the load broker sends a host lookup request to the specified name
server. If the lists are the same, the load broker does not make any change. If
the lists are different, the load broker updates the name server data by sending a
dynamic update request to the specified name server.
The name server uses round-robin scheduling to further balance the load across
the members of a DNS cluster. So every consecutive request for translating the
DNS cluster name results in a list being returned, rotated by one.
The dns-ttl value stored in the load broker configuration file governs how long
the record is to be cached by other name servers. If some intermediate name
server caches the "A" resource records for a given DNS cluster name, it caches it
for the period of time defined by the dns-ttl value. The default dns-ttl value is
45 seconds. If less time is required, you can set dns-ttl to a smaller value. To
suppress any caching, you can set the dns-ttl to 0.
The dns-refresh time specifies how often the DNS information for a given DNS
cluster is refreshed. The default is 30 seconds. If you want to quickly pick up
changes in the system load (reported by metric servers), set dns-refresh to a
smaller number.
If the load broker has not received a response from a metric server after three
polling intervals, the load broker marks the address for removal from the DNS
alias. This removal will occur at the next dns-refresh interval.
For earliest possible detection of this failure, the polling-interval should be set
to a value that is less than one-third of the value specified as the dns-refresh
period.
polling-interval < (dns-refresh) / 3
The masters list specifies the authoritative name servers to which queries will
be sent. Only one name server at a time is sent a query. A query is sent to the
first name server specified. If that name server does not respond to the query,
then the query is sent to the next name server specified. This process continues
until either a name server responds or the list is exhausted. Note that the name
servers specified in the masters statement are not necessarily the servers that
will be sent dynamic updates.
Queries are sent for the following reasons:
•
A query for A resource records is sent to the name server to obtain the list of
addresses associated with the load broker cluster name that is to be updated.
The load broker can then perform its comparison to determine whether any
updates need to be made.
•
A query for the SOA resource record is sent to the name server so that the
load broker can determine the primary master name server for the zone. The
primary master name server is then sorted to the top of the name server list
that will be sent dynamic update requests.
7–4 Using DNS to Balance Work Load
Using DNS to Balance Work Load
7.3 Load Broker Concepts
•
A query for NS resource records is sent to the name server to retrieve the list
of name servers that will receive dynamic updates. Dynamic updates are sent
to only one server at a time. A dynamic update is sent to the first server on
the list. If that name server does not respond, or rejects the dynamic update,
then the dynamic update is sent to the next server on the list. This process
continues until either the dynamic update is accepted by the name server or
the name server list is exhausted.
The name server must be set up to allow dynamic updates from the system that
runs the load broker. For information about configuring dynamic updates, see
Section 6.5.7.
TCP/IP Services supports dynamic updating of only one master server in a DNS
cluster environment.
7.3.2 Managing the Load Broker in an OpenVMS Cluster
By default, you can run the load broker on multiple systems in an OpenVMS
Cluster. This is accomplished through a locking mechanism. The first load broker
process to start in the cluster obtains the lock. Any load broker processes started
afterward go into a standby state and wait for the lock to be released. If the
system running the first load broker process goes down, the load broker process
releases the lock, allowing the next available standby load broker process to
obtain the lock. This system then runs the active load broker process; additional
servers remain on standby.
To disable the clusterwide load broker locking mechanism, enter the following
command:
$ DEFINE /SYSTEM TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS 1
7.3.3 How the Metric Server Calculates Load
The metric server calculates the current load on a DNS cluster host by using the
following equation:
rating = availablity + workload - penalty
In the equation, the variables are calculated by:
•
Availability
Availability is calculated using the IJOBLIM system parameters and the SDA
global reference variable IJOBCNT in the following equation:
availablity = (20*(IJOBLIM-IJOBCNT))/IJOBLIM
•
Workload
One consideration in the work load calculation is the system manager’s
estimate of the host’s relative CPU power specified by the system logical
TCPIP$METRIC_CPU_RATING.
To set a CPU power value, use the DCL command DEFINE to define the
system logical name TCPIP$METRIC_CPU_RATING with a value. The CPU
rating value can range from 1 (the lowest CPU power) to 100 (the highest
CPU power). If a value is specified, the value is used instead of the term
(min(235,IJOBLIM) in the following equation.
workload = (min(235,IJOBLIM)*100)/(100+load_average)
Using DNS to Balance Work Load 7–5
Using DNS to Balance Work Load
7.3 Load Broker Concepts
When you set the logical value to 0, or if you do not define TCPIP$METRIC_
CPU_RATING, the metric server uses the value of the system parameter
IJOBLIM to calculate work load.
load_average is an average of the current CPU load taken every second. It is
calculated by using 97.9% of the previous CPU load and 2.1% of the current
CPU load value.
•
Penalty
The metric server uses the FREEGOAL system parameter and the SDA
global reference variable FREECNT to calculate an available memory penalty.
penalty = 40*((FREEGOAL+2048-FREECNT)/(FREEGOAL+2048))
The value of penalty is subtracted from the rating only if the value is
positive. If the value of FREECNT is high enough, the value of penalty is not
applied.
7.4 Load Broker Startup and Shutdown
The load broker can be shut down and started independently. This is useful when
you change parameters or logical names that require the service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$LBROKER_STARTUP.COM allows you to start up
the load broker service.
•
SYS$STARTUP:TCPIP$LBROKER_SHUTDOWN.COM allows you to shut
down the load broker service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$LBROKER_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
load broker is started.
•
SYS$STARTUP:TCPIP$LBROKER_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
load broker is shut down.
7.5 Configuring the Load Broker
To configure the load broker, edit the file TCPIP$LBROKER_CONF.TEMPLATE
located in SYS$SYSDEVICE:[TCPIP$LD_BKR], then rename the file to
TCPIP$LBROKER.CONF.
After making changes to TCPIP$LBROKER.CONF, restart the load broker by
running TCPIP$CONFIG, or by using the shutdown and startup procedures.
The load broker configuration file can contain one or more DNS cluster
statements in the following format:
cluster "clustername.domain.com"
{
7–6 Using DNS to Balance Work Load
Using DNS to Balance Work Load
7.5 Configuring the Load Broker
[dns-ttl nn;]
[dns-refresh nn;]
masters {ip_address};
[polling-interval nn;]
[max-members nn;]
members {ip_address};
failover {ip_address};
};
Table 7–1 describes the valid cluster statements.
Table 7–1 Valid Cluster Statements
Statement
Description
members
failover
Specifies the IP address for each DNS cluster member.
masters
dns-ttl
Specifies the IP addresses of authoritative name servers.
Specifies the address of the host to use if all other members
are down.
Specifies the time to live for a given record. The value you
provide governs how long the record is to be cached by other
name servers. If some intermediate name servers cache A
resource records for a given DNS cluster name, they cache it
for the period specified by dns-ttl for the resource record.
The default value is 45 seconds.
dns-refresh
Specifies how often the DNS information for a given DNS
cluster name is refreshed. The default is 30 seconds. The
value of this field should be set relative to to the value of
polling-interval. The dns-refresh value should be
smaller than the polling-interval value. It is unproductive
to refresh more often then you poll.
polling-interval
Specifies the length of time between polls to cluster members.
The default is 30 seconds.
max-members
Specifies the maximum number of IP addresses to be returned
to the name server in each dynamic update. For effective
load balancing, this number should be between one-third and
one-half the number of participating DNS cluster members.
The following sample is a configuration of the load broker that load balances the
DNS cluster named WWW.TCPIP.ERN.SEA.COM.
cluster "www.tcpip.ern.sea.com"
{
dns-ttl
dns-refresh
masters {
9.20.208.53;
};
polling-interval
max-members
members {
9.20.208.100;
9.20.208.53;
9.20.208.54;
9.20.208.80;
9.20.208.129;
9.20.208.130;
};
failover 9.20.208.200;
};
45;
30;
9;
3;
Using DNS to Balance Work Load 7–7
Using DNS to Balance Work Load
7.5 Configuring the Load Broker
To retain your UCX Version 4.x DNS cluster load-balancing configuration:
1. Enter the CONVERT/CONFIGURATION BIND/CLUSTER command, as
shown in the following example:
TCPIP> CONVERT/CONFIGURATION BIND _TCPIP> /CLUSTER=SYS$SYSDEVICE:[TCPIP$LD_BKR]TCPIP$LBROKER.CONF
The output from this command is a TCPIP$LBROKER.CONF file containing
your basic configuration.
2. Edit the TCPIP$LBROKER.CONF file to produce a complete configuration
file.
7.5.1 Enabling the Load Broker
To enable DNS cluster load balancing, complete the following tasks:
1. Ensure that all hosts in the DNS cluster are running TCP/IP Services.
2. Configure the load broker (see Section 7.5).
3. Configure the primary master name server that is authoritative for the
zone containing the DNS cluster resource record to allow dynamic updates
from the host on which the load broker is running. For information about
configuring dynamic updates, see Section 6.5.7.
You can also configure the master name server with the
allow-update-forwarding option, so that slave servers that are sent dynamic
updates will forward them to the master name server. For more information,
see Table 6–20.
4. Ensure TCP/IP connectivity between the DNS cluster members and the load
broker.
5. Enable the metric server on each member of the DNS cluster:
a. Run the following command procedure:
$ @SYS$MANAGER:TCPIP$CONFIG
b. On the TCPIP$CONFIG Server Components Configuration menu, select
option 8:
8 -- METRIC.
c. On the Metric configuration display, select option 2:
2 -- Start service on this node.
Review the following guidelines:
•
DNS cluster hosts and clients are not required to be on the same bridged
LAN.
•
The number of DNS cluster member hosts is limited to 32.
•
A BIND name server can also be a DNS cluster member host.
•
The authoritative name server can run any BIND name server that supports
BIND 8.1.1 or later or that supports dynamic updates.
7–8 Using DNS to Balance Work Load
Using DNS to Balance Work Load
7.5 Configuring the Load Broker
7.5.2 Load Broker Logical Names
Table 7–2 describes the load broker’s logical names. Define these logical names
with the /SYSTEM qualifier, and restart the load broker server to make the
changes take effect.
Table 7–2 Load Broker Logical Names
Logical Name
Description
TCPIP$LBROKER_LOG_LEVEL value
Turns on diagnostics and writes them to
the TCPIP$LBROKER_RUN.LOG located in
SYS$SYSDEVICE:[TCPIP$LD_BKR]. Valid
values are 1 and 2 (2 provides more detailed
diagnostics).
TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS
Turns off the clusterwide load-broker
locking mechanism, allowing separate load
broker processes to run on each node in the
OpenVMS Cluster.
To disable the clusterwide load-broker locking
mechanism, enter the following command:
$ DEFINE /SYSTEM TCPIP$LBROKER_ALLOW_CONCURRENT_SERVERS 1
When you define this logical and then start
the load broker, multiple load brokers in an
OpenVMS Cluster will be active. For more
information, refer to Section 7.3.2.
7.5.3 Metric Server Logical Names
Table 7–3 describes the metric server’s logical names. Define these logical
names with the /SYSTEM qualifier. The metric server detects the change and
dynamically updates the current enviroment.
Table 7–3 Metric Server Logical Names
Logical Name
Description
TCPIP$METRIC_CPU_RATING value
Sets a bias value that represents your
estimate of the relative CPU power.
Valid values range from 1 (lowest
CPU power) to 100 (highest CPU
power). Use a value of 0 (zero) to
specify the default (The value of the
system parameter IJOBLIM is used).
TCPIP$METRIC_COMPUTE_INTERVAL value
Specifies how often the metric server
computes the rating. Valid value (in
seconds) is a number from 1 to 300.
The default is 10 seconds.
(continued on next page)
Using DNS to Balance Work Load 7–9
Using DNS to Balance Work Load
7.5 Configuring the Load Broker
Table 7–3 (Cont.) Metric Server Logical Names
Logical Name
Description
TCPIP$METRIC_LOG_LEVEL value
Turns on diagnostics logged to the file
TCPIP$METRIC_RUN.LOG located
in SYS$SPECIFIC:[TCPIP$METRIC].
Valid values are 1 or 2 (2 provides
more detailed diagnostics).
7.6 Metric Server Startup and Shutdown
The metric server starts up automatically at system startup time if the service
was previously enabled and can be shut down and started independently.
The following files are provided:
•
SYS$STARTUP:TCPIP$METRIC_STARTUP.COM allows you to start up the
metric service.
•
SYS$STARTUP:TCPIP$METRIC_SHUTDOWN.COM allows you to shut down
the metric service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$METRIC_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
metric service is started.
•
SYS$STARTUP:TCPIP$METRIC_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
metric service is shut down.
7.7 Solving Load Broker Problems
TCP/IP Services provides the following tools to assist in solving load broker
problems:
•
The metricview utility, to display metric information regarding DNS cluster
members.
•
Diagnostic log files.
7.7.1 Metricview Utility
The metricview utility is used to read the metric ratings. It displays the metric
rating of the member hosts in the TCP/IP DNS cluster.
To run the metricview utility, enter the following commands:
$ @SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM
$ metricview
Host
---10.10.2.11
rufus.lkg.dec.com
10.10.2.255
peach.lkg.dec.com
7–10 Using DNS to Balance Work Load
Rating
-----47
51
Using DNS to Balance Work Load
7.7 Solving Load Broker Problems
7.7.2 Viewing Diagnostic Messages
If you define the logical name TCPIP$METRIC_LOG_LEVEL, the metric server
writes diagnostic messages to the TCPIP$METRIC_RUN.LOG file. If you
experience problems with the metric server, define TCPIP$METRIC_LOG_LEVEL
and, after a period of operation, review the messages in the TCPIP$METRIC_
RUN.LOG file for an indication of what the problem could be. See Section 7.5.3
for a description of the logical name.
Using DNS to Balance Work Load 7–11
Part 3
Configuring Services
Part 3 describes how to set up and manage the Dynamic Host Configuration
Protocol (DHCP), the Bootstrap Protocol (BOOTP), the Trivial File Transport
Protocol (TFTP), the Portmapper service, the Network Time Protocol (NTP), and
the Simple Network Management Protocol (SNMP). The chapters in this part
include the following:
•
Chapter 8, Configuring and Managing the DHCP Server, describes how
to configure the DHCP server so you can centralize the configuration and
maintenance of the IP address space.
•
Chapter 9, Configuring and Managing the DHCP Client, describes how to set
up the system as a DHCP client.
•
Chapter 10, Configuring and Managing BOOTP, describes how to configure
the BOOTP server so your host can answer bootstrap requests from diskless
workstations and other network devices.
•
Chapter 11, Configuring and Managing TFTP, describes how to configure the
TFTP server to handle file transfers from diskless clients and remote systems.
•
Chapter 12, Configuring and Managing the Portmapper, 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 13, Configuring and Managing NTP, describes how to configure and
manage the NTP (Network Time Protocol), allowing your host to synchronize
its time with that of other internet hosts also running NTP.
•
Chapter 14, Configuring and Managing SNMP, describes how to configure
your host so it can answer SNMP (Simple Network Management Protocol)
requests from remote SNMP management stations.
8
Configuring and Managing the DHCP Server
Dynamic Host Configuration Protocol (DHCP), a superset of the Bootstrap
Protocol (BOOTP), provides a centralized approach to the configuration and
maintenance of IP address space. It allows the system manager to configure
various clients on a network from a single location.
DHCP allocates temporary or permanent IP addresses from an address pool to
client hosts on the network. DHCP can also configure client parameters such as
default gateway parameters, domain name server parameters, and subnet masks
for each host running a DHCP client.
This chapter reviews key DHCP and BOOTP concepts and also describes:
•
DHCP server components (Section 8.2)
•
DHCP server startup and shutdown(Section 8.3)
•
Configuring the DHCP server (Section 8.4)
•
Using the DHCP GUI to configure DHCP (Section 8.5)
•
Configuring DHCP/BOOTP IP addressing (Section 8.6)
•
Configuring DHCP manually (Section 8.7)
•
Supporting utilities (Section 8.8)
•
Solving DHCP server problems (Section 8.9)
8.1 Key Concepts
With DHCP, system managers can centralize TCP/IP network configurations and
management tasks involved with network connections. DHCP makes network
administration easier by allowing:
•
Consistent application of network parameters, such as subnet masks and
default routers, to all hosts on a network
•
Support for both DHCP and BOOTP clients
•
Static (permanent) mapping of hardware addresses to IP addresses
•
Dynamic (temporary) mapping of hardware addresses to IP addresses, where
the client leases the IP address for a defined length of time
In addition, the TCP/IP Services implementation of DHCP includes support for
DHCP server failover in a OpenVMS Cluster environment.
The DHCP protocol is a superset of BOOTP. In addition to the BOOTP
functionality, DHCP offers robust configuration services, including IP addresses,
subnet masks, and default gateways.
Configuring and Managing the DHCP Server 8–1
Configuring and Managing the DHCP Server
8.1 Key Concepts
Based on the BOOTP functionality, DHCP is built on the client/server model:
•
The DHCP server is a host that provides initialization parameters.
•
The DHCP client is a host that requests initialization parameters from a
DHCP server. A router cannot be a DHCP client.
8.1.1 How DHCP Operates
DHCP consists of two components:
•
A mechanism for allocating network addresses to clients
•
A set of rules for delivering client-specific configuration parameters from a
DHCP server to a client
DHCP operates as follows:
•
When a DHCP client boots, it broadcasts a DHCP request, asking that any
DHCP server on the network provide it with an IP address and configuration
parameters.
•
A DHCP server on the network authorized to configure this client sends the
client a reply that offers an IP address.
•
When the client receives the offer, it can accept it or wait for other offers from
other servers on the network.
•
Once the client accepts an offer, it sends an acceptance message to the server.
•
When the server receives the acceptance message, it sends an
acknowledgment with the offered IP address and any other configuration
parameters that the client requested. (The server only responds to specific
client requests; it does not impose any parameters on the client.)
•
If the dynamic address allocation method is used, the IP address offered to
the client has a specific lease time that determines how long the IP address is
valid.
During the lifetime of the lease, the client repeatedly asks the server to renew. If
the client chooses not to renew, the lease expires.
Once the lease expires, the IP address can be recycled and given to another client.
When the client reboots, it can be given the old address if available or assigned a
new address.
For more information about how DHCP operates, see RFC 2131 and RFC 1534.
8.1.2 How DHCP Allocates IP Addresses
With TCP/IP Services, DHCP uses the dynamic and static IP address-mapping
methods outlined in Table 8–1 to service DHCP and BOOTP-only client
requests.
8–2 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.1 Key Concepts
Table 8–1 DHCP IP Address Allocation Methods
Method
Dynamic
Applicable
Client
DHCP and
BOOTP
Description
The DHCP server assigns an IP address from an address pool
to a client for a specified amount of time (or until the client
explicitly relinquishes the address). Addresses no longer
needed by clients can be reused.
Use dynamic allocation when:
•
Clients plan to be connected to the network only
temporarily.
•
You have a limited pool of IP addresses that must be
shared among clients that do not need permanent IP
addresses.
•
IP addresses are scarce, and you need to reclaim retired
addresses so you can assign them the new clients being
permanently connected to the network.
For BOOTP clients, DHCP assigns dynamic IP addresses
from the address pool and stores the addresses in the lease
database by assigning each lease a time of infinity.
Static
DHCP and
BOOTP
The system manager manually assigns (in the DHCPCAP.
file) an IP address to a client and uses DHCP to pass the
assigned address to the client.
Use static allocation in an error-prone environment where it
is desirable to manage IP address assignment outside of the
DHCP functionality.
Finite
BOOTP-only
The DHCP server assigns an IP address from the pool to
the BOOTP client and defines a lease time based on certain
parameters you define in the SERVER.PCY file. When the
lease expires, the DHCP server pings the IP address. If the
server receives a reply, it extends the lease and does not offer
the address to a new client. If not, the address is free and can
be assigned to a new client.
Section 8.5 explains how to configure the different types of addressing for clients
on your network.
The typical network uses a combination of static and dynamic DHCP addressing.
As the local system manager or network administrator, you can apply any of the
IP addressing methods as appropriate for your specific policies and environment.
8.1.3 Relationship Between DHCP and BOOTP
From the client’s perspective, DHCP is an extension of the BOOTP functionality.
DHCP allows existing BOOTP clients to operate with DHCP servers without
having to change the client’s initialization software.
Based on the format of BOOTP messages, the DHCP message format does the
following:
•
Captures the BOOTP relay agents and eliminates the need to have a DHCP
server on each physical network segment.
•
Allows existing BOOTP clients to operate with DHCP servers.
Configuring and Managing the DHCP Server 8–3
Configuring and Managing the DHCP Server
8.1 Key Concepts
Messages that include a DHCP message-type option are assumed to have
been sent by a DHCP client. Messages without the DHCP message-type
option are assumed to have been sent by a BOOTP client.
However, DHCP improves the BOOTP-only functionality in the following ways:
•
DHCP allows the serial reassignment of network addresses to different clients
by assigning a network address for a finite lease period.
•
DHCP allows clients to acquire all of the IP configuration parameters they
need to operate.
8.1.4 Client ID
With BOOTP, a client is identified by its unique media access control (MAC)
address that is associated with the network adapter card.
DHCP uses a client identifier (ID) to uniquely identify the client and associate it
with a lease: The client creates the client ID from one of the following types of
addresses:
•
The MAC address.
•
A variation of the MAC address. For example, Windows 95 and Windows NT
clients create the client ID by prepending the hardware type to the hardware
address.
If the client does not include a client ID in the request, the server uses the client’s
MAC address.
8.2 DHCP Server Components
This section describes the software and system elements that comprise the DHCP
server component, including:
•
Executable files
•
Configuration files
•
Command files
•
Logical Names
•
Log files
8.2.1 Executable Files
Ten programs comprise the DHCP server component. Table 8–2 describes the
programs.
8–4 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Table 8–2 DHCP Executable Files
Program Name
Description
BPASCIITODBMOD.EXE
Used in rollover of old-style UCX BOOTP entries to
DHCP.
BPISAMTOASCII.EXE
Used in rollover of old-style UCX BOOTP entries to
DHCP.
DBDUMP.EXE
Dumps lease database in single line ASCII format.
See Section 8.8.1.
DBMODIFY.EXE
Modifies lease database. See Section 8.8.2.
DBREGISTER.EXE
Registers known MAC addresses. See Section 8.8.3.
DBSHOW.EXE
Displays specified binary database. See Section 8.8.1.
GUI.EXE
DHCP GUI. Used to manage DHCP server.
SERVER.EXE
DHCP server.
SHOWDBS.EXE
Displays lease database in easy to read format. See
Section 8.8.1.
SIGNAL.EXE
Implements UNIX style kill to allow sending signals
to DHCP server. See Section 8.4.3.
8.2.2 Configuration Files
DHCP uses the configuration files described in Table 8–3 to control the behavior
of the DHCP server and its service to DHCP clients.
Table 8–3 DHCP Configuration Files
File Name
Description
SERVER.PCY Describes the behavior of the server. For example, the policy file tells you
whether BOOTP clients should be supported, the ping timeout value, and
so on.
You may need to make modifications to this file to change the default
settings. Some of the defaults include support for BOOTP clients and
assigning names by IP addresses.
DHCPCAP.
Defines the client configuration parameters.
This file is similar to the standard BOOTPTAB file used by most BOOTP
servers. Each entry in the file can describe a single host, all the hosts
within a subnet, or a group of hosts.
NETS.
Defines the pool of IP addresses available to the DHCP server to assign to
clients. Used for dynamic address assignments.
NETMASKS.
Defines network masks if the network is subnetted. If you use subnetting
on your network, you must enter the subnet mask into the NETMASKS.
file for your network to operate correctly. This is an optional file. If your
network uses standard class A, B, or C network addressing, you do not
need to enter a mask into this file.
NAMEPOOL.
Defines the names available for assignment to DHCP clients. The server
uses the names only as a last resort (for example, when the client did
not suggest a name and there is no name associated with the IP address
offered to the client).
.DDNSKEYS
Defines the domains that are to be sent DNS/BIND dynamic updates. The
name of this file consists only of a file type of DDNSKEYS.
Configuring and Managing the DHCP Server 8–5
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
The DHCP configuration files (except for log files) are located in
SYS$SYSDEVICE:[TCPIP$DHCP] or in the directory pointed to by the
logical name TCPIP$DHCP_CONFIG. Log files are always located in the
SYS$SYSDEVICE:[TCPIP$DHCP] directory.
Template copies of the DHCP configuration files are located in text library
file SYS$LIBRARY:TCPIP$TEMPLATES.TLB. The template copies provide
instructions on how to edit the text files manually.
8.2.2.1 Server Policy
The SERVER.PCY file configures the behavior of the server. This policy file
describes various aspects of the server; for example, what sort of name service to
use, whether BOOTP should be supported, and the ping timeout value.
Use new lines to separate entries in the SERVER.PCY file from one another.
The server ignores blank lines and comments (lines beginning with the pound
(#) symbol). Each new policy option must begin and end on a separate line. A
keyword introduces a policy option. A policy option can be Boolean or can take a
value separated from the keyword by a space (but not by a new line).
If the SERVER.PCY file contains more than one specification for an option, only
the value associated with the last specification takes effect; the server disregards
earlier specifications.
Example 8–1 shows the contents of the SERVER.PCY file.
Example 8–1 Sample SERVER.PCY File
#
#
#
#
#
#
#
#
#
#
#
#
File name:
Product:
Version:
SERVER.PCY
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
DESCRIPTION:
This is a template server.pcy file. A particular site may need to make
modifications to this, especially to the name service and name allocation
policies in force
# Default time-to-live for an address lease if not specified on a
# per host, per subnet or per class basis.
default_ttl 86400
# Time to live on provisional list
provisional_ttl 60
#
#
#
#
#
Size of the internal array specifying the number of address
blocks held on the free list. This number should not be too
high, or the server will "forget" about all previous allocations
of expired leases very quickly. It should not be too low or
performance will suffer.
free_list_size 8
# Define type of name service. The name service is one of
# { dns, local, nis, nis+}.
# local means use text files on the local system (i.e. /etc/hosts).
(continued on next page)
8–6 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–1 (Cont.) Sample SERVER.PCY File
# On OpenVMS leave this option as "dns".
name_service dns
#
#
#
#
#
#
#
#
#
#
Specify whether the name service is dynamically updateable.
NIS and NIS+ are dynamically updateable, but the system
administrator may choose to disable this capability. In
both cases the server must be in the same domain as the
name server, and the JOIN server’s key must be in the
publickey database. NIS also requires the creation of
a pseudo map, "join", and the installation of the file
"updaters" in /var/yp on the name server. See manual
for further details. This option can be enabled for DNS.
The default is not to permit dynamic updating.
#name_service_updateable
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Name policy
The name may be choosen according to three possible policies:
assign_name_by_hwaddr:
A particular client (identified # by its hardware address)
always has the same name wherever possible. This option
may only be choosen if the name service is updateable.
assign_name_by_ipaddr:
The client gets a name from the IP address which was
assigned to it, as found in the name service. This
option is incompatible with assign_name_by_hwaddr.
accept_client_name:
This toggle is valid only when the policy is
assign_name_by_hwaddr. When "on" the server will use
the name suggested by the client and bind it to the
IP address delivered by the DHCP protocol. This is
true even if the client in question already has a name
in the server’s DB which is not the name suggested.
The old name continues to be "owned" by the client
and may have a valid IP address bound to it.
When this toggle is "off" the server will return to
client a pre-existing name bound to the client identifier
or hardware address, regardless of the name the client
suggests to the server.
If no name can be found by the application of one or more of
these policies, the server will generate a name for the domain
by using the name prefix in the "namepool" database.
assign_name_by_ipaddr
#
# Note: The following two settings are most appropriate when you are using
# dynamic DNS updates. To set this up on the DHCP server side uncomment these
# lines and delete the line above with "assign_name_by_ipaddr".
#assign_name_by_hwaddr
#accept_client_name
#
#
#
#
#
When the naming policy is assign_name_by_hwaddr the server will
not allow a client to use a name which is "owned" by some other
client. I.e. A name that is already bound to a different Client
identifier or MAC address. When this toggle is on, this prohibition
is lifted and the name will be re-assigned
#ignore_name_owner
(continued on next page)
Configuring and Managing the DHCP Server 8–7
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–1 (Cont.) Sample SERVER.PCY File
# Bootp.
# Remove this line if the server is not to support old-style Bootp
support_bootp
#This boolean is only valid if Bootp clients are supported
#(support_bootp option is enabled). When present it permits
#the server to permanently assign an IP address from its
#free pool to a BOOTP client in the event that no permanent
#binding exists in dhcpcap. Normally the JOIN server can
#only service BOOTP clients for which such a binding pre-exists.
#bootp_addr_from_pool
#
#
#
#
Timeout value for ping in milliseconds. Before the server offers an
address it pings (using ICMP echo) it: if a reply is received the
server assumes that it is in use and makes another choice. "ping_timeout"
is the number of milliseconds the server will wait for a reply.
ping_timeout 500
#
#
#
#
Registered clients. When this
granted to clients which have
To pre-register a client used
available starting in release
flags in on DHCP service will only be
been pre-registered in the JOIN database.
jdbreg or xjdbreg. This feature is only
2.3
#registered_clients_only
#
#
#
#
Instructs the server to check whether or not the dhcpcap file appears to
have changed each and every time a client configuration is required.
If the file has changed (as indicated by its time stamp), the server
will read and parse it anew.
auto_reread
#
#
#
#
#
#
Before a BOOTP client is given a hard-wired IP address the server checks
that the client is indeed connected to the logical IP network for which
the address is valid. If not an error is logged and no response sent.
In order for this to work properly the netmasks file must contain the
network numbers and masks for any non-standard IP Class A, B or C
configuration.
#check_bootp_client_net
#
#
#
#
#
#
Before an IP address is given to a BOOTP client the server first checks
to see whether or not it is in use by sending an ICMP echo. If a reply
is received an error is logged. If the address was from the dynamic pool
it will be marked un-available, and a new address selected from the pool.
If the address was statically configured the server refuses to configure
the client.
#ping_bootp_clients
#
#
#
#
The server will by default ignore
agent whose giaddr field shows it
the server will, presumably, hear
option forces the server to reply
any packets forwarded to it via a relay
to be directly connected to the server the clients broadcast directly. This
regardless.
#reply_to_relay_on_local_net
(continued on next page)
8–8 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–1 (Cont.) Sample SERVER.PCY File
# The server will not send a complete configuration to a DHCP client unless
# this toggle is set. Resolving a client configuration can be time consuming
# and, in a multi-server environment, the client may select another server.
#send_options_in_offer
#
#
#
#
Minimum packet size for DHCP requests. By modifying this parameter,
the DHCP server can be configured to work with some non-compliant
DHCP clients that send DHCP requests smaller than the minimum required
packet length. By default, the minimum packet size is 300 bytes.
minimum_bootp_packet_size 300
#
#
#
#
#
#
#
#
#
#
#
#
Set this true if you want to automatically delete leases when
the client changes its net. I.e. if the server has leases for
the client on several nets, and the client boots on a specific
net, say X, the all the leases on all the nets except X, whether
expired or not will be deleted.
Note that some HW, notably SUN workstations, use a MAC address
or client identifier which is the same regardless of the
interface being configured. Therefore, two interfaces of a client
of this tupe may appear to the server to be a single client
which has changed network. You would probably not want to
auto delete leases in this case.
#auto_release
#
#
#
#
#
#
#
#
#
#
Finite Bootp lease support. When this parameter is non-zero it
instructs the server to grant FINITE leases to BOOTP clients.
BOOTP clients don’t know this, so before the server can re-use
these leases it must ping the IP address. If a reply is heard
the server automatically extends the lease by this time interval (secs).
Note that the *original* lease conferred on a BOOTP client is
determined by the dhcpcap file, which need not be the same as
this extension. Also that this capability is only relevant to
BOOTP clients which are dynamically addresses (bootp_addr_from_pool
toggle on).
bp_auto_extension 0
# Set auto_sync_dbs to flush the server database to disk
# after each update. This is more reliable in the event
# of a failure, but slows the server down.
auto_sync_dbs
#
#
#
#
#
#
This toggle is used to ignore the so-called client ID
and instead always use the MAC address to identify
the client. It is useful to turn this on if you are
trying to migrate clients either from BOOTP or from
a vendor stack which doesn’t set the ID to one
which does.
#use_macaddr_as_id
#
#
#
#
Turn on if you want to support Microsoft’s Proxy Remote Access Server
(RAS). The RAS server generates a BOOTP packet with a MAC address
of 16 octets. JOIN recognizes these packets and will ignore them
(and complain about them in the log) unless this toggle is on.
# This option is not currently supported on OpenVMS.
#support_microsoft_ras
(continued on next page)
Configuring and Managing the DHCP Server 8–9
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–1 (Cont.) Sample SERVER.PCY File
# Turn on if you are using Token Ring Source Routing
# Currently this is only supported on HPUX platforms.
#tr_source_routing
#
#
#
#
#
#
#
Use canonical_name to override the default (which will
normally be the value returned by "gethostname". This is
primarily for multihomed hosts which have the
canonical name corresponding to an interface which
is ignored by JOIN (e.g. ATM interfaces).
and for high-availability servers which have per-service
IP addresses which differ from any "physical" ip host address
#canonical_name glenroy
#
#
#
#
#
#
Expand the BOOTP reply packet to 548 bytes (BOOTP clients only).
Normally joind replies with a packet of 300 octets (the legal minimum),
or a size equal to the size of the packet received, whichever is
the bigger. Setting this parameter on causes all replies to BOOTP
clients to be 548 octets. (These sizes are exclusive of the UDP (8)
IP (20, usually) and LINK LAYER (14 of 10MBPS ethernet) headers
#expand_bootp_packet
# Dynamically created name to IP mappings in the DNS are normally
# permanent. Toggle this parameter "on" to have the mappings
# in the DNS expire when the DHCP lease expires.
#dns_tracks_dhcp_lease
# If a DHCP client needs a bootfile, send the name of that file in the BOOTP
# ’file’ field, not as a DHCP option (option 67). BOOTP clients *always*
# receive a bootfile name in the ’file’ field, regardless of this option
#bootfile_not_sent_as_option
#
#
#
#
#
#
Ignore the hardware type field. For client s which *don’t* use DHCP
client identifiers, this toggle tells the server to use the clients
hardware address as its identifier, *BUT* to ignore the hadware
type field. In the JOIN DB the identifier is stored with a type field
of zero (which is also the type for those clients which are using
client idetfifiers)
#ignore_hardware_type
# When "on" server ignores the value of the "broadcast bit" and always
# broadcasts reply, even when the client can receive a pseudo unicast
# reply. This was needed by some Cabletron "smart" bridges.
#force_broadcast_reply.
8.2.2.2 Client Configuration Parameter
The DHCPCAP. file describes the various configuration parameters for clients.
This file is similar to the standard bootptab file used by most BOOTP servers.
Each entry in the file can describe a single machine (per-node basis), all the
machines within a subnet (per-subnet basis), or a group of machines (per-group
basis).
Example 8–2 shows typical information found in the DHCPCAP. file. For
information on how to modify the DHCPCAP. file, see Section 8.7.2.
8–10 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–2 Sample DHCPCAP. File
#
#
#
#
#
#
#
File name:
Product:
Version:
DHCPCAP.
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
# DESCRIPTION:
#
# This file is used by the server when running with the text
# database.
# Using the tc= capability to factor out identical data
# from several entries. Multiple tc’s permit as many
# levels of indirection as desired.
# Be careful about including backslashes where they’re needed.
# Strange things can happen otherwise.
# The data which follows is for example only. You should delete
# and add entries appropriate to configuration of your own
# networks.
# A global entry which everybody uses..
#.global:\
# :yd=alpha.beta.gamma.com:\
# :to=28800:
# Next entries for each subnet. . .
#subnet32:\
# :tc=.global:\
# :nw=192.1.1.32:\
# :gw=192.1.1.33:\
# :ba=192.1.1.63:\
# :lt=7200:t1=3600:t2=6300:
#subnet64:\
# :tc=.global:\
# :nw=192.1.1.64:\
# :gw=192.1.1.65:\
# :ba=192.1.1.95:\
# :lt=1200:t1=600:t2=1050:
# Individual entries...
# An old-style BOOTP client with the ip address hard-wired.
# This assumes that this BOOTP client will always be on
# subnet 192.1.1.32
#.xterm:\#
# :ht=1:ha=0a0b0c0d0e0f:\
# :ip=192.1.1.36:\
# :bf=mybootfile:\
# :sa=192.1.1.33:\
# :tc=.global:
(continued on next page)
Configuring and Managing the DHCP Server 8–11
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–2 (Cont.) Sample DHCPCAP. File
# A DHCP client. The lease time here (1day) overrides that specified in the
# network entries
#.xtermb:\
# :ht=1:ha=0a0b0c0d0e1f:\
# :lt=86400:\
# :tc=.global
8.2.2.3 Network Addresses
The NETS. file describes the ranges of IP addresses available to the server for the
clients. Both BOOTP and DHCP use this pool of addresses whenever dynamic IP
assignment is needed.
Each entry in the file consists of three fields:
•
The network number expressed as an IP address, for example, 142.132.3.0.
•
The owner of this IP address range expressed as the IP address of the server
host (142.132.3.1) or the host name (dhcpserver in Example 8–4). If a DHCP
cluster failover environment is configured (see Section 8.4.5), the IP address is
defined as the null address 0.0.0.0 so that applicable cluster nodes can receive
packets.
•
A range of available addresses for dynamic allocation to hosts on the network.
The range is expressed as a pair of IP addresses with a hyphen (-) between
them, for example, 143.32.3.10-143.32.3.30. There must be no extra space
separating the dash from the IP addresses. You can specify more than one
range for each network; the ranges need not be contiguous.
Example 8–3 shows the contents of the NETS. file.
Example 8–3 Sample NETS. File
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
File name:
Product:
Version:
NETS.
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
DESCRIPTION:
This file instructs the server which nets and subnets it is to
administer and addresses which are available for dynamic allocation.
Each non-comment line in this file has up to three fields:
Subnet IP address
IP address or name of host "owning" the address range.
The address range itself
(continued on next page)
8–12 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–3 (Cont.) Sample NETS. File
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
If there are fewer than three fields then the subnet and owner
are implied by previous entries. The address range is specified
as one or two IP addresses. If two then they must be separated
by a dash "-", with no whitespace intervening. Multiple ranges
may be specified for any owner. The IP addresses are checked for
syntax, for uniqueness of ownership, and validity on the network
specified. If the owner of a range is multi-homed, then the
name used must be its canonical name (e.g. as echoed by hostname),
or, if specified by address, the address must correspond to
the canonical name as given in /etc/hosts
For OpenVMS with DHCP configured on multiple cluster nodes (ie. DHCP
cluster failover) enter 0.0.0.0 in the "owning" DHCP server field
(field 2).
# Examples:
#192.1.1.32
192.1.1.34
#192.1.1.32
192.1.2.34
#192.1.1.64
192.1.2.34
#
# DHCP cluster failover example:
#192.1.1.64
0.0.0.0
192.1.1.35-192.1.1.43
192.1.1.44-192.1.1.62
192.1.1.66-192.1.1.94
192.1.1.66-192.1.1.94
The entries in the NETS. file shown in Example 8–4 describe the IP ranges for
two different networks, each with its own set of IP addresses.
Example 8–4 NETS Entries with IP Ranges for Two Networks
143.32.3.0 143.32.3.1 143.32.3.10-143.32.3.30 143.32.3.40-143.32.3.60
143.32.3.75-143.32.3.100
!
143.32.5.0 dhcpserver 143.32.5.10-143.32.5.200 "
In this example:
! This entry comprises two lines and describes three noncontiguous ranges of
IP addresses for the network 143.32.3.0.
" This entry describes a single range of addresses for the network 143.32.5.0.
Notice the use of an IP address in the first entry (143.32.3.1) and the use of
a host name (dhcpserver) in the second entry to describe the owner of the IP
address ranges.
8.2.2.4 Netmask Masks
If your network is subnetted in a format that is not consistent with the standard
class A, B, or C netmask address, you must include the network addresses and
netmasks in the NETMASKS. file during the initial DHCP server configuration.
Make sure you edit the NETMASKS. file and include an entry for each network.
Each entry in the file must include two fields: the network address and the
netmask address. Example 8–5 show a sample NETMASKS. file.
Configuring and Managing the DHCP Server 8–13
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–5 Sample NETMASKS. File
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
File name:
Product:
Version:
NETMASKS.
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
DESCRIPTION:
Network masks. This file is only needed on those platforms
which don’t provide a netmasks database, either as a text
file or as a map (NIS, NIS+, .. whatever).
This file should contain an entry for each network for which
the netmasks is other than the standard A,B or C mask. Each
entry has two fields: the network and the mask. The network
must be written with trailing zeros: e.g For net 192.1.1
you do not enter
192.1.1
but
192.1.1.0
This file also supports variable subnetting: i.e. if each
subnetted net can in turn be subnetted with a variable
mask then the subnets can also appear on the LHS. Thus
192.1.1.0
192.1.1.96
255.255.255.224
255.255.255.240
Network netmask
8.2.2.5 NamePool
The NAMEPOOL. file specifies a collection of names available for dynamic
assignment to DHCP clients. The server uses the names in this file only when
the name is not provided another way. For example, the server might use this
file when the client did not suggest a name and when there is no name associated
with the IP address being offered to the client.
In addition to this pool of names, there is also a name prefix. Once the name
pool is exhausted, the server generates names from the prefix by appending the
number 1, 2, or 3, along with a trailing ‘‘d’’. After a name has been dynamically
bound to a host, the server never uses the name again, even if that host
subsequently acquires a new name.
Each entry in the file consists of four fields:
•
The domain to which the names apply.
•
The owner of these names, expressed as either the IP address of the server
host (142.132.3.1) or the host name (dhcpserver).
•
An optional name prefix, used for generating names after the name pool is
exhausted.
•
A list of names in the pool.
8–14 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Example 8–6 shows the contents of a typical NAMEPOOL. file.
Example 8–6 Sample NAMEPOOL. File
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
File name:
Product:
Version:
NAMEPOOL.
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
DESCRIPTION:
This file contains names to be allocated to new machines coming onto the
network. Each group of names is introduced by a single line containing
two or three fields: the # domain name to which the names apply, the
machine (name of address) authorised to dispense them, and (optionally)
a prefix which will be used to generate names automatically within that
domain. White space is used to separate these fields; there must be no
leading whitespace on these lines.
Following this are the names. These may be written one or many
to a line, but each line must begin with a blank or tab.
The character ’#’ introduces comments. The text following ’#’
to the end of line will be ignored by the parsing program.
Blank lines and lines beginning with ’#’ are ignored.
In summary format is:
domain_name server generic_name
hostname...
Example:
alpha.beta.gamma.com 192.1.1.65 coastal-areas
north-utsire south-utsire viking forties cromarty forth tyne dogger
Example 8–7 shows a NAMEPOOL. file containing a name prefix.
Example 8–7 NAMEPOOL Entries Showing the Use of a Name Prefix
acme.com
142.132.3.1
pc
alpha bravo charlie delta echo
engr.acme.com
dhcpserver
EngrPC victor whiskey xray yankee zulu
In this example:
•
The first entry describes five names available to the acme.com domain with a
name prefix of pc.
•
The second entry describes five different names for the engr.acme.com domain
with a name prefix of EngrPC. Notice the use of an IP address in the first entry
(143.32.3.1) and the use of a host name (dhcpserver) in the second entry to
describe the owner of the IP address ranges.
Configuring and Managing the DHCP Server 8–15
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
8.2.2.6 .DDNSKEYS
The .DDNSKEYS file describes each DNS domain and the DNS name server
that is to receive Host/IP address update information when DHCP distributes an
address to a DHCP client in the domain. The information in this file consists of
the domain to be updated and the IP address of the DNS server to which DHCP
sends the updates. A third field for secure dynamic updates is reserved for future
use. TCP/IP Services does not support secure dynamic updates.
This file is required for DHCP to perform DNS dynamic updates.
The following example shows the contents of a typical .DDNSKEYS file:
#
#
#
#
#
#
#
File name:
Product:
Version:
.DDNSKEYS
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
# DESCRIPTION:
#
# This file describes each DNS domain and the DNS name server to which to send
# dynamic updates for that domain. The first field is the domain. The second is
# the DNS server to receive updates for the domain. There is a third as yet
# unsupported field for use with secure dynamic DNS updates. In most common use
# there will be entries for forward and reverse translation.
#
# This example defines the DNS server at IP address 10.10.2.14 to receive
# dynamic updates for the compaq.com domain (A records) and the
# 10.10.in-addr.arpa domain (PTR records).
#
#hp.com 10.10.2.14
#10.10.in-addr.arpa 10.10.2.14
8.2.3 Command Files
Table 8–4 describes the command files used by the DHCP server.
Table 8–4 DHCP Server Command Files
Command File Name
Description
TCPIP$DHCP_SETUPCOMMANDS.COM
Defines symbols to invoke DHCP utilities. It is located
in the SYS$MANAGER: directory.
TCPIP$DHCP_STARTUP.COM
DCL commands to start the DHCP server.
TCPIP$DHCP_CLUSTER_STARTUP.COM
DCL commands to start the DHCP server in a cluster
failover configuration.
TCPIP$DHCP_SHUTDOWN.COM
DCL commands to stop the DHCP server.
TCPIP$DHCP_CLUSTER_SHUTDOWN.COM
DCL commands to stop DHCP server in a cluster
failover configuration.
TCPIP$DHCP_RUN.COM
Command procedure for starting DHCP server during
the startup of DHCP server.
TCPIP$DHCP_SYSTARTUP.COM
Site-specific definitions and parameters to be invoked
when DHCP starts.
TCPIP$DHCP_SYSHUTDOWN.COM
Site-specific definitions and parameters to be invoked
when DHCP is shut down.
8–16 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
8.2.4 Logical Names
By establishing logical names, you can modify the following server characteristics:
•
The directory in which the DHCP configuration files and databases are placed
during TCPIP$CONFIG
•
Error logging and diagnostics
Table 8–5 lists the DHCP logical names and describes their function.
Table 8–5 DHCP Server Logical Names
Logical Name
Description
TCPIP$DHCP_CONFIG directory
If defined, places the following DHCP files (during
TCPIP$CONFIG) in the directory you specify:
•
DHCP configuration files in ASCII format (for example,
SERVER.PCY)
•
DHCP database files in binary format (for example,
DBA.BTR)
•
Binary database lock files (for example, RWLOCKDBA)
•
Temporary files created by TCPIP$CONFIG during the
BOOTP-to-DHCP rollover
•
The server’s process identification file (JOIN.PID)
Setting this logical name is useful when you want to
move the file location off the system disk or when you
want to set up a DHCP cluster failover environment (see
Section 8.4.5). The logical name must be defined before
running TCPIP$CONFIG.
If not defined, the preceding DHCP-related files are
placed in SYS$SYSDEVICE:[TCPIP$DHCP] during the
TCPIP$CONFIG procedure.
TCPIP$DHCP_DEBUG value
Logs full diagnostics. Valid numeric values are 1 to 6. If you
define this logical, the value of TCPIP$DHCP_LOG_LEVEL
is ignored.
TCPIP$DHCP_LOG name
Defines the name of the DHCP server log file. The default is
TCPIP$DHCP_RUN.LOG.
If defined, each time the auxiliary server starts a DHCP
server process, two log files are created: the one you
define with TCPIP$DHCP_LOG name and the default
TCPIP$DHCP_RUN.LOG.
TCPIP$DHCP_LOG_LEVEL value
Writes the specified level of diagnostic information to the log
file. Ignored if TCPIP$DHCP_DEBUG is defined.
Valid numeric values are:
0
No logging (default).
1
Log warning messages.
2
Log all messages.
You define system wide TCPIP$DHCP logical names in the
SYS$STARTUP:TCPIP$DHCP_SYSTARTUP.COM file. After making changes
to the file, enter the following commands:
$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM
$ @SYS$STARTUP:TCPIP$DHCP_STARTUP.COM
Configuring and Managing the DHCP Server 8–17
Configuring and Managing the DHCP Server
8.2 DHCP Server Components
Alternatively, you can follow these steps:
1. Manually define the system logical names.
2. Use DHCPSIGHUP to signal the DHCP server.
8.2.5 Log Files
The DHCP server creates a log file named TCPIP$DHCP_RUN.LOG in the
directory SYS$SYSDEVICE:[TCPIP$DHCP].
8.3 DHCP Server Startup and Shutdown
The DHCP server can be shut down and started independently of TCP/IP
Services. This is useful when you change parameters or logical names that
require the service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$DHCP_STARTUP.COM allows you to start up the
DHCP service.
•
SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM allows you to shut down
the DHCP service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$DHCP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when DHCP is
started.
•
SYS$STARTUP:TCPIP$DHCP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
DHCP is shut down.
8.3.1 Stopping the DHCP Server Process
If you specified automatic startup during the TCP/IP Services configuration
procedure (TCPIP$CONFIG), the DHCP server process starts automatically when
the DHCP service is started (TCPIP$DHCP_STARTUP.COM).
If you want to stop the DHCP server process, enter the following utility command
as defined in SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM:
$ DHCPSIGTERM
Be aware that a new DHCP server process starts automatically as soon as the old
process exits unless you disable the DHCP service before entering a DHCPSIGTERM
command. As an alternative method, you can shut down DHCP by executing the
following command:
$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN
Because the DHCP server has several binary databases open (updates to which
might not have been flushed to the disk), do not stop a running DHCP process
using the DCL command STOP/ID=entry_number. Instead, stop the DHCP
process by entering the DHCPSIGTERM command.
8–18 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
8.4 Configuring the DHCP Server
To configure the DHCP server, perform the following tasks:
Task
Described in...
Enable DHCP on your system and set up DHCP files and
databases.
Section 8.4.1
Set up DNS/BIND.
Section 8.4.2
Set up the cluster failover environment.
Section 8.4.5
Stop the DHCP process.
Section 8.3.1
Shut down and start up the DHCP process.
Section 8.3
Configure client information (use the DHCP GUI or make
changes manually).
Section 8.5 or Section 8.7,
respectively
Set up the NETMASKS. file, if appropriate.
Section 8.2.2.4
Define IP addressing.
Section 8.6
8.4.1 Enabling the DHCP Server
To enable DHCP initially, run the TCPIP$CONFIG procedure by entering the
following command and then choose DHCP from the Server Components menu:
$ SYS$STARTUP:@TCPIP$CONFIG
The configuration procedure asks if you want to convert existing BOOTP entries
to DHCP database:
Do you want to rollover old-style BOOTP entries into the DHCP
database? [Y]
•
If you answer Yes, the TCPIP$DHCP_BOOTPTODHCP.COM procedure
tries to locate the existing BOOTP database. Once it locates a file, the
configuration procedure asks you to confirm its selection or make a new
selection:
Name of file to use for old-style BOOTP: SYS$SYSTEM:TCPIP$BOOTP.DAT
Press return or enter new file name:
The configuration procedure does the following to the file:
Converts any existing BOOTP information to the appropriate DHCP
format in the new DHCPCAP. configuration file.
Sets up the DHCP server to support BOOTP clients.
Sets up permanent leases for existing BOOTP clients.
During TCPIP$CONFIG, all DHCP-related files are placed in the
SYS$SYSDEVICE:[TCPIP$DHCP] directory unless you define the system
logical name TCPIP$DHCP_CONFIG (see Table 8–5).
•
If you answer No, the new DHCP configuration file DHCPCAP. remains
empty, and your BOOTP clients will not be served.
TCPIP$CONFIG invokes the command procedure
SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM, which defines
the GUI Server Management Console and DHCP utilities as OpenVMS
foreign commands.
Configuring and Managing the DHCP Server 8–19
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
Important
HP recommends calling the TCPIP$DHCP_SETUPCOMMANDS.COM
procedure as part of the login process for all users who are authorized to
manage the DHCP server.
8.4.2 Configuring DHCP and DNS/BIND to Assign Host Names
DHCP uses the following methods to assign a host name:
•
By hardware address
When you specify this method, DHCP uses the host name suggested by a
client when the client sends out its initial boot request.
This method requires that both the DHCP and BIND servers are capable of
and configured for performing dynamic DNS updates.
To configure host name assignment using this method, see Section 8.4.2.1.
•
By IP address
If you specify this method to assign host names, DHCP performs a BIND IP
address lookup to obtain a host name associated with the IP address. If the
lookup is successful, DHCP uses the host name returned by BIND. If the
lookup fails, DHCP creates a name from the NAMEPOOL. file.
This method requires that you manually assign an IP address to each host
and add A and PTR records to your DNS/BIND database.
To configure host name assignment using this method, see Section 8.4.2.2.
8.4.2.1 Dynamically Assigning Host Names
To configure DHCP to assign a host name dynamically, perform the following
steps:
1. Change the SERVER.PCY file (either manually or with the DHCP GUI) to
include the following statements:
name_service_updateable
assign_name_by_hwaddr
accept_client_name
dns_tracks_dhcp_lease
2. Configure a DNS/BIND server to accept dynamic updates from your DHCP
server. If you are running the DHCP server on multiple nodes, configure the
DNS/BIND server to accept dynamic updates from each of the nodes. Refer
to Section D.3.6 for a discussion on how to configure DNS/BIND to accept
dynamic updates from DHCP.
3. Edit the DHCPCAP. file to add a domain name for all subnet entries for
which DHCP will perform dynamic DNS updates. To use the DHCP GUI to
add dynamic DNS updates for a domain, do the following:
a. Start the DHCP GUI as described in Section 8.5
b. Select the Subnets tab.
c. Select DHCP parameters from the drop down list
d. Add the domain name to the DNS Domain Name parameter.
8–20 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
4. Create a .DDNSKEYS file with an entries for the DNS/BIND server that is to
receive dynamic updates. You will most likely want to create an entry for A
and PTR records by defining a forward and reverse translation entry.
5. Create a NAMEPOOL. file to supply a pool of names to use for nodes on the
particular network. DHCP uses this pool of names to generate a host name
only when other methods are unsuccessful.
8.4.2.2 Statically Assigning Host Names
To configure DHCP to use host names defined in a DNS/BIND server database,
perform the following steps:
•
Change the SERVER.PCY file (either manually or with the DHCP GUI) to
include the following statement:
assign_name_by_ipaddr
Exclude the following statements:
accept_client_name
dns_tracks_dhcp_lease
name_service_updateable
See Section 8.2.2.1.
•
Edit the DNS/BIND forward translation (domain_name.DB) file to include
an A record for each IP address in the range of IP addresses that your
DHCP server may allocate. It is common practice to assign IP addresses
and names systematically. For example, if IP address 10.10.2.100 obtains
the name dhcp1.xyz.com, then IP address 10.10.2.101 obtains the name
dhcp2.xyz.com (see Section D.4.4.3).
•
Edit the DNS/BIND reverse translation (address.DB) file to include a PTR
record for each host name (see Section D.4.4.4).
8.4.3 Signaling the DHCP Server
One of the DHCP utilities that is defined in TCPIP$DHCP_
SETUPCOMMANDS.COM is the TCPIP$DHCP_SIGNAL utility, which provides
interprocess signaling in a manner similar to the UNIX kill signal delivery
utility. PRMMBX and SYSNAM privileges are required to run TCPIP$DHCP_
SIGNAL.EXE.
The following table shows the commands available with the TCPIP$DHCP_
SIGNAL utility:
Command
Description
DHCPSIGHUP
Causes the ASCII configuration files to be read again, flushes the
binary databases and then translates the TCPIP$DHCP_DEBUG and
TCPIP$DHCP_LOG_LEVEL logical names.
DHCPSIGTERM
DHCPSIGUSR1
Causes an orderly shutdown of DHCP.
Causes a dump of the ASCII configuration files, then flushes the binary
databases.
Configuring and Managing the DHCP Server 8–21
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
8.4.4 Returning to the BOOTP-Only Configuration
You can return to a BOOTP-only configuration at any time. Further, you can
use the previous TCPIP$BOOTP.DAT database file and the client entries it
contains. If you deleted the TCPIP$BOOTP.DAT file, you can create a new one
and populate it with entries (see Section 10.5).
To enable BOOTP after you have configured your host for DHCP, run
TCPIP$CONFIG and enable the BOOTP component from the Server Components
menu. Your existing DHCP files will remain for future use.
8.4.5 Setting Up a DHCP Cluster Failover Environment
You can set up an OpenVMS Cluster environment for DHCP server failover. In
this environment, a standby system becomes the DHCP server if the active DHCP
server process fails or is stopped, or the system on which it is running fails or
shuts down.
With cluster failover, the DHCP server uses the OpenVMS lock manager during
process initialization to acquire a system-level, exclusive-mode lock on a resource
called TCPIP$DHCP_SERVER. The first server started on the cluster obtains the
lock on TCPIP$DHCP_SERVER and becomes the active DHCP server. The other
DHCP servers wait to obtain the lock and become the standby servers.
When the active DHCP server process exits for any reason, the lock on
TCPIP$DHCP_SERVER is released and one of the standby processes acquires the
lock and becomes the active server.
To configure the DHCP server failover environment, do the following:
1. If the DHCP server is running on one of your systems, manually disable it by
entering the following command on the server system:
$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM
2. Create a directory for the DHCP configuration and binary database files
that is visible to the DHCP cluster members. Specify TCPIP$DHCP as the
directory’s owner. For example:
$ CREATE/DIRECTORY/OWNER=TCPIP$DHCP WORK1$:[DHCP_CONFIG]
3. If you have already been running DHCP server and want to start with the
existing data files, then do the following:
a. Copy the DHCP data files from the DHCP directory to TCPIP$DHCP_
CONFIG:*.* by entering commands similar to the following:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP. TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS. TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL. TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS. TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETS. TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%% TCPIP$DHCP_CONFIG:
$ COPY SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS TCPIP$DHCP_CONFIG:
8–22 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
b. Delete the DHCP data files from the DHCP directory by renaming them
to a temporary subdirectory. (You can delete the files after you are sure
that the failover environment is set up correctly.) For example, enter the
following commands:
$ CREATE/DIR SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ PURGE SYS$SYSDEVICE:[TCPIP$DHCP]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%%;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
$ RENAME SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]
4. On each cluster node that is to serve as a potential DHCP server, set up the
TCPIP$DHCP_CONFIG logical name as follows:
a. Define TCPIP$DHCP_CONFIG as a systemwide logical name. For
example:
$ DEFINE/SYSTEM TCPIP$DHCP_CONFIG WORK1$:[DHCP_CONFIG]
b. Before you run the TCPIP$STARTUP.COM procedure, add
the TCPIP$DHCP_CONFIG logical name definition to the
TCPIP$DHCP_SYSTARTUP.COM file.
5. On each cluster node that you want to be a DHCP server, run
TCPIP$CONFIG to enable the DHCP service (see Section 8.4.1).
The TCPIP$CONFIG procedure creates the TCPIP$DHCP account and stores
initial copies of the DHCP configuration data files in the directory pointed
to by the logical name TCPIP$DHCP_CONFIG. If you choose to roll over
your BOOTP database to DHCP, TCPIP$CONFIG creates your initial DHCP
binary database files in the TCPIP$DHCP_CONFIG directory.
6. Make sure that the auto_sync_dbs parameter is set in the SERVER.PCY file.
This parameter causes the DHCP server databases to be flushed after each
update. You can set the parameter by editing the SERVER.PCY file or by
setting the auto_sync_dbs parameter to True on the Server/Security tab in
the DHCP GUI.
7. Ensure that the files in TCPIP$DHCP_CONFIG: and the directory itself
are owned by TCPIP$DHCP and have owner-only protection (O:RWED). For
example:
$ DIRECTORY/SECURITY WORK1$:[DHCP_CONFIG]
$ DIRECTORY/SECURITY WORK1$:[000000]DHCP_CONFIG.DIR
8. Edit the NETS. file and set the ownership of any existing IP address range to
0.0.0.0.
Configuring and Managing the DHCP Server 8–23
Configuring and Managing the DHCP Server
8.4 Configuring the DHCP Server
With the DHCP cluster failover configured, you need to indicate that an
address range is owned by other hosts. Therefore, you specify the null IP
address of 0.0.0.0 in the second field of the NETS. file in each IP address
range to be shared among the DHCP servers. For example, the following
entry in the NETS. file is owned by IP address 17.18.208.100:
17.18.0.0
17.18.208.100
17.18.208.10-17.18.208.50
You would change the entry to the following:
17.18.0.0
0.0.0.0
17.18.208.10-17.18.208.50
If you prefer to use the DHCP GUI to configure the null address, choose the
IP Ranges parameter on the Server/Security tab and set the parameter to
True.
9. Shut down DHCP on each cluster member where DHCP is running by using
the TCPIP$DHCP_CLUSTER_SHUTDOWN command procedure. When
the command procedure is finished, restart DHCP on the cluster by using
TCPIP$DHCP_CLUSTER_STARTUP.
8.4.6 Methods to Configure DHCP Parameters
TCP/IP Services provides three methods for configuring server and client
parameters:
•
An easy-to-use DHCP graphical user interface (GUI) to do the following:
Configure dynamic and static IP addressing for all clients. See
Section 8.6.
Configure the client information appropriate for your client base. See
Section 8.5.
Set DHCP parameters to customize the DHCP server. See Section 10.4.3.
•
Manually editing the DHCP configuration files and then signaling the DHCP
server to read the files. See Section 8.7.
•
Using the DHCPDBMOD utility. See Section 8.8.2.
8.5 Using DHCP GUI to Configure DHCP
You can modify the default DHCP server settings and define additional
characteristics by performing the following tasks:
Task
Described in...
Define server and security parameters.
Section 8.5.2
Define subnet parameters.
Section 8.5.3.1
Define node parameters.
Section 8.5.3.2
Define group parameters.
Section 8.5.3.3
8–24 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.1 General Information
To use the DHCP GUI to configure DHCP:
•
You need the following system privileges:
BYPASS
SYSNAM
PRMMBX
•
If you have not already done so, execute the TCPIP$DHCP_
SETUPCOMMANDS.COM command procedure to establish DHCP foreign
commands .
•
Invoke the GUI by entering the following utility program command:
$ DHCPGUI
The system displays the configuration window with four tabs across the top of the
window. The tabs allow you to configure the following sets of DHCP parameters:
Tab
Function
Server/Security
Defines the server configuration (see Section 8.5.2). You can set your
IP address ranges, general server parameters, or view currently
leased IP addresses and their lease time.
Subnets
Assigns client configurations for entire subnets.
Nodes
Adds and customizes specific machines on your network, usually for
BOOTP clients.
Groups
Defines a group of settings for predefined collections of machines.
Choose a tab for the category of parameters you want to configure. The window
for each tab has three columns:
•
The left column lists the items that are configured for that category. The list
always contains a [New Record] item to configure another machine. Choose
an item from this list to enter or view its parameters.
•
The middle column lists the available parameters for the selected item along
with the current specification or setting. Choose a parameter to enter or
change the specification or setting.
•
The right column has fields for entering data. To add or change a parameter
setting, select a parameter and enter the value for the parameter in the field
to the right. You can enter values as:
Descriptive text, such as an IP address
Time in hours, minutes, and seconds
True or false statements
When there is more than one value field, press Tab to move to the next field.
To delete information in a field, select the text, then click Delete.
Configuring and Managing the DHCP Server 8–25
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.1.1 Saving Information in a Record
If you add or revise information in a field, you need to save the information using
one of the following methods:
1. Choose Update from the File menu.
2. Choose Exit from the File menu, then choose Save and Exit. This updates the
database when you exit the program.
8.5.1.2 Adding New Records
For some subjects, you can add more than one record. To add a new record:
1. Choose [New Record] from the list on the left side of the window.
2. Enter the information for the new record.
3. Choose and enter parameter information as appropriate.
When only one record is possible, [New Record] disappears after you configure the
first server.
8.5.2 Configuring Server and Security Parameters
Use the Server/Security tab to perform the following tasks:
•
Configure Server/Security parameters.
•
Configure IP ranges.
•
Set up the host name lists.
•
Use the Active IP Snapshot window.
•
Preload MAC addresses.
8.5.2.1 Server/Security Parameters
To configure the server parameters using the Server/Security tab of the GUI,
follow these steps:
1. Click the Server/Security tab.
2. Choose a parameter class from the drop-down list.
3. Choose the parameter you want to change.
You can change any or all of the Server/Security parameters described in this
section.
Accept Client Name
Specifies whether the server assigns names to client machines according to a
policy that is established on the server by the system manager.
Even when this capability is enabled, the server ignores the client-suggested
name if it is already in use by another client in the same domain.
If the server is unable to find a name for the client by applying this policy, it will
take one of the following actions depending upon the specified value. The valid
values are:
False:
Assign a name from the NAMEPOOL. file if an IP address lookup does not return
an associated name. Default.
True:
Use the name the client suggests for itself, if specified.
8–26 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Assign Name by Hardware Addr
Specifies whether you can assign host names by the hardware address. If you
choose True, the client computer always has the same name, even if its IP
address changes; however, to do so, the client must remain in the same domain.
This option is appropriate for sites supporting dynamic updating of the name
service. When you select this policy, the server maintains a binding of the client’s
unique identifier to the name the client first acquires.
If the name service does not dynamically update, the new name-IP address
mapping implied by this policy is not available to other clients until you bring the
name service up to date by another mechanism. This means dumping data from
the database and using it to update the name service manually. The following are
valid values:
False:
Disable assignment of host names by hardware addresses. Default.
True:
Enable assignment of host names by hardware addresses. Use the naming
method defined in the NAMEPOOL. file.
Assign Name by IP Addr
Specifies whether you can assign host names by an IP address. If you choose
True, the client receives its name from the name service as a result of a
gethostbyaddr routine call. Also, when a client computer moves, it can receive a
new name from the name service. The following are valid values:
False:
Host names cannot be assigned by IP addresses. The DHCP server does not
issue a gethostbyaddr routine call. Instead, the session uses the naming
method defined in the NAMEPOOL. file.
True:
Host names can be assigned by IP addresses. Default.
Auto Release Old Lease
Set this to True if you want to automatically delete leases when the client changes
its network. For example, if the client:
•
Receives an address on subnet A
•
Then moves to subnet B
The server releases the leased IP address on subnet A even though the leased IP
address on subnet A is still valid.
The default setting is False.
Note
Some hardware configurations use a MAC address or client identifier
that is the same regardless of which interface you are configuring. To the
DHCP server, two interfaces of a client of this type can appear to be a
single client that has changed networks. Do not autorelease these leases.
Auto Reread Config File
Instructs the server to see if the DHCPCAP. file has changed, indicated by the
timestamp. This occurs each time a client requires a configuration. If the file
changes, the server rereads and reparses the DHCPCAP. file.
The default is True.
Configuring and Managing the DHCP Server 8–27
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Auto Synchronize Database
Choose True to flush the server database to disk after each update. This
makes the server more reliable if there is a failure such as a system crash or
unintentional power shutdown. Setting this parameter to True can slow down the
server.
The default is False.
BOOTP Addr From Pool
Specifies whether the DHCP server does not require a preestablished binding for
BOOTP clients. When none exists, the server allocates an address from the pool
to the client. Because BOOTP does not understand the concept of lease times, all
such allocations are permanent regardless of the lease times specified elsewhere
in the database.
When you disable BOOTP Addr From Pool, the Server only supports BOOTP
clients whose IP address is configured into the database. This means the binding
of the IP address to the client must be preestablished. The address must be
consistent with the network to which the client is attached. See Section 8.6 for
information on how to preestablish a binding between a MAC address and an IP
address. The following are valid values:
False:
Do not pick an address from a pool. Requires a preestablished binding. Default.
True:
Pick an address from a pool. Does not require a preestablished binding.
BOOTP Client Lease Extension
TCP/IP Services does not currently support this parameter.
When you set this parameter to a value above zero, the server grants Finite
leases to BOOTP clients. BOOTP clients do not know this, so before the server
can reuse these leases, it must ping the IP address. If the server hears a reply, it
extends the lease by the time interval (in seconds) specified by this parameter.
The default value is 0 seconds.
BOOTP Compatibility
DHCP can serve BOOTP clients as well as DHCP clients. The following are valid
values:
False:
The server should act as a DHCP server only.
True:
The server should also act as a BOOTP server. Default.
Bootfile not sent as option
Because the DHCP clients normally do not require bootfile names, the space
reserved for this purpose (the ‘‘file’’ field) in reply packets is used by JOIN as
an extension of the DHCP options field. This arrangement permits the client
to receive more configuration information than would otherwise be possible in a
standard-sized DHCP packet.
Enabling this parameter sends the bootfile name in the ‘‘file’’ field, instead of
as a DHCP option. Certain network computers (NCs) expect to find the bootfile
information in the ‘‘file’’ field and will not successfully load their OS images
unless this parameter is set to True. Note: BOOTP clients always receive a
bootfile name in the ‘‘file’’ field, regardless of the state of this option.
8–28 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Canonical Name
Overrides the value normally returned by a gethostname routine call (default).
Primarily used for multihomed hosts with a canonical name corresponding to an
interface that is not recognized by DHCP (for example, ATM interfaces) and for
high-availability servers that have per-service IP addresses that differ from a
physical IP host address. The following are valid values:
gethostname routine call. Default.
False:
Use the host name returned by a
True:
Use the specified canonical host name.
Check BOOTP Client Net
Before a BOOTP client is given a hard-wired IP address, the server makes sure
that the client is connected to the logical IP network for which the address is
valid. If the client is not connected, the server logs an error and does not send a
response to the client.
For this to work properly, the NETMASKS. file must contain the network
numbers and masks for any nonstandard IP Class A, B, or C configuration.
The following are valid values:
False:
Do not check the IP network of the address. Default.
True:
Check the IP network of the address.
DNS expiration tracks DHCP lease
This parameter implies that SIG resource records for DNS are updated with
expiration times that match the DHCP client’s lease time. If a client sends a
‘‘DHCP release’’, the lease is prematurely expired and the SIG record is marked
as expired. In order to reduce the amount of traffic between DHCP and DNS, the
default value is False.
This policy affects only installations that use the Dynamic DNS option.
Default Lease Time
Specifies the value used on all leases for clients that have no other value explicitly
configured. Enter the lease time of the IP address granted to a client.
The default lease time is one day.
Expand BOOTP Packet
Expands the BOOTP reply packet to 548 bytes. Applies to BOOTP clients only.
The following are valid values:
False:
All replies to BOOTP clients are 300 octets or a size equal to the size of the
packet received, whichever is larger. Default.
True:
All replies to BOOTP clients are expanded to 548 bytes.
Force Broadcast Reply
The DHCP server generally sends unicast reply packets in response to client
packets. This toggle tells the server to send broadcast reply packets instead of
unicast reply packets. The following are valid values:
False:
Forces the DHCP server to use unicast reply packets. Default.
True:
Forces DHCP server to broadcast reply packets to the client, even when the
server could use unicast replies.
Configuring and Managing the DHCP Server 8–29
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Free List Size
Specifies the size of the internal array specifying the number of address blocks
held on the free list. If this number is too high, the server will lose previous
allocations of expired leases quickly. If this number is too low, performance can
suffer.
The default setting is 8.
Ignore Hardware Type
This toggle tells the server to use the clients’ hardware address as its identifier
(for those clients that do not use DHCP client identifiers), but to ignore the
hardware type field. In the DHCP DB the identifier is stored with a type field of
zero (which is also the type for those clients which are using client identifiers).
Set this option to True only to work around problems introduced by clients that
broadcast multiple DHCP requests with conflicting hardware types (for example,
HP Jet Direct). The default value is False.
Ignore Name Owner
This parameter applies only if both "Assign Name by Hardware Address" and
"Accept Client Name" are True. In such a case, a previously established namehardware address binding with the same name will be overwritten with the MAC
address of the requesting client in DHCP’s internal name database.
Listen on PPP Interfaces
Not currently supported.
If True, the server will respond to DHCP requests on Point-to-Point Protocol
(PPP) interfaces of the host. By default, DHCP ignores these interfaces.
Min BOOTP Packet Size
Specifies the minimum packet size for DHCP requests. Change this value to
allow the Server to work with some noncompliant DHCP clients that send DHCP
requests smaller than the minimum required packet length.
The default minimum packet size is 300 bytes.
Name Service
Specifies the implementation of the underlying name service. Name service
authenticates, routes, addresses, and performs naming-related functions for other
computers on the network.
DNS is the only name service available with TCP/IP Services.
Name Service Updatable
Choose True to have TCP/IP Services automatically update the name service with
the assigned IP addresses and host names.
Ping BOOTP Clients
Before the DHCP server assigns an IP address to a BOOTP client, the server
checks to see if the address is available by using ping to send an Internet Control
Message Protocol (ICMP) echo request. If the server receives a reply, it logs an
error. Then:
•
If the address was from the dynamic pool, the server marks it as unavailable,
and selects a new address from the pool.
•
If the address was statically configured, the server refuses to configure the
client.
8–30 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
The following are valid values:
False:
Do not send an ICMP echo request to a BOOTP client before assigning an IP
address. Default.
True:
Send an ICMP echo request to a BOOTP client before assigning an IP address.
Ping Timeout
Specifies the duration (in milliseconds) of the ping timeout. Enter the amount of
time the server is to wait before concluding no other host is using the IP address.
After the timeout, the ping command stops checking.
If you do not want the server to ping before giving out an IP address, set the
timeout value to 0.
The default is 500 milliseconds.
Provisional Time To Live
Specifies the maximum time period that an IP address can remain on the
provisionally allocated list before it can be allocated to another client. The
value should be limited to a few minutes.
The default is 1 minute.
Reply to Relay On Local Net
Specifies whether the server ignores packets forwarded to it from a relay agent
on the same subnet as the server.
The following are valid values:
False:
Do not reply (the server should hear the client broadcast directly). Default.
True:
Reply no matter where the agent is located (the value in giaddr field).
Restrict to Known MAC Addresses
Specifies whether to restrict IP addresses that are assigned to a matching
MAC address. When specified, you can manually assign a MAC address. This
parameter indicates whether the server should respond to clients with a MAC
address that is unknown to the server.
Choose True to have the server provide DHCP information to only those hosts
that have a known MAC address. To register a known MAC address client, use
Preload MAC Addresses feature from the Server/Security tab or use the DBREG
utility.
The following are valid values:
False:
Do not allow manual assignment of MAC addresses. Default.
True:
Allow manual assignment of MAC addresses.
Send Options in DHCP Offer
Specifies whether the server is to send a complete configuration to a DHCP
client. Resolving a client configuration can be time consuming. In a multiserver
environment, the client can select another server.
The following are valid values:
False:
Send a minimum configuration. Default.
True:
Send a complete configuration.
Configuring and Managing the DHCP Server 8–31
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Support Microsoft RAS Server
Specifies support for the Microsoft Proxy Remote Access Server (RAS). The RAS
server generates a BOOTP packet with a MAC address of 16 octets.
The following are valid values:
False:
Ignore a BOOTP packet with a MAC address of 16 octets. Default.
True:
Recognize a BOOTP packet with a MAC address of 16 octets.
Use MAC addr as client ID
Specifies whether the server is to use the client ID to uniquely identify a client.
If set to True, the server uses the client’s MAC address as the client ID. BOOTP
also uses the MAC address to uniquely identify a client.
The following are valid values:
False:
Use client ID to identify clients. Default.
True:
Use MAC address to identify clients.
8.5.2.2 Configuring IP Ranges
Use the IP Ranges parameters to specify the IP addresses that are available to
assign to clients.
Note
If your network contains subnets, that information must be included in
the NETMASKS. file. See Section 8.2.2.4 for more information on the use
of netmasks when you are using subnet addressing.
To configure the server IP ranges:
1. Click the Server/Security tab.
2. Choose IP Ranges from the drop-down list.
3. Choose [New IP Range].
4. For each IP range, enter the subnet address or name, a server address, and
an IP range to be assigned to clients on the selected subnets.
IP Range Parameters
You can change any or all of the IP range parameters described in this section.
Subnet Address
Enter the subnet address or name.
DHCP Server (address)
Enter the IP address or the name of the Server. For cluster failover
configurations, enter 0.0.0.0 for the IP address.
IP Ranges
The IP Address Range is a group of unique IP addresses that the server can
assign to clients on a selected subnet. To assign an IP Address Range to a subnet:
1. Enter the beginning of the IP Address Range for the subnet: network, subnet,
and host address.
2. Enter the end of the IP Address Range.
8–32 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
3. If your network has more than one subnet, enter the remaining subnet IP
numbers.
Note
A subnet address can have more than one corresponding IP Address
Range.
The server can configure clients on more than one subnet when the routers
between the server and the client forward BOOTP packets.
8.5.2.3 Configuring Host Names
Use the Host Names Lists Parameters to configure a host name. If you have
set the server configuration so that the server automatically accepts the name a
client suggests for itself or you have added A and PTR records for the hosts to
your DNS/BIND database, you do not need to set up host names.
Note
Follow the instructions in this section only if the Accept Client Name
parameter is set to False.
To configure a host name:
1. Click the Server/Security tab.
2. Choose Host Name Lists from the drop-down list.
3. Choose [New Host name List].
4. For each host name, enter:
–
Domain name
–
DHCP server name
–
Host name Prefix (required as part of the host name)
–
Host names
8.5.2.3.1 Host Name List Parameters
parameters to set up host names.
You can use the following host name list
Domain Name
Specifies the domain name. Enter the domain name exactly as it was assigned by
the NIC Domain Registrar, including its top-level domain extension. For example,
enter school.edu, company.com, or city.gov.
DHCP Server
Enter the IP address or name of the DHCP server.
Hostname Prefix
Specifies a host name prefix.
The host name prefix is used when a computer requests a host name and one is
not available.
Using the mycompany.com domain as an example, assume:
•
All names in the host name list have been assigned.
Configuring and Managing the DHCP Server 8–33
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
•
Host name prefix is magic.
Then, the DHCP server gives the host names magic1 and magic2 to the next two
computers that request host names.
Enter a specific host name prefix.
Host names
Specifies the list of host names. Enter as many host names as needed. Different
DHCP servers can own the same host names.
8.5.2.4 Active IP Snapshot
You can use the Active IP Snapshot window to view the lease database, manually
add a new lease, and remove a lease.
Viewing a Lease
The left side of the Active IP Snapshot window lists each DHCP client with a
lease granted by the server. To see the details:
1. Click the Server/Security tab.
2. Choose Active IP Snapshot from the drop-down list.
3. Select a record on the left side of the window.
4. Review the information on the right side of the window. It lists the
information that applies to the selected record.
Adding a New Lease
Typically you only add a new lease when you intend to permanently attach a
hardware address to an IP address. The IP address does not need to come from
the DHCP IP addresses you have defined.
To add a new lease, use the following procedure:
1. Click the Server/Security tab.
2. Choose Active IP Snapshot from the drop-down list.
3. Choose [New Record].
4. Enter a value for each parameter.
5. Click Add.
Changes made to the database take effect immediately.
Note
Ensure that the IP address you specify does not belong to any pool of IP
addresses configured in an IP range. If it does, it could be released and
used by other clients (MAC address).
If you want to grant a lease for an infinite period of time, which effectively
make a permanent binding between an IP address and a MAC address,
set the Lease Expiration parameter to a value of -1.
Removing a Lease
To remove a lease, use the following procedure:
1. Click the Server/Security tab.
8–34 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
2. Choose Active IP Snapshot from the drop-down list.
3. On the left side of the window, select the record you want to remove.
4. Click Delete.
Changes to the database take effect immediately.
Refreshing the Active IP Snapshot Window
To refresh the Active IP Snapshot window so that it reflects the current status of
the database, click Refresh. This parameter will refresh data on leases that are
active or expired, or both.
8.5.2.5 Preload MAC Addresses
Use the Preload MAC Addresses window to restrict the assignment of IP
addresses. To enable this security measure, set the Restrict to known MAC
addr value to True in the Server/Security Parameters window. You can then
manually assign the desired MAC addresses. The server ignores all other client
DHCP requests.
Checking the Status of a MAC Address
Each configured MAC address and type is listed on the left side of the Preload
MAC Addresses window. To see the details of a MAC address:
1. Click the Server/Security tab.
2. Choose Preload MAC Addresses from the drop-down list.
3. Select a record from the left side of the window.
The right side of the window lists the information applicable to the address.
Adding a New MAC Address
Initially, you may need to add large numbers of MAC addresses to the known
clients database; it may be more practical to use the command line utility jdbreg
for this purpose. You would typically use the GUI to add MAC addresses when
new (trusted) clients appear on the network.
To add a new MAC address:
1. Click the Server/Security tab.
2. Choose Preload MAC Addresses from the drop-down list.
3. Choose [New Record].
4. Enter a value for each parameter.
5. Click Add.
Changes to the database take effect immediately.
Removing a MAC Address
To remove a MAC address:
1. Click the Server/Security tab.
2. Choose Preload MAC Addresses from the drop-down list.
3. Choose the MAC address you want to delete.
4. Click Delete.
Changes to the database take effect immediately.
Configuring and Managing the DHCP Server 8–35
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Searching for a MAC or IP Address
To search for a MAC or IP address:
1. Click the Server/Security tab.
2. Choose Preload MAC Addresses from the drop-down list.
3. Click Find.
4. Enter the MAC or IP address you want to locate.
5. Click OK.
Refreshing the MAC Addresses Window
To refresh the MAC address window so that it reflects the current status of the
database, click Refresh.
8.5.3 Configuring Parameters for Clients
DHCP allows you to configure many client parameters in addition to the client’s
IP address. For example you can configure the IP address of a client’s bind server
and its DNS domain name.
There are three ways to assign configuration parameters to DHCP clients. You
can assign parameters to:
•
A specific client
To assign parameters to a specific client, use the node configuration options
described in Section 8.5.3.2. This is called a node group and is identified by
the client’s MAC address.
•
A net or subnet
To assign parameters to all clients in a subnet, use the subnet configuration
options described in Section 8.5.3.1. This is called a subnet group and is
identified by the subnet in which the client is being configured. You will likely
configure each client within a subnet with similar parameters, for example,
DNS domain name, DNS server, default route, and so forth.
•
A group of clients
To assign parameters to a group of clients that are not in the same subnet,
use the group configuration options described in Section 8.5.3.3. This is called
an include group. You can declare a node or subnet group as a member of an
include group to pull in the include group’s parameters.
After the DHCP server finds an IP address for a client, it matches the client’s
MAC address against your node groups and the client’s subnet against your
subnet groups, pulling any parameters from matched groups into the list of
parameters to be sent to the DHCP client. If a match occurs against both a
subnet and a node group, and a particular parameter is assigned in both the
subnet and the node group, then the value from the node group is used. When
a match occurs on a subnet or node group that is a member of an include group,
the DHCP server pulls in parameters from the include group also.
8.5.3.1 The Subnets Tab
A subnet is a segment of a logical network that has been divided into smaller
physical networks. Use the Subnets tab to configure parameters to be passed to
DHCP clients according to the subnet in which they reside.
8–36 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.3.1.1 Configuring a Subnet
parameters in the Subnets tab.
You do not have to change every value for the
To configure a subnet group using the Subnets tab, use the following procedure.
For a description of the subnet parameters, see Section 8.5.3.4.
1. Click the Subnets tab.
2. Choose [New Record].
3. Choose the Name parameter from the Name/ID Parameters menu.
4. Enter the name of the subnet configuration in the Value field. This name is
a tag for internal use of the DHCP server only. For more information, see
Section 8.5.3.4.1.
5. Choose Member of Group (optional). Enter the name of the include group that
the subnet group is joining. Any client that matches this entry will pull in
the parameters from the specified include group.
6. Set up key information:
a. Choose the net or subnet IP address.
Enter the net or subnet IP address that identifies the subnet portion of
the network.
b. Choose the vendor class (optional).
Enter the vendor class (for example, TCPVMS or JOIN) that identifies the
DHCP client vendor class to which this entry should apply. Note that you
can have multiple subnet entries for the same Net or Subnet IP Address
if they have different Vendor Class key values. If the entry should apply
to any vendor class or you are not using vendor classes leave the Vendor
Class field blank.
7. Choose from the lists of DHCP parameters on the drop-down list.
Different lists of DHCP parameters are available on the drop down list.
Choose either BASIC DHCP Parameters or DHCP Parameters.
8. As appropriate, enter information for Network, Lease, Time, BOOTP,
NetBIOS, X Window, TCP, IP, and Link parameters. For more information
about these parameters, refer to Section 8.5.3.4.
9. Choose Update from the File menu to update the server with the new
configuration.
The new configuration takes effect immediately.
8.5.3.1.2 Removing a Subnet Record
To remove a subnet record:
1. Click the Subnets tab.
2. Choose DHCP Parameters from the drop-down list.
3. Choose the subnet record you want to delete.
4. Click Delete.
Changes to the database take effect immediately.
Configuring and Managing the DHCP Server 8–37
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.3.2 The Nodes Tab
A node is a workstation, computer, or other device on the network. Use the Nodes
tab to configure parameters to be passed to specific client nodes.
8.5.3.2.1 Configuring a node You need not change every value for the
parameters in the Nodes tab. A node group can be a member of an include
group although the settings for a node group override those from a subnet or
include group.
To configure a node group using the Nodes tab, use the following procedure. For
a description of the node parameters, see Section 8.5.3.4.
1. Click the Nodes tab.
2. Choose [New Record].
3. Enter the name of the node configuration in the Value field. This name is
a tag for internal use of the DHCP server only. For more information, see
Section 8.5.3.4.1.
4. Choose Member of Group (optional). Enter the name of the include group that
the node group is joining. The client that matches this entry will pull in the
parameters from the specified include group.
5. Set up key information:
a. Choose Hardware Address. Enter either the hardware address or the
client ID of the node.
If you are using the hardware address (MAC address) of the node, enter
it using the format xx:xx:xx:xx:xx:xx, for example, 00:08:C7:08:E3:63. The
hardware address is assigned during manufacturing, and usually appears
when you turn on or reboot your computer.
b. Choose Hardware Type. Enter the type of network the node is connected
to: Token Ring, Ether3, Pronet, ARCnet, or 0 (see Table 8–6).
6. Choose from the lists of DHCP parameters on the drop-down list.
Different lists of DHCP parameters are available on the drop-down list.
Choose either BASIC DHCP Parameters or DHCP Parameters.
7. As appropriate, enter information for Network, Lease, Time, BOOTP,
NetBIOS, X Window, TCP, IP, and Link parameters. For more information
about these parameters, refer to Section 8.5.3.4.
8. Choose Update from the File menu to update the server with the new
configuration.
The new configuration takes effect immediately.
8–38 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Table 8–6 Network Type Symbol and Number
Symbol
Number
Network Type
ethernet or ether
1
10 MB Ethernet
ethernet3 or ether3
2
3 MB experimental
ax.25
3
AX.25 Amateur Radio
protnet
4
Protnet proNET Token Ring
chaos
5
Chaos
token-ring,tr,ieee802
6
IEEE802
arcnet
7
ARCnet
8.5.3.2.2 Removing a node record
To remove a node record:
1. Click the Nodes tab.
2. Choose DHCP Parameters from the drop-down list.
3. Choose the Node record you want to delete.
4. Click Delete.
Changes to the database take effect immediately.
8.5.3.3 The Groups Tab
An include group is a collection of parameters to be passed to a set of
workstations or other computers on the network which can be on different
subnets. Use the Groups tab to configure include groups.
8.5.3.3.1 Using group parameters You can define a group so that a set of
workstations, possibly on different subnets, has the same configuration values.
For example, you might want a group to include specific lease time information
for your network environment and you want this lease information to be used for
all of your clients. You can define an include group holding this lease information
and make your subnet groups members of this include group. The alternative
would be to duplicate the lease information in each individual subnet group
entry which is more difficult and error prone. Include groups can be members of
other include groups. This allows you to create hierarchies of available network
services across many clients.
8.5.3.3.2 Defining a group To define an include group using the Groups tab,
use the following procedure. For a description of the group parameters, see
Section 8.5.3.4.
1. Click the Groups tab.
2. Choose [New Record].
3. Enter the name of the include group in the Value field. This name is a
tag for internal use of the DHCP server only. For more information see
Section 8.5.3.4.1.
4. Choose Member of Group (optional). Enter the name of an include group that
the include group is joining. Use this feature to create hierarchies of groups
and minimize duplication elsewhere.
5. Choose Group Members (optional).
Configuring and Managing the DHCP Server 8–39
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Enter the names of subnets, nodes, or other groups that are to be members
of the group, that will pull in this group’s parameters. If you have already
created a node or subnet group or groups that are members of the include
group you are entering the DHCP GUI will display the names of these groups
in the Group Members field. If you want to include a new member or delete
an existing member you can do so here in the group’s Group Members field or
under the Subnets or Nodes tab in the Member of Group field of the groups
pulling in this group.
6. Set up key information:
Enter the vendor class (for example, TCPVMS or JOIN) that identifies
the DHCP client vendor class to which this entry should apply. Note
that you can have multiple include groups with the same name if they
have different vendor class key values. If the entry should apply to any
vendor class or you are not using vendor classes leave the vendor class
field blank.
7. Choose from the lists of DHCP parameters on the drop-down list.
Different lists of DHCP parameters are available on the drop down list.
Choose either BASIC DHCP Parameters or DHCP Parameters.
8. As appropriate, enter information for Network, Lease, Time, BOOTP,
NetBIOS, X Window, TCP, IP, and Link parameters. For more information
about these parameters, refer to Section 8.5.3.4.
9. Choose Update from the File menu.
The new configuration takes effect immediately.
8.5.3.3.3 Removing a group record
To remove a group record:
1. Click the Groups tab.
2. Choose DHCP Parameters from the drop-down list.
3. Choose the Group record you want to delete.
4. Click Delete.
Changes to the database take effect immediately.
8.5.3.4 Nodes, Subnets, Group Parameters
This section describes the subnet, group, and node parameters. The parameters
are grouped by the following categories:
•
Name and ID Parameters
•
Key Parameters
•
BOOTP Parameters
•
IP Parameters
•
Lease Parameters
•
Link Parameters
•
NetBIOS Parameters
•
Network Parameters
•
TCP Parameters
•
Time Parameters
8–40 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
•
X Window Parameters
For any parameter, list the values in order of preference.
8.5.3.4.1 Name/ID parameters Name and identification parameters determine
the name of the configuration and information that identifies which client or
clients are being configured by this record.
Name
Specifies the name for this subnet, node, or include group configuration. The
names used here are tags for the internal use of the DHCP server. You can name
them as you choose but do not use the same name more than once except where
you use a different vendor class for the duplicate names.
Group Members
Specifies the names of subnet, node, and include groups that are members of the
group (that is, those that inherit this group’s parameters).
Member of Group
Specifies the name of the group that the subnet, node, or include group is joining.
8.5.3.4.1.1 Limitations on Group Hierarchies
The hierarchies provided for with member groups do not support multiple
inheritance. An include group can have multiple members, but an include,
subnet, or node group can be a member of only one group. For example, you
can make Group_A with members Group_B and Group_C, but you can not make
Group_A a member of Group_B and Group_C.
8.5.3.4.2 Key Parameters Key parameters identify the keys for the
configuration record. The Key parameters include Hardware Address/Client
ID, Hardware Type, Net or Subnet IP Address, and Vendor Class.
Hardware Address/Client ID
This parameter specifies the hardware address (MAC address) of the node.
Enter the hardware address in the format xx:xx:xx:x:xx:xx, for example,
00:08:C7:08:E3:63. The hardware address is assigned during manufacturing
and usually is displayed when you turn on or reboot your workstation.
Hardware Type
This field takes a string of characters and specifies the network type associated
with this node, such as Ethernet or token ring.
Enter either the symbol or the actual number as shown in Table 8–6. For
example, to specify Ethernet as the hardware type, enter either the symbol
ether or the number 1.
Net or Subnet IP Address
Specifies the address of the subnet record (if its a Subnet configuration record).
Enter the IP address that identifies this subnet portion of the network, for
example, 129.84.3.0.
Vendor Class
A DHCP client can pass a vendor class string to the server to identify the client
vendor implementation. For example, TCPVMS for the TCP/IP Services DHCP
client. The DHCP server uses the vendor class string as part of the key lookup
when determining which groups of configured parameters apply to the client. The
information is a string of octets, usually ASCII, that the server interprets.
Configuring and Managing the DHCP Server 8–41
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.3.4.3 BOOTP Parameters The server version of DHCP fully supports the
following BOOTP parameters. If a BOOTP client makes a request of the server,
it acts as a BOOTP server.
Boot File
Specifies the fully qualified path name of the client’s default boot image.
Boot File Server Address
Specifies the server address of the boot file.
Boot File Server Name
Specifies the host name of the server with the boot file.
Boot File Size
Specifies the length in 512-octet blocks of the default boot image for the client.
Specify the file length as a number.
Cookie Servers
Specifies a list of RFC 865 cookie servers available to the client. Enter the servers
in order of preference.
Use this format: ddd.ddd.ddd.ddd.
DNS Domain Name
Specifies the domain name the client should use when resolving host names
through the Domain Name System.
DNS Servers
Specifies a list of DNS (STD 13, RFC 1035) name servers available to the client.
Enter the servers in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Extensions Path
Specifies a string which identifies a file, retrievable through TFTP, that contains
information that the server can interpret in the same way as the 64-octet vendorextension field in the BOOTP response. There is no limit on the length of this
file.
Home Directory
Specifies the directory where the boot file resides, if it is not specified in the boot
file name.
Also specifies the name of the client. The name can or can not be qualified with
the local domain name. See RFC 1035 for character-set restrictions.
Host IP Address (BOOTP only)
Specifies the host IP address for BOOTP clients.
Host Name
Specifies the host name parameter if you are setting up a configuration for a
single client identified by its MAC address.
Also specifies the name of the client. The local domain name can or can not
qualify the client name. See RFC 1035 for character-set restrictions.
8–42 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
IEN-116 Name Servers
Specifies a list of IEN-116 name servers available to the client. Enter the servers
in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Impress Servers
Specifies a list of Imagen Impress servers available to the client. Enter the
servers in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Log Servers
Specifies a list of MIT-LCS UDP log servers available to the client. Enter the
servers in order of preference.
Use this format: ddd.ddd.ddd.ddd.
LPR Servers
Specifies a list of RFC 1179 line-printer servers available to the client. Enter the
servers in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Merit Dump File
Specifies the path name of a file to which the client’s core image should be
dumped in the event the client fails. The path is formatted as a character string
consisting of characters from the NVT ASCII character set.
Resource Location Servers
Specifies a list of RFC 887 resource location servers available to the client. Enter
the servers in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Root Path
Specifies the path name that contains the client’s root directory or partition. The
path is formatted as a character string consisting of characters from the NVT
ASCII character set.
Routers
Specifies the list of IP addresses for routers (gateways) on the client’s subnet. If
you specify a default gateway of 0.0.0.0, the server uses the client’s IP address as
the default gateway address.
Use this format: ddd.ddd.ddd.ddd.
Subnet Mask
Specifies the client’s subnet mask as described in RFC 950.
A subnet mask allows the addition of subnetwork numbers to an address, and
provides for more complex address assignments.
If you specify both the subnet mask and the router option in a DHCP reply, the
subnet mask option must be first.
Use this format: ddd.ddd.ddd.ddd.
Configuring and Managing the DHCP Server 8–43
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Send Client’s Host Name
Specifies whether the server should send the client’s host name to the client in
the reply.
The following are valid values:
False:
Do not send the client’s host name. Default.
True:
Send the client’s host name.
Swap Server
Specifies the IP address of the client’s swap server.
Use this format: ddd.ddd.ddd.ddd.
TFTP Root Directory
Specifies the root directory for Trivial File Transfer Protocol (TFTP).
Time Offset
Specifies the offset of the client in seconds from Universal Coordinated Time
(UTC).
Time Servers
Specifies a list of RFC 868 time servers available to the client. Enter the servers
in order of preference.
Use this format: ddd.ddd.ddd.ddd.
Vendor Magic Cookie
Specifies a vendor magic cookie for the client.
8.5.3.4.4 IP parameters
on a per-host basis.
IP layer parameters affect the operation of the IP layer
Broadcast Address
Specifies the broadcast address in use on the client’s subnet.
Forward Nonlocal Datagrams
Specifies whether the client should configure its IP layer to allow forwarding of
datagrams with nonlocal source routes.
The following are valid values:
False:
Disable forwarding of datagrams with nonlocal source routes.
True:
Enable forwarding.
IP Forwarding
Specifies whether the client should configure its IP layer for packet forwarding.
The following are valid values:
False:
Disable IP forwarding.
True:
Enable IP forwarding.
IP Time-to-Live
Specifies the default time-to-live that the client should use on outgoing
datagrams. Specify time-to-live as an octet.
Minimum value
1
Maximum value
255
8–44 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Interface MTU
Specifies the maximum transmit unit (MTU) to use on this interface. Specify the
MTU as a 16-bit unsigned integer.
Minimum legal value is 68.
Maximum Reassembly Size
Specifies the maximum size datagram that the client should be prepared to
reassemble. Specify the size as a 16-bit unsigned integer.
Minimum legal value is 576.
MTU Plateaus
Specifies a table of MTU sizes to use when performing Path MTU Discovery as
defined in RFC 1191. The table is formatted as a list of 16-bit unsigned integers,
ordered from smallest to largest.
The minimum value cannot be smaller than 68.
PMTU Timeout
Specifies the timeout to use when aging Path MTU values discovered by the
mechanism defined in RFC 1191. Specify the timeout in seconds as a 32-bit
unsigned integer.
Perform Mask Discovery
Specifies whether the client should perform subnet mask discovery using the
Internet Control Message Protocol (ICMP).
The following are valid values:
False:
Client should not perform mask discovery.
True:
Client should perform mask discovery.
Perform Router Discovery
Specifies whether the client should solicit routers using the Router Discovery
mechanism defined in RFC 1256.
The following are valid values:
False:
Client should not perform router discovery.
True:
Client should perform router discovery.
Policy Filters
Specifies policy filters for nonlocal source routing. The filters consist of a list of
IP addresses and masks that specify destination/mask pairs with which to filter
incoming source routes.
The client should discard a source-routed datagram whose next-hop address does
not match one of the filters.
Use this format: ddd.ddd.ddd.ddd.
Solicit Router
Specifies the IP address to which the client should transmit router solicitation
requests.
Use this format: ddd.ddd.ddd.ddd.
Configuring and Managing the DHCP Server 8–45
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Static Routes
Specifies a list of static routes that should be installed in the client’s routing table.
If you specify multiple routes to the same destination, list them in descending
order of priority.
The routes consist of a list of IP address pairs. The first address is the destination
address, and the second address is the router for the destination.
Note
The default route (0.0.0.0) is an illegal destination for a static route.
Use this format: ddd.ddd.ddd.ddd.
Subnets Are Local
Specifies whether the client can assume that all subnets of the IP network to
which the client is connected use the same MTU (maximum transmit unit) as the
subnet of the network to which the client is directly connected.
The following are valid values:
False:
The client should assume that some subnets of the directly connected network
can have smaller MTUs.
True:
All subnets share the same MTU.
Supply Masks
Specifies whether the client should respond to subnet mask requests using the
Internet Control Message Protocol (ICMP).
The following are valid values:
False:
Client should not respond.
True:
Client should respond.
8.5.3.4.5 Lease parameters Lease parameters allow you to change information
about the IP lease times. Lease times determine the length of time a client can
use an IP address.
DHCP Rebinding Time
Specifies the time interval in seconds from address assignment until the client
requests a new lease from any server on the network.
DHCP Renewal Time
Specifies the time interval in seconds from address assignment until the client
attempts to extend the duration of its lease with the original server.
DHCP Lease Time
The client uses this option in a client request (DHCPDISCOVER or
DHCPREQUEST) message to request a lease time for the IP address.
The server uses this option in a server reply (DHCPOFFER) message to specify
the lease time it is willing to offer.
Enter the time in months, days, hours, minutes, and seconds; for example, 2
months 5 days 45 minutes. By default, the server interprets the lease in seconds.
For an infinite lease for a BOOTP client, specify a -1.
8–46 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
8.5.3.4.6 Link Parameters Link Layer parameters affect the operation of the
Link layer on a per-host basis.
ARP Cache Timeout
Specifies the timeout in seconds for ARP cache entries. The time is specified as a
32-bit unsigned integer.
Ethernet Encapsulation
If it is an Ethernet interface, use this option to specify whether the client should
use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation.
The following are valid values:
False:
Use RFC 894 encapsulation.
True:
Use RFC 1042 encapsulation.
Trailer Encapsulation
Specifies whether the client should negotiate the use of trailers (RFC 893) when
using the ARP protocol.
The following are valid values:
False:
Client should not attempt to use trailers.
True:
Client should attempt to use trailers.
8.5.3.4.7 NetBIOS Parameters NetBIOS parameters configure NetBIOS related
parameters on a per-host basis.
NetBIOS Datagram Distribution Server
Specifies a list of RFC 1001/1002 NBDD servers listed in the order of preference.
Use this format: ddd.ddd.ddd.ddd.
NetBIOS Name Server/WINS Server
Specifies a list of RFC 1001/1002 NBNS name servers listed in the order of
preference.
Use this format: ddd.ddd.ddd.ddd.
NetBIOS Node Type
Allows you to configure NetBIOS-over-TCP/IP clients as described in RFC
1001/1002. Specify the value as a single octet (from 0 to 255) that identifies
the client type as shown in Table 8–7.
Table 8–7 NetBIOS Node Type and Value
Node Type
Value (hexadecimal)
B-node
1
P-node
2
M-node
4
H-node
8
Note
The NetBIOS over TCP/IP clients must be configurable.
Configuring and Managing the DHCP Server 8–47
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
NetBIOS Scope
The NetBIOS scope option specifies the NetBIOS scope text parameter for the
client as specified in RFC 1001/1002. There can be character-set restrictions.
8.5.3.4.8 Network Parameters Network parameters allow you to change basic
network configuration information.
Finger Servers
Specifies a list of finger servers available to the client. List the servers in the
order of preference.
IRC Servers
Specifies a list of IRC (Internet Relay Chat) servers available to the client. List
the servers in the order of preference.
Mobile IP Home Agents
Specifies a list of IP addresses indicating mobile IP home agents available to the
client. List the agents in the order of preference.
NNTP Servers
Specifies a list of Network News Transfer Protocol (NNTP) servers available to
the client. List the servers in the order of preference.
NetWare Domain
Specifies the NetWare domain name.
NetWare Options
Specifies a list of NetWare servers.
POP3 Servers
Specifies a list of Post Office Protocol 3 (POP3) servers available to the client.
List the servers in the order of preference.
SMTP Servers
Specifies a list of Simple Mail Transfer Protocol (SMTP) servers available to the
client. List the servers in the order of preference.
STDA Servers
Specifies a list of StreetTalk Directory Assistance (STDA) servers available to the
client. List the servers in the order of preference.
StreetTalk Servers
Specifies a list of StreetTalk servers available to the client. List the servers in the
order of preference.
WWW Servers
Specifies a list of World Wide Web servers available to the client. List the servers
in the order of preference.
8.5.3.4.9 TCP Parameters
layer on a per-host basis.
TCP parameters affect the operation of the TCP
Keep Alive Interval
Specifies the interval that the client should wait before sending a keepalive
message on a TCP connection.
A value of 0 (zero) indicates that the client should not generate keepalive
messages on connections unless an application requests them.
8–48 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.5 Using DHCP GUI to Configure DHCP
Specify the time in seconds as a 32-bit unsigned integer.
Keep Alive Octet
This parameter specifies whether the client is to send TCP keepalive messages
with a garbage octet for compatibility with older implementations.
The following are valid values:
False:
Do not send a garbage octet.
True:
Send a garbage octet. (Sets the compatibility mode.)
TCP Default Time-to-Live
This option specifies the default time-to-live that the client uses when sending
TCP segments.
Minimum value is 1.
8.5.3.4.10 Time Parameters Time parameters allow you to change information
about network time services available to clients on the network.
Network Time Protocol (NTP) Servers
Specifies a list of RFC 1305 time servers available to the client. List the server
addresses in the order of preference.
Use this format: ddd.ddd.ddd.ddd.
8.5.3.4.11 X Window Parameters
parameters on a per-host basis.
X parameters configure X11-related
X Window Display Manager
Specifies a list of IP addresses of systems that are running the X Window System
display manager and that are available to the client.
Enter IP addresses in the order of preference.
Use this format: ddd.ddd.ddd.ddd.
X Window Font Server
Specifies a list of X Window System font servers available to the client. Enter the
server addresses in the order of preference.
Use this format: ddd.ddd.ddd.ddd.
8.6 Configuring DHCP/BOOTP IP Addressing
After you convert your existing BOOTP file to the new DHCPCAP. file as
described in Section 8.4.1, you are ready to begin serving your existing BOOTP
clients without any further changes.
This section explains how to use the GUI to configure static IP addressing for any
DHCP/BOOTP clients you add in the future, as appropriate.
Configuring static IP addressing for DHCP and BOOTP client requires different
steps described in the following sections.
Configuring and Managing the DHCP Server 8–49
Configuring and Managing the DHCP Server
8.6 Configuring DHCP/BOOTP IP Addressing
8.6.1 Static IP Addressing for BOOTP Clients
To define static IP addressing, specify a specific IP address for a specific MAC
address as follows:
1. Start the GUI by entering the following command:
$ DHCPGUI
2. Click the Nodes tab.
3. Choose [New Record].
4. Enter the host name (Name).
5. Enter the MAC/hardware address. For example, 08:00:20:3f:12:4b.
6. Choose Hardware Type from Key Parameters. Enter the type of network on
which the node resides. Enter the hardware type using the symbol or the
type number as shown in Table 8–6.
7. Choose [Host IP Address].
8. Enter the Host IP address of the host computer for this node.
9. As appropriate, enter information for Network, Lease, Time, BOOTP,
NetBIOS, X Window, TCP, IP, and Link parameters. For more information
about these parameters, refer to Section 8.5.3.4.
10. Choose Update from the File menu to update the server with the new
configuration.
8.6.2 Static IP Addressing for DHCP Clients
Select static addressing if you want to assign a specific IP address with a
permanent lease time to a DHCP client, and you do not want the client to be able
to release this IP address. Also, select static addressing if you need to select an
IP address that is not part of any IP address pool.
Selecting an IP address from outside an IP address pool allows the server to
specify a permanent mapping between a DHCP client’s MAC address and the
desired IP address. A client can reuse and release any address within an IP pool.
To configure a specific, permanent address for a DHCP client, do the following:
1. Start the GUI by entering the following command:
$ DHCPGUI
2. Click the Server/Security tab.
3. Choose Active IP Snapshot, then choose [New Record].
4. Enter the MAC address.
5. Enter the MAC type.
6. Enter the MAC address length.
7. Enter an IP address that does not belong to any IP address pools.
8. Enter -1 (infinite lease) for the lease expiration.
9. Enter the server IP address.
10. If you want a name associated with the client, specify the client’s host name
and domain name.
8–50 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.6 Configuring DHCP/BOOTP IP Addressing
If you set the Use MAC addr as Client ID parameter to True, the server uses the
MAC address to uniquely identify the clients. The MAC address field might not
be the actual MAC address of the client’s network adapter. Clients that modify
the structure of the MAC address before sending it to the server include:
•
Windows 95, Windows NT, and Windows for Workgroups 3.11 with Microsoft
TCP/IP
On these platforms, the MAC address is prefixed with the hardware type.
The MAC type is 0 and the length is 7 (instead of 6). For example, if your
Ethernet address is 11:22:33:44:55:66, you need to specify the following for
the static IP mapping:
•
–
MAC Address: 01:11:22:33:44:55:66
–
MAC Type: 0
–
MAC length: 7
FTP Software’s OnNet client
On this platform, the string "cid-" prefixes the MAC address. The MAC
type is 0 and the length is 16. For example, if your Ethernet address is
11:22:33:44:55:66, you need to specify the following for the static IP mapping:
–
MAC Address: cid-112233445566
–
MAC Type: 0
–
MAC length: 16
8.7 Configuring DHCP Manually
After you run the TCPIP$CONFIG.COM procedure and enable the DHCP server
on your system, you can manually define the following client information on a
case-by-case basis:
•
Static, dynamic, or finite addressing
•
Other identifying parameters, such as default gateways and DNS domain
names
8.7.1 Tasks Involved
Defining client addressing and additional parameters manually involves the
following steps:
1. Modify the appropriate text-based configuration files.
These files are listed in Section 8.2.2.
You manually edit the DHCP configuration files using a text editor such as
EDT, TPU, or LSE. Depending on your environment, you may or may not
need to modify all the files.
2. If appropriate, run DHCP utilities to update the binary databases.
When you are modifying information already stored in the databases, you use
command line utilities to access and update the database contents. These
utilities are defined as both OpenVMS and UNIX commands. Table 8–10 lists
the utilities.
3. Reinitialize the DHCP server for the changes to take effect (see Section 8.7.3).
Configuring and Managing the DHCP Server 8–51
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
8.7.2 Modifying the Client Configuration Parameters File
The DHCPCAP. file describes the various configuration parameters for the clients.
This file is similar to the standard bootptab file used by most BOOTP servers.
Each entry in the file can describe a single machine (per-node basis) or all the
machines within a subnet (per-subnet basis) or a group of machines (per-group
basis).
8.7.2.1 DHCPCAP Configuration Syntax
The DHCPCAP. configuration file uses two-character, case-sensitive symbols that
represent host parameters. Colons (:) follow and separate parameters from one
another. For example, gw specifies gateway. For a list of the available symbols,
see Section 8.7.2.5.
The following is the format of a configuration file entry:
entryname:symbol=value:symbol=value:symbol=value:
In this format:
•
entryname is usually the name of the BOOTP or DHCP client.
•
symbol is the two-character symbol that describes the parameters to be
associated with the client.
•
value is a valid entry that represents the symbol. For more information, see
Section 8.7.2.4.
Example 8–8 shows a sample DHCPCAP file entry.
Example 8–8 Sample Single-Host DHCPCAP File Entry
mypc:\
:ht=ether:\
:ha=112233445566:\
:ip=143.32.3.10:\
:gw=143.32.3.1:\
:dn=acme.com:
8.7.2.2 DHCPCAP Configuration Rules
When you create the DHCPCAP file, entries must conform to the following rules:
•
Start each new host entry on a new line. You can make a single entry span
multiple lines by ending each line with a backslash (\).
•
Terminate each entry name and each symbol/value pair with a colon (:). For
readability, you can leave blank spaces between symbol/value pairs.
•
Enter the entry name in the first field in the configuration file entry.
•
Make sure that the host hardware type (ht) precedes the host hardware
address (ha).
You can delete symbol values associated with a particular client by entering an at
sign (@) immediately following the symbol. For example, gw@.
Both BOOTP and DHCP interpret lines that begin with any of the following as
comments:
•
The pound sign (#)
•
One or more blank spaces followed by #
8–52 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
•
A blank line
8.7.2.3 DHCPCAP Configuration Examples
Example 8–9 shows a sample single-host DHCPCAP. file entry. This entry, mypc,
describes the configuration for a BOOTP client. It describes the client itself, its
IP address, the default gateway, and the domain name.
Example 8–9 Sample Single Host DHCPCAP Entry
mypc:\
:ht=ether:\
:ha=112233445566:\
:ip=143.32.3.10:\
:gw=143.32.3.1:\
:dn=acme.com:
Example 8–10 shows a subnet DHCPCAP. file entry. This entry, subnet5,
describes the parameters for all the clients on a particular subnet, 143.32.5.0. It
describes the default gateway, subnet mask, domain name, DNS server address,
and lease time of the address.
Example 8–10 Sample Subnet DHCPCAP Entry
subnet5:\
:nw=143.32.5.0:\
:gw=143.32.5.1:\
:sm=255.255.255.0:\
:dn=engr.acme.com:\
:ds=143.32.5.10:\
:lt=3600:
8.7.2.4 Symbol Value Formats
The symbol values require specific formats. Use only the following formats:
•
ASCII string
Enclose this string in quotation marks (‘‘string’’) if it contains any of the
special characters: colon (:), pound sign (#), tab, or space.
•
ASCII integer list
A list of integers separated by white space consisting of ASCII-format
characters that represent an unsigned hexadecimal, octal, or decimal integer.
Begin the string with 0X or 0x if this is a hexadecimal integer.
Begin the string with zero (0) if this is an octal integer.
•
IP address list
ASCII string representing an IP address in dotted-decimal notation (for
example, 128.119.95.2).
An IP address list is a string of one or more IP addresses, with the addresses
separated by spaces. For example:
tg=128.119.91.2
128.119.95.42
128.119.95.8
You can also use IP address lists to define DHCP address ranges, routing
policy filters, and static routes.
•
ASCII-format representation of a hexadecimal integer that DHCP and
BOOTP interpret as a hardware address.
Configuring and Managing the DHCP Server 8–53
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
The ASCII string must have the correct number of digits for the specified
hardware type; for example, twelve digits for a 48-bit Ethernet address. To
improve readability, you can:
Separate the two-digit sequences (bytes) with hyphens (-).
Separate the two-digit sequences (bytes) with periods (.).
Add a 0x prefix to each byte (or only some bytes) of the address.
Add a hyphen between some bytes and 0x prefixes before others.
Add a period between some bytes and 0x prefixes before others.
Examples of valid hexadecimal ASCII strings are:
ha=7F-FF-81-00-0A-47
ha=0X7F0XFF0X81000A47
ha=0X7F-FF0XF8-1000A47
•
Booleans and switches
A boolean symbol performs a function just by its presence. A switch is the
value 0 or 1, and it associates one of two functions to those values (usually,
disable and enable, respectively).
:hn:\
:ms=1:\
#This is an example of a boolean type field
#This is an example of a switch type field
8.7.2.5 DHCP Configuration Symbols
Table 8–8 describes each DHCP configuration file symbol and indicates whether
you use the symbol in DHCP configuration only or in BOOTP and DHCP
configuration.
Table 8–8 BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
as
Maximum
datagram
reassembly size
ASCII integer
Specifies the maximum size
datagram that the client should
be prepared to reassemble. The
minimum value is 576.
at
ARP cache timeout
ASCII integer
Specifies the timeout (in seconds) for
ARP cache entries.
ba
Broadcast address
IP address
Specifies the broadcast address in
use on the client’s subnet.
bf
Boot file
ASCII string
Specifies the fully qualified path
name of the client’s default boot
image.
br
IP forwarding
Boolean
Specifies whether the client should
configure its IP layer for packet
forwarding. A value of 0 means
disable IP forwarding, and a value of
1 means enable IP forwarding.
bs
Boot file size
ASCII integer or
auto
Specifies the length in 512-octet
blocks of the default boot image for
the client.
(continued on next page)
8–54 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
bw
NetBIOS name
servers
IP address list
Specifies a list of RFC 1001/1002
NBNS name servers listed in order of
preference.
bx
NetBIOS over
TCP/IP datagram
distribution server
IP address list
Specifies a list of RFC 1001/1002
NBDD servers listed in order of
preference.
by
NetBIOS over
TCP/IP node type
ASCII integer
Specifies whether clients can be
configured as described in RFC 1001
and 1002. The NetBIOS node type
option allows NetBIOS over TCP/IP
configurable clients to be configured
as described in RFC 1001 and 1002.
Specify the value as a single octet
(from 0 to 255) that identifies the
client type.
bz
NetBIOS over
TCP/IP scope
ASCII string
Specifies the NetBIOS over TCP/IP
scope text parameter for the client as
specified in RFC 1001/1002. There
can be character-set restrictions.
ck
Client identifier
Opaque
cs
Cookie server
address list
IP address list
Specifies a list of RFC 865 cookie
servers available to the client. Enter
servers in order of preference.
ct
Vendor class
String
Specifies the vendor type and
configuration of a DHCP client. The
information is a string of n octets,
interpreted by servers. Vendors
may choose to define specific vendor
class identifiers to convey particular
configuration or other identification
information about a client. For
example, the identifier may encode
the client’s hardware configuration.
Servers not equipped to interpret the
class-specific information sent by a
client must ignore it (although it may
be reported).
da
STDA servers
IP address list
Specifies a list of StreetTalk
Directory Assistance (STDA)
servers available to the client.
Servers should be listed in order
of preference.
df
Merit dump file
ASCII string
Specifies the path name of a file
to which the client’s core image
should be dumped in the event the
client fails. The path is formatted
as a character string consisting of
characters from the NVT ASCII
character set.
dn
DNS domain name
ASCII String
Specifies the domain name that the
client should use when resolving host
names via the Domain Name System.
(continued on next page)
Configuring and Managing the DHCP Server 8–55
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
ds
DNS servers
IP address list
Specifies a list of Domain Name
System (RFC 1035) name servers
available to the client. Enter servers
in order of preference.
ec
Ethernet
encapsulation
0 or 1
Specifies whether the client should
use Ethernet Version 2 (RFC
894) or IEEE 802.3 (RFC 1042)
encapsulation if the interface is an
Ethernet. The switch values are:
•
0 - Use RFC 894 encapsulation
•
1 - Use RFC 1042 encapsulation
ef
Extensions path
ASCII string
Specifies a file, retrievable through
TFTP, that contains information that
can be interpreted in the same way
as the 64-octet vendor-extension field
in the BOOTP response. The length
of the file is unconstrained.
fi
Finger servers
IP address list
Specifies a list of finger servers
available to the client. Servers
should be listed in order of
preference.
fn
Forward nonlocal
datagarams
0 or 1
Specifies whether the client should
configure its IP layer to allow
forwarding of datagrams with
nonlocal source routes.
gw
Gateway address
list
IP address list
Specifies a list of the IP addresses
of gateways for the specified subnet.
This list consists of the default
routes.
ha
Client’s hardware
address
ASCII string
Specifies whether host names can be
assigned by the hardware address. If
so specified, the client host, provided
it remains in the same domain,
retains the same name, even if its IP
address changes.
hn
Host name
Boolean
Specifies that the DHCP server
should write the client’s host name
to the vend field of the DHCP reply
packet and send the packet to the
client. Can appear only in the format
hn: or hn@:.
ho
Host name
ASCII string
Specifies the name of the client. The
name may or may not be qualified
with the local domain name.
ht
Client’s hardware
type
ASCII string or
ASCII integer
Specifies the hardware type code as
assigned in the ARP section of RFC
1340, Assigned Numbers.
(continued on next page)
8–56 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
hr
Forwarding
enable/disable
0 or 1
Specifies whether the client should
configure its IP layer for packet
forwarding. The values are:
•
0 - Disable
•
1 - Enable
im
Impress server
address list
IP address list
Specifies a list of Imagen Impress
servers available to the client. Enter
servers in order of preference.
ip
Client IP address
IP address
Specifies the IP address of the
BOOTP client or a single IP address
to assign the DHCP client.
it
IP time to live
ASCII string
Specifies the default time to live that
the client should use on outgoing
datagrams.
ki
TCP keepalive
interval
ASCII integer
Specifies the interval (in seconds)
that the client TCP should wait
before sending a keepalive message
on a TCP.
ko
TCP keepalive
garbage
0 or 1
Specifies whether the client should
send TCP keepalive messages with
an octet of garbage for compatibility
with older implementations.
lg
Log server
IP address list
Specifies a list of MIT-LCS UDP log
servers available to the client. Enter
servers in order of preference.
lp
LPR server address
list
IP address list
Specifies a list of RFC 1179 line
printer servers available to the client.
Enter servers in order of preference.
lt
Lease time
ASCII integer
Specifies in a client request, that a
client is allowed to request a lease
time for the IP address. In a server
reply, specifies the lease time the
server is willing to offer. Enter the
time in seconds.
md
Perform mask
discovery
0 or 1
Specifies whether the client should
perform subnet mask discovery using
ICMP.
mm
Maximum DHCP
message size
Integer
Specifies the maximum length
DHCP message that it is willing to
accept. The length is specified as an
unsigned 16-bit integer. A client may
use the maximum DHCP message
size option in DHCPDISCOVER
or DHCPREQUEST messages,
but should not use the option in
DHCPDECLINE messages.
ms
Mask supplier
0 or 1
Specifies whether the client should
respond to subnet mask requests
using ICMP.
(continued on next page)
Configuring and Managing the DHCP Server 8–57
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
Specifies the NNTP server.
nn
NNTP
IP address list
no
NetWare options
Opaque
ns
IEN-116 name
server address list
IP address list
Specifies a list of IEN 116 name
servers available to the client. Enter
servers in order of preference.
nt
NTP servers
IP address list
Specifies a list of NNTP (Network
Time Protocol) servers.
ov
Overload file/sname
Integer
Specifies that the DHCP sname or
file fields are being overloaded by
using them to carry DHCP options.
A DHCP server inserts this option if
the returned parameters will exceed
the usual space allotted for options.
pf
Policy filter
IP address list
Specifies policy filters for nonlocal
source routing. The filters consist
of a list of IP addresses and masks
that specify destination/mask pairs
with which to filter incoming source
routes.
pl
Path MTU plateau
table
ASCII integer
list
Specifies a table of MTU sizes to
use when performing Path MTU
Discovery as defined in RFC 1191.
The minimum value is 68.
pt
Path MTU aging
timeout
Integer
Specifies the timeout (in seconds) to
use when aging Path MTU values are
discovered by the mechanism defined
in RFC 1191 [12]. The timeout is
specified as a 32-bit unsigned integer.
rd
Perform router
discovery
0 or 1
Specifies whether the client should
solicit routers using the Router
Discovery mechanism defined in RFC
1256.
rl
Resource location
protocol server
address list
IP address list
Specifies a list of RFC 887 Resource
Location servers available to the
client. Servers should be listed in
order of preference.
rp
Root path
ASCII string
Specifies the path name that contains
the client’s root directory or partition.
The path is formatted as a character
string consisting of characters from
the NVT ASCII character set.
rs
Router solicitation
address
IP address
Specifies the address to which
the client should transmit router
solicitation requests.
sa
Boot server address
IP address
Specifies the IP address of the TFTP
server the client uses.
(continued on next page)
8–58 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
sl
All subnets are
local
0 or 1
Specifies whether the client can
assume that all subnets of the
IP network to which the client is
connected use the same MTU as the
subnet of that network to which the
client is directly connected.
sn
Boot file server
name
ASCII string
Specifies the host name of the bootfile
server.
sm
Subnet mask
IP address
Specifies the client’s subnet mask as
per RFC 950. A subnet mask allows
the addition of subnetwork numbers
to an address and provides more
complex address assignments. If
both the subnet mask and the router
option are specified in a DHCP reply,
the subnet mask option must be first.
sp
SMTP servers
IP address list
Specifies a list of SMTP (Simple Mail
Transport Protocol) servers available
to the client. Servers should be listed
in order of preference.
sr
Static route
IP address list
Specifies a list of static routes that
the client should install in its routing
cache. If multiple routes to the same
destination are specified, they are
listed in descending order of priority.
The routes consist of a list of IP
address pairs. The first address is
the destination address, and the
second address is the router for the
destination.
st
StreetTalk servers
IP address list
Specifies a list of StreetTalk
servers available to the client.
Servers should be listed in order
of preference.
sw
Swap server
IP address
Specifies the IP address of the client’s
swap server.
sv
Server IP
IP address
Specifies the server ID in a
DHCOFFER and DHCPREQUEST
message and optionally in a
DHCPACK and DHCPNAK
messages. DHCP servers include
this option in the DHCPOFFER
in order to allow the client to
distinguish between lease offers.
DHCP clients use the contents of
the ‘‘server identifier’’ field as the
destination address for any DHCP
messages unicast to the DHCP
server. DHCP clients also indicate
which of several lease offers is being
accepted by including this option in a
DHCPREQUEST message.
(continued on next page)
Configuring and Managing the DHCP Server 8–59
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
t1
DHCP renewal
time
Integer
Specifies the time interval (in
seconds) from address assignment
until the client transitions to the
RENEWING state. The value is
specified as a 32-bit unsigned integer.
t2
DHCP rebinding
time
Integer
Specifies the time interval (in
seconds) from address assignment
until the client transitions to the
REBINDING state. The value is
specified as a 32-bit unsigned integer.
to
Time offset
ASCII integer or
auto
Specifies (in seconds) the offset of
the client’s subnet in seconds from
Coordinated Universal Time (UTC).
The offset is expressed as a twos
complement 32-bit integer. A positive
offset indicates a location east of the
zero meridian and a negative offset
indicates a location west of the zero
meridian.
tr
Trailer
encapsulation
0 or 1
Specifies whether the client should
negotiate the use of trailers (RFC
893) when using the ARP protocol.
tu
Interface MTU
ASCII integer
Specifies the MTU to use on this
interface.
ts
Time server
address list
IP address list
Specifies a list of RFC 868 time
servers available to the client.
Servers should be listed in order
of preference.
tt
TCP default TTL
ASCII integer
Specifies the default time to live that
the client should use when sending
TCP segments.
uc
User class
ASCII string
Specifies the type or category of user
or application the client represents.
This option is used by a DHCP
client to optionally identify the type
or category of user or application
it represents. The format of this
option is an NVT ASCII text object
of varying length which represents a
user class of which the client host is
a member.
DHCP administrators may define
specific user class identifiers to
convey information about a host’s
software configuration or about its
user’s preferences. For example,
an identifier may specify that a
particular DHCP client is a member
of the class ‘‘accounting auditors’’,
which have special service needs
such as a particular database server.
(continued on next page)
8–60 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–8 (Cont.) BOOTP/DHCP Configuration File Symbols
Symbol
Function
Value Format
Description
vm
Vendor’s magic
cookie selector
ASCII string
Specifies a vendor magic cookie for
the client.
xd
X Window System
display manager
IP address list
Specifies a list of IP addresses of
systems that are running the X
Window System display manager
that are available to the client. Enter
addresses in order of preference.
xf
X Window System
font server
IP address list
Specifies a list of X Window System
font servers available to the
client. Enter addresses in order
of preference.
yd
NIS domain name
ASCII string
Specifies the name of the client’s NIS
domain. The domain is formatted
as a character string consisting of
characters from the NVT ASCII
character set.
ys
NIS servers
IP address list
Specifies a list of IP addresses
indicating NIS servers available
to the client. Servers should be listed
in order of preference.
zd
NIS+ domain name
ASCII string
Specifies the name of the client’s
NIS+ domain. The domain is
formatted as a character string
consisting of characters from the
NVT ASCII character set.
zs
NIS+ server
IP address list
Specifies a list of IP addresses
indicating NIS+ servers available
to the client. Servers should be listed
in order of preference.
Table 8–9 Vendor Specific Options
Symbol
Function
Value Format
For Join DHCP clients:
cb
Client binary
ASCII string
mf
NFS mounted file
systems
ASCII string list
pr
Printers
ASCII string list
ps
SVR4 printer setup
ASCII string list
ss
Name service
switch
ASCII string
(continued on next page)
Configuring and Managing the DHCP Server 8–61
Configuring and Managing the DHCP Server
8.7 Configuring DHCP Manually
Table 8–9 (Cont.) Vendor Specific Options
Symbol
Function
Value Format
For OpenVMS DHCP clients:
sd
SMTP substitute
domain
ASCII string
sg
SMTP gateway
ASCII string
sn
SMTP substitute
domain not local
Boolean
sz
SMTP zone
ASCII string
For SUN DHCP clients:
aa
Sun Vendor Option
#2
IP address list
8.7.3 Reinitializing the DHCP Server
Once you have made changes to the configuration files, you must force the server
to read them again by sending it an HUP signal (see Section 8.3.1). Enter the
following command:
$ DHCPSIGHUP
8.8 Supporting Utilities
The commands you use to modify and look at the contents of the DHCP databases
are described in Table 8–10. TCP/IP Services supplies UNIX type commands for
users familiar with the JOIN implementation of a DHCP server.
8–62 Configuring and Managing the DHCP Server
Configuring and Managing the DHCP Server
8.8 Supporting Utilities
Table 8–10 DHCP Utility Commands Associated with Databases
OpenVMS
Command
UNIX
Command
Active IP
Snapshot
Add/Delete
DHCPDBMOD
jdbmod
Modifies lease and naming
information in the database. Allows
you to preassign static IP addresses
to clients. Also allows you to create,
delete, or modify existing entries.
Preload MAC
Addresses
DHCPDBREG
jdbreg
Populates the database with MAC
addresses of known clients. Each
record to be loaded is terminated by
a new line, and the fields within each
record are separated by the vertical
bar ( | ) character.
DHCPDBDUMP
jdbdump
Reads and outputs information
stored in the lease database files
including MAC address information,
IP addresses, and lease information.
Each line of output describes the
lease information for one client.
DHCPSHOWDBS
SHOWDBS
Reads the same information
described for DHCPDBDUMP, except
that the output is in a format that is
easier to read.
DHCPDBSHOW
DBSHOW
Displays the contents of a single
DHCP binary database.
DHCP GUI
Active IP
Snapshot
Description
For information about how to enter the DHCP utility commands, see Sections
8.8.1 through 8.8.3.
8.8.1 DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW Utilities
The DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW commands dump the information
stored in the lease database files. The dumped lease information includes:
•
MAC address
•
MAC address type
•
MAC address length (octets)
•
IP address
•
Start of lease (UTC)
•
Lease expiration (UTC)
•
Time when lease can be extended (UTC)
•
Time when host last renewed or acquired this lease (UTC)
•
IP address of server owning the lease
•
Host name (without domain)
•
Domain name
Configuring and Managing the DHCP Server 8–63
Configuring and Managing the DHCP Server
8.8 Supporting Utilities
Each line of output describes the lease information for one client. The output is
in a format that is used by the DHCPDBMOD utility to modify the lease database.
Note
The DHCPBDUMP, DHCPSHOWDBS, and DHCPDBSHOW commands perform read
operations on the database, while DHCPDBMOD performs write operations.
The DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW commands accept a number of
different flags and arguments. Table 8–11 lists some of the more important
flags.
Table 8–11 DHCPDBDUMP, DHCPSHOWDBS, and DHCPDBSHOW Command
Flags
Flag
Description
-a
-c
-e
Dumps dates in readable format.
Dumps currently active leases only.
Dumps expired leases only.
The following examples show typical output from the DHCPSHOWDBS, DHCPDBSHOW,
and DHCPDBDUMP commands:
$ DHCPSHOWDBS
IP address
Owner
ified
client id
10.10.2.100
10.10.2.6
0 01:08:00:2b:e5:2c:44
Expires
Granted on
Last mod
01/28/2000 13:50
01/28/2000 13:30
01/28/2000 13:30
10.10.2.101
10.10.2.6
0 01:08:00:2b:bf:7d:bb
01/28/2000 13:52
01/28/2000 13:32
01/28/2000 13:32
10.10.4.100
10.10.2.5
0 01:08:00:2b:e5:2c:44
01/21/2000 09:27
01/21/2000 09:07
01/21/2000 09:07
IP address
10.10.2.101
10.10.2.100
Name
gody.HP.com.
sarek12.HP.com.
$ DHCPDBSHOW a
IP address
owner
st modified
network
10.10.2.101
10.10.2.6
/14/2000 10:58:10 10.10.2.0
10.10.2.103
10.10.2.6
/14/2000 10:48:21 10.10.2.0
10.10.2.100
10.10.2.6
/14/2000 10:54:23 10.10.2.0
10.10.4.100
10.10.2.5
/21/2000 09:07:26 10.10.4.0
10.10.2.104
10.10.2.6
/14/2000 10:49:33 10.10.2.0
expires
granted on
client id
02/14/2000 11:18:10 02/14/2000
0,7,01:08:00:2b:e5:2c:44
02/14/2000 11:08:21 02/14/2000
1,6,08:00:2b:2a:de:1e
02/14/2000 11:14:23 02/14/2000
0,7,01:08:00:2b:bf:7d:bb
01/21/2000 09:27:26 01/21/2000
0,7,01:08:00:2b:e5:2c:44
02/14/2000 11:09:33 02/14/2000
1,6,08:00:2b:2a:de:a8
Record count = 5
8–64 Configuring and Managing the DHCP Server
la
10:58:10
02
10:48:21
02
10:54:23
02
09:07:26
01
10:49:33
02
Configuring and Managing the DHCP Server
8.8 Supporting Utilities
$ DHCPDBDUMP
01:08:00:2b:e5:2c:44|0|7|10.10.2.100|949084208|949085408|949084808|949084208|
10.10.2.6|sarek12|HP.com|
01:08:00:2b:bf:7d:bb|0|7|10.10.2.101|949084349|949085549|949084949|949084349|
10.10.2.6|gody|HP.com|
01:08:00:2b:e5:2c:44|0|7|10.10.4.100|948463
8.8.2 DHCPDBMOD Utility
The DHCPDBMOD command modifies the lease and naming information in the
database files. It allows the user to create, delete, or modify existing database
entries and to preassign static IP address to clients.
The utility takes input from a file that describes various entries in the database.
The syntax of each entry is similar to the output of DHCPDBDUMP.
Use the following format:
•
Terminate each record to be loaded by a new line.
•
Delimit the fields within each record with the vertical bar ( | ) character.
•
Express date fields in one of the following ways:
–
Coordinated Universal Time (UTC), the number of seconds since 00:00
01/01/1970 GMT
–
A format more easily understood, such as Mon Jan 09 1995 10:00 or
01/09/1995 10:00:00
Example 8–11 shows a sample entry. The first entry describes the client called
alpha.acme.com with the IP address 143.32.3.20.
The second entry describes a Microsoft DHCP client with the IP address
143.32.3.21. No name is given for this client.
Example 8–11 Sample DHCPDBMOD Entry
$ DHCPDBMOD
00:a0:24:8c:6b:09!|1"|6#|143.32.3.20$|844989457%|844989466&|844989466’|844989466(
|143.32.3.1)|alpha+>|acme.com+?|
01:00:40:05:14:df:11|0|7|143.32.3.21|844989457|844989466|844989466|844989466
|143.32.3.1|||
Although some fields can be empty, each entry consists of the following fields:
! MAC address
" MAC address type
# MAC address length (octets)
$ IP address
% Start of lease (UTC)
& Lease expiration (UTC)—use -1 to indicate an infinite lease
’ Time when lease can be extended (UTC)
( Time when host last renewed or acquired this lease (UTC)
Configuring and Managing the DHCP Server 8–65
Configuring and Managing the DHCP Server
8.8 Supporting Utilities
) IP address of server owning the lease
+> Host name (without domain)
+? Domain name
The DHCPDBMOD command accepts a number of different flags and arguments.
Table 8–12 shows some of the more important flags.
Table 8–12 DHCPDBMOD Command Flags
Flag
Description
-d
-e
-l
-n
-w
Deletes the record.
Stores the record even if the lease has expired.
Stores the lease information only. Does not store name information.
Stores the name information only. Does not store lease information.
Overwrites the record if a record already exists.
By default, DHCPDBMOD stores both lease and name information for nonexpired and
new clients.
8.8.3 DHCPDBREG Utility
Use the DHCPDBREG command to populate the database with the MAC address of
known MAC clients. Set the SERVER.PCY parameter Restrict to Known MAC
Address to True to use this utility. The DHCPDBREG command can add or remove
hosts from the list of known MAC addresses. Use the following syntax when you
enter a record:
•
Terminate each record to be loaded by a new line.
•
Delimit the fields within each record with the vertical bar ( | ) character.
Each entry contains the following three fields:
•
MAC address
•
MAC address type
•
MAC address length (octets)
The DHCPDBREG command accepts a number of different flags. Two of the most
important flags are as follows:
Flags
Description
-d
Deletes the record.
-s
Displays all registered MAC addresses.
8.9 Solving DHCP Server Problems
If the DHCP log file contains the message: ‘‘network not administered by server’’
and you use class A, B, or C IP addressing, check the NETMASKS. file to see that
you have entered the netmask correctly for the subnet.
8–66 Configuring and Managing the DHCP Server
9
Configuring and Managing the DHCP Client
DHCP client is the TCP/IP Services component which allows a system to request
network configuration information from a DHCP server and then use that
information to configure one or more of its network interfaces.
TCP/IP Services DHCP client is an OpenVMS implementation of the Tru64 UNIX
client.
This chapter reviews key concepts and describes the following topics:
•
DHCP client components (Section 9.2)
•
DHCP client startup and shutdown (Section 9.3)
•
Configuring the DHCP client (Section 9.4)
•
TCP/IP management commands (Section 9.5)
•
Using the SHOWDHC utility (Section 9.6)
9.1 Key Concepts
When a system connects to a network, in addition to the appropriate network
software, it must have configuration information that identifies the system
in network communications. As a minimum, it must have an IP address, a
broadcast address, and a subnet mask configured before any communication with
other systems can take place. This information can be statically configured, that
is, permanently stored in a local database and used every time the network is
initialized. Or it can be dynamically configured by obtaining the information from
a DHCP server during network initialization. The DHCP server maintains the
configuration information, and upon a client request for such information, returns
the configuration for that particular host through a client and server dialog using
the DHCP protocol.
A system can have more than one network interface installed and you can use
DHCP client to dynamically configure all or a subset of the installed interfaces.
There is one DHCP client process running on a system and it configures all
interfaces that are designated as under DHCP control.
In an OpenVMS Cluster, you can use DHCP client to configure one of the systems,
a mix of systems or all systems in the cluster. Each system in the cluster using
DHCP to configure its interfaces, must run DHCP client.
Note
If a system is running DHCP client, it can not also run a DHCP server.
Configuring and Managing the DHCP Client 9–1
Configuring and Managing the DHCP Client
9.1 Key Concepts
9.1.1 Designating the Primary Interface
Some of the parameters that are configurable by DHCP are interface specific.
Examples of interface-specific parameters are the IP address and subnet mask.
Most DHCP configurable parameters, however, are systemwide configurable
parameters. Examples of systemwide parameters are the host name and DNS
domain name.
The TCP/IP Services DHCP client supports controlled configuration of systemwide
configurable items by designation of what is called the primary interface. The
primary interface is the interface on which the DHCP client will use systemwide
parameters received from the DHCP server to configure the system. Systemwide
parameters received on an interface that is not designated primary will not be
configured on your system by the DHCP client. There may be only one interface
on a system that is designated as the primary DHCP interface, but you are not
required to have any interface designated as the primary interface.
For example, if a system has multiple interfaces under DHCP control and the
system receives a different host name from a DHCP server on each of the DHCP
controlled interfaces, DHCP client uses the host name it receives on the primary
interface to configure the host name for the client.
If a system has multiple interfaces and only one is under DHCP control, you can
configure the systemwide parameters manually.
DHCP client uses the following rules to resolve conflicts:
•
The only-one-primary-interface rule
This rule solves the potential conflict between two DHCP controlled interfaces
on a host getting different systemwide parameter values. To resolve the
conflict, you designate one interface to be the primary interface and
the parameters values that you receive on that interface are the values
DHCP client uses to configure the system. TCP/IP Services does not let you
designate two primary interfaces.
•
The primary-interface-not-required rule
This rule solves the problem of DHCP configuring an interface (or interfaces)
with an IP address but also keeping manual control of the systemwide
parameters. In this case, DHCP client does not designate the interface as the
primary interface and ignores any systemwide parameters it receives from a
DHCP server.
Systemwide parameters are configured for a system as the last part of processing
the final message (a DHCPACK protocol message) from the DHCP server. DHCP
client, first configures the interface’s IP address, subnet mask, and broadcast
address; then, if the interface is designated as the primary interface, DHCP client
configures the systemwide parameters.
See Table 9–2 for a list of the DHCP configurable parameters supported by the
TCP/IP Services DHCP client.
9–2 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.1 Key Concepts
9.1.2 Requesting a Lease
A DHCP server allocates IP addresses to clients on a temporary or permanent
basis. This time period is called a lease. A client can request a lease for some
period of time, which the DHCP server can either honor or assign a different
time period depending on the policy in force. A client may request a lease for an
infinite period of time, but the server may choose to give out a lengthy but not
infinite lease. For whatever time period the DHCP server assigns, the DHCP
server guarantees not to reassign the IP address to any other system until the
lease expires.
Lease times are represented in DHCP dialogs as relative time to be interpreted
with respect to the client’s clock. If there is drift between the client’s clock and
the server’s clock, the server may consider the lease expired before the client
does. To compensate, the server may return a shorter lease duration to the client
than the server commits to its local database of client information.
9.1.3 Requesting Parameters
The first service provided by a DHCP server is to provide storage of network
parameters for network clients. DHCP clients can query the DHCP server to
retrieve the configuration parameters. In its initial discover or request message,
a client can supply a list of parameters for which it needs information. If the
server does not return any or all of the values for the requested parameters, the
client uses default values for any missing values.
9.1.4 Understanding How the DHCP Client Operates
When your system has an interface configured under DHCP control, the following
sequence of steps occur at TCP/IP Services startup time:
1. The TCPIP$STARTUP procedure installs the DHCP client image,
TCPIP$DHCP_CLIENT.EXE, with the appropriate OpenVMS system
privileges.
2. Then it issues the following command to start the interface:
$ TCPIP START COMMUNICATION/INITIALIZE
This command creates a subprocess and runs the DHCPCONF utility as
follows to set up the interface:
DHCPCONF -W 30 ifname START
Alternatively, the command procedure issues the following command if the
interface is the primary interface:
DHCPCONF -P -W 30 ifname START
The -w 30 option on the DHCPCONF command line tells DHCPCONF to
wait for a maximum of 30 seconds before returning. This wait prevents
the TCPIP$STARTUP procedure from hanging indefinitely when there are
problems reaching a DHCP server. If the 30-second timer expires, the DHCP
client process will, by default, continue to complete the DHCP dialog until it
is successful or it is shut down.
Configuring and Managing the DHCP Client 9–3
Configuring and Managing the DHCP Client
9.1 Key Concepts
3. DHCPCONF creates the DHCP client process.
If this is the first interface to be configured during the startup procedure,
DHCPCONF creates a detached process and runs the TCPIP$DHCP_
CLIENT_RUN.COM command procedure. TCPIP$DHCP_CLIENT_RUN
invokes the DHCP client image, TCPIP$DHCP_CLIENT.EXE. TCPIP$DHCP_
CLIENT continues to run until it is manually shutdown or the system
is shutdown. Therefore, if more than one interface is to be configured,
TCPIP$DHCP_CLIENT is ready to accept another DHCPCONF start
command.
4. DHCP client accepts the DHCPCONF start command.
DHCP client reads the start command and begins the DHCP dialog with the
server. DHCPCONF and the DHCP client use a simple UDP-based protocol to
communicate. If a HOSTNAME. file exists, the suggested host name is sent
to the server.
5. The DHCP client/server DHCP dialog completes.
DHCP client engages in a dialog with the DHCP server and when it completes
the DHCP client sets the interface’s IP address, subnet mask and broadcast
address by sending the information via an ioctl to the TCP/IP kernel. If
the interface is designated as the primary interface then any system-wide
parameters received from the DHCP server are configured into the system.
6. DHCP client saves all parameters received from the DHCP server in a file
(interface.DHC). This step occurs even if the interface is not designated as the
primary interface.
7. DHCP client sends a task completion message to DHCPCONF to indicate that
the interface is initialized and ready for work.
8. The START COMMUNICATION/INITIALIZE command then repeats this
process for the next interface configured to be under DHCP control.
9.2 DHCP Client Components
The section describes the software and system elements that comprise DHCP
client including:
•
Executable files
•
Configuration files
•
Command files
•
System logical names
•
Log files
9.2.1 Executable Files
Three programs comprise the DHCP client component:
•
TCPIP$DHCP_CLIENT.EXE
This is the executable file for the DHCP agent or daemon. This process
engages in the DHCP protocol dialog with the DHCP server, receives the
parameters from the server and then configures the parameters on the local
system. The parameters include IP addresses and their lease information,
among others.
9–4 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
There is one DHCP client process per system, even for multihomed hosts.
The DHCP client process is always running on a system that has an interface
designated under DHCP control. The DHCP client uses the OpenVMS
lock manager to prevent multiple DHCP client processes from executing
concurrently on a system. The resource name used to control the number of
client processes is TCPIP$DHCP_CLIENT_scsnode.
You stop this process by invoking the TCPIP$DHCP_CLIENT_SHUTDOWN
command procedure or by sending a DHCPSIGTERM to the process
using the TCPIP$DHCP_SIGNAL utility. Do not use the DCL command
STOP/IDENTIFICATION to stop this process.
To ensure proper termination of the DHCP client process, HP recommends
that you run the TCPIP$SHUTDOWN.COM procedure from your site-specific
shutdown procedure.
When a DHCP client process is not already executing, and you or the system
issues a DHCPCONF command, the system will automatically run the
DHCP client process. The TCP/IP command SET INTERFACE/DHCP and
the TCP/IP command START COMMUNICATION/INITIALIZE both invoke
DHCPCONF to start the DHCP client. Running TCPIP$DHCP_CLIENT_
STARTUP.COM will not itself create a DHCP client process.
•
TCPIP$DHCP_CLIENT_CONF.EXE
This is the executable file for the DHCPCONF command, which is the UNIX
interface to the DHCP client. It communicates with the DHCP client process
to start the client, release a lease, drop the interface from control and other
requests.
Most users do not need to execute a DHCPCONF command directly. The
TCP/IP command SET INTERFACE/DHCP issues the necessary DHCPCONF
commands.
•
TCPIP$DHCP_CLIENT_SHOWDHC.EXE
This is the executable file for the SHOWDHC command. This command
displays the data stored in an interface’s parameter file (interface.DHC).
Refer to Section 9.6 for a description of the commands supported by this
program.
9.2.2 Configuration Files
DHCP client uses the following files to control its environment:
•
Configuration
•
Interface
•
Host name
•
DHCPTAGS
9.2.2.1 Client Configuration File
DHCP client has one configuration file that controls DHCP client behavior. This
optional file, named CLIENT.PCY, is an ASCII file located in the DHCP home
directory, which is either SYS$SYSDEVICE:[TCPIP$DHCP] or a directory pointed
to by the system logical TCPIP$DHCP_CONFIG. If CLIENT.PCY does not exist,
DHCP client uses default values for each of the configurable parameters.
Configuring and Managing the DHCP Client 9–5
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
Example 9–1 Client Startup File
#
#
#
#
#
#
#
File name:
Product:
Version:
CLIENT.PCY
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
class_id TCPVMS
request routers
request host_name
request dns_servers
request dns_domain_name
Example 9–1 shows the contents of a typical CLIENT.PCY file.
The format of the configuration file must adhere to the following rules:
•
Blank lines are ignored.
•
The pound (#) character introduces a comment that continues to the next
newline character.
•
Each new policy option must begin and end on a separate line.
•
Policy options are introduced by a keyword and may be Boolean, or they may
take a value separated from the keyword by white space (but not a newline
character).
•
If an option is present more than once, only the value attached to the last
occurrence will be take effect; earlier values are ignored.
Table 9–1 describes the configuration keywords.
Table 9–1 Configuration Keywords
Keyword
Description
class_id
Specifies the client’s class identification. Consult RFC
2131 for details. The only class supported by TCP/IP
Services is TCPVMS.
lease_desired seconds
Specifies that a client may request a lease of a
particular duration, although DHCP servers are not
bound to honor the request. If the client does not want
a lease of a particular duration, seconds should be set
to 0. If an infinite lease is required, set seconds to
-1. Otherwise, specify (in seconds) the lease duration
required. The default value is 0 seconds. A DHCP
server grants a client permission to use an IP address
for a fixed period of time, which may be infinite. In
the language of DHCP, the client is granted a lease on
the IP address.
(continued on next page)
9–6 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
Table 9–1 (Cont.) Configuration Keywords
Keyword
Description
retries
Specifies the maximum number of DHCPDISCOVER,
DHCPOFFER, DHCP_REQUEST, DHCPNAK
sequences the client attempts. An offer received
and then refused is an unusual event; if it occurs more
than once, this indicates a problem with the server.
If you do not want to limit the number of bad offers
that a client is willing to accept, set the value of this
parameter to 0 (zero) or a negative value. The default
value is 2 attempts.
start_delay seconds
Specifies the maximum time (in seconds) the client
delays before broadcasting DHCP packets. When the
DHCP client is invoked to configure an interface it
will delay for a short time before broadcasting the
first DHCP packet. The delay time is randomized
from a value of 0 up to the value specified by seconds.
The TCP/IP commands SET INTERFACE/DHCP
and the START COMMUNICATION/INITIALZE
command (executed at product startup time) both
execute dhcpconf start commands and experience the
randomized delay. The default value for seconds is 10
seconds.
timeouts
value,value,value....
Specifies how long the client should wait for replies
before timing out and retrying the broadcast.
The DHCP protocol requires clients to implement
an exponential retransmission and backoff when
broadcasting discover or request packets.
Each time the client sends a DHCP protocol packet,
it waits for a response until a timeout occurs after an
interval (in seconds) given by a member of the list of
values. If a timeout occurs, the packet retransmits
with the same XID (see RFC 1541), and the timeout is
set to the next positive value in the comma-separated
list. The last element in the list is negative or 0 (zero).
At this point, the next action depends on options to
the DHCPCONF program. One option is to fail. Another
option is to retry forever. If the last value in the
list is negative, DHCP suspends configuration of the
interface for an amount of time given by the negative
number terminating the list of values. During this
time, the interface is considered idle—the client is not
expecting responses destined for the interface and will
ignore any that arrive. When the idle time is over,
the client begins retransmitting with a new XID, and
a timeout value is given by the first element in the
array of values. If the last value is 0 (zero), the client
continues to use the same XID and timeout of the last
positive value in the list of values. The default list of
values is 4, 8, 16, 32, 0.
(continued on next page)
Configuring and Managing the DHCP Client 9–7
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
Table 9–1 (Cont.) Configuration Keywords
Keyword
Description
use_saved_config
Specifies to use the configuration stored in
ifname.DHC from a previous invocation of the protocol
if the following conditions exist:
request parameter_name
•
The lease is still valid.
•
There is no reply to DHCP.
•
use_saved_config is set.
Specifies the parameter to request from the DHCP
server. There may be many instances of the request
keyword, each with a different parameter_name.
Each parameter which is configurable through DHCP
is identified by a unique parameter. Limited size of
DHCP packets dictates that a client should not request
data which it cannot use.
Different implementations of DHCP servers or
differing DHCP server policies can dictate that a
server return more configuration parameters than
a client requests. On the other hand, some DHCP
servers will not send a parameter to a client unless
the client explicitly requests it. If your DHCP server
is configured to deliver a particular parameter to your
TCP/IP Services DHCP client and the client is not
receiving the information, verify that the DHCP client
has a request statement for the information in its
CLIENT.PCY file.
Table 9–2 lists the DHCP parameters that a TCP/IP
Services DHCP client may request from a server. Note
that vendor-specific options, like the ones marked with
TCPVMS in columns 3 and 4 of the DHCPTAGS. file
entries, may not appear in a request statement.
Table 9–2 lists the Request statement parameters supported by the TCP/IP
Services DHCP client implementation.
9–8 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
Table 9–2 Supported Request Parameters
Parameter Name
DHCP Option
Code
This parameter requests...
Interface-specific parameters
broadcast_address
28
The broadcast address in use on the client’s
subnet.
interface_mtu
26
The MTU size to use when performing Path
MTU discovery.
subnet_mask
1
The client’s subnet mask.
dns_domain_name
15
The domain name that the client should
use when resolving host names using the
Domain Name System (DNS).
dns_servers
6
A list of DNS name servers available to the
client.
host_name
ip_time_to_live
12
The host name of the client.
23
The default time-to-live value the client
should use on outgoing datagrams.
ip_forwarding
19
How the client should configure its IP layer
for packet forwarding.
keepalive_interval
38
The time interval (in seconds) that the
client TCP should wait before sending a
keepalive message on a TCP connection.
routers
3
A list of IP addresses for routers on the
client’s subnet. Routers are listed in the
order of preference.
static_routes
33
A list of static routes the client should
install in its routing cache. If multiple
routes to the same destination are specified,
they are listed in descending order of
priority. The routes consist of a list of IP
address pairs. The first address is the
destination address and the second address
is the router for the destination.
Systemwide parameters
tcp_default_time_to_live
37
The default time-to-live value that the
client uses when sending TCP segments.
9.2.2.2 The Interface File
When the DHCP client receives parameters to configure the interface on the
client, it stores them in a file named ifname.DHC along with the IP address lease
information. The ifname part of the file name is the name of the interface on
which the parameters were received. For example, the file created for parameters
received on interface SE0 is SE0.DHC. There is one file per interface, and the files
are placed in the directory specified by the system logical name TCPIP$DHCP_
CONFIG (if it is defined) or in the SYS$SYSDEVICE:[TCPIP$DHCP] directory.
The interface file is a binary file, and you can display its contents by using the
SHOWDHC utility. See Section 9.6 for information on how to use the SHOWDHC
utility.
Configuring and Managing the DHCP Client 9–9
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
9.2.2.3 The Host Name File
You can configure the DHCP client to suggest a host name of your choice to the
DHCP server by entering the name into a file named HOSTNAME.ifname. This
file contains one line of text that contains the unqualified host name to suggest.
You store the file in directory specified by the system logical TCPIP$DHCP_
CONFIG, if defined, or in the SYS$SYSDEVICE:[TCPIP$DHCP] directory.
If you have multiple interfaces and want to suggest a different host name
for each one, put the desired interface host names into separate files called
HOSTNAME.ifname, where ifname is the name of the interface. For example,
if you have two interfaces, WF0 and WE0, and you want the WF0 interface to
receive the host name myhostfiber and the WE0 interface to receive the name
myhostether, enter the following commands:
$ CREATE SYS$SYSDEVICE:[TCPIP$DHCP]HOSTNAME.WF0
myhostfiber
<CTRL-Z>
$ CREATE SYS$SYSDEVICE:[TCPIP$DHCP]HOSTNAME.WE0
myhostether
<CTRL-Z>
When configuring an interface, the DHCP client will first check for a
HOSTNAME.ifname file and then, if that is not found, for the HOSTNAME.
file.
When you initially configure the DHCP client the value of your node’s SCSNODE
parameter is placed into a file called HOSTNAME. with no .ifname extension.
If you change the HOSTNAME.ifname file, you must delete the interface.DHC file
for the change to take effect.
9.2.2.4 The DHCPTAGS. File
The DHCPTAGS. file identifies the type of each parameter returned to the DHCP
client by the DHCP server. Each supported option consists of the following:
•
Option code number
•
A two digit mnemonic code
•
A short mnemonic text string for use in the DHCPCAP database
•
A description of each option
The options are defined as follows:
•
Standard
The semantics on which all client and server DHCP implementations agree.
These options are administered by the Internet Assigned Numbers Authority
(IANA). They are numbered from 1 to 127, and 255.
•
Site specific
Within a specific site all client and server implementations agree on the
semantics, but at another site the type and meaning of an option may differ.
These options are numbered from 128 to 254.
•
Vendor specific
Each vendor may define 256 options unique to that vendor. The vendor is
identified within a DHCP packet by the Vendor Class option (#60). An option
with a specific numeric identifier belonging to one vendor will, in general,
have a type and semantics different from those of another vendor. Vendor
9–10 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.2 DHCP Client Components
options are super encapsulated into the vendor field (#43); within a specific
DHCP packet there may be several instances of option #43.
•
Pseudotags
These are fields of the BOOTP packet and are not defined in RFC2131. Do
not change these fields.
In general, the DHCP server knows little about the semantics of the first three
options. Its only duty is to deliver those values to clients that need them.
The responsibility for understanding and using the data rests with the client.
Pseudotags have a meaning specific to TCP/IP Services.
9.2.3 Command Files
Table 9–3 lists the command files that the DHCP client uses to start up and shut
down the component.
Table 9–3 DHCP Client Command Files
Command File Name
Description
TCPIP$DHCP_CLIENT_STARTUP.COM
Installs the DHCP client image.
TCPIP$DHCP_CLIENT_SHUTDOWN.COM
Stops DHCP client.
9.2.4 System Logicals
Use the logicals listed in Table 9–4 to alter the behavior of the DHCP client.
Table 9–4 DHCP Client System Logicals
Logical Name
Purpose
TCPIP$DHCP_DEBUG
Turns on DHCP client diagnostics. Refer to
Section 8.2.4 for a description of this logical.
TCPIP$DHCP_CONFIG directory
Specifies the directory from which to read
input files (CLIENT.PCY, DHCPTAGS. and
HOSTNAME.) and to which to write output
files (ifname.DHC). Note that DHCP client
log files will still go to the default directory of
the DHCP client account.
TCPIP$DHCP_LOG_LEVEL value
Writes the specified level of diagnostic
information to the log file. Ignored if
TCPIP$DHCP_DEBUG is defined.
Valid numeric values are:
0
No logging (default).
1
Log warning messages.
2
Log all messages.
9.2.5 Log Files
DHCP client creates a log file named TCPIP$DHCP_CLIENT_RUN.LOG in the
directory SYS$SYSDEVICE:[TCPIP$DHCP].
Configuring and Managing the DHCP Client 9–11
Configuring and Managing the DHCP Client
9.3 DHCP Client Startup and Shutdown
9.3 DHCP Client Startup and Shutdown
The DHCP client can be shut down and started independently of TCP/IP Services.
This is useful when you change parameters or logical names that require the
service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$DHCP_CLIENT_STARTUP.COM allows you to start
up the DHCP client service.
•
SYS$STARTUP:TCPIP$DHCP_CLIENT_SHUTDOWN.COM allows you to
shut down the DHCP client service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$DHCP_CLIENT_SYSTARTUP.COM can be used as
a repository for site-specific definitions and parameters to be invoked when
DHCP client is started.
•
SYS$STARTUP:TCPIP$DHCP_CLIENT_SYSHUTDOWN.COM can be used
as a repository for site-specific definitions and parameters to be invoked when
DHCP client is shut down.
9.4 Configuring the DHCP Client
In order for the DHCP client to run, you must perform the following steps:
1. Put at least one interface under DHCP control.
2. Configure the DHCP client software.
9.4.1 Putting Interfaces under DHCP Control
For the DHCP client to execute, at least one interface on your host must be
designated as being under DHCP control. This means that the interface IP
address, subnet mask, and broadcast address are set automatically by DHCP
when the system invokes the command procedure TCPIP$STARTUP.COM.
To place interfaces under DHCP control, you have these options:
•
Use DHCP client autoconfigure for new TCP/IP Services installations.
•
Use TCPIP$CONFIG to put interfaces under DHCP control.
9.4.1.1 Using Autoconfigure for a New TCP/IP Installation
If UCX or TCP/IP Services have never been installed on the
system, you can install TCP/IP Services and manually invoke the
SYS$STARTUP:TCPIP$STARTUP.COM procedure. TCPIP$STARTUP.COM
detects that you have never run TCPIP$CONFIG and asks whether you
want DHCP client to configure your host for you. If you answer Yes,
TCPIP$STARTUP.COM invokes TCPIP$CONFIG to configure a small set of
services and sets any unconfigured interfaces to be under DHCP control. This
process is done in silent mode and asks you no questions.
The services enabled when you autoconfigure are:
•
FTP client
•
TELNET client
•
TELNET server
9–12 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.4 Configuring the DHCP Client
If you want more than the set of services configured by this option, you can
configure your host with the subset of TCP/IP Services and at a later time run
TCPIP$CONFIG to configure other services.
DHCP client autoconfigure puts each unconfigured IP interface under DHCP
control. It employs the following rules to decide which, if any, interface should
be marked as the primary interface. (See Section 9.1.1 for an explanation of the
DHCP primary interface.)
•
If any interface currently has a permanent IP address, then TCPIP$CONFIG
will not mark any of the interfaces under DHCP control as primary.
•
If no interfaces are currently configured, then the first interface that
TCPIP$CONFIG sees and marks as under DHCP control becomes the primary
DHCP interface.
9.4.1.2 Using TCPIP$CONFIG to Configure an Existing Installation
If you have an existing TCP/IP installation, use TCPIP$CONFIG to place
interfaces under DHCP control. To do this, perform the following steps:
1. From the TCPIP$CONFIG main menu, choose the Core Environment option
and then choose the Interfaces option.
2. TCPIP$CONFIG presents a menu for each interface that it finds and gives
you the option to:
Configure the interface manually.
Allow DHCP client to configure the interface.
Leave the interface unchanged.
The following example illustrates this procedure:
INTERFACE Configuration
The Ethernet device(s) on your system are: ESA0:
Start of configuration questions for Internet interface SE0.
SE0 is the Ethernet device ESA0:
Interface: SE0
IP_Addr: 10.0.0.1
NETWRK: 255.0.0.0
C_Addr:
C_NETWRK:
Flags:
Receive buffer:
BRDCST: 10.255.255.255
C_BRDCST:
0
HP TCP/IP Services for OpenVMS Interface SE0 Reconfiguration Menu
Reconfiguration options:
1 - Configure interface manually
2 - Let DHCP configure interface
(Current default)
[E] - Exit menu (Do not reconfigure interface SE0)
Enter configuration option: 2
End of configuration questions for Internet interface SE0
3. If the system has multiple interfaces, DHCP client displays information about
each existing interface and gives you the option to configure the interface
manually or to allow DHCP to configure the interface.
Configuring and Managing the DHCP Client 9–13
Configuring and Managing the DHCP Client
9.4 Configuring the DHCP Client
4. The next phase in the configuration process allows you to designate an
interface as the primary DHCP interface.
Primary DHCP Interface Configuration
DHCP Client configures system-wide parameters and
interface-specific parameters. Only one interface, the
DHCP "primary" interface, can receive system-wide
parameters.
Which interface? (SE0,NONE,HELP) [NONE]:SE0
5. At this point, TCPIP$CONFIG sets up the account for the DHCP client and
default directory and for initial copies of the required configuration and data
files. For more information, see Section 9.4.2.
9.4.2 Configuring the Software
For the DHCP client to function, DHCP client software must be configured. As
with any TCP/IP service, configuration involves:
•
Creation of a default directory and an account in which the software can run
•
Creation of data files
TCPIP$CONFIG.COM provides a menu option under the client menu called
DHCP client. This option configures the DHCP client for you. You can choose
this option explicitly, but if you put an interface under DHCP control from the
Interfaces menu in TCPIP$CONFIG, this step occurs automatically.
The DHCP client software configuration does the following:
•
Creates the TCPIP$DHCP account, if it is not present.
•
Creates the SYS$SYSDEVICE:[TCPIP$DHCP] directory, if it is not present.
•
Enables the DHCP client service, if it is not present in the configuration
database.
Note that there is no service database entry for the DHCP client.
•
Creates the initial versions of the following required configuration and data
files.
DHCPTAGS.
TCPIP$CONFIG extracts a copy of the DHCPTAGS. file from the
librarian file, TCPIP$TEMPLATES.TLB. This file generally does not
require modification. For a description of the DHCPTAGS. file, see
Section 9.2.2.4.
CLIENT.PCY
TCPIP$CONFIG extracts a copy of the CLIENT.PCY file
TCPIP$TEMPLATES.TLB. This file governs the behavior of the DHCP
client. Among other things, it tells the DHCP client which DHCP
configurable parameters to request from the DHCP server. The file, as
it comes from TCPIP$TEMPLATES.TLB, requests the most essential
parameters from the server, including:
Default route
Host name
DNS servers IP addresses
DNS domain name
For more information about this file, see Section 9.2.2.1.
9–14 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.4 Configuring the DHCP Client
HOSTNAME.[ifname]
This file contains a host name that you want to suggest that the DHCP
server use as the system’s host name. TCPIP$CONFIG puts the value of
the cluster system parameter SCSNODE from the client system into this
file. For more information about this file, see Section 9.2.2.3.
After extracting the files, TCPIP$CONFIG places the files into the directory
pointed to by the TCPIP$DHCP_CONFIG logical, if it is defined. If
TCPIP$DHCP_CONFIG is not defined, then the files are put into the
SYS$SYSDEVICE:[TCPIP$DHCP] directory. No files are created if a version
already exists.
Note
The DHCP client cannot coexist on the same system with a DHCP server,
and TCPIP$CONFIG does not allow you to configure the DHCP client on
a system with the DHCP server configured.
9.4.3 Configuring a Cluster Environment
If you want multiple OpenVMS Cluster nodes to share the same CLIENT.PCY
file, and the nodes have identical interface names, a conflict will arise if you
simply define TCPIP$DHCP_CONFIG to a common directory shared between the
systems.
For example, if two systems in a cluster have an interface named SE0 that is
under DHCP control, configure for this situation in the following way:
1. Define the system logical TCPIP$DHCP_CONFIG as a search list that points
first to a system-specific directory that you create for the DHCP client and
then to the common directory.
2. Place the CLIENT.PCY file in the common directory.
3. If you want, place the HOSTNAME file into the SYS$SPECIFIC: directory.
The ifname.DHC files will be created in the SYS$SPECIFIC:[ ] directory. For
completeness, you might want to make the default device and directory for
the TCPIP$DHCP account the SYS$SPECIFIC:[ ] directory, too.
9.4.4 Signaling the DHCP Client
You can use the TCPIP$DHCP_SIGNAL utility to signal the DHCP client to:
•
Translate utility logicals and read configuration files.
•
Shut down the DHCP client.
•
Dump the diagnostic state of the DHCP client to a file.
Table 9–5 shows the commands available with the TCPIP$DHCP_SIGNAL
utility.
Configuring and Managing the DHCP Client 9–15
Configuring and Managing the DHCP Client
9.4 Configuring the DHCP Client
Table 9–5 DHCP Signal Commands
Command
Description
DHCPSIGHUP
Causes the ASCII configuration files to be read again and then
translates the TCPIP$DHCP_DEBUG and TCPIP$DHCP_LOG_LEVEL
logicals.
DHCPSIGTERM
Causes an orderly shutdown of DHCP client. Use this command
cautiously, as active lease and timer information is lost when you
signal the DHCP client to shutdown. As a consequence, when you
again start up the DHCP client, the system could be running with an
expired lease.
DHCPSIGUSR1
Causes diagnostic state information to be written to the TCPIP$DHCP_
CLIENT_RUN.LOG file.
9.5 TCP/IP Management Commands
You can use TCP/IP management commands to:
•
Temporarily put an interface under DHCP control.
•
Permanently put an interface under DHCP control.
9.5.1 Temporarily Configuring Interfaces
The TCP/IP command SET INTERFACE temporarily puts an interface under
DHCP control. It does not make any change to the TCPIP$CONFIGURATION
data base.
The format of the command is:
SET INTERFACE ifname/DHCP [/[NO]PRIMARY]
In this format, ifname is the name of the interface; for example, SE0.
You must enter the SET NOINTERFACE command on the interface before you
enter the SET INTERFACE/DHCP command.
After you enter the SET INTERFACE/DHCP command, the interface receives
a new IP address from the DHCP server, but the information stored in the
TCPIP$CONFIGURATION.DAT file is unchanged. For example, if you issue
the TCP/IP command SHOW CONFIGURATION INTERFACE for the interface
you see the IP address you had set up for the interface before you temporarily
configured the interface. In addition, when you stop and restart TCP/IP Services,
the interface will have the previously assigned IP address.
Use the TCPIP$CONFIG.COM command procedure to place the interface
permanently under DHCP control, or follow the procedure described in
Section 9.5.2.
9.5.2 Permanently Configuring Interfaces
The TCP/IP command SET CONFIGURATION INTERFACE /DHCP configures
an interface to be under DHCP control by adding or changing an entry in the
TCPIP$CONFIGURATION database. After entering this command, every time
TCPIP$STARTUP.COM is run the DHCP client is invoked to configure the
interface.
The format of the command is:
SET CONFIGURATION INTERFACE ifname/DHCP [/[NO]PRIMARY]
9–16 Configuring and Managing the DHCP Client
Configuring and Managing the DHCP Client
9.5 TCP/IP Management Commands
In this format, ifname is the name of the interface; for example, SE0.
The optional qualifier /PRIMARY indicates that the interface is to be the primary
DHCP client interface. (For a description of the DHCP client primary interface,
see Section 9.1.1.) TCP/IP Services issues an error if one of the other interfaces
has the primary designation.
/NOPRIMARY indicates that the interface is no longer to be marked as the
primary DHCP client interface. Because a primary DHCP interface is not
required, no error occurs if turning off this option leaves no primary DHCP
interface.
Note that this command does not change the current run-time configuration
of the interface. For any changes to the TCPIP$CONFIGURATION database
to take effect, you must run restart TCP/IP Services, or enter the START
COMMUNICATION/INITIALIZE command.
9.6 Using the SHOWDHC Utility
TCP/IP Services provides the SHOWDHC utility for displaying the contents of an
interface parameter file.
The SHOWDHC utility displays data stored in an ifname.DHC file.
The format of the SHOWDHC utility command is as follows:
SHOWDHC filename
In this format, filename is the name of an ifname.DHC file.
The format of the SHOWDHC output is a single line in the format of the
DHCPCAP. file. For more information about the format of the DHCPCAP. file, see
Section 8.2.2.2. Example 9–2 shows typical output from the SHOWDHC utility.
Example 9–2 SHOWDHC Sample Output
$ SHOWDHC SE0.DHC
se0.dhc:
ht=1:ha=08.00.2b.2a.de.a8:sa=10.10.2.3:yi=10.10.2.101:sm=255.255.255.0:gw=10.10.
2.66:ds=10.10.2.11:ho=rufus:dn=lkg.dec.com:ba=10.10.2.255:lt=1200:sv=10.10.2.3:
t1=600:t2=1050:
Configuring and Managing the DHCP Client 9–17
10
Configuring and Managing BOOTP
The Bootstrap Protocol (BOOTP) server answers network bootstrap requests
from diskless workstations and other network devices such as routers, terminal
servers, and network switching equipment. When it receives such a request, the
BOOTP server looks up the client’s address in the BOOTP database file.
The Trivial File Transfer Protocol (TFTP) handles the file transfer from a TFTP
server to a diskless client or other remote system. The client initiates the file
transfer. TFTP is described in Chapter 11.
Because BOOTP is a subset of DHCP, you cannot enable both BOOTP and DHCP
on the same host.
This chapter reviews key concepts and describes:
•
How to plan for configuring BOOTP (Section 10.2)
•
How to configure the BOOTP service (Section 10.3)
•
How to manage the BOOTP service (Section 10.4)
•
Create the BOOTP database and populate it with client entries (Section 10.5)
•
Solve BOOTP problems (Section 10.6)
10.1 Key Concepts
The BOOTP server answers client requests for diskless client configuration by
sending address and file name information to the client. When the client receives
this information from the BOOTP server, it initiates a file transfer using the
TFTP protocol.
The BOOTP server performs the following steps to accomplish a bootstrap:
1. The BOOTP server receives a configuration request from a client. A broadcast
request goes out to all potential servers on the subnetwork or is directed to a
predetermined known server address.
2. The BOOTP server reads information in the BOOTP database to get
information about the client. The identity of the client is based on the
network hardware address contained in the request.
3. BOOTP identifies the network client.
4. BOOTP constructs a response that contains all of the information in the
BOOTP database for that client. The client information in the database
includes:
•
Client’s IP address
•
Client’s host name (usually)
•
Name and size of the client’s system load file
Configuring and Managing BOOTP 10–1
Configuring and Managing BOOTP
10.1 Key Concepts
•
IP address of the TFTP server storing this file
•
IP addresses of the hosts offering common network services, such as a log
server or a print (LPD) server
5. When the client receives the configuration information in the BOOTP
response, it sends a request to the TFTP server host named in the response.
This request is necessary only if the client must retrieve the load file.
6. If the client sends a read request (RRQ) to the TFTP server, the TFTP server
attempts to locate this file. If it finds the file, the server transfers it to the
client.
10.2 BOOTP Planning and Preconfiguration Tasks
When planning BOOTP, you need to make decisions about the network
configuration and the local BOOTP service.
10.2.1 Network Configuration Decisions
Before you start to set up BOOTP, answer the following questions:
•
What clients will access the BOOTP server? For each client, obtain the
following information:
System image and location from where it can be copied
Additional information requested
Hardware address
IP address
•
What hosts in your network will run the BOOTP server?
•
Will gateways be used for downloading? Gateways let you specify a specific
path for the data transfer.
•
Do you want to limit client access to specific server directories?
10.2.2 BOOTP Service Decisions
Before you start to configure BOOTP, consider the following:
•
Default priority for the TCPIP$BOOTP server account in the user
authorization file (UAF)
For optimal performance, use the default priority level for the TCPIP$BOOTP
user account.
In a large or active subnetwork, clients might generate several broadcast
requests per minute. The server continues to process all incoming requests,
even those for which it lacks information in its database.
In most cases, all this processing does not create system performance
problems. However, it does use, perhaps unnecessarily, system resources. A
different network configuration might avoid wasted system overhead.
•
Segmented subnetworks
To reduce large volumes of BOOTP request traffic to a specific server, segment
very large subnetworks with filtering bridges.
10–2 Configuring and Managing BOOTP
Configuring and Managing BOOTP
10.2 BOOTP Planning and Preconfiguration Tasks
If you configure multiple servers, each server competes to provide the
requested configuration information. For efficient use of each server, partition
the database with a subset of the overall client population designated to each
server.
•
Separate directory for each client
To avoid writing over the same file name with configuration information
from multiple clients, create a separate subdirectory for each client in the
TCPIP$TFTP_ROOT directory tree.
Some BOOTP clients, such as routers and terminal servers, can store
configuration options on the BOOTP server host. In a network with two or
more of these clients, the clients can use the same file name to store the
configuration information with TFTP.
•
Security needs
Identify your system’s security needs (see Section 10.2.3).
10.2.3 BOOTP Security
For security purposes, the server runs as an unprivileged image that can access
only the directories and files for which it has read access.
HP recommends that you safeguard your system’s normal file protection
mechanisms from unauthorized access. In particular, ensure the security of
system files.
The BOOTP server runs as the nonprivileged OpenVMS user account
TCPIP$BOOTP. When you set up BOOTP, follow these security procedures:
•
Ensure that neither server has automatic access to any files.
To make files accessible to the BOOTP server, grant appropriate access to
its account. Use the normal OpenVMS file protection procedures. To display
the current file protection settings on a directory, enter the DCL command
DIRECTORY/SECURITY.
•
Prevent unauthorized access to sensitive system or user data. Before you
enable BOOTP, ensure that you have set up all the necessary file protections.
•
Give the TCPIP$BOOTP user account read access to the files in the
TCPIP$TFTP_ROOT: directory tree that might be used for downloading.
•
Some clients first send a BOOTP request for the name of the file that they
need downloaded. On receipt, BOOTP opens the file for read access and
retrieves its size. BOOTP needs access to confirm that the file exists and to
provide the size of the file to the client in the BOOTP response.
Ensure that BOOTP has access to this file.
10.3 Configuring the BOOTP Service
To set up the BOOTP server software, run TCPIP$CONFIG (see the HP TCP/IP
Services for OpenVMS Installation and Configuration manual).
The procedure creates:
•
BOOTP user account
•
Service records in the services database
•
Default directories
Configuring and Managing BOOTP 10–3
Configuring and Managing BOOTP
10.3 Configuring the BOOTP Service
•
Empty TCPIP$BOOTP database file
10.4 Managing the BOOTP Service
The following sections describe how to manage the BOOTP service.
10.4.1 Enabling and Disabling BOOTP
To enable and disable BOOTP, use these commands:
•
On the running system:
ENABLE SERVICE BOOTP
DISABLE SERVICE BOOTP
•
In the configuration database:
SET CONFIGURATION ENABLE SERVICE BOOTP
SET CONFIGURATION DISABLE SERVICE BOOTP
To check whether these services are enabled or disabled, enter the following
commands:
•
SHOW SERVICE BOOTP
•
SHOW CONFIGURATION ENABLE SERVICE BOOTP
The following examples show how to use the SHOW SERVICE command to get
information about BOOTP.
1. To display information about the BOOTP server processes, enter the
SHOW SERVICE command. For example:
TCPIP> SHOW SERVICE BOOTP
Service
BOOTP
Port Proto
67 UDP
Process
TCPIP$BOOTP
Address
0.0.0.0
State
Enabled
2. To display BOOTP service settings and statistics, include the /FULL qualifier.
For example:
TCPIP> SHOW SERVICE BOOTP /FULL
Service: BOOTP
Port:
67
Inactivity: 5
Limit:
1
State:
Enabled
Protocol: UDP
User_name: TCPIP$BOOTP
Active:
1
Address: 0.0.0.0
Process: TCPIP$BOOTP
Peak:
1
File: TCPIP$SYSTEM:TCPIP$BOOTP_RUN.COM
Flags: Listen
Socket Opts: Rcheck Scheck
Receive:
0
Send:
Log Opts:
File:
0
Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimeO Addr
SYS$SYSDEVICE:[TCPIP$BOOTP]TCPIP$BOOTP_RUN.LOG
Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
10–4 Configuring and Managing BOOTP
Configuring and Managing BOOTP
10.4 Managing the BOOTP Service
10.4.2 BOOTP Management Commands
Table 10–1 summarizes the BOOTP management commands.
Table 10–1 BOOTP Management Commands
Command
Function
CONVERT/VMS BOOTP
Populates an existing BOOTP database with
entries from a UNIX /etc/bootptab file.
CREATE BOOTP
Creates an empty BOOTP database.
SET BOOTP
Adds or modifies client entries to the BOOTP
database.
SHOW BOOTP
Displays client information from the BOOTP
database.
ENABLE SERVICE BOOTP
Dynamically enables the BOOTP service.
DISABLE SERVICE BOOTP
Dynamically disables the BOOTP service.
SET CONFIGURATION ENABLE SERVICE BOOTP
Sets the configuration database to enable
BOOTP at product startup.
SET CONFIGURATION DISABLE SERVICE BOOTP
Sets the configuration database to disable
BOOTP at product startup.
SET SERVICE BOOTP
Configures the BOOTP service in the services
database.
SET NOSERVICE BOOTP
Disables the BOOTP service in the
configuration database.
SHOW SERVICE BOOTP
Displays BOOTP server information stored in
the services database.
10.4.3 BOOTP Logical Names
Table 10–2 lists the logical names you can use to manage the BOOTP software.
Table 10–2 BOOTP and TFTP Logical Names
Name
Function
TCPIP$BOOTP
Points to the location of the BOOTP database file.
TCPIP$TFTP_ROOT
Defines a concealed device. Points to the TFTP data storage
tree, for example, SYS$SYSDEVICE:[TCPIP$TFTP_ROOT.].
TCPIP$BOOTP_TRACE
Displays the client hardware address for every incoming
BOOTP request and response to requests.
10.4.4 BOOTP Startup and Shutdown
The BOOTP service can be shut down and started independently. This is useful
when you change parameters or logical names that require the service to be
restarted. The following files are provided:
•
SYS$STARTUP:TCPIP$BOOTP_STARTUP.COM allows you to start up
BOOTP.
•
SYS$STARTUP:TCPIP$BOOTP_SHUTDOWN.COM allows you to shut down
BOOTP.
Configuring and Managing BOOTP 10–5
Configuring and Managing BOOTP
10.4 Managing the BOOTP Service
To preserve site-specific parameter settings and commands, you can create
the following files. These files are not overwritten when you reinstall TCP/IP
Services:
•
SYS$STARTUP:TCPIP$BOOTP_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
BOOTP is started.
•
SYS$STARTUP:TCPIP$BOOTP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
BOOTP is shut down.
10.5 Creating a BOOTP Database
If you choose to configure BOOTP while configuring TCP/IP Services,
TCPIP$CONFIG creates an empty BOOTP database.
If you need to create it manually, use the TCP/IP management
command CREATE BOOTP. This command creates the file
SYS$SYSTEM:TCPIP$BOOTP.DAT. The command uses the logical name
TCPIP$BOOTP to point to the BOOTP database file. To create a separate
database, perhaps in a different disk directory or with a different file name,
modify this logical name.
To create a temporary, separate, and empty BOOTP file, you can use a processspecific logical name. However, HP does not recommend creating separate or
private BOOTP databases because the TCPIP$BOOTP user account requires read
access to the database file.
10.5.1 Populating the BOOTP Database
For each BOOTP client in the BOOTP database, use the SET BOOTP command
to enter the following required information:
•
Client’s hardware address (required).
•
Either the client’s name or IP address (required).
•
Network mask (required).
•
Client’s system image file name (required).
•
Interim gateway (routing) systems.
•
Either the name or IP address of other network servers. Some of the optional
servers that you can specify are:
Cookie servers
IEN-116 name servers
IMPRESS network image servers
LPR print servers
MIT-LCS UDP logging servers
DNS (BIND) name servers
Resource location (RLP) servers
Network time servers
10–6 Configuring and Managing BOOTP
Configuring and Managing BOOTP
10.5 Creating a BOOTP Database
To populate the BOOTP database with client entries, use these commands:
•
CONVERT/VMS BOOTP (adds UNIX client records)
•
SET BOOTP (adds individual client records)
10.5.2 Converting UNIX Records
You can use the BOOTP client information in an existing UNIX boot file. The
CONVERT/VMS BOOTP command populates the existing BOOTP database with
entries from a BIND formatted UNIX /etc/bootptab file.
Before you enter CONVERT/VMS BOOTP, define the logical name
TCPIP$BOOTP. The CONVERT/VMS BOOTP command uses it to determine
the directory and file name for the database. Enter the following command:
$ DEFINE /SYSTEM TCPIP$BOOTP SYS$COMMON:[SYSEXE]TCPIP$BOOTP.DAT
If you do not define TCPIP$BOOTP, the database is created as
[current_directory]TCPIP$BOOTP.DAT.
To populate the BOOTP database by using entries in a UNIX /etc/bootptab file,
follow these steps:
1. Copy the /etc/bootptab file to your system.
2. Edit the output file. Examine the directory path for each client entry. Modify
the UNIX path names to OpenVMS specifications. For example, change:
:hd=/usr/apple/orange/bootptab:
to
:hd="DISK_BIRD2$:[USR.APPLE.ORANGE]BOOTPTAB.DAT":
Note that this is a UNIX file and is not compatible with OpenVMS.
3. Enter the CONVERT command as follows:
TCPIP> CONVERT /VMS BOOTP
The command reads the entries in your edited output file and adds them
to the BOOTP database. If it finds an existing record for a client with a
converted record, and if the information differs, the command updates the
existing record with the newer data.
The CONVERT/VMS BOOTP command has the following format:
CONVERT/VMS BOOTP source_file /ADD_HOST /FILE=sys_image_file
In this command format:
•
source_file
Specifies the name of the file you edited (the output from the COPY
command). The default is ETC.BOOTPTAB.
•
/ADD_HOST
Adds client entries that are new to your system to the hosts database. The
default is not to add client entries to the hosts database.
•
/FILE=sys_image_file
Specifies the download file. Use this parameter if you are adding new clients
to the BOOTP database. All these new clients have the same download file.
Configuring and Managing BOOTP 10–7
Configuring and Managing BOOTP
10.5 Creating a BOOTP Database
10.5.3 Creating Individual Entries
To add individual entries to the BOOTP database, use the SET BOOTP command,
which has the following format:
SET BOOTP host /FILE=download_file/HARDWARE=ADDRESS=hex_address
In the following example, the SET BOOTP command adds host PLOVER, with
hardware address 08-00-2D-20-23-21, to the BOOTP database. Note that the SET
BOOTP command accepts as a parameter either the host name or the host’s IP
address. In the following example, the host name is specified:
TCPIP> SET BOOTP PLOVER /HARDWARE=ADDRESS=08-00-2D-20-23-21 /FILE=PLOVER.SYS
To display the BOOTP database, enter the SHOW BOOTP command, as follows:
TCPIP> SHOW BOOTP
Host
Hardware address
10.10.2.3
10.10.2.120
10.10.2.22
08-00-00-20-23-21
08-00-2B-A2-20-49
08-00-2D-20-23-21
10.5.4 Modifying and Deleting Entries
To modify a record in the BOOTP database, use the SET BOOTP command. For
example, the following command stops using hosts seagull, tern, and sandpiper
as gateways for downline loading to PLOVER:
TCPIP> SET BOOTP PLOVER /NOGATEWAYS=(seagull,tern,sandpiper)
To delete an entry from the BOOTP database, use the SET NOBOOTP command.
10.6 Solving BOOTP Problems
Most problems with BOOTP are due to:
•
Inaccurate client information in the BOOTP database.
•
Directory access restrictions because the TCPIP$BOOTP user account is not
privileged.
•
File access restrictions because the TCPIP$BOOTP user account is not
privileged.
If BOOTP fails to respond to a client request, follow these steps:
1. Verify the accuracy of the information in the BOOTP database for that client,
especially the hardware address and image file name.
2. Turn on logging.
3. Ensure that the BOOTP server has access to directories and files.
4. Set directory and file protections appropriately.
The BOOTP server ignores incoming requests from unknown clients (for example,
clients that are not found in the BOOTP database). Therefore, it can be difficult
to identify why incoming requests are not serviced.
By default, BOOTP does not generate logging information, even though it opens
the file SYS$SYSDEVICE:[TCPIP$BOOTP]TCPIP$BOOTP_RUN.LOG. If you
turn on logging, the log displays the client hardware address for every incoming
BOOTP request, as well as any information used in response to those requests.
With this information, you can detect whether the server sees a particular client
10–8 Configuring and Managing BOOTP
Configuring and Managing BOOTP
10.6 Solving BOOTP Problems
request. To turn on logging, define the following logical name. To activate the
logical, shut down and restart the BOOTP service. For example:
$ DEFINE /SYSTEM TCPIP$BOOTP_TRACE 1
$ @SYS$STARTUP:TCPIP$BOOTP_SHUTDOWN.COM
$ @SYS$STARTUP:TCPIP$BOOTP_STARTUP.COM
Remove the logical names and restart BOOTP as soon as the problem is fixed. On
a busy network with frequent BOOTP requests, the log file can rapidly consume
large amounts of space on your system disk.
Configuring and Managing BOOTP 10–9
11
Configuring and Managing TFTP
The Trivial File Transfer Protocol (TFTP) handles the file transfer from a TFTP
server to a diskless client or other remote system. The client initiates the file
transfer.
If the client sends a read request to the TFTP server, the server attempts to
locate this file.
The Bootstrap Protocol (BOOTP) server answers network bootstrap requests
from diskless workstations and other network devices such as routers, terminal
servers, and network switching equipment. For more information about setting
up the BOOTP service, see Chapter 10.
This chapter reviews key concepts and describes:
•
How to set up the TFTP service (Section 11.2)
•
TFTP security (Section 11.3)
•
How to solve TFTP problems (Section 11.4)
11.1 Key Concepts
TFTP has the following characteristics:
•
TFTP clients are not registered in a database.
•
TFTP, which runs as an unprivileged user in the TCPIP$TFTP account, is
restricted to those files that the normal unprivileged user can access.
•
TFTP clients are not regulated by the usual OpenVMS user security methods.
•
No user name or password is required to use the TFTP service.
11.2 Setting up the TFTP Service
To set up the TFTP server software, run the TCPIP$CONFIG procedure. Refer to
the HP TCP/IP Services for OpenVMS Installation and Configuration manual for
information about running TCPIP$CONFIG.
The procedure creates:
•
A TFTP user account
•
Service records in the services database
•
Default directories
•
A TFTP root directory to which the logical name TCPIP$TFTP_ROOT: will
point
Configuring and Managing TFTP 11–1
Configuring and Managing TFTP
11.2 Setting up the TFTP Service
11.2.1 Transferring Data to the TFTP Host
The TFTP server allows clients to transfer data and program images to the TFTP
server host. However, before the data transfer, a file must be created on the
TFTP server host to which the data is transferred. This process controls the
creation of files on the host, thereby preventing unwanted files from being created
on the TFTP host.
Each incoming transfer of data to a file creates a new version of the target file.
As a result, you must manage the consumption of disk space on the server system
by carefully setting up file version limits for the target files and directories.
To limit the number of versions of a file that can be created in a new
directory, include the /VERSION_LIMIT qualifier on the DCL command
CREATE/DIRECTORY. For example:
$ CREATE/DIRECTORY/VERSION_LIMIT=10 [MYPROJECT.SAVE]
For more information about managing the directories and files for TFTP
transfers, see Section 11.3.
11.2.2 TFTP Management Commands
Table 11–1 summarizes the TFTP management commands.
Table 11–1 TFTP Management Commands
Command
Function
ENABLE SERVICE TFTP
Enables the TFTP service.
DISABLE SERVICE TFTP
Disables the TFTP service.
SET SERVICE TFTP
Configures TFTP in the service database.
SET NOSERVICE TFTP
Disables TFTP in the service database.
SHOW SERVICE TFTP
Displays information about TFTP from the service
database.
11.2.3 TFTP Logical Names
The logical name described in Table 11–2 can be used to modify the behavior of
the TFTP service.
Table 11–2 TFTP Logical Names
Name
Function
TCPIP$TFTP_EXTLOG
Enables logging of client read and write
requests, as well as any error messages the
server reports to the clients while processing
those requests. By default, this logical name
is set to 0, or OFF.
(continued on next page)
11–2 Configuring and Managing TFTP
Configuring and Managing TFTP
11.2 Setting up the TFTP Service
Table 11–2 (Cont.) TFTP Logical Names
Name
Function
TCPIP$TFTP_FASTCLOSE
If set, the socket and file are closed
immediately after the server receives
the last block of a file, on client write
operations. If the logical is set, the server’s
last acknowledgment message is lost and no
retransmission is done. This may appear to
the client to be a failure. By default, this
logical is set to 0, or OFF.
TCPIP$TFTP_ROOT
Defines a concealed device that points to TFTP
data storage. By default, the concealed device
is SYS$SYSDEVICE:[TCPIP$TFTP_ROOT].
For more information, see Section 11.3.
TCPIP$TFTP_TRACE
Enables logging of detailed tracing
information about server operation, including
logging of blocks sent and received, as well
as other useful trace information. By default,
this logical name is set to 0, or OFF.
11.2.4 TFTP Startup and Shutdown
The TFTP service can be shut down and started independently. This is useful
when you change parameters or logical names that require the service to be
restarted. The following files are provided:
•
SYS$STARTUP:TCPIP$TFTP_STARTUP.COM allows you to start up TFTP
separately.
•
SYS$STARTUP:TCPIP$TFTP_SHUTDOWN.COM allows you to shut down
TFTP separately.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services.
•
SYS$STARTUP:TCPIP$TFTP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when TFPT is
started.
•
SYS$STARTUP:TCPIP$TFTP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
TFTP is shut down.
11.2.5 Enabling and Disabling TFTP
To enable and disable TFTP, use these commands:
•
On the running system:
ENABLE SERVICE TFTP
DISABLE SERVICE TFTP
•
In the configuration database:
SET CONFIGURATION ENABLE SERVICE TFTP
SET CONFIGURATION DISABLE SERVICE TFTP
To check whether these services are enabled or disabled, use these commands:
•
SHOW SERVICE TFTP
Configuring and Managing TFTP 11–3
Configuring and Managing TFTP
11.2 Setting up the TFTP Service
•
SHOW CONFIGURATION ENABLE SERVICE TFTP
The following example illustrates how to obtain complete information about TFTP
settings and statistics:
TCPIP> SHOW SERVICE TFTP /FULL
Service: TFTP
Port:
Inactivity:
Limit:
File:
Flags:
69
5
1
State:
Enabled
Protocol: UDP
User_name: TCPIP$TFTP
Active:
1
SYS$SYSDEVICE:[TCPIP$TFTP]TCPIP$TFTP_RUN.COM
Listen
Socket Opts: Rcheck Scheck
Receive:
0
Send:
Log Opts:
File:
Address: 0.0.0.0
Process: TCPIP$TFTP
Peak:
1
0
Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
SYS$SYSDEVICE:[TCPIP$TFTP]TCPIP$TFTPD_RUN.LOG
Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
11.3 TFTP Security
For security purposes, the server runs as an unprivileged image that can access
only the directories and files for which it has read access.
HP recommends that you safeguard your system’s normal file protection
mechanisms from unauthorized TFTP access. In particular, ensure the security of
system files.
A client’s download request can use one of several formats for its file name
specification:
•
If the unprivileged TFTP server has read access to the requested file, the
client uses a fully qualified file name, including the device, directory, name,
and extension, to directly access the file.
•
If the client specifies only the file name and extension, the TFTP server
attempts to locate the file in the default TFTP directory tree.
You can designate this directory tree with the system logical name
TCPIP$TFTP_ROOT:. This is a concealed device name that usually points to
the directory SYS$SYSDEVICE:[TCPIP$TFTP_ROOT]. When looking for a
directory, the TFTP server looks first in the TCPIP$TFTP_ROOT: area with
the same name as the requesting client’s host name.
For example, if a client named GULL.SHORE.COM sends a read request
for the file SERVICE.DAT, the server’s first attempt to find the file is in
TCPIP$TFTP_ROOT:[GULL]. If that directory does not exist, the server
next looks in the TCPIP$TFTP_ROOT: root directory, for example, in
TCPIP$TFTP_ROOT:[000000]SERVICE.DAT.
If the TFTP client requests a file by specifying a name in UNIX format (for
example, /etc/gull/myfile), TFTP translates this file specification into
OpenVMS format.
11–4 Configuring and Managing TFTP
Configuring and Managing TFTP
11.3 TFTP Security
The TFTP server runs as the nonprivileged OpenVMS user accounts
TCPIP$TFTP. When you set up TFTP, follow these security procedures:
•
Ensure that neither server has automatic access to any files.
To make files accessible to the TFTP server, grant appropriate access to its
account. Use the normal OpenVMS file protection procedures. For example,
enter the DCL command DIRECTORY/SECURITY.
•
Prevent unauthorized access to sensitive system or user data. Before you
enable TFTP, ensure that you have set up all the necessary file protections.
•
Give the TCPIP$TFTP user account read access to the files in the
TCPIP$TFTP_ROOT: directory tree that might be used for downloading.
11.4 Solving TFTP Problems
The TFTP server is restricted to accessing only files or directories that OpenVMS
file system security measures allow. Verify that these files have the appropriate
protection and ownership so that the TFTP server has access to them. See
Section 11.3 for more information.
•
Ensure that the TFTP server has access to directories and files. Set
protections accordingly.
•
Create the target files to enable TFTP to reply to write requests.
The log file, SYS$SYSDEVICE:[TCPIP$TFTP]TCPIP$TFTP_RUN.LOG, can be
useful for troubleshooting TFTP transfer failures.
Configuring and Managing TFTP 11–5
12
Configuring and Managing the Portmapper
The Portmapper service eliminates the need to preconfigure all client and server
remote procedure call (RPC) applications with the port numbers they use. The
Portmapper ‘‘listens’’ at port 111 and maintains a database of registered server
programs, their unique program numbers, and assigned port numbers.
This chapter describes:
•
How to configure the services that use RPC with information that the
Portmapper needs (Section 12.1)
•
How to start up and shut down the Portmapper (Section 12.2)
•
How to display Portmapper settings (Section 12.3)
For information about programming with the RPC application programming
interface (API), refer to the Compaq TCP/IP Services for OpenVMS ONC RPC
Programming manual.
12.1 Configuring Services to Use the Portmapper
You must run the Portmapper in order to use the following applications:
•
MOUNT
•
NFS Server
•
PC-NFS
•
Any customer-developed programs that use RPC
When you configure these services with TCPIP$CONFIG, you are automatically
prompted to set up the Portmapper service. The Portmapper service is then
started when you start TCP/IP Services.
The SET SERVICE command configures the applications so that they are known
to the Portmapper. To set RPC-related parameters, use the /RPC qualifier, as
follows:
TCPIP> SET SERVICE service _TCPIP> /RPC=(PROGRAM_NUMBER=n, VERSION_NUMBER=(LOWEST=n, HIGHEST=n))
The TCPIP services that use the Portmapper have the following default values
for the /RPC qualifier:
Service
Default Program
Number
Default Lowest
Version
Default Highest Version
MOUNT
100005
1
3
Configuring and Managing the Portmapper 12–1
Configuring and Managing the Portmapper
12.1 Configuring Services to Use the Portmapper
Service
Default Program
Number
Default Lowest
Version
Default Highest Version
NFS Server
100003
2
3
PC-NFS
150001
1
2
PORTMAPPER
100000
1
1
12.2 Portmapper Startup and Shutdown
The Portmapper service can be shut down and started independently. This is
useful when you change parameters or logical names that require the service to
be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$PORTMAPPER_STARTUP.COM allows you start up
the Portmapper service separately.
•
SYS$STARTUP:TCPIP$PORTMAPPER_SHUTDOWN.COM allows you to
shut down the Portmapper service separately.
To preserve site-specific parameter settings and commands, you can create
the following files. These files are not overwritten when you reinstall TCP/IP
Services.
•
SYS$STARTUP:TCPIP$PORTMAPPER_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters used in the Portmapper
startup procedure.
•
SYS$STARTUP:TCPIP$PORTMAPPER_SYSHUTDOWN.COM can be used
as a repository for site-specific definitions and parameters used in the
Portmapper shutdown procedure.
12.3 Displaying Portmapper Information
The following examples show a variety of commands you can use to get
information about the Portmapper and the services that depend on it.
1. The following example displays the RPC options for these running services:
MOUNT, NFS, PC-NFS, and the Portmapper.
TCPIP> SHOW SERVICE /RPC /PERMANENT
Service
RPC
Program Number
MOUNT
NFS
PCNFS
PORTMAPPER
TCPIP>
100005
100003
150001
100000
Protocol Versions
Lowest / Highest
1
2
1
2
3
3
2
2
2. In the following example, the /FULL and /PERMANENT qualifiers display
the RPC options for the NFS server, whose program number is 100003, lowest
version is 2, and highest version is 3.
12–2 Configuring and Managing the Portmapper
Configuring and Managing the Portmapper
12.3 Displaying Portmapper Information
TCPIP> SHOW SERVICE NFS /FULL /PERMANENT
Service: NFS
Port:
Inactivity:
Limit:
File:
Flags:
2049
0
1
Protocol: UDP
User_name: TCPIP$NFS
TCPIP$SYSTEM:TCPIP$NFS_RUN.COM
TCPIP
Socket Opts: Rcheck Scheck
Receive:
64000
Send:
Log Opts:
File:
Address: 0.0.0.0
Process: TCPIP$NFS
64000
Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
SYS$SYSDEVICE:[TCPIP$NFS]TCPIP$NFS_RUN.LOG
RPC Opts
Program number:
100003 Low version:
2
High version:
3
Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
TCPIP>
3. The following example shows how to display information about all the
registered applications:
TCPIP> SHOW PORTMAPPER
Program Number
Version Protocol Port-number Process Service-name
--------------------- ------- -------- ----------- -------- -----------000186A0 (
100000)
2 TCP
111
00000060 PORTMAPPER
000186A0 (
100000)
2 UDP
111
00000060 PORTMAPPER
000186A5 (
100005)
1 UDP
10
00000064 MOUNT
000186A5 (
100005)
3 UDP
10
00000064 MOUNT
000186A5 (
100005)
1 TCP
10
00000064 MOUNT
000186A5 (
100005)
3 TCP
10
00000064 MOUNT
000186A3 (
100003)
2 TCP
2049
00000065 NFS
000186A3 (
100003)
2 UDP
2049
00000065 NFS
000186A3 (
100003)
3 TCP
2049
00000065 NFS
000186A3 (
100003)
3 UDP
2049
00000065 NFS
4. The following example shows how to monitor the server:
TCPIP> SHOW SERVICE PORTMAPPER
Service
PORTMAPPER
Port
Protocol
Process
111
TCP,UDP
TCPIP$PORTM
Address
0.0.0.0
State
Enabled
TCPIP>
Configuring and Managing the Portmapper 12–3
13
Configuring and Managing NTP
The Network Time Protocol (NTP) synchronizes time and coordinates time
distribution throughout a TCP/IP network. NTP provides accurate and
dependable timekeeping for hosts on TCP/IP networks. TCP/IP Services NTP
software is an implementation of the NTP Version 4 specification and maintains
compatibility with NTP Versions 1, 2, and 3.
Time synchronization is important in client/server computing. For example,
systems that share common databases require coordinated transaction processing
and timestamping of instrumental data.
NTP provides synchronization that is traceable to clocks of high absolute accuracy
and avoids synchronization to clocks that keep incorrect time.
This chapter reviews key concepts and describes:
•
How to start up and shut down NTP (Section 13.2)
•
How to configure the NTP host (Section 13.3)
•
How to configure the host as a backup time server (Section 13.4)
•
NTP event logging (Section 13.5)
•
How to configure NTP authentication (Section 13.6)
•
How to use NTP utilities (Section 13.7)
•
How to solve NTP problems (Section 13.8)
13.1 Key Concepts
Synchronized timekeeping means that hosts with accurate system timestamps
send time quotes to each other. Hosts that run NTP can be either time servers or
clients, although they are often both servers and clients.
NTP does not attempt to synchronize clocks to each other. Rather, each server
attempts to synchronize to Coordinated Universal Time (UTC) using the best
available source and the best available transmission paths to that source. NTP
expects that the time being distributed from the root of the synchronization
subnet will be derived from some external source of UTC (for example, a radio
clock).
If your network is isolated and you cannot access other NTP servers on the
internet, you can designate one of your nodes as the reference clock to which all
other hosts will synchronize.
Configuring and Managing NTP 13–1
Configuring and Managing NTP
13.1 Key Concepts
13.1.1 Time Distributed Through a Hierarchy of Servers
In the NTP environment, time is distributed through a hierarchy of NTP time
servers. Each server adopts a stratum that indicates how far away it is operating
from an external source of UTC. NTP times are an offset of UTC. Stratum 1
servers have access to an external time source, usually a radio clock. A stratum 2
server is one that is currently obtaining time from a stratum 1 server; a stratum
3 server gets its time from a stratum 2 server; and so on. To avoid long-lived
synchronization loops, the number of strata is limited to 15.
Stratum 2 (and higher) hosts might be company or campus servers that obtain
time from some number of primary servers and provide time to many local clients.
In general:
•
Lower-strata hosts act as time servers.
•
Higher-strata hosts are clients that adjust their time clocks according to the
servers.
Internet time servers are usually stratum 1 servers. Other hosts connected to an
internet time server have stratum numbers of 2 or higher and can act as time
servers for other hosts on the network. Clients usually choose one of the lowest
accessible stratum servers from which to synchronize.
13.1.2 How Hosts Negotiate Synchronization
The identifying stratum number of each host is encoded within UDP datagrams.
Peers communicate by exchanging these timestamped UDP datagrams. NTP uses
these exchanges to construct a list of possible synchronization sources, then sorts
them according to stratum and synchronization distance. Peers are accepted or
rejected, leaving only the most accurate and precise sources.
NTP evaluates any new peer to determine whether it qualifies as a new (more
suitable) synchronization source.
NTP rejects the peer under the following conditions:
•
The peer is not synchronized.
•
The stratum is higher than the current source’s stratum.
•
The peer is synchronized to the local node.
NTP accepts the peer under the following conditions:
•
There is no current time source.
•
The current source is unreachable.
•
The current source is not synchronized.
•
The new source’s stratum is lower than the current source.
•
The new source’s stratum is the same as the current source, but its distance
is closer to the synchronization source by more than 50 percent.
13–2 Configuring and Managing NTP
Configuring and Managing NTP
13.1 Key Concepts
13.1.3 How the OpenVMS System Maintains the System Clock
The OpenVMS system clock is maintained as a software timer with a resolution of
100 nanoseconds, updated at 10-millisecond intervals. A clock update is triggered
when a register, loaded with a predefined value, has decremented to zero. Upon
reaching zero, an interrupt is triggered that reloads the register, and the process
is repeated.
The smaller the value loaded into this register, the more quickly the register
reaches zero and triggers an update. Consequently, the clock runs more quickly.
A larger value means more time between updates; therefore, the clock runs more
slowly. A clock tick is the amount of time between clock updates.
13.1.4 How NTP Makes Adjustments to System Time
Once NTP has selected a suitable synchronization source, NTP compares the
source’s time with that of the local clock. If NTP determines that the local clock
is running ahead of or behind the synchronization source, NTP uses a general
drift mechanism to slow down or speed up the clock as needed. NTP accomplishes
this by issuing a series of new clock ticks. For example, if NTP detects that the
local clock is drifting ahead by +0.1884338 second, it issues a series of new ticks
to reduce the difference between the synchronization source and the local clock.
If the local system time is not reasonably correct, NTP does not set the local clock.
For example, if the new time is more than 1000 seconds off in either direction,
NTP does not set the clock. In this case, NTP logs the error and shuts down.
NTP maintains a record of the resets it makes along with informational messages
in the NTP log file, TCPIP$NTP_RUN.LOG. For details about event logging and
for help interpreting an NTP log file, see Section 13.5.
13.1.5 Configuring the Local Host
The system manager of the local host, determines which network hosts to use
for synchronization and populates an NTP configuration file with a list of the
participating hosts.
NTP hosts can be configured in any of the following modes:
•
Client/server mode
This mode indicates that the local host wants to obtain time from the remote
server and will supply time to the remote server. This mode is appropriate in
configurations involving a number of redundant time servers interconnected
through diverse network paths. Internet time servers generally use this
mode.
Indicate this mode with a peer statement in the configuration file, as shown
in the following example:
peer 18.72.0.3
•
Client mode
This mode indicates that the local host wants to obtain time from the
remote server but will not provide time to the remote server. Client mode
is appropriate for file server and workstation clients that do not provide
synchronization to other local clients. A host with higher stratum generally
uses this mode.
Configuring and Managing NTP 13–3
Configuring and Managing NTP
13.1 Key Concepts
Indicate client mode with the server statement in the configuration file, as
shown in the following example:
server 18.72.0.3
•
Broadcast mode
This mode indicates that the local server will send periodic broadcast
messages to a client population at the broadcast/multicast address specified.
This specification normally applies to the local server operating as a sender.
Indicate this mode with a broadcast statement in the configuration file, as
shown in the following example:
broadcast 18.72.0.255
•
Multicast mode
A multicast client is configured using the broadcast statement, but with a
multicast group (class D) address instead of a local subnet broadcast address.
However, there is a subtle difference between broadcasting and multicasting.
Broadcasting is specific to each interface and local subnet address. If more
than one interface is attached to a machine, a separate broadcast statement
applies to each one.
IP multicasting is a different paradigm. A multicast message has the
same format as a broadcast message and is configured with the same
broadcast statement, but with a multicast group address instead of a local
subnet address. By design, multicast messages travel from the sender
via a shortest-path or shared tree to the receivers, which might require
these messages to emit from one or all interfaces but to carry a common
source address. However, it is possible to configure multiple multicast group
addresses using multiple broadcast statements. Other than these differences,
multicast messages are processed just like broadcast messages. Note that
the calibration feature in broadcast mode is extremely important, since IP
multicast messages can travel far different paths through the IP routing
fabric than can ordinary IP unicast messages.
The Internet Assigned Number Association (IANA) has assigned multicast
group address 224.0.1.1 to NTP, but you should use this address only where
the multicast span can be reliably constrained to protect neighbor networks.
In general, you should use group addresses that have been given out by
your administrator, as described in RFC 2365, or GLOP group addresses, as
described in RFC 2770.
•
Manycast mode
Manycasting is an automatic discovery and configuration paradigm new to
NTP Version 4. It is intended as a means for a multicast client to survey the
nearby network neighborhood for cooperating manycast servers, to validate
them using cryptographic means, and to evaluate their time values with
respect to other servers in the vicinity. The intended result is that each
manycast client mobilizes client associations with the best three of the
available manycast servers and automatically reconfigures to sustain this
number of servers if one or more fail.
A persistent manycast client association is configured using the server
statement, but with a multicast (class D) group address instead of an
ordinary IP (class A, B, C) address. There can be as many manycast client
associations as different group addressses.
13–4 Configuring and Managing NTP
Configuring and Managing NTP
13.1 Key Concepts
Manycast servers configured with the manycastserver statement listen on the
specified group address for manycast client messages. Note the distinction
between a manycast client, which is configured with a server statement, and
a manycast server, which is configured with a manycastserver statement.
If a manycast server is in range of the current time-to-live and is
synchronized to a valid source and operating at a stratum level equal to
or lower than that of the manycast client, the server replies to the manycast
client message with an ordinary server-mode message.
The manycast client that receives this message mobilizes an ephemeral client
association as in ordinary client/server mode, according to the matching
manycast client template. Then the client polls the server in burst mode
at its unicast address in order to set the host clock reliably and to validate
the source. The client runs the NTP intersection and clustering algorithms,
which discard all but the best three associations. The surviving associations
then continue in ordinary client/server mode.
•
Burst mode
Two burst modes can be enabled in client/server mode using the server
statement and the iburst and burst keywords. In either mode, a single poll
initiates a burst of eight client messages at intervals randomized over a range
of 1 to 4 seconds. However, the interval between the first message and the
second message is increased to about 16 seconds in order for a dialup modem
to complete a call, if necessary.
Received server messages update the NTP Version 4 clock filter, which selects
the best (most accurate) time values. When the last client message in the
burst is sent, the next received server message updates the system variables
and sets the system clock in the usual manner, as if only a single client/server
cycle had occurred. The result is not only a rapid and reliable setting of the
system clock, but also a considerable reduction in network jitter.
The iburst keyword can be configured when it is important to set the clock
quickly, such as when an association is either first mobilized or first becomes
reachable, or when the network attachment requires an initial calling or
training procedure. The burst is initiated only when the server first becomes
reachable. It results in good accuracy with intermittent connections typical of
PPP and ISDN services. Outlyers caused by initial dialup delays and other
factors are avoided, and the client sets the clock within 30 seconds after the
first message.
The burst keyword can be configured in cases of excessive network jitter
or when the network attachment requires an initial calling or training
procedure. The burst is initiated at each poll interval when the server is
reachable. The burst does produce additional network overhead and can
cause trouble if used indiscriminately. It should be used only if the poll
interval is expected to settle to values equal to or greater than 1024 seconds.
13.2 NTP Service Startup and Shutdown
The NTP service can be shut down and started independently of TCP/IP Services.
The following files are provided:
•
SYS$STARTUP:TCPIP$NTP_STARTUP.COM allows you to start the NTP
service.
Configuring and Managing NTP 13–5
Configuring and Managing NTP
13.2 NTP Service Startup and Shutdown
•
SYS$STARTUP:TCPIP$NTP_SHUTDOWN.COM allows you to shut down the
NTP service.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$NTP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when the NTP
service is started.
•
SYS$STARTUP:TCPIP$NTP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
NTP service is shut down.
13.3 Configuring Your NTP Host
The NTP configuration file TCPIP$NTP.CONF contains a list of hosts your system
will use for time synchronization. Before configuring your host, you must do the
following:
1. Select time sources.
2. Obtain the IP addresses or host names of the time sources.
3. Obtain the version number of NTP that the hosts are running.
To ensure reliable synchronization, select multiple time sources that you are
certain provide accurate time and that are synchronized to an Internet time
server.
To minimize common points of failure, avoid synchronizing the following:
•
The local host to another peer at the same stratum, unless the latter is
receiving time from a lower stratum source to which the local host cannot
connect.
•
More than one host in a particular administrative domain to the same time
server outside that domain.
To simplify configuration file maintenance, avoid configuring peer associations
with higher-stratum servers.
13.3.1 Creating the Configuration File
To create a configuration file for your local host, edit a copy of the file
TCPIP$NTP.TEMPLATE (located in SYS$SPECIFIC:[TCPIP$NTP])
to add the names of participating hosts, then save the file as
SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF. This file is not overwritten
when you install subsequent versions of TCP/IP Services.
Note
If a UCX version of NTP is configured on your system, your
TCPIP$NTP.CONF file is created automatically and is populated with
entries from the file UCX$NTP.CONF when you run the TCPIP$CONFIG
procedure.
13–6 Configuring and Managing NTP
Configuring and Managing NTP
13.3 Configuring Your NTP Host
13.3.2 Configuration Statements and Options
In the following configuration statements, the various modes are determined by
the statement keyword and the type of the required IP address. Addresses are
classsed by type as (s) a remote server or peer (IP class A, B, and C), (b) the
broadcast address of a local interface, (m) a multicast address (IP class D), or (r) a
reference clock address (127.127.x.x).
NTP configuration statements are formatted as follows:
•
peer address [key ID] [version number] [prefer] [minpoll interval]
[maxpoll interval]
server address [key ID] [version number] [prefer ][burst] [iburst]
[minpoll interval] [maxpoll interval]
broadcast address [key ID] [version number][minpoll interval][ttl nn]
manycastclient address [key ID] [version number][[minpoll interval]
[maxpoll interval][ttl nn]
These four statements specify the time server name or address to be used and
the mode in which to operate. The address can be either a DNS name or an
IP address.
peer — For type s addresses only, this statement mobilizes a persistent
symmetric-active mode association with the specified remote peer. This
statement should not be used for type b, type m, or type r addresses.
server — For type s and type r addresses only. This statement mobilizes
a persistent client mode association with the specified remote server or
local reference clock. This statement should not be used for type b or type
m addresses.
broadcast — For type b and type m addresses only. This statement
mobilizes a persisent broadcast mode association. Multiple statements
can be used to specify multiple local broadcast interfaces (subnets) or
multiple multicast groups. Note that local broadcast messages go only to
the interface associated with the subnet specified, but multicast messages
go to all interfaces.
manycastclient — For type m addresses only. This statement mobilizes a
manycast client mode association for the multicast address specified. In
this case, a specific address must be supplied that matches the address
used on the manycastserver statement for the designated manycast
servers.
The manycastclient statement specifies that the local server is to operate
in client mode with the remote servers that are discovered as the result of
broadcast/multicast messages. The client broadcasts a request message to
the group address associated with the specified address and specifically
enabled servers respond to these messages. The client selects the servers
providing the best time and continues as with the server statement. The
remaining servers are discarded as if never heard.
The following table describes the options to the NTP configuration statements:
Configuring and Managing NTP 13–7
Configuring and Managing NTP
13.3 Configuring Your NTP Host
•
Option
Description
key ID
For all packets sent to the address, includes authentication
fields encrypted using the specified key identifier, an
unsigned 32-bit integer. The default is no encryption.
version number
Specifies the version number to be used for outgoing NTP
packets. Versions 1, 2, 3, and 4 are the choices. The
default is 4.
prefer
Marks the server as preferred. This host will be chosen for
synchronization from a set of correctly operating hosts.
burst
When the server is reachable and at each poll interval,
send a burst of eight packets instead of the usual one
packet. The interval between the first and the second
packets is about 16 seconds to allow a modem call to
complete, while the interval between the remaining
packets is about 2 seconds. This is designed to improve
timekeeping quality with the server command and s
addresses.
iburst
When the server is unreachable and at each poll interval,
send a burst of eight packets instead of the usual one. As
long as the server is unreachable, the spacing between
packets is about 16 seconds to allow a modem call to
complete. Once the server is reachable, the interval
between packets is about 2 seconds. This is designed
to speed the initial synchronization acquisition with the
server command and s addresses.
minpoll interval
Specifies the minimum polling interval for NTP messages,
in seconds to the power of 2. The allowable range is 4
(16 seconds) to 14 (16384 seconds), inclusive. This option
is not applicable to reference clocks. The default is 6 (64
seconds).
maxpoll interval
Specifies the maximum polling interval (in seconds), for
NTP messages. The allowable range is 4 (16 seconds)
to 14 (16384 seconds) inclusive. The default is 10 (1024
seconds). This option does not apply to reference clocks.
ttl nn
Specifies the time-to-live for multicast packets. Used only
with broadcast and manycast modes.
broadcastclient
This statement enables the reception of broadcast server messages to local
interface (type b) addresses. Upon receiving a message for the first time, the
broadcast client measures the nominal server propagation delay using a brief
client/server exchange with the server, then enters broadcastclient mode,
in which it listens for and synchronizes to succeeding broadcast messages.
Note that to avoid accidental or malicious disruption in this mode, both the
server and client should use authentication and the same trusted key and key
identifier.
•
broadcastdelay seconds
The broadcast and multicast modes require a special calibration to determine
the network delay between the local and remote servers. Usually, this is done
automatically by the initial protocol exchanges between the client and server.
In some cases, the calibration procedure fails because of network or server
access controls. This statement specifies the default delay to be used under
these circumstances. Typically (for Ethernet), a number between 0.003 and
13–8 Configuring and Managing NTP
Configuring and Managing NTP
13.3 Configuring Your NTP Host
0.007 second is appropriate. When this statement is not used, the default is
0.004 second.
•
multicastclient address
This statement enables reception of multicast server messages to the
multicast group addresses (type m) specified. Upon receiving a message for the
first time, the multicast client measures the nominal server propagation delay
using a brief client/server exchange with the server, then enters the broadcast
client mode, in which it synchronizes to suceeding multicast messages.
Note that to avoid accidental or malicious disruption in this mode, both the
server and client should use authentication and the same trusted key and key
identifier.
•
manycastserver address
This statement enables reception of manycast client messages to the multicast
group addresses (type m) specified. At least one address is required. The
Internet Assigned Number Association (IANA) has assigned multicast group
address 224.0.1.1 to NTP, but you should use this address only where the
multicast span can be reliably constrained to protect neighbor networks.
In general, you should use group addresses that have been given out by
your administrator, as described in RFC 2365, or GLOP group addresses, as
described in RFC 2770. Note that to avoid accidental or malicious disruption
in this mode, both the server and client should use authentication and the
same trusted key and key identifier.
•
driftfile file-specification
This statement specifies the name of the file used to record the frequency
offset of the local clock oscillator. If the file exists, it is read at startup to
set the initial frequency offset, and then is updated hourly with the current
frequency computed by the NTP server.
If the file does not exist or if the driftfile statement is not specified in the
configuration file, the initial frequency offset is assumed to be zero. If the file
does not exist but the driftfile keyword is specified without a parameter,
the default, SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT is used.
In these cases, it might take some hours for the frequency to stabilize and for
the residual timing errors to subside.
The drift file TCPIP$NTP.DRIFT consists of a single floating-point number
that records the frequency of the offset measured in parts per million (ppm).
•
enable auth | bclient | monitor | ntp | stats
disable auth | bclient | monitor | ntp | stats
These statements enable and disable the following server options:
auth
Controls synchronization with unconfigured peers only if the peer
has been correctly authenticated using a trusted key and key
identifier. By default, auth is enabled.
bclient
Controls the server to listen for messages from broadcast or
multicast servers. By default, bclient is disabled.
monitor
Controls the monitoring facility. By default,
monitor is enabled.
Configuring and Managing NTP 13–9
Configuring and Managing NTP
13.3 Configuring Your NTP Host
•
ntp
Enables the server to adjust its local clock by means of NTP.
If disabled, the local clock free runs at its intrinsic time and
frequency offset. This statement is useful in case the local clock is
controlled by some other device or protocol and NTP is used only
to provide synchronization to other clients. In this case, the local
clock driver can be used to provide this function and also certain
time variables for error estimates and leap indicators. The default
for this flag is enable.
stats
Enables the statistics facility. By default,
stats is enabled.
logconfig configkeyword
This statement controls the amount and type of output written to the system
log file. By default, all output is turned off. All configkeyword keywords can
be prefixed with a plus sign (+) to add messages or a minus sign (-) to remove
messages. Messages can be controlled in four classes (clock, peer, sys,
and sync). Within these classes, four types of messages can be controlled.
Informational messages (info) control configuration information. Event
messages (events) control logging of events (reachability, synchronization,
alarm conditions). Statistics messages (statistics) control statistical output.
The final message group is the status (status) messages. This message group
describes mainly the synchronization status.
Configuration keywords are formed by concatenating the message class with
the event class. The all prefix can be used instead of a message class. A
message class can also be followed by the all keyword to enable or disable
all messages of the respective message class. Therefore, a minimal log
configuration might look like the following example:
logconfig +sysevents +syncstatus
This configuration would list the synchronization state of the NTP server and
the major system events.
For a simple reference server, the following minimum message configuration
might be useful:
logconfig +syncall +clockall
This configuration lists all clock information and synchronization information.
All other events and messages about peers, system events, and so forth, are
suppressed.
•
tinker [panic panic | dispersion dispersion | minpoll minpoll | allan
allan | huffpuff huffpuff]
This statement can be used to alter several system variables in exceptional
circumstances. It should occur in the configuration file before any other
configuration options. The default values of these options have been carefully
optimized for a wide range of network speeds and reliability expectations. In
general, they interact in intricate ways that are hard to predict, and some
combinations can result in unpredictable behavior. It is rarely necessary to
change the default values.
The options operate as follows:
•
panic panic
This option becomes the new value for the panic threshold, normally 1000
seconds. If set to zero, the panic sanity check is disabled and a clock
offset of any value is accepted.
•
dispersion dispersion
13–10 Configuring and Managing NTP
Configuring and Managing NTP
13.3 Configuring Your NTP Host
This option becomes the new value for the dispersion increase rate,
usually .000015.
•
minpoll minpoll
This option becomes the new value for the minimum poll interval used
when configuring a multicast client, a manycast client, and symmetric
passive-mode association. The value defaults to 6 (64 seconds) and has a
lower limit of 4 (16 seconds).
•
allan allan
This option becomes the new value for the minimum Allan intercept,
which is a parameter of the PLL/FLL clock discipline algorithm. The
value defaults to 1024 seconds, which is also the lower limit.
•
huffpuff huffpuff
This option becomes the new value for the experimental huff-n-puff filter
span, which determines the most recent interval that the algorithm will
search for a minimum delay. The lower limit is 900 seconds (15 minutes),
but a more reasonable value is 7200 (2 hours). There is no default, since
the filter is not enabled unless this statement is given.
13.3.2.1 NTP Monitoring Options
TCP/IP Services NTP includes a comprehensive monitoring facility that is
suitable for continuous, long-term recording of server and client timekeeping
performance. Statistics files are managed using file generation sets and scripts.
You can specify the following monitoring commands in your configuration file:
•
statistics name [ ... ]
Enables writing of statistics records. The following is a list of the supported
name statistics:
loopstats
Enables recording of loop filter statistics information. Each update of the
local clock outputs a line of the following form to the file generation set
named loopstats:
48773 10847.650 0.0001307 17.3478 2
The first two fields show the date (Modified Julian Day) and time (seconds
and fraction past UTC midnight). (A Julian Day [JD] begins at noon and
runs until the next noon. The JD number is the number of days [or part
of a day] since noon [UTC] on January 1, 4713 B.C. A Modified Julian
Day [MJD] is the JD minus 2,400,000.5.)
The next three fields show time offset (in seconds), frequency offset (in
parts per million), and time constant of the clock discipline algorithm at
each update of the clock.
peerstats
Enables recording of peer statistics information. This includes statistics
records of all peers of an NTP server and of special signals, where present
and configured. Each valid update appends a line of the following form to
the current element of a file generation set named peerstats:
48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142
Configuring and Managing NTP 13–11
Configuring and Managing NTP
13.3 Configuring Your NTP Host
The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next two fields show
the peer address and status, respectively. The status field is encoded in
hexadecimal. The final three fields show the offset, delay, and dispersion
(in seconds).
clockstats
Enables recording of clock driver statistics information. Each update
received from a clock driver outputs a line in the following form to the file
generation set named clockstats:
49213 525.624 127.127.4.1 93 226 00:08:29.606 D
The first two fields show the date (Modified Julian Day) and time (seconds
and fraction past UTC midnight). The next field shows the clock address.
The final field shows the last time code received from the clock in decoded
ASCII format, where meaningful. In some clock drivers, a good deal of
additional information can be gathered and displayed as well. For further
details, see information specific to each clock.
rawstats
Enables recording of raw timestamps. Each valid update appends a line
in the following form to the file-generation set named rawstats:
51554 79509.68 9.20.208.53 9.20.208.97
3156617109.664603 3156617109.673268 03456142.801203010
3156619216.137622
The first two fields show the date (Modified Julian Day) and time (seconds
and fraction past UTC midnight). The next two fields show the peer and
local addresses. The next four fields are:
*
The origination timestamp
*
The received timestamp
*
The transmitted timestamp (the last one sent to the same peer)
*
The timestamp of the packet’s arrival on the server
statsdir directory-path
Indicates the full path of a directory in which statistics files should be
created.
13.3.2.2 Access Control Options
TCP/IP Services NTP implements a general-purpose address-and-mask based
restriction list. The list is sorted by address and by mask, and the list is searched
in this order for matches. The last match to be found defines the restriction flags
associated with the incoming packets. The source address of incoming packets is
used for the match. The 32-bit address is and’ed with the mask associated with
the restriction entry, and then is compared with the entry’s address (which has
also been and’ed with the mask) to look for a match.
Although this facility might be useful for keeping unwanted or broken remote
time servers from affecting your own, it is not considered an alternative to the
standard NTP authentication facility.
13–12 Configuring and Managing NTP
Configuring and Managing NTP
13.3 Configuring Your NTP Host
13.3.2.2.1 The Kiss-of-Death Packet Ordinarily, packets denied service are
simply dropped with no further action except to increment statistics counters.
Sometimes a more proactive response is needed, such as a server message that
explicitly requests the client to stop sending and leave a message for the system
operator. A special packet format has been created for this purpose called the
kiss-of-death (kod) packet. If the kod flag is set and either service is denied or
the client limit is exceeded, the server returns the packet and sets the leap bits
unsynchronized, stratum 0, and the ASCII string DENY in the reference source
identifier field. If the kod flag is not set, the server simply drops the packet.
A client or peer that receives a kiss-of-death packet performs a set of sanity
checks to minimize security exposure. If this is the first packet received from the
server, the client assumes an access-denied condition at the server. The client
updates the stratum and reference identifier peer variables and sets the accessdenied bit in the peer flash variable. For information about displaying the flash
variable, see Section 13.8.1.2. If this bit is set, the client sends no packets to the
server. If this is not the first packet, the client assumes a client limit condition
at the server but does not update the peer variables. In either case, a message is
sent to the server’s log file.
13.3.2.2.2 Access Control Statements and Flags
statement is as follows:
•
The syntax for the restrict
restrict address [mask mask] [flag][...]
The address argument is the address of a host or network. The mask
argument defaults to 255.255.255.255, meaning that address is treated as
the address of an individual host. A default entry (address 0.0.0.0, mask
0.0.0.0) is always the first entry in the list. The text string DEFAULT with
no mask option can be used to indicate the default entry.
The flag argument always restricts access (that is, an entry with no flags
indicates that free access to the server is to be given). The flags are not
orthogonal in that more restrictive flags often make less restrictive ones
redundant. The flags can generally be classed into two categories: those
that restrict time service and those that restrict informational queries and
attempts to do run-time reconfiguration of the server.
You can specify one or more of the flags shown in the following table:
Table 13–1 Restrict Statement Flags
Flag
Description
kod
ignore
If access is denied, send a kiss-of-death packet.
noquery
Ignore all NTP mode 6 and 7 packets (that is, information
queries and configuration requests, respectively) from the
source. Time service is not affected.
nomodify
Ignore all NTP mode 6 and 7 packets that attempt to modify
the state of the server (that is, run-time reconfiguration).
Queries that return information are permitted.
noserve
Ignore NTP packets whose mode is other than 6 or 7. In effect,
time service is denied, though queries are still permitted.
Ignore all packets from hosts that match this entry. If this flag
is specified, do not respond to queries and time server polls.
(continued on next page)
Configuring and Managing NTP 13–13
Configuring and Managing NTP
13.3 Configuring Your NTP Host
Table 13–1 (Cont.) Restrict Statement Flags
Flag
Description
nopeer
Provide stateless time service to polling hosts, but do not
allocate peer memory resources to these hosts even if they
might be considered useful as future synchronization partners.
notrust
Treat these hosts normally in other respects, but never use
them as synchronization sources.
limited
These hosts are subject to limitation of number of clients
from the same network. In this context, net refers to the IP
notion of net (class A, class B, class C, and so forth). Only
the first clientlimit hosts that respond to the server and
that are active during the last clientperiod seconds are
accepted. Requests from other clients from the same net are
rejected; only time request packets are taken into account.
Query packets sent by the NTPQ and NTPDC programs are
not subject to these limits. A history of clients is kept using
the monitoring capability of the NTP server. Thus, monitoring
is always active as long as there is a restriction entry with the
limited flag.
ntpport
This is actually a match algorithm modifier, not a restriction
flag. Its presence causes the restriction entry to be matched
only if the source port in the packet is the standard NTP UDP
port (123). Both ntpport and non-ntpport can be specified.
The ntpport is considered more specific and is sorted later in
the list.
version
Ignore these hosts if not the current NTP version. Default
restriction list entries, with the flags ignore, interface,
ntpport, for each of the local host’s interface addresses are
inserted into the table at startup to prevent the server from
attempting to synchronize to its own time. A default entry is
also always present if it is otherwise unconfigured. No flags
are associated with the default entry (that is, everything but
your own NTP server is unrestricted).
•
clientlimit limit
The limit argument sets the client_limit variable, which limits the number
of simultaneous access-controlled clients. The default value for this variable
is 3.
•
clientperiod period
The period argument sets the client_limit_period variable that specifies
the number of seconds after which a client is considered inactive and thus no
longer counted for client limit restriction. The default value for this variable
is 3600 seconds.
13–14 Configuring and Managing NTP
Configuring and Managing NTP
13.3 Configuring Your NTP Host
13.3.2.3 Sample NTP Configuration File
A sample of the NTP configuration template follows:
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
File name:
Product:
Version:
TCPIP$NTP.CONF
HP TCP/IP Services for OpenVMS
V5.4
© Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
NTP server configuration file
DESCRIPTION:
This file contains configuration information for the NTP server.
Before starting the NTP server, you must edit this file and copy
it to SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF.
Refer to the HP TCP/IP Services for OpenVMS Management guide for
instructions on editing and using this file.
CONFIGURATION INSTRUCTIONS:
The Network Time Protocol (NTP) provides synchronized timekeeping among
a set of distributed time servers and clients. The local OpenVMS host
maintains an NTP configuration file, TCPIP$NTP.CONF, of participating peers.
TCPIP$NTP.CONF is maintained in the SYS$SPECIFIC:[TCPIP$NTP] directory.
Determine the peer hosts with which the local hosts should negotiate
and synchronize. Include at least one (but preferably three) hosts
that you are certain have the following characteristics:
1. provide accurate time
2. synchronize to Internet Time Servers
(if they are not themselves Internet Time Servers)
The NTP configuration file is not dynamic, and therefore requires
restarting NTP after being edited to make the changes take effect.
However, you can make run-time configuration requests interactively
using the NTPDC utility.
CONFIGURATION:
Your NTP configuration file should always include the following
driftfile entry. The driftfile is the name of the file that stores
the clock drift (also known as frequency error) of the system clock.
driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
#
#
#
#
#
#
#
#
#
#
#
#
#
Samples entries follow below. Replace them with your own list of
hosts and identify the appropriate association mode. If you specify
multiple hosts, NTP can choose the best source with which to
synchronize. This also provides redundancy in case one of the hosts
becomes unavailable.
Client/Server Mode
Client/Server mode indicates that the local host wants to obtain
time from the remote server and is willing to supply time to the
remote server. Indicate Client/Server mode with a peer statement.
Identify each peer with a fully-qualified DNS host name or with an
IP address in dotted-decimal notation.
Configuring and Managing NTP 13–15
Configuring and Managing NTP
13.3 Configuring Your NTP Host
peer 10.1.2.3
peer ntp0.myorg.mycorp.com
peer ntp1.myorg.mycorp.com
#
#
#
#
#
#
#
Client Mode
Client mode indicates that the local host wants to obtain time from
the remote server but it is not willing to provide time to the
remote server. Indicate client mode with the server statement.
Identify each server with a fully-qualified DNS host name or with an
IP address in dotted-decimal notation.
server 10.2.3.4
server 10.3.4.5
server ntp3.myorg.mycorp.com
#
#
#
The following commands allow interoperation of NTP with another time
service such as DTSS. If enabled (by removing #), NTP will not set
the system clock.
# server 127.127.1.0 prefer
# fudge 127.127.1.0 stratum 0
#
#
#
#
#
The following commands allow this node to act as a backup NTP server
(or as the sole NTP server on an isolated network), using its own
system clock as the reference source. If enabled (by removing #),
this NTP server will become active only when all other normal
synchronization sources are unavailable.
# server 127.127.1.0
# fudge 127.127.1.0 stratum 8
13.3.3 Using NTP with Another Time Service
A local host can run more than one time service. For example, a host can have
both NTP and DTSS (Digital Time Synchronization Service) installed. However,
only one of these time services is allowed to set the system clock.
If you are running a time service in addition to NTP, you must stop either the
other time source or NTP from setting the system clock. You can stop NTP from
setting the system clock by adding the following statements to the configuration
file:
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 0
In these statements, the hardware address of the local clock (LOCAL) is
127.127.1.0. These statements force NTP to use its own system clock as a
reference clock. The host continues to respond to NTP time queries but does
not make any adjustments to the system clock, thereby allowing the other time
service to make those changes.
13.4 Configuring NTP as Backup Time Server
You can configure the NTP service as a backup time server. In this case, if all
other network synchronization sources become unavailable, the NTP service
becomes active. You can also use this method to allow the local node to act as
the NTP server in an an isolated network. To configure the NTP service as the
backup server or the sole NTP server, enter the following commands in the NTP
configuration file:
server 127.127.1.0
fudge 127.127.1.0 stratum 8
13–16 Configuring and Managing NTP
Configuring and Managing NTP
13.4 Configuring NTP as Backup Time Server
In this example, the stratum is set to a high number (8) so that it will not
interfere with any other, possibly better, time synchronization source. You should
set the stratum to a number that is higher than the stratum of all other time
synchronization sources.
13.5 NTP Event Logging
NTP maintains a record of system clock updates in the file
SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP_RUN.LOG. NTP reopens this log
file daily, each time creating a new version of the file (older versions are not
automatically purged). Events logged to this file can include the following
messages:
•
Synchronization status that indicates synchronization was lost, stratum
changes, and so forth
•
System time adjustments
•
Time adjustment status
Logging can be increased by using the logconfig option in TCPIP$NTP.CONF. For
more information, see Section 13.3.2.
In addition, you can enable debugging diagnostics by defining the following logical
name with /SYSTEM and a value from 1 through 6, where 6 specifies the most
detailed logging:
$ DEFINE /SYSTEM TCPIP$NTP_LOG_LEVEL n
Table 13–2 describes the messages most frequently included in the NTP log file.
Table 13–2 NTP Log File Messages
Message
Description
Time slew time
Indicates that NTP has set the local clock by slewing
the local time to match the synchronization source. This
happens because the local host is no longer synchronized.
For example:
time slew -0.218843 s
Synchronization lost
This usually occurs after a time reset. All peer filter
registers are cleared, for example, for that particular peer;
all state variables are reset along with the polling interval;
and the clock selection procedure is once again performed.
Couldn’t resolve hostname, giving up on it
Indicates that the host name could not be resolved. This
peer will not be considered for the candidate list of peers.
For example:
couldn’t resolve ’fred’, giving up on it
Send to IP-address: reason
Indicates that a problem occurred while sending a packet
to its destination. The most common reason logged is
‘‘connection refused.’’ For example:
sendto(16.20.208.100): connection refused
(continued on next page)
Configuring and Managing NTP 13–17
Configuring and Managing NTP
13.5 NTP Event Logging
Table 13–2 (Cont.) NTP Log File Messages
Message
Description
Time Correction of delta-time seconds
exceeds sanity limit (1000); set clock
manually to the correct UTC time
NTP has detected a time difference greater than 1000
seconds between the local clock and the server clock.
You must set the clock manually or use the NTPDATE
program and then restart NTP. Once NTP sets the clock, it
continuously tracks the discrepancy between the local time
and NTP time and adjusts the clock accordingly.
offset: n sec freq x ppm poll: y sec error z
An hourly message, in which:
No clock adjustments will be made, DTSS is
active
•
offset is the offset (in seconds) of the peer clock
relative to the local clock (that is, the amount to adjust
the local clock to bring it into correspondence with the
reference clock).
•
freq is the computed error in the intrinsic frequency
of the local clock (also known as ‘‘drift’’) (in parts per
million).
•
poll is the minimum interval (in seconds) between
transmitted messages (that is, messages sent between
NTP peers, as in a client to a server).
•
error is the measure of network jitter (that is,
latencies in computer hardware and software).
Indicates that the DTSS time service is running on the
system. The DTSS time service should be disabled if you
would like NTP to set the system time. To disable the DTSS
time service, enter the following command:
$ RUN SYS$SYSTEM:NCL DISABLE DTSS
Alternatively, you can configure the NTP server not to
make clock adjustments, as described in Section 13.3.3.
NTP dynamically detects whether the DTSS time service is
enabled at any time and will log this message if appropriate.
Clock adjustments will resume. DTSS no
longer active
Indicates that the DTSS time service has been disabled
on the system. NTP will now handle clock adjustments.
NTP dynamically detects whether the DTSS time service is
enabled at any time and will log this message if appropriate.
13.5.1 Sample NTP Log Files
The following sample shows a standard NTP log file that has no extra logging
enabled. Each line of the NTP log file begins with the date, the time, the program
name, and the process identification (PID). The following samples show the
remainder of each log file line.
13–18 Configuring and Managing NTP
Configuring and Managing NTP
13.5 NTP Event Logging
ntpd version = 4.1.0
precision = 976 usec
frequency initialized
time slew 0.148981 s
offset: 0.008022 sec
offset: 0.003190 sec
offset: -0.000622 sec
offset: -0.003216 sec
offset: -0.000899 sec
offset: -0.000299 sec
time slew -0.156010 s
offset: 0.002615 sec
offset: -0.002466 sec
offset: 0.000100 sec
offset: 0.002842 sec
offset: 0.000089 sec
offset: 0.001094 sec
-66.795 from SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
freq: 1.301 ppm
freq: 4.218 ppm
freq: 4.575 ppm
freq: 3.749 ppm
freq: 2.823 ppm
freq: 2.510 ppm
poll: 128 sec error:
0.014056
poll: 256 sec error:
0.007071
poll: 512 sec error:
0.005358
poll: 1024 sec error: 0.005610
poll: 1024 sec error: 0.005710
poll: 1024 sec error: 0.005468
freq: 4.022 ppm
freq: 3.237 ppm
freq: 1.737 ppm
freq: 2.393 ppm
freq: 3.204 ppm
freq: 3.576 ppm
poll: 1024 sec
poll: 1024 sec
poll: 1024 sec
poll: 1024 sec
poll: 1024 sec
poll: 1024 sec
error:
error:
error:
error:
error:
error:
0.005297
0.005626
0.006343
0.006023
0.006199
0.005628
The next sample shows an NTP log file with all categories of logging enabled.
ntpd version = 4.1.0
precision = 976 usec
frequency initialized 3.157 from SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
system event ’event_restart’ (0x01) status ’sync_alarm, sync_unspec, 1 event, event_unspec’ (0xc010)
peer 204.123.2.70 event ’event_reach’ (0x84) status ’unreach, conf, 1 event, event_reach’ (0x8014)
peer 204.123.2.71 event ’event_reach’ (0x84) status ’unreach, conf, 1 event, event_reach’ (0x8014)
peer 16.140.0.12 event ’event_reach’ (0x84) status ’unreach, conf, 1 event, event_reach’ (0x8014)
system event ’event_peer/strat_chg’ (0x04) status ’sync_alarm,sync_ntp, 2 events, event_restart’
(0xc621)
system event ’event_sync_chg’ (0x03) status ’leap_none, sync_ntp, 3 events, event_peer/strat_chg’
(0x634)
system event ’event_peer/strat_chg’ (0x04) status ’leap_none, sync_ntp, 4 events, event_sync_chg’
(0x643)
peer 16.141.40.135 event ’event_reach’ (0x84) status ’unreach,conf, 1 event, event_reach’ (0x8014)
peer 16.141.40.135 event ’event_unreach’ (0x83) status ’unreach, conf, 2 events, event_unreach’
(0x8023)
peer 16.141.40.135 event ’event_reach’ (0x84) status ’unreach,conf, 3 events, event_reach’ (0x8034)
offset: 0.015558 sec freq: 4.407 ppm poll: 128 sec error: 0.008575
peer 16.141.40.135 event ’event_unreach’ (0x83) status ’unreach, conf, 4 events, event_unreach’
(0x8043)
offset: 0.021501 sec freq: 8.734 ppm poll: 512 sec error: 0.015413
peer 16.141.40.135 event ’event_reach’ (0x84) status ’unreach,conf, 5 events, event_reach’ (0x8054)
offset: 0.016173 sec freq: 25.014 ppm poll: 1024 sec error:0.011453
offset: -0.043169 sec freq: 13.291 ppm poll: 1024 sec error: 0.024752
offset: -0.017786 sec freq: 6.005 ppm poll: 1024 sec error:0.025309
13.6 NTP Authentication Support
Authentication support is implemented using the MD5 algorithm to compute a
message digest. The servers involved in an association must agree on the key
and key identifier used to authenticate their messages.
Keys and related information are specified in a key file. Keys are used for:
•
Ordinary NTP associations
•
The NTPQ utility program
•
The NTPDC utility program
Configuring and Managing NTP 13–19
Configuring and Managing NTP
13.6 NTP Authentication Support
13.6.1 NTP Authentication Commands
Table 13–3 describes additional configuration statements and options that support
authentication.
Table 13–3 Authentication Commands
Command
Description
keys keys-file
Specifies the file name for the keys file, which
contains the encryption keys and key identifiers
used by NTP, NTPQ, and NTPDC when operating in
authenticated mode.
trustedkey key-ID [...]
Specifies the encryption key identifiers that are
trusted for the purposes of authenticating peers
suitable for synchronization, as well as keys
used by the NTPQ and NTPDC programs. The
authentication procedures require that the local and
remote servers share the same key ID and key value
for this purpose, although different key values can be
used with different servers. The key-ID argument is
a 32-bit unsigned decimal integer from 1 to 15. Note
that the NTP key 0 indicates an invalid key value
or key identifier; therefore, it should not be used for
any other purpose.
requestkey key-ID
Specifies the key identifier to use with the NTPDC
program, which uses a proprietary protocol specific to
this implementation of NTP. This program is useful
in diagnosing and repairing problems that affect the
operation of NTP. For information about NTPDC, see
Section 13.7.3.
The key-ID argument to this command is an
unsigned 32-bit decimal number that identifies
the trusted key in the keys file. If the requestkey
command is not included in the configuration file,
or if the keys do not match, any request to change a
server variable is denied.
controlkey key-ID
Specifies the key identifier to use with the NTPQ
program, which uses the standard protocol defined
in RFC 1305. This program is useful in diagnosing
and repairing problems that affect the operation
of NTP. For more information about NTPQ, see
Section 13.7.4.
The key-ID argument to this command is a 32-bit
decimal integer that identifies a trusted key in
the keys file. If the controlkey command is not
included in the configuration file, or if the keys do
not match, any request to change a server variable is
denied.
Keys are defined in a keys file, as described in Section 13.6.2.
13–20 Configuring and Managing NTP
Configuring and Managing NTP
13.6 NTP Authentication Support
13.6.2 Authentication Key Format
The NTP service reads keys from a keys file that is specified using the keys
command in the configuration file. You can supply one or more keys from 1 to 15
in the keys file.
Key entries use the following format:
key-ID key-type key-value
Each entry contains the following:
•
key-ID, which is an arbitrary, unsigned 32-bit number (in decimal). The range
of possible values is 1 to 15. Key IDs are specified by the requestkey and
controlkey statements in the configuration file. The key ID number 0 (56
zero bits) is reserved; it is used to indicate an invalid key ID or key value.
•
key-type, which identifies the type of key value. Only one key format, M, is
currently supported. This indicates that the MD5 authentication scheme is
being used.
•
key-value, which is an ASCII string up to 8 characters long. The following
characters are not allowed:
space
pound sign (#)
\t
\n
\0
Because this file contains authorization data, HP recommends that you limit read
access to this file. In particular, you should disable world read access.
The following is a sample keys file:
#
#
4
6
12
M
M
M
DonTTelL
hElloWrl
ImASecrt
13.7 NTP Utilities
NTP provides several utility programs that help you manage and make changes
to the NTP server. These utilities include:
•
NTPDATE, the date and time utility that sets the local date and time by
polling the specified server. Run NTPDATE manually or from the host
startup script to set the clock at boot time before NTP starts.
NTPDATE does not set the date if NTP is already running on the same host.
For information about using NTPDATE, see Section 13.7.1.
•
NTPTRACE, the trace utility that follows the chain of NTP servers back
to their master time source. For information about using NTPTRACE, see
Section 13.7.2.
•
NTPDC, the special query program that provides extensive state and
statistics information and allows you to set configuration options at run time.
Run this program in interactive mode or with command-line arguments.
For information about using NTPDC, see Section 13.7.3.
Configuring and Managing NTP 13–21
Configuring and Managing NTP
13.7 NTP Utilities
•
NTPQ, the standard query program that queries NTP servers about their
current state and requests changes to that state.
For information about using NTPQ, see Section 13.7.4.
•
NTP_GENKEYS, the random key generator program that generates random
keys that are used by the NTP Version 3 and NTP Version 4 symmetric key
authentication scheme.
For information about using NTP_GENKEYS, see Section 13.7.5.
To define the commands described in the following sections, run the following
procedure:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
13.7.1 Setting the Date and Time with NTPDATE
The NTPDATE program sets the local date and time by polling a specified server
or servers to determine the correct time. A number of samples are obtained from
each of the servers specified, and a subset of the NTP clock filter and selection
algorithms are applied to select the best samples. The accuracy and reliability
of NTPDATE depends on the number of servers it polls, the number of polls it
makes each time it runs, and the interval length between runs.
Run NTPDATE manually to set the host clock or from the host startup file to set
the clock at boot time. In some cases, it is useful to set the clock manually before
you start NTP. The NTPDATE program makes time adjustments (called ‘‘stepping
the time’’) by calling the OpenVMS routine SYS$SETIME.
Note
NTPDATE does not set the date and time if an NTP server is running on
the same host.
Enter specific commands using the following format:
NTPDATE [option...] host [host...]
For example, the following command sets the clock based on the time provided
from one of the specified hosts (BIRDY, OWL, or FRED):
$ NTPDATE BIRDY OWL FRED
NTP sets the date and time by polling the servers you specify as arguments to
the command. Samples are obtained from each of the specified servers. NTP then
analyzes the results to select the best server to use as a time source. Table 13–4
describes the NTPDATE command options.
Table 13–4 NTPDATE Options
Option
Description
-d
-o version
Changes the time and prints information useful for debugging.
Specifies the NTP version (1, 2, or 3) for outgoing packets (for
compatibility with older versions of NTP). Version 4 is the default.
(continued on next page)
13–22 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
Table 13–4 (Cont.) NTPDATE Options
Option
Description
-p n
Specifies the number of samples NTPDATE acquires from each server.
The default is 4. You can specify from 1 to 8.
-q
Specifies a query only; does not set the clock.
13.7.2 Tracing a Time Source with NTPTRACE
Use the NTPTRACE utility to determine the source from which an NTP server
obtains its time. NTPTRACE follows the chain of time servers back to the master
time source.
Use the following syntax when entering commands:
NTPTRACE [option...]
The following example shows output from an NTPTRACE command. In the
following example, the chain of servers is from the local host to the stratum 1
server FRED, which is synchronizing to a GPS reference clock:
$ NTPTRACE
LOCALHOST: stratum 3, offset -0.000000, synch distance1.50948
parrot.birds.com: stratum 2, offset -0.126774, synch distance 0.00909
fred.birds.com: stratum 1, offset -0.129567, synch distance 0.00168,
refid ’GPS’
All times are in seconds. The output fields on each line are as follows:
•
Host name
•
Host stratum
•
Time offset between the host and the local host (not always zero for
LOCALHOST).
•
Synchronization distance
•
Reference clock ID (only for stratum 1 servers)
Table 13–5 describes the NTPTRACE command options.
Table 13–5 NTPTRACE Options
Option
Description
-d
-n
Enables debugging output.
-r retries
Sets the number of retransmission attempts for each host. The default
is 5.
-t timeout
-v
Sets the retransmission timeout (in seconds). The default is 2.
Displays IP addresses instead of host names. This may be necessary if
a name server is down.
Displays additional information about the NTP servers.
Configuring and Managing NTP 13–23
Configuring and Managing NTP
13.7 NTP Utilities
13.7.3 Making Run-Time Requests with NTPDC
You can make run-time changes to NTP with query commands by running the
NTPDC utility. NTPDC displays time values in seconds.
Run-time requests are always authenticated requests. Authentication not only
provides verification that the requester has permission to make such changes, but
also gives an extra degree of protection against transmission errors.
The reconfiguration facility works well with a server on the local host and
between time-synchronized hosts on the same LAN. The facility works poorly
for more distant hosts. Authenticated requests include a timestamp. The server
compares the timestamp to its receive timestamp. If they differ by more than a
small amount, the request is rejected for the following reasons:
•
To make it more difficult for an intruder to overhear traffic on your LAN.
•
To make it more difficult for topologically remote hosts to request
configuration changes to your server.
To run NTPDC, enter the following command:
$ NTPDC
NTPDC>
At the NTPDC> prompt, enter the appropriate type of command from the
following list:
•
Interactive commands
•
Control commands
•
Run-time configuration request commands
The following sections describe the NTPDC commands.
13.7.3.1 NTPDC Interactive Commands
Interactive commands consist of a command name followed by one or more
keywords. The interactive commands include:
•
help [command-keyword]
Enter a question mark (?) to display a list of all the command keywords
known to this version of NTPDC. Enter a question mark followed by a
command keyword to display information about the function and use of the
command.
•
host hostname
Sets the host to which future queries will be sent. The hostname can be either
a host name or a numeric address.
•
hostnames [ yes | no ]
If you specify yes, host names are displayed. If you specify no, numeric
addresses are displayed. The default is yes unless you include the -n option
on the command line, as described in Table 13–5.
•
keyid key-ID
Specifies the key number to be used to authenticate configuration requests.
This must correspond to a key number the server has been configured to use
for this purpose.
•
quit
Exits NTPDC.
13–24 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
•
passwd
Prompts you to enter a password (not echoed) to be used to authenticate
configuration requests. The password must correspond to the key configured
for use by the NTP server for this purpose.
•
timeout milliseconds
Specify a timeout period for responses to server queries. The default is about
8000 milliseconds (8 seconds). Because NTPDC retries each query once after
a timeout, the total waiting time for a timeout is twice the timeout value set.
13.7.3.2 NTPDC Control Message Commands
Control message commands request information about the server. These are
read-only commands in that they make no modification of the server configuration
state.
The NTPDC control message commands include:
•
listpeers
Displays a brief list of the peers for which the server is maintaining state.
These include all configured peer associations as well as peers whose stratum
is such that the server considers them to be possible future synchronization
candidates.
•
peers
Obtains a list of peers for which the server is maintaining state, along with a
summary of that state. The summary information includes:
The address of the remote peer
The local interface address (0.0.0.0 if a local address has not been
determined)
The stratum of the remote peer (a stratum of 16 indicates the remote peer
is unsynchronized)
The polling interval (in seconds)
The reachability register (in octal)
The current estimated delay, offset, and dispersion of the peer (in
seconds)
In addition, the character in the left margin indicates the operating mode of
this peer entry, as follows:
Plus sign (+) denotes symmetric active.
Minus sign (-) indicates symmetric passive.
Equals sign (=) means the remote server is being polled in client mode.
Up arrow (^) indicates that the server is broadcasting to this address.
Tilde (~) denotes that the remote peer is sending broadcasts.
Asterisk (*) marks the peer to which the server is currently
synchronizing.
The contents of the host field can be one of the following four forms:
Host name
IP address
Reference clock implementation name with its parameter
REFCLK (implementation number parameter)
Configuring and Managing NTP 13–25
Configuring and Managing NTP
13.7 NTP Utilities
If you specify hostnames no, only IP addresses are displayed.
•
dmpeers
Displays a slightly different peer summary list, identical to the output of the
peers command except for the character in the leftmost column. Characters
appear only beside peers that were included in the final stage of the clock
selection algorithm:
Dot (.) indicates that this peer was rejected in the ‘‘falseticker’’ detection.
Plus sign (+) indicates that the peer was accepted.
Asterisk (*) denotes the peer to which the server is currently
synchronizing.
•
showpeer peer-address [...]
Shows a detailed display of the current peer variables for one or more peers.
•
pstats peer-address [...]
Shows per-peer statistics counters associated with the specified peers.
•
loopinfo [ oneline | multiline ]
Displays the values of selected loop-filter variables. The loop filter is the part
of NTP that adjusts the local system clock. These options include:
offset — the last offset given to the loop filter by the packet processing
code.
frequency — the frequency error of the local clock (in parts per million).
time_const — controls the stiffness of the phase-lock loop and, therefore,
the speed at which it can adapt to oscillator drift.
watchdog timer — the number of seconds that have elapsed since the last
sample offset was given to the loop filter.
The oneline and multiline options specify the format in which this
information is to be displayed; multiline is the default.
•
sysinfo
Displays a variety of system state variables, such as the state related to the
local server. These variables include:
system flags — shows various system flags, some of which can be set and
cleared by the enable and disable configuration commands, respectively.
These are the auth, bclient, monitor, ntp, and stats flags.
stability — the residual frequency error remaining after the system
frequency correction is applied. It is intended for maintenance and
debugging.
broadcastdelay — shows the default broadcast delay as set by the
broadcastdelay configuration command.
authdelay — shows the default authentication delay as set by the
authdelay configuration command.
•
sysstats
Displays statistics counters maintained in the protocol module.
•
memstats
Displays statistics counters related to memory allocation code.
13–26 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
•
iostats
Displays statistics counters maintained in the input/output module.
•
timerstats
Displays statistics counters maintained in the timer/event queue support
code.
•
reslist
Displays the server’s restriction list. This list is displayed in the order in
which the restrictions are applied.
•
monlist [ version]
Displays traffic counts collected. This information is maintained by the
monitor facility. Normally you do not need to specify the version number.
13.7.3.3 NTPDC Request Commands
The following commands make authenticated requests:
•
addpeer peer-address key-ID [version] [prefer]
Adds a configured peer association at the given address and operates in
symmetric active mode. The existing association with the same peer can be
deleted when this command is executed or can be converted to conform to the
new configuration.
The key-ID is the key identifier for requestkey, as described in Table 13–3.
All outgoing packets to the remote server have an authentication field
attached that is encrypted with this key.
The value for version can be 1, 2, 3 or 4. The default is Version 4.
The prefer keyword indicates a preferred peer that will be used for clock
synchronization, if possible.
•
addserver peer-address key-ID [version] [prefer]
This command is the same as addpeer except that the operating mode is
client.
•
broadcast peer-address key-ID [version] [prefer]
This command is the same as addpeer except that the operating mode is
broadcast. In this case, a valid key identifier and key value are required.
The peer-address parameter can be either the broadcast address of the local
network or a multicast group address assigned to NTP.
•
unconfig peer-address [...]
Causes the configured bit to be removed from the specified remote peer.
This command deletes the peer association. When appropriate, however, the
association may persist in an unconfigured mode if the remote pee continues
in this fashion.
•
enable [flag] [...]
disable [flag] [...]
These commands operate in the same way as the enable and disable
configuration commands. For details, see Section 13.3.2.
•
fudge peer-address [time1] [time2] [stratum stratum] [refID]
Provides a way to set time, stratum, and identification data for a reference
clock. (The TCP/IP Services product supports only the local reference clock.)
Configuring and Managing NTP 13–27
Configuring and Managing NTP
13.7 NTP Utilities
Use the following syntax to enter the NTPDC foreign command:
NTPDC [-i] [-l] [-n] [-p] [-s] [-c command][host1,host2,...]
Table 13–6 describes the NTPDC options.
Table 13–6 NTPDC Options
Option
Description
-c command
The command argument is interpreted as an interactive format
command and is added to the list of commands to be executed on
the specified hosts. You can specify multiple -c options.
-i
-l
-n
Forces NTPDC to operate in interactive mode.
-p
Displays a list of the peers known to the server as well as a summary
of their state.
-s
Displays a list of the peers known to the server as well as a summary
of their state. Uses a slightly different format than the -p option.
Obtains a list of peers that are known to the servers.
Displays all host addresses in numeric format rather than converting
them to host names.
13.7.4 Querying the NTP Server with NTPQ
The NTPQ program allows you to query the NTP server about its current state
and to request changes to that state. NTPQ can also obtain and display a list of
peers in a common format by sending multiple queries to the server.
The NTPQ program authenticates requests based on the key entry in the keys
file that is configured using the controlkey command (described in Table 13–3).
The NTPQ program uses NTP mode 6 packets to communicate with the NTP
server; therefore, NTPQ can query any compatible server on the network.
Because NTP is a UDP protocol, this communication is somewhat unreliable over
long distances (in terms of network topology). The NTPQ program makes one
attempt to restransmit requests and times out requests if the remote host does
not respond within the expected amount of time. NTPQ displays time values in
milliseconds.
To run the NTPQ program, enter the following command:
$ NTPQ
NTPQ>
At the NTPQ> prompt, enter commands in the following syntax:
command [options...]
The following commands allow you to query and set NTP server state information:
•
? [command-keyword]
A question mark (?) by itself prints a list of all the command keywords known
to this version of NTPQ. A question mark followed by a command keyword
prints function and usage information about the command.
•
addvars variable-name[=value] [,...]
•
rmvars variable-name [,...]
•
clearvars
13–28 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
The data carried by NTP mode 6 messages consists of a list of items in the
following form:
variable-name=value
In requests to the server to read variables, the =value portion is ignored
and can be omitted. The NTPQ program maintains an internal list in which
data to be included in control messages can be assembled and sent using the
readlist and writelist commands. The addvars command allows variables
and their optional values to be added to the list. If you want to add more
than one variable, separate the list items by commas and do not include
blank spaces. The rmvars command removes individual variables from the
list, while the clearvars command removes all variables from the list.
•
authenticate yes | no
By default, NTPQ does not authenticate requests unless they are
write requests. The authenticate yes command causes NTPQ to send
authentication with all requests it makes. Authenticated requests cause some
servers to handle requests slightly differently. To prevent any mishap, do a
peer display before turning on authentication.
•
cooked
Reformats variables that are recognized by the server. Variables that NTPQ
does not recognize are marked with a trailing question mark (?).
•
debug more | less | no
Adjusts the level of NTPQ debugging. The default is debug no.
•
help
Displays the list of NTPQ interactive commands. This is the same as entering
a question mark (?).
•
host [hostname]
Sets the host to which future queries will be sent; host-name can be either a
host name or an Internet address. If host-name is not specified, the current
host is used.
•
hostnames yes | no
If yes is specified, displays host names in information displays. If no is
specified, displays Internet addresses instead. The default is hostnames yes.
The default can be modified using the command line option -n.
•
key-ID n
Specifies the key ID number to be used to authenticate configuration requests.
This must correspond to a key ID number the server has been configured to
use for this purpose.
•
keytype md5 | des
Sets the authentication key to either MD5 or DES. Only MD5 is supported in
this implementation.
•
ntpversion 1 | 2 | 3 | 4
Sets the NTP version number that NTPQ claims in packets. The default is
Version 4. Mode 6 control messages (as well as modes) did not exist in NTP
Version 1.
Configuring and Managing NTP 13–29
Configuring and Managing NTP
13.7 NTP Utilities
•
passwd
Prompts you to enter a password (not echoed) to be used to authenticate
configuration requests. The password must correspond to the key value
configured for use by the NTP server for this purpose (see Section 13.6.2).
•
quit
Exits NTPQ.
•
raw
Displays all output from query commands as received from the remote server.
The only data formatting performed is to translate non-ASCII data into a
printable form.
•
timeout milliseconds
Specifies a timeout period for responses to server queries. The default is
about 5000 milliseconds. Since NTPQ retries each query once after a timeout,
the total waiting time for a timeout is twice the timeout value.
13.7.4.1 NTPQ Control Message Commands
Each peer known to an NTP server has a 16-bit integer association identifier
assigned to it. NTP control messages that carry peer variables must identify
the peer that the values correspond to by including the peer’s association ID. An
association ID of zero indicates the variables are system variables whose names
are drawn from a separate name space.
Control message commands result in one or more NTP mode 6 messages being
sent to the server, and cause the data returned to be displayed in a format that
you control using the commands listed in Section 13.7.4. Most control message
commands send a single message and expect a single response. The exceptions
are the peers command, which sends a preprogrammed series of messages to
obtain the data it needs, and the mreadlist and mreadvar commands, which are
repeated for each specified association.
•
associations
Displays a list of association identifiers and peer status for recognized peers
of the server being queried. The list is printed in columns. The first of
these is an index that numbers the associations from 1 for internal use; the
second is the actual association identifier returned by the server; and the
third is the status word for the peer. This list is followed by a number of
columns containing data decoded from the status word. The data returned
by the associations command is cached internally in NTPQ. The index is
then used when dealing with servers that use association identifiers. For any
subsequent commands that require an association identifier as an argument,
the index can be used as an alternative.
•
lassociations
Obtains and displays a list of association identifiers and peer status for all
associations for which the server is maintaining state. This command differs
from the associations command only for servers that retain state for outof-spec client associations. Normally such associations are omitted from the
display when the associations command is used but are included in the
output of the lassociations command.
13–30 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
•
lopeers
Obtains and displays a list of all peers and clients having the destination
address.
•
lpassociations
Displays data for all associations, including unrecognized client associations,
from the internally cached list of associations.
•
lpeers
Similar to peers except that a summary of all associations for which the
server is maintaining state is displayed. This command can produce a much
longer list of peers.
•
mreadlist assocID assocID
Similar to the readlist command except that the query is done for each
of a range of (nonzero) association IDs. This range is determined from the
association list cached by the most recent associations command.
•
mreadvar assocID assocID [variable-name[=value] [,...] ]
Similar to the readvar command except that the query is done for each of
a range of (nonzero) association IDs. This range is determined from the
association list cached by the most recent associations command.
•
opeers
An old form of the peers command, with the reference ID replaced by the
local interface address.
•
passociations
Displays association data concerning recognized peers from the internally
cached list of associations. This command performs identically to the
associations command except that it displays the internally stored data
rather than make a new query.
•
peers
Displays a list of recognized peers of the server, along with a summary of
each peer’s state. Summary information includes the address of the remote
peer; the reference ID (0.0.0.0 if the reference ID is unknown); the stratum of
the remote peer; the polling interval (in seconds); the reachability register (in
octal); and the current estimated delay, offset, and dispersion of the peer (in
milliseconds).
The character in the left margin indicates the fate of this peer in the clock
selection process. The codes are as follows:
Table 13–7 Peer State Symbols
Symbol
Indicates
Space
The peer was discarded, because of high stratum or
failed sanity checks.
Lowercase x
The peer was designated a ‘‘falseticker’’ by the
intersection algorithm.
(continued on next page)
Configuring and Managing NTP 13–31
Configuring and Managing NTP
13.7 NTP Utilities
Table 13–7 (Cont.) Peer State Symbols
Symbol
Indicates
Dot (.)
The peer was culled from the end of the candidate
list.
Hyphen (-)
The peer was discarded by the clustering algorithm.
Plus sign (+)
The peer was included in the final selection set.
Pound sign (#)
The peer was selected for synchronization, but the
distance exceeds the maximum.
Asterisk (*)
The peer was selected for synchronization.
Because the peers command depends on the ability to parse the values in
the responses it gets, it might fail to work with servers that control the data
formats poorly.
The contents of the host field can be in one of four forms: a host name, an
IP address, a reference clock implementation name with its parameter, or
REFCLK (implementation number parameter). If you specified hostnames no,
the IP addresses are displayed.
•
pstatus assocID
Sends a read status request to the server for the given association. The
names and values of the peer variables returned are printed. The status word
from the header is displayed preceding the variables, both in hexadecimal and
in English.
•
readlist [assocID]
Requests that the server return the values of the variables in the internal
variable list. If the association ID is omitted or is zero, the variables
are assumed to be system variables. Otherwise, they are treated as peer
variables. If the internal variable list is empty, a request is sent without
data; the remote server should return a default display.
•
readvar [assocID] [variable-name[=value] [,...]]
Requests that the values of the specified variables be returned by the server
by sending a read variables request. If the association ID is omitted or is
zero, the variables are system variables; otherwise, they are peer variables,
and the values returned are those of the corresponding peer. If the variable
list is empty, a request is sent without data; the remote server should return
a default display.
•
showvars
Displays the variables on the variable list.
•
version
Displays the NTPQ version number.
•
writelist [assocID]
Like the readlist request except that the internal list variables are written
instead of read.
•
writevar assocID variable-name=value [,...]
Like the readvar request except that the specified variables are written
instead of read.
13–32 Configuring and Managing NTP
Configuring and Managing NTP
13.7 NTP Utilities
Use the following syntax to enter the NTPQ foreign command:
NTPQ [-i] [-n] [-p] [-c command] [host1,host2,...]
Table 13–8 describes the NTPQ options.
Table 13–8 NTPQ Options
Option
Description
-c command
Adds the specified interactive command to the list of commands to be
executed on the specified host. You can enter multiple -c options on
the command line.
-i
Forces NTPQ to operate in interactive mode. This is the default mode
of operation.
-n
Displays host addresses numeric format rather than converting them
to host names.
-p
Displays a list of the peers known to the server as well as a summary
of their state.
The -c and -p options send the query to the specified host immediately. If you
omit the host names, the default is the local host. To enter interactive mode,
specify the -i or -n option.
13.7.5 Generating Random Keys with NTP_GENKEYS
The NTP_GENKEYS program allows you to generate random keys used by
the NTP Version 3 and NTP Version 4 symmetric key authentication scheme.
By default, the program generates the TCPIP$NTP.KEYS file containing 16
random symmetric keys. A timestamp is appended to the file name. Because the
algorithms are seeded by the system clock, each run of the program produces a
different file and file name.
The TCPIP$NTP.KEYS file contains 16 MD5 keys. Each key consists of 16
characters randomized over the ASCII 95-character printing subset. The file
is read by the NTP server at the location specified by the keys configuration
file command. An additional key consisting of an easily remembered password
should be added manually for use with the NTPQ and NTPDC programs. The file
must be distributed by secure means to other servers and clients that share the
same security compartment. The key identifier for the MD5 program uses only
identifiers 1 through 16. The key identifier for each association is specified as the
key argument in the server or peer configuration file command.
13.8 Solving NTP Problems
Some common NTP problems include:
•
System clock not synchronized.
NTP cannot synchronize a clock that is off by more than 1000 seconds. To
solve this problem, set the clock using NTPDATE, then restart NTP.
•
NTPDATE fails to set the clock.
This occurs if NTP is already running.
•
More than one service is actively setting the system clock.
NTP can run with other time services but must be explicitly instructed not to
set the system clock. NTP can still provide synchronization to other clients
even if it is not updating the system clock.
Configuring and Managing NTP 13–33
Configuring and Managing NTP
13.8 Solving NTP Problems
•
NTP appears to be running without error, but the system clock is off by a
one-, two-, three-, or four-hour interval.
You might need to adjust the time zone differential. For more information,
please consult the OpenVMS documentation set.
13.8.1 NTP Debugging Techniques
Once the configuration file has been created and edited, the next step is to verify
correct operation and then fix any resulting problems.
13.8.1.1 Initial Startup
The best way to verify correct operation is by using the NTPQ and NTPDC
programs, either on the server itself or from another machine elsewhere in the
network. The NTPQ program implements the management functions specified in
the NTP specification RFC 1305, Appendix A. The NTPDC program implements
additional functions not provided in the standard. Both programs can be used to
inspect the state variables defined in the specification and, in the case of NTPDC,
additional ones of interest. In addition, the NTPDC program can be used to
selectively reconfigure and enable or disable some functions while the server is
running. Problems are apparent in the server’s log file. The log file should show
the startup banner, some brief initialization data, and the computed precision
value.
Another common problem is incorrect DNS names. Check that each DNS name
used in the configuration file exists and that the address responds to the ping
command. When the server is first started it normally polls the servers listed
in the configuration file at 64-second intervals. To allow a sufficient number
of samples for the NTP algorithms to discriminate reliably between correctly
operating servers and possible intruders, at least four valid messages from the
majority of servers and peers listed in the configuration file are required before
the server can set the local clock. However, if the difference between the client
time and server time is greater than the panic threshold (which defaults to
1000 seconds), the server sends a message to the server log and shuts down
without setting the clock. It is necessary to set the local clock to within the panic
threshold first, either manually by wristwatch and the SET TIME command, or
by using the NTPDATE command. The panic threshold can be changed by the
tinker panic statement.
13.8.1.2 Verifying Correct Operation
After starting the server, run the NTPQ program with the -n switch to avoid
distractions because of name resolution problems. Use the peer command to
display a list showing the status of configured peers and other clients trying to
access the server. After operating for a few minutes, the display should look
similar to the following:
NTPQ> peer
remote
refid
st t when poll reach delay offset jitter
=====================================================================
-isipc6.cairn.ne .GPS1.
1 u 18 64 377 65.592 -5.891 0.044
+saicpc-isiepc2. pogo.udel.edu 2 u 241 128 370 10.477 -0.117 0.067
+uclpc.cairn.net pogo.udel.edu 2 u 37 64 177 212.111 -0.551 0.187
*pogo.udel.edu .GPS1.
1 u 95 128 377 0.607 0.123 0.027
The host names or addresses shown in the remote column correspond to the
server and peer entries listed in the configuration file; however, the DNS names
might not agree if the names listed are not the canonical DNS names. The refid
column shows the current source of synchronization; the st column shows the
stratum; the t column shows the type (u = unicast, m = multicast, l = local, - =
13–34 Configuring and Managing NTP
Configuring and Managing NTP
13.8 Solving NTP Problems
don’t know); and the poll column shows the poll interval in seconds. The when
column shows the time (in seconds) since the peer was last heard, and the reach
column shows the status of the reachability register (in octal) (see RFC 1305).
The remaining entries show the latest delay, offset, and jitter (in milliseconds).
Note that, in NTP Version 4, what used to be the dispersion column is replaced
by the jitter column.
The symbol at the left margin displays the synchronization status of each peer.
The currently selected peer is marked with an asterisk (*), while additional peers
that are not currently selected but are designated acceptable for synchronization
are marked with a plus sign (+). Peers marked with * and + are included in the
weighted average computation to set the local clock; the data produced by peers
marked with other symbols are discarded. See Table 13–7 for the meaning of
these symbols.
Additional details for each peer can be determined by the following procedure.
First, use the associations command to display an index of association identifiers,
as shown in the following example:
NTPQ> associations
ind assID status conf reach auth condition last_event cnt
===========================================================
1 50252 f314 yes yes ok
outlyer reachable 1
2 50253 f414 yes yes ok candidat reachable 1
3 50254 f414 yes yes ok candidat reachable 1
4 50255 f614 yes yes ok sys.peer reachable 1
Each line in this display is associated with the corresponding line in the preceding
peer display. The assID column shows the unique identifier for each mobilized
association, and the status column shows the peer status word (in hexadecimal),
as defined in the NTP specification.
Next, use the readvar command and the respective assID identifier to display a
detailed synopsis for the selected peer, as shown in the following example:
NTPQ> readvar 50253
status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach,
srcadr=saicpc-isiepc2.cairn.net, srcport=123, dstadr=140.173.1.46,
dstport=123, keyid=3816249004, stratum=2, precision=-27,
rootdelay=10.925, rootdispersion=12.848, refid=pogo.udel.edu,
reftime=bd11b225.133e1437 Sat, Jul 8 2000 13:59:01.075, delay=10.550,
offset=-1.357, jitter=0.074, dispersion=1.444, reach=377, valid=7,
hmode=1, pmode=1, hpoll=6, ppoll=7, leap=00, flash=00 ok,
org=bd11b23c.01385836 Sat, Jul 8 2000 13:59:24.004,
rec=bd11b23c.02dc8fb8 Sat, Jul 8 2000 13:59:24.011,
xmt=bd11b21a.ac34c1a8 Sat, Jul 8 2000 13:58:50.672,
filtdelay= 10.45 10.50 10.63 10.40 10.48 10.43 10.49 11.26,
filtoffset= -1.18 -1.26 -1.26 -1.35 -1.35 -1.42 -1.54 -1.81,
filtdisp=
0.51 1.47 2.46 3.45 4.40 5.34 6.33 7.28,
This example was chosen to illustrate one of the most complex configurations
involving symmetric modes. As the result of debugging experience, the names
and values of these variables might change from time to time. The fields in this
display include most variables defined in the NTP Version 3 specification, as well
as those defined for NTP Version 4.
A useful indicator of miscellaneous problems is the flash value, which reveals
the state of the various sanity tests on incoming packets. There are currently
eleven bits, one for each test, numbered from right to left. If the test fails, the
corresponding bits are set to 1 and 0. If any bit is set following each processing
step, the packet is discarded.
Configuring and Managing NTP 13–35
Configuring and Managing NTP
13.8 Solving NTP Problems
The three lines identified as filtdelay, filtoffset, and filtdisp reveal
the round-trip delay, clock offset and dispersion for each of the last eight
measurement rounds (all in milliseconds). Note that the dispersion, which is
an estimate of the error, increases as the age of the sample increases. From
these data, it is usually possible to determine the incidence of severe packet loss,
network congestion, and unstable local clock oscillators. Every case is unique;
however, if one or more of the rounds show large values or change radically from
one round to another, the network is probably congested or experiencing loss.
Once the server has set the local clock, it continuously tracks the discrepancy
between local time and NTP time and adjusts the local clock accordingly. This
adjustment consists of two components: time and frequency. Adjustments to time
and frequency are determined automatically by the clock discipline algorithm,
which functions as a hybrid phase/frequency feedback loop. The behavior of
this algorithm is controlled carefully to minimize residual errors resulting from
normal network jitter and frequency variations of the local clock hardware
oscillator. However, when started for the first time, the algorithm may take some
time to converge on the intrinsic frequency error of the host machine.
The state of the local clock itself can be determined using the readvar statement
(without the argument), as shown in the following example:
NTPQ> readvar
status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.0.99j4-r Fri Jul 7 23:38:17 GMT 2002 (1)",
processor="i386", system="FreeBSD3.4-RELEASE", leap=00, stratum=2,
precision=-27, rootdelay=0.552, rootdispersion=12.532, peer=50255,
refid=pogo.udel.edu,
reftime=bd11b220.ac89f40a Sat, Jul 8 2002 13:58:56.673, poll=6,
clock=bd11b225.ee201472 Sat, Jul 8 2002 13:59:01.930, state=4,
phase=0.179, frequency=44.298, jitter=0.022, stability=0.001,
hostname="barnstable.udel.edu", publickey=3171372095,
params=3171372095,
refresh=3172016539
An explanation of most of these variables is in the RFC 1305 specification. The
most useful variables are clock, which shows when the clock was last adjusted,
and reftime, which shows when the server clock of refid was last adjusted.
The mean millisecond time offset (phase) and deviation (jitter) monitor the
clock quality, and the mean Ppm frequency offset (frequency) and deviation
(stability) monitor the clock stability and serve as useful diagnostic tools. NTP
operators have found that these data represent useful environment and hardware
alarms. If the motherboard fan or some hardware bit malfunctions, the system
clock is usually the first to reflect these problems.
When nothing seems to happen in the peer display after several minutes, it
might indicate a network problem. One common network problem is an accesscontrolled router on the path to the selected peer, or an access-controlled server
using methods described in Section 13.3.2.2. Another common problem is that the
server is down or is running in unsynchronized mode because of a local problem.
Use the NTPQ program to look at the server variables in the same way you look
at your own.
13–36 Configuring and Managing NTP
Configuring and Managing NTP
13.8 Solving NTP Problems
13.8.1.3 Special Problems
The frequency tolerance of computer clock oscillators can vary widely, which
can put a strain on the server’s ability to compensate for the intrinsic frequency
error. While the server can handle frequency errors up to 500 parts per million
(ppm), or 43 seconds per day, values much higher than 100 ppm reduce the
headroom and increase the time to identify the particular value and record it in
the TCPIP$NTP.DRIFT file. In extreme cases, before the particular oscillator
frequency error has been determined, the residual system time offsets can sweep
from one extreme to the other of the 128-millisecond tracking window only for
the behavior to repeat at 900-second intervals until the measurements have
converged.
To determine whether excessive frequency error is occurring, observe the nominal
filtoffset values for a number of rounds and divide by the poll interval. If the
result is approximately 500 ppm, NTP probably will not work properly until the
frequency error is reduced.
A common cause of this problem is the hardware time-of-year (TOY) clock chip,
which must be disabled when NTP disciplines the software clock.
If the TOY chip is not the cause, the problem might be that the hardware clock
frequency is too slow or too fast.
NTPD provides for access controls that deflect unwanted traffic from selected
hosts or networks. The controls described in Section 13.3.2.2 include detailed
packet filter operations based on source address and address mask. Normally,
filtered packets are dropped without notice other than to increment tally counters.
However, the server can be configured to generate a kiss-of-death (kod) packet to
be sent to the client. If outright access is denied, the kod is the response to the
first client packet. In this case, the client association is permanently disabled and
the access-denied bit is set in the flash peer variable, and a message is sent to
the server’s log file.
The access control provisions include a limit on the packet rate from a host or
network. If an incoming packet exceeds the limit, it is dropped and a kod is sent
to the source. If this occurs after the client association has synchronized, the
association is not disabled, but a message is sent to the system log. For more
information, see Section 13.3.2.2.
13.8.1.4 Debugging Checklist
If the NTPQ or NTPDC programs do not show that messages are being received
by the server or that received messages do not result in correct synchronization,
verify the following:
1. Check the TCPIP$NTP_RUN.LOG log file for messages about configuration
errors, name lookup failures, or initialization problems.
2. Using ping or other utilities,verify that packets actually do make the round
trip between the client and server. Using dig or other utilities, verify that the
DNS server names do exist and resolve to valid Internet addresses.
3. Using the NTPDC program, verify that the packets received and packets sent
counters are incrementing. If the sent counter does not increment and the
configuration file includes configured servers, something might be wrong in
the host network or the interface configuration. If this counter does increment
but the received counter does not increment, something might be wrong in the
network, the remote server NTP server might not be running, or the server
itself might be down or not responding.
Configuring and Managing NTP 13–37
Configuring and Managing NTP
13.8 Solving NTP Problems
4. If both the sent and received counters do increment but the reach values in
the peer display with NTPQ continues to show zero, received packets are
probably being discarded. If this is the case, the cause should be evident from
the flash variable.
5. If the reach values in the peer display show that the servers are alive and
responding, note the symbols at the left margin that indicate the status of
each server resulting from the various grooming and mitigation algorithms.
After a few minutes of operation, one of the reachable server candidates
should show an asterisk (*). If this does not happen, the intersection
algorithm, which classifies the servers as ‘‘truechimers’’ or ‘‘falsetickers’’,
might be unable to find a majority of ‘‘truechimers’’ among the server
population.
13–38 Configuring and Managing NTP
14
Configuring and Managing SNMP
The Simple Network Management Protocol (SNMP) is network management
technology that facilitates the management of a TCP/IP network or internet in a
vendor-independent manner. SNMP enables a network administrator to manage
the various network components using a set of well-known procedures understood
by all components, regardless of the vendor that manufactured them.
Configuring SNMP on your OpenVMS system allows a remote SNMP
management client to obtain information about your host and to set system and
network parameters.
This chapter reviews key concepts of SNMP and describes:
•
How to manage the SNMP service (Section 14.2)
•
How to verify the installation of SNMP (Section 14.3)
•
How to configure SNMP (Section 14.4)
•
SNMP log files (Section 14.5)
•
How to solve SNMP problems (Section 14.6)
For information about writing programs using SNMP, refer to the Compaq
TCP/IP Services for OpenVMS SNMP Programming and Reference guide.
14.1 Key Concepts
Systems using SNMP are divided into two categories:
•
Management consoles, sometimes called clients, network management
stations, or directors
•
Agents, sometimes called servers
The management console is the system that issues a query; the agents run on the
system being queried. Queries are sent and received in the form of protocol data
units (PDUs) inside SNMP messages, which are carried in user data protocol
(UDP) datagrams.
You can configure your host so that an SNMP client can obtain information about
your host and perform updates on your host’s management information base
(MIB) data items. For example, you can configure your host to:
•
Respond to a client’s read requests (‘‘gets’’) for network information.
•
Process client write requests (‘‘sets’’) on your host’s MIB data items.
•
Send alert messages (‘‘traps’’) to a client as a result of events that might need
to be monitored (for example, an authentication failure).
Configuring and Managing SNMP 14–1
Configuring and Managing SNMP
14.1 Key Concepts
TCP/IP Services provides an SNMP master agent, two subagents (MIB II and
Host Resources MIB), a MIB converter and compiler, a simple MIB browser, and
MIB utility programs. Each subagent contains routines that perform read and
write operations on its MIB data items.
Table 14–1 describes the SNMP components and the sample code supplied for
custom subagent development.
Table 14–1 SNMP Components
Component
Description
Master agent
SNMP Version 2
Process name: TCPIP$SNMP_n, where n is the number of
times that the master agent has been started since the SNMP
service was enabled.
Keeps track of managed objects and allows objects to register
themselves. Sends information about these objects to remote
SNMP management consoles. Also maintains a small set of
variables for the MIB II component.
MIB II
Process name: TCPIP$OS_MIBS.
Provides information about the TCP/IP protocol stack and
other network activity.
Host resources MIB
Process name: TCPIP$HR_MIB.
Provides information about the host system.
MIB converter
Extracts a MIB definition in ASN.1 notation into a MIB
definition (.MY) file.
MIB compiler
Compiles MIB-definition files (for example, CHESS_MIB.MY)
into source code templates for use in building subagents.
SNMP utility programs
Acts as a simple clients to obtain a set of values for a MIB and
to listen for and send trap messages. For information about
using the MIB utility programs, see the Compaq TCP/IP
Services for OpenVMS SNMP Programming and Reference
manual.
SNMP subagent
example
Implements an example based on the chess game; includes
executable and source code.
14.1.1 Understanding How SNMP Operates
The TCPIP$CONFIG procedure sets up the SNMP UDP-based service at wellknown port 161.
In addition, TCPIP$CONFIG sets up required files in the
SYS$SYSDEVICE:[TCPIP$SNMP] directory.
The SNMP startup procedure (SYS$STARTUP:TCPIP$SNMP_STARTUP.COM)
runs from the general TCPIP$STARTUP.COM procedure or can be run directly
by the system manager.
TCPIP$SNMP_STARTUP.COM does the following:
1. Checks the TCP/IP Services license and enables the SNMP service.
2. Installs images with the required privileges (as appropriate: BYPASS,
PHY_IO, and WORLD).
3. Runs SYS$STARTUP:TCPIP$SNMP_SYSTARTUP.COM.
14–2 Configuring and Managing SNMP
Configuring and Managing SNMP
14.1 Key Concepts
To ensure compatibility with previous versions of TCP/IP
Services, TCPIP$SNMP_SYSTARTUP.COM in turn runs
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_STARTUP.COM,
which installs and adjusts privileges for any additional, user-written subagents.
On startup, the TCP/IP Services kernel runs the TCPIP$SYSTEM:TCPIP$SNMP_
RUN.COM procedure, which does the following:
•
Purges log files in the SYS$SYSDEVICE:[TCPIP$SNMP] directory.
•
Runs the subagent image as a detached process.
•
Runs SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_
RUN.COM to start any additional subagents.
As each subagent starts, it makes itself known to the master agent, a sequence
that includes registering the MIB subtrees that the subagent maintains and
communicating the port number on which it listens.
Once SNMP starts, the following sequence occurs for each incoming SNMP
request. This sequence is standard for SNMP implementations.
1. The master agent listens for incoming SNMP requests from clients on port
161. Authentication is limited to the validation of the community name.
When a request arrives, the master agent communicates with the appropriate
subagent.
2. Subagent routines collect the requested data and return the data to the
master agent.
3. The master agent responds to the client from which the original request was
made.
The SNMP shutdown procedure TCPIP$SNMP_SHUTDOWN.COM runs either
from the general shutdown procedure TCPIP$SHUTDOWN.COM or can be run
directly by the system manager.
TCPIP$SNMP_SHUTDOWN.COM does the following:
•
Stops subagent processes and removes the SNMP images.
•
Runs the SYS$STARTUP:TCPIP$SNMP_SYSHUTDOWN.COM procedure.
To ensure compatibility with previous versions, this procedure in turn
runs SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_
SHUTDOWN.COM, which stops any additional subagent processes and deinstalls
their images, if necessary.
14.1.2 Ensuring Access to Mounted Data
If the proxy setup between the SNMP server and the NFS server is not correct,
the Host Resources MIB subagent cannot access data that has been mounted.
To ensure access to mounted data, set up a proxy to an anonymous user (for
example, to TCPIP$NOBODY) on the NFS server system. For more information
about adding proxy entries, see Chapter 22.
Configuring and Managing SNMP 14–3
Configuring and Managing SNMP
14.2 Managing the SNMP Service
14.2 Managing the SNMP Service
The following command procedures are supplied to allow you to start up and shut
down the SNMP service independently of TCP/IP Services:
•
SYS$STARTUP:TCPIP$SNMP_STARTUP.COM allows you to start up the
SNMP service.
•
SYS$STARTUP:TCPIP$SNMP_SHUTDOWN.COM allows you to shut down
the SNMP service.
Both the startup and shutdown procedures invoke the appropriate
TCPIP$EXTENSION_MIB_*.COM file to ensure compatibility with previous
versions of TCP/IP Services.
These files might be overwritten when you install subsequent versions of the
TCP/IP Services product. For more information about these procedures, see
Section 14.1.1.
To maintain site-specific SNMP logical names, commands, and parameter
settings, you can create the following files:
•
SYS$STARTUP:TCPIP$SNMP_SYSTARTUP.COM can be used as a repository
site-specific definitions and parameters to be invoked when SNMP is started.
•
SYS$STARTUP:TCPIP$SNMP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
SNMP is shut down.
Enter the commands for starting and stopping site-specific subagents in these
command procedures.
14.3 Verifying the SNMP Installation
A separate installation verification procedure (IVP) exists for SNMP. To verify
your configuration, complete these steps:
1. Log in to the SYSTEM account, or make sure that your process has the
following privileges:
•
TMPMBX
•
NETMBX
•
SETPRV
2. Run the command procedure:
$ @SYS$MANAGER:TCPIP$CONFIG
3. Enter option 7 (Run tests), and then option 2 from the HP TCP/IP Services
for OpenVMS Test menu.
Note that, like the Internet IVP, the SNMP IVP requires that TCP/IP Services
be running. (It does not require that SNMP be running.)
4. To run the SNMP IVP any time after exiting the configuration procedure,
enter the following command:
$ RUN SYS$COMMON:[SYSTEST.TCPIP]TCPIP$SNMPIVP.EXE
14–4 Configuring and Managing SNMP
Configuring and Managing SNMP
14.3 Verifying the SNMP Installation
14.3.1 SNMP Executable and Command Files
Table 14–2 lists the names of the primary SNMP executable and command files
and their locations. For a list of files that help you build your own subagent, see
the Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference
guide.
Table 14–2 SNMP Executable, Command, and Data Files
File
Location
Function
TCPIP$ESNMP_SERVER.EXE
SYS$SYSTEM
Master agent image.
TCPIP$OS_MIBS.EXE
SYS$SYSTEM
MIB II subagent image.
TCPIP$HR_MIB.EXE
SYS$SYSTEM
Host Resources MIB
subagent image.
TCPIP$SNMP_REQUEST.EXE
SYS$SYSTEM
Simple MIB browser.
TCPIP$SNMP_TRAPSND.EXE
SYS$SYSTEM
Program for sending trap
messages.
TCPIP$SNMP_TRAPRCV.EXE
SYS$SYSTEM
Program for receiving trap
messages.
TCPIP$ESNMP_SHR.EXE
SYS$SHARE
Routines in the eSNMP
application programming
interface (API).
TCPIP$SNMP_STARTUP.COM
SYS$STARTUP
Installs master and
subagent images and runs
TCPIP$SNMP_RUN.COM.
TCPIP$SNMP_RUN.COM
TCPIP$SYSTEM
Starts the master agent and
subagents.
TCPIP$SNMP_SHUTDOWN.COM
SYS$STARTUP
Stops the master agent and
subagents.
TCPIP$SNMP_SYSTARTUP.COM
SYS$STARTUP
Sets site-specific
configuration values on
startup.
TCPIP$SNMP_SYSHUTDOWN.COM SYS$STARTUP
Sets site-specific
configuration values on
shutdown.
TCPIP$EXTENSION_MIB_STARTUP.COM
SYS$SYSDEVICE:[TCPIP$SNMP]
Starts custom subagents.
TCPIP$EXTENSION_MIB_SHUTDOWN.COM
SYS$SYSDEVICE:[TCPIP$SNMP]
Shuts down custom
subagents.
TCPIP$VMS_SNMP_CONF.DAT
SYS$SYSDEVICE:[TCPIP$SNMP]
User-editable configuration
data file.
TCPIP$SNMP_CONF.DAT
SYS$SYSDEVICE:[TCPIP$SNMP]
Configuration data file
used in the startup of the
master agent and standard
subagents.
Configuring and Managing SNMP 14–5
Configuring and Managing SNMP
14.4 Configuring SNMP
14.4 Configuring SNMP
You can configure SNMP in three ways, which can be used in combination:
•
Using the standard TCPIP$CONFIG.COM procedure and the SET
CONFIGURATION SNMP command. These methods write configuration
information into the TCP/IP Services configuration database file
TCPIP$CONFIGURATION.DAT. Section 14.4.1 describes how to use
TCPIP$CONFIG to initially configure SNMP.
•
Editing the text configuration file TCPIP$VMS_SNMP_CONF.DAT,
located in the SYS$SYSDEVICE:[TCPIP$SNMP] directory. This method
provides options not available with TCPIP$CONFIG and with the SET
CONFIGURATION SNMP command.
Note
Although the OpenVMS SNMP configuration file is based on the UNIX
implementation, there are several important differences. For example,
the option snmpEnableAuthenTraps is not used. See the description of
specific options for details.
The configuration file is described in Section 14.4.3.
•
Assigning logical names. This method provides the same options as the text
configuration file. For more information, see Section 14.4.3.
If the same option is defined in multiple ways, the configuration methods are
resolved as follows:
•
Values specified through TCPIP$CONFIG or SET CONFIGURATION SNMP
take precedence over any options specified in the TCPIP$VMS_SNMP_
CONF.DAT file or set with logical names.
•
Values specified in the TCPIP$VMS_SNMP_CONF.DAT file take precedence
over logical name settings.
14.4.1 Initial SNMP Configuration
SNMP runs as a TCP/IP service. To be sure all SNMP-related files are included
and enabled properly, run the TCPIP$CONFIG configuration procedure to
configure SNMP initially or to set up a new configuration. When you enable
SNMP during TCPIP$CONFIG, the procedure prompts you for the correct
parameters.
14–6 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
Note
You cannot use TCPIP$CONFIG to modify your existing SNMP
configuration; TCPIP$CONFIG is intended only to set up a new SNMP
configuration.
To modify the current SNMP configuration (for example, to specify an
additional community name and address), you must enter the SET
CONFIGURATION SNMP command with applicable qualifiers.
When you run TCPIP$CONFIG after a TCP/IP Services upgrade, be sure to
disable and then reenable the SNMP service.
You supply the following information about your host when you configure SNMP
initially during TCPIP$CONFIG or when you issue the SET CONFIGURATION
SNMP command to modify your existing SNMP configuration. For detailed
information about the SET CONFIGURATION SNMP command and qualifiers,
see the HP TCP/IP Services for OpenVMS Management Command Reference
manual.
•
The name of the person to contact about the system. For example:
TCPIP> SET CONFIGURATION SNMP/CONTACT="Sam Spade"
•
The physical location of the system. For example:
TCPIP> SET CONFIGURATION SNMP _TCPIP> /LOCATION=(FIRST="Falcon Building",SECOND="Los Angeles, CA")
•
The community information used to authenticate requests from a network
manager and to determine the addresses to which trap messages are sent.
SNMP network management clients are grouped into communities as
specified in RFC 1157. You can define one or more communities, which your
master agent uses to authenticate requests.
The parameters you specify for each community are as follows:
–
Community name
The name associated with the community. The standard community is
‘‘public.’’ You can choose not to provide this community name when you
run TCPIP$CONFIG. Answer no to the question ‘‘Do you want to provide
the public community.’’ If you disable the public community, you might
need to reconfigure SNMP clients in your environment.
Community names are case sensitive. When you use TCPIP$CONFIG
to specify a community name, do not use quotation marks to preserve
the case; the case is preserved exactly as you enter it. However,
if you customize your existing SNMP configuration using the SET
CONFIGURATION SNMP command, make sure you enclose the
community name in quotation marks to preserve the case. If you do not
enclose the community name in quotation marks, the name is changed to
all uppercase.
The community name must be a string of alphanumeric characters.
You cannot include a space or other nonalphanumeric character in the
community name.
You can also modify the community name using the community option in
the configuration file, as described in Table 14–4.
Configuring and Managing SNMP 14–7
Configuring and Managing SNMP
14.4 Configuring SNMP
–
Community address
The address associated with the community. One community name can
have multiple addresses in its entry. For example:
TCPIP> SET CONFIGURATION SNMP /ADDRESS=(6.10.1.2,100.2.2.1)
Specifying address 0.0.0.0 for READ and WRITE allows any host the type
of access specified. To allow any network manager to monitor your system
remotely, specify the standard community name (public, in lowercase
letters) with address 0.0.0.0. For example:
TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /ADDRESS=0.0.0.0
Traps are sent to UDP port 162 on hosts for all trap addresses regardless
of community name. The use of address 0.0.0.0 on a trap means that
traps are not sent unless another address is also specified.
–
Types of access
The types of access associated with the community are described in the
following table:
Access
Type
Allows the Master Agent and Subagent to...
READ
Respond to a client’s read requests (gets) for network information.
Default. Members of a read-only community do not have write access
to the SNMP MIB objects.
TRAP
Send alert messages (traps) to a client as a result of unusual events.
For example, a trap message is sent to the client as a result of
a get request that specifies an unauthorized community string
(authenticationFailure).
WRITE
Process client write requests (sets) on your host’s MIB data items.
For example, to allow the master agent to respond to client get requests, enter:
TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /TYPE=READ
To configure your host to allow client set requests, use the /FLAGS=SETS
qualifier. For example:
TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /FLAGS=SETS
14.4.2 Displaying the Current SNMP Configuration
To display configuration information in the SNMP configuration database, use the
SHOW CONFIGURATION SNMP command. If you want to display the addresses
that the agent recognizes as members of the community, use the /FULL qualifier.
For example:
TCPIP> SHOW CONFIGURATION SNMP /FULL
SNMP Configuration
Flags:
AuthenTraps Sets
Contact: Sam Spade
Location
First: Falcon Building
Second: Los Angeles, CA
Community
Type
address_list
public
Read
0.0.0.0
14–8 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
writeit
Read Write 9.20.208.53
trapit
Read Trap 9.20.208.53, 9.20.208.100
In this example, the configuration allows read access to any client on any host
through the public community and read/write access to the client on host
9.20.208.53 through the writeit community. In addition, trap messages are sent
to UDP port 162 on hosts 9.20.208.53 and 9.20.208.100.
Alternatively, you can display the configuration options in the SNMP
configuration text file described in Section 14.4.3. For more information, see
Section 14.6.5.2.
14.4.3 SNMP Options
You can configure the way SNMP runs by entering SNMP options into the SNMP
configuration file TCPIP$VMS_SNMP_CONF.DAT.
When it starts, the SNMP master agent creates the temporary file
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$TMP_SNMP_CONF.DAT from data in
the standard TCP/IP configuration database file TCPIP$CONFIGURATION.DAT.
For troubleshooting purposes, a few versions of this file are preserved. The
master agent appends this temporary file to TCPIP$VMS_SNMP_CONF.DAT to
produce the master configuration file TCPIP$SNMP_CONF.DAT.
When the standard OS_MIBS and HR_MIB subagents start up, they read
TCPIP$SNMP_CONF.DAT. Only the master agent and these standard subagents
use values in the text files.
By default, custom subagents do not take advantage of the configuration options.
To take advantage of these options, you must assign a logical that is visible to
the subagent process. The following example shows how to define TCPIP$SNMP_
GEN_LOGFILE logical to set the snmp_gen_logfile configuration option:
$ ASSIGN/SYSTEM 1 TCPIP$SNMP_GEN_LOGFILE
If a configuration option is not handled by the eSNMP API, the subagent must
include an explicit genenv( ) or similar call to access the value of the option.
14.4.3.1 Using Logical Names to Configure SNMP
Most configuration options have a corresponding logical name. In some cases,
you can define system logical names as an alternative to entering a value in
the text file. For a list of the options and their associated logical names, see
Section 14.4.3.4.
14.4.3.2 Dynamic Options
Some options are available for you to change dynamically; that is, without
shutting down and restarting the SNMP service. To change configuration values
dynamically, you can do one of the following:
•
Define the appropriate logical name.
•
Edit the configuration file, then define snmp_signal to be sighup. Be sure
to deassign snmp_signal afterwards to prevent continuous rereading of the
configuration file.
Configuring and Managing SNMP 14–9
Configuring and Managing SNMP
14.4 Configuring SNMP
14.4.3.3 Modifying the Configuration File
The master agent and the subagents convert lines in the configuration file that
begin with the OpenVMS-specific config command to user-mode process logicals
by adding the prefix TCPIP$. For example, SNMP_GEN_LOGFILE becomes
TCPIP$SNMP_GEN_LOGFILE. (This mechanism does not apply to options with
other keywords, such as trap.) Because the logicals are local to agent processes,
they are not visible to a DCL command SHOW LOGICAL issued in another
process.
If there are lines with duplicate configuration tags, the last line
supersedes all others. Because the temporary file TCPIP$TMP_
CONF.DAT (described in Section 14.4.3) is appended after the user-editable
TCPIP$VMS_SNMP_CONF.DAT file, the standard TCPIP configuration values
from that temporary file always supersede those from the user-edited file.
Lines in the configuration file that begin with a pound sign (#) are ignored. The
pound sign is the comment character.
Option names and values are not case sensitive. Boolean values are considered
on if the option is present with no value. Otherwise, they are considered off.
Thus, to turn off an option that was enabled at startup, you must specify zero as
the value.
If you specify a value that is longer than the limit, the value is converted to
hexadecimal and then truncated. For example, if you specify the value 257
in place of an 8-bit unsigned value, it is converted to hexadecimal (0101) and
truncated to 1.
14.4.3.4 SNMP Configuration Options
Most of the SNMP options set in the TCPIP$VMS_SNMP_CONF.DAT file must
be entered using the following syntax:
config option-name value
There are several types of SNMP configuration options:
•
Logging options, described in Table 14–3. These options control the way
messages are logged.
•
Operation options, described in Table 14–4. These options control the
operational settings for SNMP. Some of these options cannot be set by using a
logical name.
•
Timing options, described in Table 14–5. These options control the way
timeouts are handled.
•
Testing and troubleshooting options, described in Table 14–6. These options
are useful when you are testing SNMP functions and troubleshooting
subagent problems.
•
Backward-compatibility options, described in Table 14–7. These options are
available to provide compatibility with subagents developed under previous
versions of SNMP.
Except for the community name, option values are not case sensitive.
14–10 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–3 SNMP Logging Options
SNMP_GEN_LOGFILE
Logical name:
TCPIP$SNMP_GEN_LOGFILE
Format:
config SNMP_GEN_LOGFILE 1
Description:
Redirects messages to SYS$OUTPUT and records them in the
following files:
Type:
•
TCPIP$ESNMP_SERVERprocess-id.LOG, where process-id is
the 8-digit hexadecimal process identifier of the master agent.
•
TCPIP$ESNMP_RESIDENT_SUBAGENTprocess-id.LOG,
where process-id is the 8-digit hexadecimal process identifier of
the resident subagent.
•
TCPIP$OS_MIBSprocess-id.LOG, where process-id is the 8-digit
hexadecimal process identifier of the MIB II subagent.
•
TCPIP$HR_MIBprocess-id.LOG, where process-id is the 8digit hexadecimal process identifier of the Host Resources MIB
subagent.
Dynamic
SNMP_SUPPRESS_LOGGING_TIMESTAMP
Logical name:
TCPIP$SNMP_SUPPRESS_LOGGING_TIMESTAMP
Format:
config SNMP_SUPPRESS_LOGGING_TIMESTAMP 1
Description:
Specifies whether a timestamp is included in the log message.
If not defined, a timestamp is included. The value can be 1 (to
prevent timestamp information from being included) or 0 (to allow
timestamp information to be included; the default).
Type:
Dynamic
SNMP_VERBOSE_LOGGING
Logical name:
TCPIP$SNMP_VERBOSE_LOGGING
Format:
config SNMP_VERBOSE_LOGGING 1
Description:
Specifies whether to log detailed information or not. The value can
be 1 (to log detailed information) or 0 (to log the default amount of
information).
Type:
Dynamic
Configuring and Managing SNMP 14–11
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–4 SNMP Operation Options
COMMUNITY
Logical name:
Not available
Format:
COMMUNITY name address type
Description:
Specifies the community name. See Section 14.4 for more
information about specifying a community name.
Type:
Dynamic
SNMPENABLEAUTHENTRAPS
Logical name:
Not available
Format:
SNMPENABLEAUTHENTRAPS
Description:
This configuration option reflects the setting of the
/FLAGS=AUTHENTICATION qualifier to the SET
CONFIGURATION SNMP command and is included in the
configuration file for backward compatibility. This option in the
configuration file is ignored.
Type:
Not dynamic
SNMP_RESTARTS
Logical name:
TCPIP$SNMP_RESTARTS
Format:
config SNMP_RESTARTS 5
Description:
Specifies the maximum number of times to restart a subagent. The
default for OS_MIBS and HR_MIB is 3.
Type:
Not dynamic
SNMP_SELECT_ERROR_LIMIT
Logical name:
TCPIP$SNMP_SELECT_ERROR_LIMIT
Format:
config SNMP_SELECT_ERROR_LIMIT 500
Description:
Specifies the number of iterations for the error limit. The default
value is 100.
Type:
Not dynamic
(continued on next page)
14–12 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–4 (Cont.) SNMP Operation Options
SNMP_SIGNAL
Logical name:
TCPIP$SNMP_SIGNAL
Format:
DEFINE TCPIP$SNMP_SIGNAL value
Description:
Simulates a UNIX-style signal that affects the way agents operate.
Following is a list of values:
SIGUSR1—causes a dump of MIB registration area with
contexts to the following log file:
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$SNMP_DUMP.LOG
SIGHUP—rereads the configuration file.
SIGINT—causes the process to exit.
SIGTERM—same as SIGINT.
SIGUSR2—turns on tracing.
SIGCHLD—turns off tracing.
Do not set this option in the configuration text file. After setting
the logical name, be sure to reset it to prevent system performance
problems.
Type:
Dynamic
SYSNAME
Logical name:
Not available
Format:
SYSNAME host-name
Description:
Specifies the SNMP host name. This host name is used only by
SNMP. You can reset the host name by editing this option and then
restarting the master agent.
Type:
Not dynamic
SYSCONTACT
Logical name:
Not available
Format:
SYSCONTACT contact-information
Description:
Specifies the contact information.
Do not modify this option. Use TCPIP$CONFIG or the SET
CONFIGURATION SNMP command to change the information
associated with this option.
Type:
Not dynamic
(continued on next page)
Configuring and Managing SNMP 14–13
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–4 (Cont.) SNMP Operation Options
SYSLOCATION
Logical name:
Not available
Format:
SYSLOCATION host-location
Description:
Specifies the host or contact location information.
Do not modify this option. Use TCPIP$CONFIG or the SET
CONFIGURATION SNMP command to change the information
associated with this option.
Type:
Not dynamic
trap
Logical name:
Not available
Format:
trap trap-name version IP-address
Description:
Specifies:
The name of the trap (trap-name).
Whether to trap for SNMP Version 1 requests only (version).
Specify V1 for Version 1 traps only. Specify V2C for both
Version 1 and Version 2 traps.
The internet address of the client (address). Do not specify
0.0.0.0 for the client address.
For information about setting individual trap types depending on
the destination host, see Section 14.6.5.3.
Type:
Not dynamic
Table 14–5 Timing and Timeout Handling Options
AGENTX_SESSION_TIMEOUT
Logical name:
TCPIP$AGENTX_SESSION_TIMEOUT
Format:
config AGENTX_SESSION_TIMEOUT seconds
(continued on next page)
14–14 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–5 (Cont.) Timing and Timeout Handling Options
AGENTX_SESSION_TIMEOUT
Description:
Specifies the default timeout for a session between a subagent and
the master agent. Subagents can supersede this value when they
register their MIBs.
The value of this option is used by both the master agent and the
subagent. Normally, all subagents running on the same host have
the same timeout value, which is specified by this option.
When the subagent reads the value of this option, the value is
interpreted as follows:
If the option is not defined, the default value of 3 seconds is
assumed.
If the option is set to 0, the timeout value used by the master
agent is used.
If the option is set to a nonzero integer, that value is used
instead of the master agent’s default timeout value.
When the master agent reads the value of this option, the value is
interpreted as follows:
If the option is not defined, the default value of 3 seconds is
assumed.
If the option is set to a value greater than 0, this timeout value
is used, unless a different value has been specified for the
subagent.
Do not set the value of this option to 0.
The maximum value you can specify is 255. This option can be
used to increase the timeout for communication between the master
agent and subagents on a slow system.
Type:
Dynamic
SNMP_MASTER_TIMEOUT
Logical name:
TCPIP$SNMP_MASTER_TIMEOUT
Format:
config SNMP_MASTER_TIMEOUT seconds
Description:
Specifies (in seconds) the default time to wait listening for an SNMP
request. The default is 10 seconds.
Type:
Not dynamic
(continued on next page)
Configuring and Managing SNMP 14–15
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–5 (Cont.) Timing and Timeout Handling Options
SNMP_ARE_YOU_THERE_TIME
Logical name:
TCPIP$SNMP_ARE_YOU_THERE_TIME
Format:
config SNMP_ARE_YOU_THERE_TIME seconds
Description:
Specifies the time subagents wait between sending the
esnmp_are_you_there( ) message to the master agent.
For the OS_MIBS and the HR_MIB, the default is 5400 seconds (90
minutes).
If you also specify the SNMP_INACT_TIME option, make sure the
value of the SNMP_ARE_YOU_THERE_TIME option is less than or
equal to the value of the SNMP_INACT_TIME option.
Type:
Dynamic
SNMP_POLL_TIME
Logical name:
TCPIP$SNMP_POLL_TIME
Format:
config SNMP_POLL_TIME seconds
Description:
Specifies the interval between times that interface counts and other
values are reset for standard subagents.
Type:
Dynamic
SNMP_INACT_TERM
Logical name:
TCPIP$SNMP_INACT_TERM
Format:
config SNMP_INACT_TERM n
Description:
In this format, n can be 1 (to terminate the master agent) or 0 (to
never terminate the master agent). Specify the amount of time to
wait using the SNMP_INACT_TIME option.
Type:
Dynamic
SNMP_INACT_TIME
Logical name:
TCPIP$SNMP_INACT_TIME
Format:
config SNMP_INACT_TIME seconds
Description:
Specifies (in seconds) the amount of time that must pass before the
subagent is considered inactive (that is, the amount of time during
which the master agent receives no message from the subagent).
See also the SNMP_INACT_TERM and SNMP_ARE_YOU_THERE_
TIME options.
Type:
Dynamic
Time-related parameters are important in determining the responsiveness of the
SNMP agents to client requests, particularly on systems with limited memory or
those that are heavily loaded.
14–16 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
On startup, each subagent first sets up a default session timeout (see the
AGENTX_SESSION_TIMEOUT option). It then registers its MIB regions. The
subagent can register each of its MIB regions with a different timeout. A value of
0 causes the session timeout for the entire subagent to be used.
The master agent listens for SNMP requests. The timeout value is 10 seconds,
unless the SNMP_MASTER_TIMEOUT option has been defined. After a timeout
occurs, the master agent updates counters, checks for requests, then loops to wait
for another SNMP request. When an SNMP request arrives, the master agent
determines which if any registered subagents can handle it. It then resets the
SNMP_MASTER_TIMEOUT timeout to use the maximum of the timeouts for all
MIB regions involved.
When it is not processing an SNMP request, a subagent may send are_you_there
messages to the master agent at a default interval determined by the subagent.
For the chess example, the default is 30 seconds; for the OS_MIBS and HR_MIB
subagents, the default is 5400 seconds (90 minutes). Both values are derived
from those used in the UNIX implementation of SNMP; the second value was set
high to minimize system overhead.
The following relationships among configuration option values are recommended
but are not enforced. See the descriptions of the specific options for details.
•
SNMP_ARE_YOU_THERE_TIME and SNMP_INACT_TIME
The SNMP_ARE_YOU_THERE_TIME option determines the time between
are_you_there messages. If the SNMP_INACT_TERM option is set, and
if the master agent does not receive any SNMP request or are_you_there
mesages from a subagent during the time associated with the SNMP_INACT_
TIME option, the master agent automatically exits. By default, the SNMP_
INACT_TERM option is not set.
If the SNMP_ARE_YOU_THERE_TIME option is not set and no external
SNMP requests are received, the master agent will exit even if subagents are
still active.
•
SNMP_INACT_TIME and SNMP_POLL_TIME
The values for these options should be a multiple of the value of the SNMP_
MASTER_TIMEOUT option.
The master agent checks whether these intervals have elapsed after the time
specified by the SNMP_MASTER_TIMEOUT option. Therefore, a value for
these two options that is not a multiple of SNMP_MASTER_TIMEOUT will
have the same effect as one that is the next higher multiple.
•
The client should allow a large enough timeout interval to accommodate
the server to avoid query failures or unnecessary retries. Particular care is
required when network load is high and when communicating with heavily
used servers and those in which tracing is turned on. See Table 14–6 for
details on using trace.
Configuring and Managing SNMP 14–17
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–6 Testing and Troubleshooting Options
ACCEPT
Logical name:
Not available
Format:
accept IP-address
Description:
If nonlocal subagents are allowed (using the SNMP_ALLOW_INET_
TRANSPORT, AGENT_INET_ADDR, or AGENTX_INET_PORT
option), the ACCEPT option specifies the IP address of the host
from which a connection will be accepted. If these options are not
set, connections from nonlocal subagents are rejected. To allow
access from all subagents, specify the IP-address as 0.0.0.0.
Type:
Dynamic
AGENTX_LOCAL_PORT
Logical name:
TCPIP$AGENTX_LOCAL_PORT
Format:
config AGENTX_LOCAL_PORT port number
Description:
Specifies the local port number from which to accept nonlocal
subagent connections.
Type:
Dynamic
AGENTX_INET_PORT
Logical name:
TCPIP$AGENTX_INET_PORT
Format:
config AGENTX_INET_PORT port number
Description:
Specifies the TCP/IP port number from which to accept connections
from nonlocal subagents.
Type:
Dynamic
SNMP_ALLOW_INET_TRANSPORT
Logical name:
TCPIP$SNMP_ALLOW_INET_TRANSPORT
Format:
config SNMP_ALLOW_INET_TRANSPORT n
Description:
Specifies whether the master agent accepts connections from
nonlocal subagents.
Type:
Dynamic
(continued on next page)
14–18 Configuring and Managing SNMP
Configuring and Managing SNMP
14.4 Configuring SNMP
Table 14–6 (Cont.) Testing and Troubleshooting Options
SNMP_TRACE
Logical name:
TCPIP$SNMP_TRACE
Format:
config TCPIP$SNMP_TRACE n
Description:
Allows you to direct trace log messages to standard log files when
agents are running in normal production mode. (Alternatively, you
can get trace logs while running the subagent in interactive mode,
as described in Section 14.6.4.)
Running with tracing produces a great deal of output and may
slow down the system. In addition, utilities like the MIB browser
(snmp_request) may need a longer timeout interval when running
with tracing on.
The type of data and the amount of data logged for custom
subagents depends on how the subagents are programmed, except
for the logging that is handled automatically by the eSNMP API
routines. The chess example code provides some samples of using
the ESNMP_LOG macro.
Type:
Not dynamic
Table 14–7 Backward-Compatibility Options
SNMP_PROHIBIT_DUPLICATE_REGISTRATIONS
Logical name:
TCPIP$SNMP_PROHIBIT_DUPLICATE_REGISTRATIONS
Format:
config SNMP_PROHIBIT_DUPLICATE_REGISTRATIONS n
Description:
In this format, n can be 1 (to set the option), or 0 (to turn the option
off). If this option is set, a subagent that tries to register with the
same name as a previously registered subagent will be rejected. By
default, duplicate registrations are allowed; the AgentX protocol
does not check for duplicate subagents based on the subagent name.
Type:
Dynamic
SNMP_V1_TRAP_DEFAULT
Logical name:
TCPIP$SNMP_V1_TRAP_DEFAULT
Format:
config SNMP_V1_TRAP_DEFAULT n
Description:
In this format, n can be 1 (to set the option), or 0 (to turn
the option off). When this option is set, traps defined in the
TCPIP$CONFIG.COM procedure or using the TCP/IP management
command SET CONFIGURATION SNMP are sent in SNMP Version
1 format. The default is to send these types of traps in Version 2
format.
Type:
Dynamic
Configuring and Managing SNMP 14–19
Configuring and Managing SNMP
14.5 SNMP Log Files
14.5 SNMP Log Files
Unless the SNMP_TRACE option is set, output from the SNMP master agent and
subagent processes to SYS$OUTPUT is redirected to the following files:
•
TCPIP$SNMP_RUN.LOG
•
TCPIP$OS_MIBS.LOG
•
TCPIP$HR_MIB.LOG
The output is written to these files continuously while SNMP processes are
running. Buffering may cause a delay in writing to disk; therefore, if a process is
terminated abnormally, some data may be lost.
While processes are running, output for SYS$ERROR can be redirected to other
files. See Section 14.4.3 for information about controlling this. In addition, the
master agent and subagents may write to SYS$ERROR. This output is redirected
to the following files:
•
TCPIP$SNMP_RUN.LOG
•
TCPIP$OS_MIBS.ERR
•
TCPIP$HR_MIB.ERR
Unlike a regular log or a trace log, this output is written when the corresponding
SNMP process terminates. Therefore, abnormal termination can cause data to be
lost.
All of the listed log files are located in the SYS$SYSDEVICE:[TCPIP$SNMP]
directory. The configuration-related files described in Section 14.4.3 are also
stored there. TCP/IP Services does not allow you write to log files in other
directories.
The log level and specific events during processing determine how much
information is recorded in the log files; log files can be empty or nonexistent.
The log files contain startup and event information and additional messages,
depending on the logging level specified for an agent. The SNMP logging facility
uses three logging levels:
•
Trace (logs trace, warning, and error messages)
•
Warning (logs warning and error messages)
•
Error
The default logging level for the master agent and standard subagents is
Warning. Because the Chess example subagent does not use a default, messages
are captured only if you specify tracing, as described in Section 14.6.4.
Many logging options are configurable using the text configuration file
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT; see
Table 14–3 for more details.
The following log files exist under normal production conditions if special
configuration options are not used. In most cases, a new version of each file is
created each time SNMP is started:
14–20 Configuring and Managing SNMP
Configuring and Managing SNMP
14.5 SNMP Log Files
Agent
Process
SYS$OUTPUT
SYS$ERROR
Master agent
TCPIP$SNMP
TCPIP$SNMP_
RUN.LOG
TCPIP$SNMP_RUN.LOG
Resident
subagent
TCPIP$SNMP
TCPIP$SNMP_
RUN.LOG
TCPIP$SNMP_RUN.LOG
OS_MIBS1
TCPIP$OS_MIBS
TCPIP$OS_MIBS.LOG
TCPIP$OS_MIBS.ERR
TCPIP$HR_MIB.LOG
TCPIP$HR_MIB.ERR
HR_MIB
1 If
TCPIP$HR_MIB
1
no output has been generated, a .LOG or .ERR file might not exist.
If the configuration option SNMP_GEN_LOGFILE is set, files in the preceding
table continue to be used for SYS$ERROR data. For SYS$OUTPUT data, as
soon as the agents detect the option, data is written to the following files, where
process-ID is the hexadecimal process ID of the process listed:
Agent
Process
SYS$OUTPUT
Master agent
TCPIP$SNMP
TCPIP$ESNMP_SERVERprocess-ID.LOG
Resident
subagent
TCPIP$SNMP
TCPIP$ESNMP_RESIDENT_SUBAGENTprocess-ID.LOG
OS_MIBS
TCPIP$OS_MIBS
TCPIP$OS_MIBSprocess-ID.LOG
HR_MIB
TCPIP$HR_MIB
TCPIP$HR_MIBprocess-ID.LOG
Unless it is suppressed, the timestamp gives a line-by-line record of when output
was written to each file and is useful in resolving timing-related problems.
The SNMP_GEN_LOGFILE option does not affect the name of
the output file for customer written subagents. Customer-written
subagents generate files based on the IMAGENAME symbol in
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM.
For details about logging from customer extension subagents, refer to the Compaq
TCP/IP Services for OpenVMS SNMP Programming and Reference guide.
14.6 Solving SNMP Problems
The following sections contain information about how to analyze and solve many
SNMP problems. Be sure to configure SNMP according to the instructions in
this guide, and use the information here and in the Compaq TCP/IP Services
for OpenVMS SNMP Programming and Reference guide when writing your own
subagents.
14.6.1 Multiple SNMP Processes Displayed for SHOW SYSTEM Command
When you enter the DCL command SHOW SYSTEM during the TCPIP or SNMP
startup sequence, the process TCPIP$SNMP_n may appear in the display without
the subagent processes (TCPIP$OS_MIBS and TCPIP$HR_MIB). This is because
TCPIP$SNMP is the main SNMP process started by the TCP/IP kernel when
the SNMP service is enabled; it starts the subagents as detached processes, and
then continues to run as the master agent. The number at the end of this process
name reflects the number of times this main process has started since SNMP has
been enabled.
Configuring and Managing SNMP 14–21
Configuring and Managing SNMP
14.6 Solving SNMP Problems
14.6.2 Problems Starting and Stopping SNMP Processes
If there are startup errors noted in the SNMP log files, or if SNMP startup seems
normal but one or more of the SNMP processes disappears, follow these steps:
1. Check the log files for any errors indicating timeouts, protection problems, or
configuration errors.
2. Start up the master agent and subagents by running the images interactively
and enabling tracing (see Section 14.6.4).
To verify the SNMP installation, enter the command SHOW CONFIGURATION
SNMP, as described in Section 14.4.2.
To stop all SNMP processes, enter:
$ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN
If you disable the SNMP service by entering the DISABLE SERVICE SNMP
command, automatic restarts are prevented, but detached SNMP master and
subagent processes are not stopped.
14.6.3 Restarting MIB Subagent Processes
Usually the SNMP master agent and subagent processes start up and are shut
down together as described in Section 14.1.1.
If the SNMP master agent process stops for any reason, TCP/IP Services attempts
to restart it and, if successful, increments the count (n) in the process name
TCPIP$SNMP_n. As part of the startup sequence, any subagents that have
stopped will be restarted. If a subagent process has not stopped, an attempt to
restart it will have no effect because OpenVMS does not allow a duplicate process
name (unlike the SNMP master agent, subagent names do not include a startup
count).
If the master agent continues to run but a subagent stops, there is no automatic
restart attempt. You can correct the problem by doing one of the following:
•
Restart TCP/IP Services.
•
Restart SNMP.
•
Manually stop the TCPIP$SNMP_n process to force a master agent restart.
•
Configure the SNMP variable AUTRESTARTS and stop all the subagent
processes. See Section 14.4.3 for more information.
14.6.4 Obtaining Trace Log Messages
To get trace log messages you can:
•
Configure SNMP to enable trace output while SNMP continues processing.
•
Enable tracing while running SNMP interactively.
To configure SNMP to log tracing messages while it is running, set the
snmp_trace configuration option. With this option enabled, trace output is
produced and written to standard logs (see Section 14.5) when agents are run in
normal production mode.
See Section 14.4.3 for details about the configuration options and about how to
enable those options dynamically or without running interactively.
14–22 Configuring and Managing SNMP
Configuring and Managing SNMP
14.6 Solving SNMP Problems
To obtain trace log messages interactively, follow these steps:
1. Shut down SNMP. Enter:
$ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN
2. From separate windows, run the master agent and subagents interactively.
For example, run each image by entering the following commands in separate
windows:
$ MCR TCPIP$ESNMP_SERVER -T
$ MCR TCPIP$OS_MIBS -TRACE
$ MCR TCPIP$HR_MIB -TRACE
To specify custom subagents located in directories other than SYS$SYSTEM,
use the MCR command and specify the full directory path. For example,
to run the Chess example subagent with trace logging, enter the following
command:
$ MCR SYS$COMMON:[SYSHLP.EXAMPLES.TCPIP.SNMP]TCPIP$CHESS_SUBAGENT -TRACE
When agents are run interactively, output comes to the terminal unless the
SNMP_GEN_LOGFILE option is enabled.
Running in trace mode can produce a great deal of output, and also slow down
performance significantly. Programs like browsers may need to allow a longer
timeout interval under these circumstance. For example, use the -w with the
supplied MIB browser.
For more information about the MIB browser supplied with TCP/IP Services, and
on using tracing with custom subagents, see the Compaq TCP/IP Services for
OpenVMS SNMP Programming and Reference guide.
The type of trace data written depends on the way the subagent routines are
programmed, except for logging handled within eSNMP API routines. For more
details, see the Chess example code.
14.6.5 Processing Set Requests and Traps
To make sure that the master agent processes SNMP Set requests from
management clients correctly, follow these steps:
1. Configure SNMP to allow the master agent to process Set requests, either by
using the TCPIP$CONFIG.COM configuration procedure or by using the SET
CONFIGURATION SNMP command.
2. Make sure that the management client is configured correctly for Get and Set
requests, as described in the Compaq TCP/IP Services for OpenVMS SNMP
Programming and Reference guide.
3. Configure write communities as needed on the OpenVMS server. Refer to
Section 14.6.5.2.2 for more information.
4. Make sure that the requested MIB variable is defined with write access and
implemented as such in the subagent. Refer to the Compaq TCP/IP Services
for OpenVMS SNMP Programming and Reference guide for more information.
If SNMP is not responding to Set requests after you follow these steps, refer to
Section 14.6.6 for troubleshooting procedures and Section 14.6.5.2.2 to check the
community configuration information.
Configuring and Managing SNMP 14–23
Configuring and Managing SNMP
14.6 Solving SNMP Problems
14.6.5.1 Enabling Set Request Processing and Authentication Traps
On an OpenVMS server, configure SNMP with the /FLAGS=SETS qualifier to the
management command SET CONFIGURATION SNMP, or enable SNMP during
the configuration procedure (TCPIP$CONFIG) by answering Yes to the question
Do you want to allow clients modify (SET) access?
To enable set requests and traps on an existing SNMP configuration, enter the
SET CONFIGURATION SNMP command with the /FLAGS=options qualifier,
specifying the SETS option to enable set requests and the AUTHEN_TRAPS
option to enable sending authentication failure traps.
When you enter the SET CONFIGURATION SNMP command and qualifiers,
take the following information into consideration:
•
SNMP functions without the need to configure flags for set commands
(/FLAGS=SETS) and authentication traps (/FLAGS=AUTHEN_TRAPS).
Note that when you enter the SHOW CONFIGURATION SNMP command,
the keywords associated with these flags are displayed as follows:
Flags:
AuthenTraps Sets
•
The /FLAGS=SETS qualifier is required to enable SNMP client set command
requests. If set commands are not enabled, the client receives a "no such
variable" message, even if access type requirements are met. (See the
command guidelines in Section 14.6.5.1.)
•
The /FLAGS=AUTHEN_TRAPS qualifier allows the SNMP master to send
trap messages to specified trap community addresses when MIB access with a
community name is not supported by the agent. This also allows the master
to send trap messages when the agent does not grant the host the access
required for a request (for example, READ for a get request or WRITE for a
set request).
For example, to enable response to set requests and to allow authentication traps
on an existing SNMP configuration, enter the following command:
TCPIP> SET CONFIGURATION SNMP/FLAGS=(SETS,AUTHEN_TRAPS)
See the HP TCP/IP Services for OpenVMS Management Command Reference
guide for detailed information about the SET CONFIGURATION SNMP
command.
Restart SNMP after making any changes to the configuration.
14.6.5.2 Displaying Configuration Information
When you enter the SHOW CONFIGURATION SNMP command to display your
current SNMP configuration, the information associated with the /FLAGS=options
qualifier is displayed as follows:
Flags:
AuthenTraps Sets
SNMP will function even if you do not include the /FLAGS=SETS and
/FLAGS=AUTHEN_TRAPS qualifiers.
To remove flags that were set previously, enter the following commands:
TCPIP> SET CONFIGURATION /FLAGS=NOSETS
TCPIP> SET CONFIGURATION /FLAGS=NOAUTHEN_TRAPS
14–24 Configuring and Managing SNMP
Configuring and Managing SNMP
14.6 Solving SNMP Problems
Alternatively, you can display configuration information in the SNMP
configuration file (SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_
CONF.DAT). The configuration file displays more information than the SHOW
CONFIGURATION SNMP command when multiple types of traps or addresses
for them have been defined. For example:
$ TYPE SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT
trap
V1 elmginkgo 15.9.0.200
community
alternate 15.4.3.2 read
community
public 0.0.0.0 read
community
TRAPIT 1.2.4.5 write
trap
v2c
TRAPIT 1.2.4.5
community
rw
10.1.1.3
write
community
rw
15.9.0.200
write
Note that the first two lines of the configuration file are not displayed by the
following SHOW CONFIGURATION SNMP/FULL command:
TCPIP> SHOW CONFIGURATION SNMP/FULL
Community
Type
Address_list
public
Read
0.0.0.0
TRAPIT
Read Write Trap
1.2.4.5
rw
Read Write
10.1.1.3, 15.9.0.200
14.6.5.2.1 Specifying Location and Contact Information To specify the location
and contact information, include the /LOCATION and /CONTACT qualifiers on
the SET CONFIGURATION SNMP command line.
If you do not specify the location and contact information, it is displayed as ‘‘not
defined’’ by the SHOW CONFIGURATION SNMP/FULL command. For example:
TCPIP> SHOW CONFIGURATION SNMP/FULL
SNMP Configuration
Flags:
Sets
Contact: not defined
Location: not defined
To remove a previously specified location, enter:
TCPIP> SET CONFIGURATION SNMP /LOCATION=(NOFIRST,NOSECOND)
Note
If you enabled SNMP when you had a previous version of TCP/IP Services
installed, you might need to specify NOTHIRD through NOSIXTH to
remove existing location information.
Once you specify a contact name using /CONTACT=name, you can change the
name but you cannot remove it. If you enter /CONTACT=" ", the previously
specified contact name remains in effect.
Configuring and Managing SNMP 14–25
Configuring and Managing SNMP
14.6 Solving SNMP Problems
14.6.5.2.2 Verifying Community Information To display the community strings
for the OpenVMS host, enter the following command:
TCPIP> SHOW CONFIGURATION SNMP /FULL
Also, check the community configuration in the TCPIP$VMS_SNMP_CONF.DAT
file, as described in Table 14–4.
Make sure that the community string used in the messages matches a valid
community of the appropriate type on the server. Check also that the MIB
variable is defined with write access and implemented as such in the subagent.
Note that in OpenVMS standard MIBS, the Set command is not implemented for
some variables defined as writable in the MIB II and Host Resources MIB.
For example, the community must be configured as /TYPE=(READ,WRITE) to
process set requests.
If SNMP is not responding to set commands or to other requests:
•
One of conditions listed above has not been met.
•
The commmunity name is invalid. Check to make sure uppercase or
lowercase letters are specified correctly. Community names are case sensitive.
•
SNMP is not running on the system.
•
There are network, delay, or timeout problems.
•
The community address was specified incorrectly.
•
Communities with write access are not defined on the server.
•
The ‘‘public’’ community configuration was not specified as /TYPE=READ with
address 0.0.0.0.
•
The SNMP configuration is correct, but SNMP was not restarted after
changes were made.
14.6.5.3 Enabling SNMP Version 1 Traps
By default, SNMP sends Version 2 traps, which can be configured using either
the TCPIP$CONFIG.COM procedure or the SET CONFIGURATION SNMP
command. You can modify SNMP to send Version 1 traps by default, using the
trap option described in Table 14–4.
You can implement individual SNMP Version 1 traps even if Version 2 traps are
set by default. Add a line for each trap destination to the TCPIP$VMS_SNMP_
CONF.DAT file using the following format of the trap option:
trap v1 community IP-address[:port]
When SNMP Version 1 traps are set by default, you can send SNMP Version 2
traps by adding a line to the TCPIP$VMS_SNMP_CONF.DAT file for each Version
2 trap destination using the following format of the trap option:
trap v2c community IP-address[:port]
In these formats:
•
community specifies the community name.
•
IP-address specifies the IP address of host that is listening for traps.
•
port specifies the port number. The default port number is 162.
14–26 Configuring and Managing SNMP
Configuring and Managing SNMP
14.6 Solving SNMP Problems
Regardless of the default trap type, you can control the trap type for each trap
destination using the appropriate tag (v1 or v2c). For example, the following
entries in the TCPIP$VMS_SNMP_CONF.DAT file will cause a Version 1 trap
to go to the host with the IP address 120.2.1.2 (community name v1type), and a
Version 2 trap to go to the host with the IP address 120.2.2.2 (community name
v2type). Both traps will go to the well-known port 162:
trap v1 v1type 120.1.2.1
trap v2c v2type 12.2.2.2
14.6.6 Solving Management Client Response Problems
When an SNMP client is not getting a response to set, get, getnext, or getbulk
requests, even though the SNMP server is configured and running, the problem
might be with the operation of the subagent or in the transmission of the query
or response message. To test, follow these guidelines:
1. Confirm that TCP/IP Services is running on your host. Enter:
TCPIP> SHOW INTERFACE
•
If TCP/IP Services is not running, a response similar to the following is
displayed:
%TCPIP-E-INTEERROR, error processing interface request
-TCPIP-E-NOTSTARTED, TCP/IP Services is not running
•
If TCP/IP Services is running, a response similar to the following is
displayed:
Packets
Interface
WE0
WF0
LO0
IP_Addr
126.65.100.68
126.65.100.108
127.0.0.1
Network mask
255.255.0.0
255.255.0.0
255.0.0.0
Receive
20298
20290
3290
Send
5
2
3290
MTU
1500
4470
0
2. To ensure the successful startup of the SNMP master agent and subagents
and the operation of the TCPIP$SNMP_REQUEST utility (MIB browser),
confirm that the BIND resolver has been configured correctly by entering the
following command:
TCPIP> SHOW NAME_SERVICE
Refer to Appendix D for information about configuring the BIND resolver.
3. Check the status of the SNMP service using the following DCL command:
SHOW LOGICAL/TABLE=TCPIP$STARTUP_TABLE.
This command shows when each TCP/IP Services service startup completed
and which user performed each startup. If the SNMP service is not listed, it
was either shut down or it was not started.
4. Use the MIB browser on the host to retrieve the OID in question, as
described in Compaq TCP/IP Services for OpenVMS SNMP Programming
and Reference.
5. If the local query is successful, use a MIB browser from another host. This is
useful when timeout problems indicate that network delays are the cause of
the problem.
Configuring and Managing SNMP 14–27
Configuring and Managing SNMP
14.6 Solving SNMP Problems
6. Check the log files for any problems associated with SNMP startup. For
detailed information, start the SNMP components separately with tracing
enabled, as described in Section 14.6.4.
7. Use a protocol analyzer to intercept messages going to the target. The
TCPTRACE utility is available on OpenVMS hosts. Enter the DCL command
HELP TCPTRACE for information about how to use this utility. For the
failing message:
•
Confirm the community configuration, as described in Section 14.6.5.2.2.
Make sure the default community is configured correctly. For example,
make sure that a read-only community name, such as ‘‘public,’’ is not
being used for set requests. For more information about community
names, refer to the Compaq TCP/IP Services for OpenVMS SNMP
Programming and Reference guide.
•
Check to make sure the client used the correct query format.
8. Check for problems with ownership, protections, or installation of images,
using standard OpenVMS DCL commands, such as DIRECTORY and
INSTALL.
For example, the following message indicates that one of these factors is a
possible problem:
WARNING: select returned -1 on snmpd sockets: not owner
The owner for all SNMP executables should be [SYSTEM]. At a minimum,
the protection should be set to S:RWED,O:RWED,G:RE,W:RE.
9. If you cannot get a response for MIB variables handled by certain subagents,
verify that the subagents are running by entering the following command:
$ SHOW SYSTEM
Check for the following processes:
•
TCPIP$SNMP_n (master agent)
•
TCPIP$OS_MIBS (standard subagent)
•
TCPIP$HR_MIB (standard subagent)
See the Compaq TCP/IP Services for OpenVMS SNMP Programming and
Reference guide for descriptions of these processes.
Also check for custom subagents whose process names appear after RUN
commands in the following command procedure:
SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM.
If these processes and additional subagents follow the model of the Chess
example, they should be in LEF state. Excessive time in HIB state
indicates a problem. If the processes are not there, check log files for
the possible cause of abnormal termination. Note that you must run the
SYS$STARTUP:TCPIP$SNMP_SHUTDOWN.COM procedure in order to
see entries in the latest .LOG and .ERR files. If a query on members of the
hrFSTable group results in no response or in a ‘‘no such name’’ response, the
problem might be one of the following:
•
No devices are mounted through NFS.
•
Access to mount information is not available because the proxy is not set
up to allow the TCPIP$HR_MIB subagent to access NFS-mounted disks.
14–28 Configuring and Managing SNMP
Configuring and Managing SNMP
14.6 Solving SNMP Problems
Additional problems occur if file protections or installation privileges were
changed on SYS$SYSTEM:TCPIP$HR_MIB.EXE.
14.6.6.1 Solving Timeout Problems with SNMP Subagents
If queries from a client to an OpenVMS SNMP server are consistently timing
out, consider solutions on either the client or server side. For information about
checking the client side, refer to the Compaq TCP/IP Services for OpenVMS
SNMP Programming and Reference guide.
On the server:
•
Adjust the default timeout value for master agent/subagent communication
by redefining the system logical TCPIP$ESNMP_DEFAULT_TIMEOUT, as
described in Table 14–5.
•
Analyze the performance of slow areas of subagent code to improve the speed
of those areas.
•
Split up one subagent into multiple subagents, each handling a subset of the
original OID tree.
•
Adjust the timeout for individual subagents using esnmp_init( ), as described
in the Compaq TCP/IP Services for OpenVMS SNMP Programming and
Reference guide.
Before making extensive modifications to either the client or the server, consider
analyzing the network load for congestion problems.
14.6.7 Disabling SNMP OPCOM Messages
To disable OPCOM messages for SNMP, enter the following command sequence:
TCPIP> SET SERVICE SNMP /LOG=NOALL
TCPIP> DISABLE SERVICE SNMP
TCPIP> ENABLE SERVICE SNMP
Be aware that when you disable OPCOM messages, you may be suppressing
information that is useful for solving problems.
Configuring and Managing SNMP 14–29
Part 4
Configuring Network Applications
Part 4 describes how to set up popular networking end-user applications and
includes the following chapters:
•
Chapter 15, Configuring and Managing TELNET, describes how to set your
host as a TELNET server, allowing users on remote hosts to establish login
sessions.
•
Chapter 16, Configuring and Managing FTP, describes how to set up your
host as a FTP server, allowing users on remote hosts to transfer files.
•
Chapter 17, Remote (R) Commands, describes how to set up the server
implementations of the popular Berkeley Remote (R) commands that enable
remote file copying (RCP), remote logins (RLOGIN), remote command
execution (RSH and REXEC), and remote management of magnetic tape and
CD-ROM (RMT/RCD) drives.
•
Chapter 18, Configuring and Managing SMTP, Chapter 19, Configuring and
Managing the POP Server, and Chapter 20, Configuring and Managing the
IMAP Server, describe how to configure and manage the components that
allow users to send and receive internet electronic mail.
•
Chapter 21, Configuring XDMCP-Compatible X Displays, describes how to
configure an XDMCP-compatible X display using the TCP/IP Services XDM
server.
15
Configuring and Managing TELNET
The TCP/IP Services product includes and implementation of the TELNET
end-user application.
This chapter describes how to set up your host as a TELNET server.
For information about using TELNET, see the HP TCP/IP Services for OpenVMS
User’s Guide. For information about using the TELNET print symbiont, see
Chapter 25.
This chapter describes:
•
How to manage the TELNET service (Section 15.1)
•
How to solve TELNET problems (Section 15.2)
15.1 Managing TELNET
Managing TELNET includes the following tasks:
•
Setting up user accounts
•
Creating and deleting sessions
•
Displaying login messages
15.1.1 TELNET Startup and Shutdown
The TELNET service can be shut down and started independently of TCP/IP
Services. This is useful when you change parameters or logical names that
require the service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$TELNET_STARTUP.COM allows you to start up
TELNET independently.
•
SYS$STARTUP:TCPIP$TELNET_SHUTDOWN.COM allows you to shut
down TELNET independently.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$TELNET_SYSTARTUP.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
TELNET is started.
•
SYS$STARTUP:TCPIP$TELNET_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
TELNET is shut down.
Configuring and Managing TELNET 15–1
Configuring and Managing TELNET
15.1 Managing TELNET
15.1.2 Managing TELNET with Logical Names
Table 15–1 lists the logical names you can use in managing the TELNET
service.
Table 15–1 TELNET Logical Names
Logical Name
Description
TCPIP$TELNET_NO_REM_ID
Disables the intrusion detection mechanism
used by DECnet network login logicals
SYS$REM_ID, SYS$REM_NODE,
SYS$NODE_FULLNAME. When this logical
is set to TRUE, the SYS$REM* logicals are
not set, thus bypassing intrusion-detection on
logins. By default, this logical is not set.
TCPIP$TELNET_VTA
Enables TELNET virtual terminals.
15.1.3 Setting Up User Accounts
Hosts typically run a TELNET server with TELNET client software. Users on
client hosts need valid accounts on server hosts before using TELNET to establish
a remote session.
If your local host is to be a TELNET server, create OpenVMS accounts for remote
users. You can create several individual accounts or one account that many
remote users will share.
15.1.4 Creating and Deleting Sessions
You can create and delete TELNET sessions from within a command procedure or
interactively. Enter the DCL command TELNET with the /CREATE_SESSION
or /DELETE_SESSION qualifier. These qualifiers have the same function as the
following commands:
TELNET> CREATE_SESSION host port dev-unit
TELNET> DELETE_SESSION dev-unit
For example:
$ TELNET /CREATE_SESSION TS405 2002 902
You can create a TELNET device that times out after a specified idle period then
reconnects when data is written to it. Use the /TIMEOUT qualifier to specify the
idle time and the reconnection interval, as described in the following table:
15–2 Configuring and Managing TELNET
Configuring and Managing TELNET
15.1 Managing TELNET
Qualifier
Description
/TIMEOUT
Creates a TELNET device that has the following connection
attributes:
/NOTIMEOUT
•
NOIDLE—The connection is broken when the device is
finally deassigned. The device will automatically reconnect
when data is written to it.
•
IDLE—Specifies the idle time for the device (in the format
hh:mm:ss). Note that the time has a granularity of 1
second. If the device is idle for at least the specified
amount of time, then the connection will be broken. ‘‘Idle’’
means that the device has neither received nor sent any
data for the idle period.
•
NORECONNECTION—The device does not automatically
retry reconnections if they fail.
•
RECONNECTION—When data is written to the device
and it is not connected, this value determines the interval
between reconnection attempts. For example, if an
application writes to a TN with a RECONNECTION value
of 0:1:00 and the first connection attempt fails, subsequent
connection attempts will be made in 1-minute intervals.
Creates a TELNET device that breaks the connection when
the device is finally deassigned (the last channel assignment is
deassigned).
15.1.5 Displaying Login Messages
To display login and logout messages at the operator’s console and log file, enter:
TCPIP> SET SERVICE TELNET /LOG=(LOGIN,LOGOUT)
15.1.6 TELNET Client (TN3270)
IBM 3270 Information Display System (IDS) terminal emulation (TN3270) lets
users make connections to hosts that use IBM 3270 model terminals.
TN3270 has default IBM 3270 IDS function assignments for DIGITAL keyboards.
In addition, users can make their own assignments and might ask you for help.
TCP/IP Services provides EBCDIC-to-DMCS and DMCS-to-EBCDIC translation
tables you can customize. Appendix B describes how to customize and rebuild
these translation tables.
For more information about using TN3270, enter the following DCL command:
$ HELP TN3270
15.1.7 Configuring and Managing the Kerberos TELNET Server
Kerberos is a network authentication protocol designed to provide strong
authentication for client/server applications by using secret-key cryptography.
Kerberos uses strong cryptography so that a client can prove its identity to
a server (and vice versa) across an insecure network connection. The TCP/IP
TELNET service uses Kerberos to make sure the identity of any user who
requests access to a remote host is authentic.
TCP/IP Services supports Kerberos security for TELNET connections, providing a
Kerberos TELNET server and a Kerberos TELNET client.
Configuring and Managing TELNET 15–3
Configuring and Managing TELNET
15.1 Managing TELNET
Before you can use the Kerberos TELNET client, the OpenVMS Security Client
software must be configured on the OpenVMS system. For more information
about installing and configuring the OpenVMS Security Client software, see the
HP Open Source Security for OpenVMS, Volume 3: Kerberos manual.
It is assumed that anyone using the Kerberos security features in TCP/IP has
expert knowledge of Kerberos.
Note
Encryption is not supported in this version of TCP/IP Services.
For information about using the Kerberos TELNET client, refer to the HP
TCP/IP Services for OpenVMS User’s Guide.
15.1.7.1 Configuring the Kerberos TELNET Server
TCP/IP Services supports a separate Kerberos TELNET server, in addition to the
standard TCP/IP TELNET server.
You can enable the TELNET server with Kerberos support by selecting the
Kerberos TELNET server from the TCPIP$CONFIG.COM command procedure,
as described in the HP TCP/IP Services for OpenVMS Installation and
Configuration guide.
15.1.7.2 Connecting to the Kerberos TELNET Server
The Kerberos TELNET server uses port 2323. Specify this port on the TELNET
command line. For example:
$ TELNET/AUTHENTICATE terse.mbs.com /PORT=2323
%TELNET-I-TRYING, Trying ... 17.21.205.153
%TELNET-I-SESSION, Session 01, host terse.mbs.com, port 2323
-TELNET-I-ESCAPE, Escape character is ^]
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3
Username:
15.1.8 Kerberos Principal Names
Before you use the Kerberos TELNET client, make sure the local host name
is fully qualified in the local hosts database. Kerberos realms form principal
names using fully-qualified domain names. For example, terse.mbs.com is a fully
qualified domain name; terse is a simple host name.
HP TCP/IP Services for OpenVMS is usually configured so that the host name is
entered in the hosts database as a simple host name. That is, on host TERSE,
the TCP/IP management command SHOW HOST TERSE returns terse, not
terse.mbs.com.
To correct a mismatch between the Kerberos realm and the TCP/IP Services
configurations, follow these steps from a privileged account at a time when
system usage is low:
1. Find the host’s numeric address. For example:
15–4 Configuring and Managing TELNET
Configuring and Managing TELNET
15.1 Managing TELNET
$ TCPIP
TCPIP> SHOW HOST terse
LOCAL database
Host address
15.28.311.11
Host name
terse
2. Remove the simple host name. For example:
TCPIP> SET NOHOST terse/CONFIRM
3. Use the SET HOST command to associate the fully qualified domain name
with the IP address, as shown in the following example:
TCPIP> SET host "terse.mbs.com"/ADDRESS=15.28.311.11 _TCPIP> /ALIAS=("TERSE.MBS.COM", "terse", "TERSE")
Specify the /ALIAS qualifier to ensure that applications can handle host
names in uppercase and lowercase.
4. Confirm that the first name returned is fully qualified.
TCPIP> SHOW HOST terse
LOCAL database
Host address
15.28.311.11
Host name
terse.mbs.com, TERSE.MBS.COM, terse, TERSE
15.2 Solving TELNET Problems
To improve TELNET performance, try modifying some of the internet parameters.
These changes might also decrease the use of system resources.
15.2.1 TELNET Characteristics That Affect Performance
The settings for the TELNET systemwide characteristics might affect TCP/IP
Services and TELNET performance. To display the TELNET systemwide
characteristics, enter:
TCPIP> SHOW SERVICE TELNET /FULL
The command generates a display similar to the following:
Service: TELNET
State: Enabled
Port: 23 Protocol: TCP Address: 0.0.0.0
Inactivity: 1 User_name: Process: not defined
Limit:30 Active: 1 Peak: 4
File: not defined
Flags: Listen Priv Rtty
Socket Opts: Keepalive
Receive: 3000 Send: 3000
Log Opts: Actv Dactv Conn Error Logi Logo Mdfy Rjct Addr
File: not defined
Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
Configuring and Managing TELNET 15–5
Configuring and Managing TELNET
15.2 Solving TELNET Problems
15.2.2 Requests That Cannot Be Satisfied
The TELNET server sends the following error message for a TELNET login
request that cannot be satisfied:
SS$_EXQUOTA
This error is due to insufficient local resources, such as:
•
Too many sessions
To determine whether this is the cause of the problem, check to see whether
the maximum number of concurrent sessions has been exceeded. Enter the
following TCP/IP management command:
TCPIP> SHOW SERVICE TELNET
If the maximum number of concurrent sessions has been exceeded, the display
shows:
PEAK=limit
To increase the number of allowed sessions, enter the following command:
TCPIP> SET SERVICE TELNET /LIMIT=n
•
Insufficient OpenVMS nonpaged pool
To determine whether this is the cause of the problem, check to see whether
the OpenVMS nonpaged pool is insufficient for servicing a new TELNET
connection. If so, monitor the server.
To improve any of the parameters, redefine the logical names.
•
Excessive OpenVMS login sessions
To determine whether this is the cause of the problem, check to see whether
the limit for maximum OpenVMS sessions has been exceeded. If the current
value is not appropriate, redefine it.
Verify that the CHANNELCNT parameter (in SYSGEN) is larger than the
number of simultaneous TELNET and RLOGIN sessions that you plan to
support.
15–6 Configuring and Managing TELNET
16
Configuring and Managing FTP
The File Transfer Protocol (FTP) software transfers files between ‘‘nontrusted’’
hosts. Nontrusted hosts require user name and password information for remote
logins.
The TCP/IP Services product includes an implementation of the FTP end-user
applications.
This chapter describes:
•
How to manage the FTP service (Section 16.1)
•
How to solve FTP problems (Section 16.2)
For information on using FTP, see the HP TCP/IP Services for OpenVMS User’s
Guide.
16.1 Managing FTP
Managing FTP consists of the the following tasks:
•
Enabling and disabling FTP
•
Starting and Stopping FTP
•
Configuring anonymous FTP
•
Defining FTP logical names
•
Monitoring FTP with FTP log files
16.1.1 Enabling and Disabling FTP
After FTP is configured by TCPIP$CONFIG, the postinstallation configuration
procedure, it is started automatically when TCP/IP Services is started.
To stop any new connections without losing existing connections, disable the FTP
server interactively using the SET NOSERVICE command. This is useful before
shutting down FTP, as described in Section 16.1.2.
To disable FTP when TCP/IP Services starts, use the SET CONFIGURATION
NOSERVICE command.
See the HP TCP/IP Services for OpenVMS Management Command Reference
for descriptions of the SET SERVICE and SET CONFIGURATION SERVICE
commands.
Configuring and Managing FTP 16–1
Configuring and Managing FTP
16.1 Managing FTP
16.1.2 FTP Startup and Shutdown
The FTP service can be shut down and started independently from TCP/IP
Services. This is useful when you change parameters or logical names that
require the service to be restarted.
The following command procedures are provided:
•
SYS$STARTUP:TCPIP$FTP_STARTUP.COM allows you to start FTP
independently.
•
SYS$STARTUP:TCPIP$FTP_SHUTDOWN.COM allows you to shut down
FTP independently.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$FTP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when FTP is started.
•
SYS$STARTUP:TCPIP$FTP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when
FTP is shut down.
16.1.3 Configuring Anonymous FTP
Anonymous FTP is an FTP session in which a user logs in to the remote server
using the user name ANONYMOUS and, by convention, the user’s real user name
as the password.
On the local FTP server, local users can access files without password
authentication. Remote users do not require an account. File access is controlled
by regular OpenVMS access restrictions.
When you use TCPIP$CONFIG to establish an ANONYMOUS account, a
new account is created with the UIC [ANONY,ANONYMOUS] (by default,
[3376,xx]), user name ANONYMOUS, account ANONY, default directory
SYS$SYSDEVICE:[ANONYMOUS], and the following types of login access:
network
full access
batch
no access
local
no access
dialup
no access
local
no access
The usual OpenVMS file protection codes restrict file access for inbound
anonymous FTP sessions to this directory, its subdirectories, and files with
an owner attribute of [ANONY,ANONYMOUS].
When the ANONYMOUS account has been created, a remote FTP client can:
•
Copy files to and from GUEST$PUBLIC.
•
From the ANONYMOUS$USER directory:
Delete files
Create directories
Delete directories
Rename files
16–2 Configuring and Managing FTP
Configuring and Managing FTP
16.1 Managing FTP
Rename directories
You can set up guest and public directories for bulletin board or group interest.
Make sure the directory protections are set to read-only or read/write, as needed.
In the following example, UNIX user ubird connects to the ANONYMOUS
account on OpenVMS host TRAGOPAN. TRAGOPAN asks for ubird’s password,
which is not echoed. In response to this request, the user should supply the local
system user name for identification purposes.
% ftp tragopan
Connected to tragopan.asian.pheasant.edu.
220 tragopan.asian.pheasant.edu FTP Server (Version 5.1) Ready.
Name (tragopan:wings): ANONYMOUS
331 Guest login ok, send ident as password.
Password: CARIBBEAN
230 Guest login ok, access restrictions apply.
Welcome to HP TCP/IP Services for OpenVMS
on internet host TRAGOPAN
Date 24-JUN-2000
FTP>
16.1.3.1 Concealed File Systems
The FTP server processes each command individually as it receives the command
and displays a reply based on the command parameters. A reply can include a
file specification that displays part of the server file system.
16.1.3.2 Setting Up Anonymous FTP
Complete the following steps to set up anonymous FTP access on your system:
1. Use the TCPIP$CONFIG procedure to create an account named
ANONYMOUS with the password GUEST.
To create the ANONYMOUS user account, select Optional Components from
the main menu, then select Setup Anonymous FTP Account and Directories.
2. Set user account access restrictions NOLOCAL, NOBATCH, NOREMOTE,
and NODIALUP.
3. Optionally, create public directories and assign to them the devices names
GUEST$PUBLIC and ANONYMOUS$USER. HP neither creates nor
recommends the use of these directories. If you create these directories,
be careful to set protections on them to allow read access only (for
GUEST$PUBLIC) and use other security measures to protect the
ANONYMOUS$USER directory.
4. Create a welcome banner.
When an anonymous user logs in, FTP informs the user of the account’s
restrictions. You can use the TCPIP$FTP_ANONYMOUS_WELCOME logical
name add more information to the welcome text for anonymous users.
Define this logical using the following format:
$ DEFINE/SYSTEM/EXEC TCPIP$FTP_ANONYMOUS_WELCOME "Anonymous User Account"
5. Specify the file name and location for the log files generated by FTP sessions.
Use the TCPIP$FTP_ANONYMOUS_LOG logical name. If you do
not define TCPIP$FTP_ANONYMOUS_LOG, FTP puts the files in
SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG.
Configuring and Managing FTP 16–3
Configuring and Managing FTP
16.1 Managing FTP
Set this logical when the FTP server is not running. For example, to shut
down the FTP server, define the file name and location of the log file, and
then restart the server, enter the following commands:
$ @SYS$STARTUP:TCPIP$FTP_SHUTDOWN.COM
$ DEFINE/SYSTEM TCPIP$FTP_ANONYMOUS_LOG dev:[directory]filename
$ @SYS$STARTUP:TCPIP$FTP_STARTUP.COM
Where dev:[directory]filename is a complete directory and file name
specification.
6. Specify a user name for the anonymous FTP account. Define the logical name
TCPIP$FTP_ANONYMOUS_ALIAS. See Table 16–1 for more information.
16.1.4 Managing FTP with Logical Names
Table 16–1 lists the logical names that you can use to manage the FTP server.
After you define a logical name, you must stop and start the FTP server for the
new setting to take effect.
Table 16–1 FTP Logical Names
Logical Name
Description
TCPIP$FTP_ALLOW_ADDR_
REDIRECT
Allows active-mode connections from an IP address other than
the server’s. By default, such connections are not allowed,
thereby preventing unauthorized data connections from
unknown servers.
TCPIP$FTP_ALLOW_PORT_REDIRECT
Allows passive-mode connections from ports other than port
20. By default, such connections are not allowed, preventing
unauthorized data connections from unknown servers.
TCPIP$FTP_ANONYMOUS_ALIAS
Defines an equivalence list (up to 10 entries) of the login names
of users with access to the ANONYMOUS account. These users
share the same access rights and restrictions.
If you do not define this logical name, the default is
ANONYMOUS as the only login name.
The following command shows how to create an equivalence list
with the names THOMAS, JONES, and SMITH. These users
can log in to the ANONYMOUS account without a password.
$ DEFINE/SYSTEM/EXEC TCPIP$FTP_ANONYMOUS_ALIAS _$ THOMAS,JONES,SMITH
TCPIP$FTP_ANONYMOUS_
DIRECTORY
Defines public directories accessible by the anonymous FTP
user.
TCPIP$FTP_ANONYMOUS_LOG
Defines the location of the anonymous log file. The default is
SYS$SYSDEVICE:[TCPIP$FTP].
TCPIP$FTP_ANONYMOUS_WELCOME
Allows you to specify text that is displayed to anonymous
users at connect time, after the login sequence. For more
information, see Section 16.1.3.2.
(continued on next page)
16–4 Configuring and Managing FTP
Configuring and Managing FTP
16.1 Managing FTP
Table 16–1 (Cont.) FTP Logical Names
Logical Name
Description
TCPIP$FTP_CONVERT_FILE
Define this logical name as TRUE or FALSE. If defined as
TRUE, the FTP server converts files to variable with fixedlength control (VFC) formatted files before transfer. With the
VFC file, users retain the Record Management Services (RMS)
formatting information of their files. For more information
about RMS, refer to the OpenVMS Record Management Services
Reference Manual.
If TCPIP$FTP_CONVERT_FILE is defined as FALSE, there is
no conversion, and RMS formatting information is lost after the
file transfer.
TCPIP$FTPD_ALLOW_ADDR_
REDIRECT
Allows passive-mode connections from an IP address other than
the client’s. By default, such connections are not allowed,
thereby preventing unauthorized data connections from
unknown clients.
TCPIP$FTPD_ALLOW_PORT_
REDIRECT
Allows passive-mode connections from a privileged port.
By default, such connections are not allowed, preventing
unauthorized data connections from unknown clients.
TCPIP$FTPD_DIR_RECURSIVE
Enables recursive directory listings for the
commands.
TCPIP$FTPD_IDLETIMEOUT
Defines the maximum time interval that FTP child processes
can remain idle before FTP closes them. TCP/IP Services
terminates the FTP process if no control or data connection
activity exists for the specified time. The default idle time is 15
minutes. This feature can help to improve system performance.
TCPIP$FTPD_KEEPALIVE
Enables the FTP server to detect idle and broken FTP
connections. Define this logical on the server host by entering:
ls and dir
Specify the value as hh:mm:ss.
TCPIP> DEFINE /SYSTEM/EXEC TCPIP$FTPD_KEEPALIVE 1
TCPIP$FTPD_LOG_CLIENT_ACTIVITY
Activates logging of session-specific information, requests, and
responses. The log file created is SYS$LOGIN:TCPIP$FTP_
SERVER.LOG.
TCPIP$FTPD_NO_FILESIZE_HINT
If defined, the FTP client does not display the file size hint.
TCPIP$FTP_FILE_ALQ
Specifies the number of blocks to be preallocated by Record
Management Services (RMS) to a disk when a file is created.
TCPIP$FTP_FILE_DEQ
Specifies the number of blocks to be added when RMS
automatically extends the file.
TCPIP$FTP_HELP
Specifies an alternate HELP file. By default, the command
HELP FTP reads the data in SYS$HELP:TCPIP$FTP_
HELP.HLB. This logical allows you to specify an alternate
HELP file, useful for getting information in a non-English
language. For example, to define an alternate HELP library
file, enter the following command:
$ DEFINE/SYSTEM TCPIP$FTP_HELP dev:[directory]filename.HLB
where dev:[directory]filename.HLB specifies the alternate HELP
library file.
(continued on next page)
Configuring and Managing FTP 16–5
Configuring and Managing FTP
16.1 Managing FTP
Table 16–1 (Cont.) FTP Logical Names
Logical Name
Description
TCPIP$FTP_KEEPALIVE
Enables the FTP client to detect idle and broken FTP
connections. Define this logical name in the system logical
name table, as follows:
$ DEFINE /SYSTEM/EXEC TCPIP$FTP_KEEPALIVE 1
TCPIP$FTP_NO_VERSION
If defined, FTP does not send file version numbers when you
enter the mget and the ls commands to a host that is not an
OpenVMS host. Define this logical name in the system logical
name table, as follows:
$ DEFINE /SYSTEM/EXEC TCPIP$FTP_NO_VERSION 1
TCPIP$FTP_RAW_BINARY
With this logical name turned on, FTP transfers files in block
I/O mode if the server and client are in binary (image) mode.
To activate this feature, define the logical name as TRUE.
An FTP end-user can override your FALSE definition with the
FTP PUT /RAW command.
TCPIP$FTP_SERVER
Defines the name and location of the TCPIP$FTP_
SERVER.LOG file. By default, the log file is stored in the
directory pointed to by SYS$LOGIN. For example, to specify a
different directory, enter the following command:
$ DEFINE /SYSTEM TCPIP$FTP_SERVER dev:[directory]filename.log
TCPIP$FTP_SERVER_ANNOUNCE
Allows you to specify text that is displayed to users when they
connect, before the login sequence.
The following example shows how to specify a prelogin
announcement:
$ DEFINE/SYSTEM/EXEC TCPIP$FTP_SERVER_ANNOUNCE "FTP Ready"
To activate this change, shut down the FTP server and restart
it, as described in Section 16.1.2.
TCPIP$FTP_SERVER_LOG_CLIENT_
BY_ADDRESS
Specifies that the FTP server will be using IP addresses instead
of host names.
TCPIP$FTP_SERVER_NAME_
SERVICE_RETRY
Specifies the number of times the BIND resolver should
attempt to contact a BIND server if the first attempt fails.
This logical name has no effect if the FTP server is using
IP addresses instead of host names (that is, the logical
name TCPIP$FTP_SERVER_LOG_CLIENT_BY_ADDRESS
is defined).
TCPIP$FTP_SERVER_NAME_
SERVICE_TIMEOUT
Specifies the number of seconds for the timeout interval. For
more information, refer to the description of the SET NAME_
SERVICE/TIMEOUT command in the HP TCP/IP Services for
OpenVMS Management Command Reference manual.
This logical name has no effect if the FTP server is using
IP addresses instead of host names (that is, the logical
name TCPIP$FTP_SERVER_LOG_CLIENT_BY_ADDRESS
is defined).
TCPIP$FTP_STREAMLF
If defined, the FTP server and client create files as RMS
STREAM_LF files. The default is variable-length files.
(continued on next page)
16–6 Configuring and Managing FTP
Configuring and Managing FTP
16.1 Managing FTP
Table 16–1 (Cont.) FTP Logical Names
Logical Name
Description
TCPIP$FTP_SERVER_GENERIC_
READY_MESSAGE
If defined, the FTP server will not display specific service
information when users connect. For example, when this
logical name is not defined:
NODE> FTP FTPSERVER/USER=auser/PASS=mypassword
220 ftpserver.node.com FTP Server (Version 5.4) Ready.
Connected to ftpserver.mysys.myco.com.
331 Username AUSER requires a Password
230 User logged in.
FTP>
When this logical name is defined, the following is displayed
when users connect:
$ FTP FTPSERVER/USER=auser/PASS=mypassword
220 FTP server ready
Connected to ftpserver.mysys.myco.com.
331 Username AUSER requires a Password
230 User logged in.
FTP>
You must restart the FTP service after changing the setting of
this logical name.
TCPIP$FTP_WNDSIZ
Sets the size of the TCP send and receive transmission
windows. Specify a decimal number for the number of bytes.
16.1.4.1 FTP Log Files
By default, the FTP server creates several log files you can use to monitor the
service and user transactions. These log files are:
•
SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_RUN.LOG
This log file contains an abbreviated dialog of each new connection process. It
is created by each new invocation of the server and is accessible only after an
ongoing connection times out or after being closed by the user.
•
SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG
This log file contains Anonymous FTP entries that show:
The user name and source host (FTP client) for the session
The time the session was initiated and terminated
The FTP command that was entered
A time notation for the command
The source and destination file names
•
SYS$LOGIN:TCPIP$FTP_SERVER.LOG
This log file is created in the user’s default login directory. It records session
information, requests, and responses. To initiate the creation of this log file,
the user can define the TCPIP$FTP_LOG_CLIENT_ACTIVITY logical name.
To ensure that all users’ FTP activity is being logged, define this logical
systemwide, as described in Section 16.1.4.
The number of log files (one per FTP session) might become large. To limit the
number of versions, enter:
$ SET FILE file /VERSION=n
Configuring and Managing FTP 16–7
Configuring and Managing FTP
16.2 Solving FTP Problems
16.2 Solving FTP Problems
You can improve FTP performance for users who transfer large files from systems
that are not running TCP/IP Services to a host running the TCP/IP Services
software.
16.2.1 Performance
Large file transfers can affect file transfer performance. A file transfer consists of
the following events:
1. FTP calls RMS to create the file.
2. RMS creates the file with the system’s default for number of blocks to be
allocated (FTP_FILE_ALQ value).
3. If the file being copied is larger than the space originally allocated, RMS
extends the space by adding blocks of memory space.
4. The number of extension blocks is determined by the system’s RMS default
extension quantity (FTP_FILE_DEQ value). For more information about
RMS, refer to the OpenVMS Record Management Services Reference Manual.
Performance is affected by the RMS overhead taken up by the file extension
process. One way to improve performance is to reset the appropriate parameters.
To do this, redefine the FTP logical names that:
•
Reset buffer sizes
•
Preallocate disk blocks
•
Increase the inactivity timer
These logical names are described in the following sections.
16.2.1.1 Buffer Sizes
Changing the window size of the send and receive buffers can improve network
performance. To set or modify the window size, define or redefine the logical
name TCPIP$FTP_WNDSIZ.
•
For a systemwide change, redefine this logical name in the system table.
Edit the SYS$MANAGER:TCPIP$SERVICES_SETUP file to add this line:
$ DEFINE /SYSTEM /EXEC TCPIP$FTP_WNDSIZ 4096
•
For the change to apply to one user, define the logical name in the
LOGIN.COM file in the default directory of that user.
For noisy lines, such as modems, you should set the value of the TCPIP$FTP_
WNDSIZ parameter to a lower number.
16.2.1.2 File Allocation and Extension Sizes
FTP logical names preallocate disk blocks. FTP tells RMS to truncate unused
blocks so that disk space is not wasted. This can affect RMS performance.
To reduce the RMS overhead, use the following logical names:
•
TCPIP$FTP_FILE_ALQ — Modifies the allocation quantity.
Specifies the number of blocks to be allocated to a disk file when it is created.
For example:
$ DEFINE /SYSTEM/EXEC TCPIP$FTP_FILE_ALQ 50000
•
TCPIP$FTP_FILE_DEQ — Default extension quantity.
16–8 Configuring and Managing FTP
Configuring and Managing FTP
16.2 Solving FTP Problems
Specifies the number of blocks to be added when RMS automatically extends
the file. For example,
$ DEFINE TCPIP$FTP_FILE_DEQ 100
Define these logicals in the TCPIP$SYSTARTUP.COM procedure, or in the
SYS$MANAGER:STARTUP_VMS.COM file before the command that starts
TCP/IP Services. Because disk quotas may control the system, these logical
names are defined by default as zero (system RMS defaults) or are undefined. For
file transfers between hosts that both use VMS Plus mode, these logical names
have no effect.
16.2.1.3 Inactivity Timer
The larger the inactivity timer value, the longer FTP maintains sessions without
timing out. Excessive inactive sessions might slow down performance, degrade
security, or prevent other users from establishing sessions.
To increase the inactivity timer, change the value of the
TCPIP$FTPD_IDLETIMEOUT logical name. The default is 15 minutes. For
example:
$ DEFINE TCPIP$FTPD_IDLETIMEOUT 01:00:00
Configuring and Managing FTP 16–9
17
Remote (R) Commands
The TCP/IP Services software includes client and server implementations of the
Berkeley Remote (R) command applications: RCP, RLOGIN, RSH, REXEC, and
RMT/RCD. These applications provide end users with the following capabilities:
RCP
Allows files to be copied between remote hosts.
RLOGIN
Provides interactive access to remote hosts.
RSH
Passes a command to a remote host for execution.
REXEC
Authenticates and executes RCP and other commands.
RMT/RCD
Provides remote access to magnetic tape and CD-ROM drives.
This chapter reviews key concepts and describes:
•
How to manage the R command servers (Section 17.2)
•
Security considerations (Section 17.3)
•
How to create a welcome message (Section 17.4)
•
How the Remote Magnetic Tape/Remote CD-ROM (RMT/RCD) service
operates (Section 17.5)
For information about using these applications, see the HP TCP/IP Services for
OpenVMS User’s Guide.
17.1 Key Concepts
In addition to password authentication, the R commands use a system based on
trusted hosts and users. Trusted users on trusted hosts are allowed to access
the local system without providing a password. Trusted hosts are also called
‘‘equivalent hosts’’ because the software assumes that users given access to a
remote host should be given equivalent access to the local host. The system
assumes that user accounts with the same name on both hosts are ‘‘owned’’ by
the same user. For example, the user logged in as molly on a trusted system is
granted the same access as a user logged in as molly on the local system.
This authentication system requires databases that define the trusted hosts and
the trusted users. On UNIX systems, these databases include:
•
/etc/hosts.equiv
This file defines the trusted hosts and users for the entire system.
•
.rhosts
This file defines the trusted hosts and users for an individual user account.
This file is located in the user’s home directory.
On OpenVMS hosts, the proxy database TCPIP$PROXY.DAT defines trusted
hosts and users for the entire system.
Remote (R) Commands 17–1
Remote (R) Commands
17.2 Managing the R Command Servers
17.2 Managing the R Command Servers
The following sections describe the command procedures and logical names used
in managing the R command servers.
17.2.1 R Command Server Startup and Shutdown
Each R command server can be shut down and started independently. This is
useful when you change parameters or logical names that require the service to
be restarted.
The following files allow you to start up each R command server independently:
•
SYS$STARTUP:TCPIP$REXEC_STARTUP.COM
•
SYS$STARTUP:TCPIP$RMT_STARTUP.COM
•
SYS$STARTUP:TCPIP$RSH_STARTUP.COM
•
SYS$STARTUP:TCPIP$RLOGIN_STARTUP.COM
The following files allow you to shut down the each R command server
independently:
•
SYS$STARTUP:TCPIP$REXEC_SHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RMT_SHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RSH_SHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RLOGIN_SHUTDOWN.COM
To preserve site-specific parameter settings and commands to be executed when
the R server starts up, create one of the following files, as appropriate. These
files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$REXEC_SYSTARTUP.COM
•
SYS$STARTUP:TCPIP$RMT_SYSTARTUP.COM
•
SYS$STARTUP:TCPIP$RSH_SYSTARTUP.COM
•
SYS$STARTUP:TCPIP$RLOGIN_SYSTARTUP.COM
To preserve site-specific parameter settings and commands to be executed when
the R server shuts down, create one of the following files, as appropriate. These
files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$REXEC_SYSHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RMT_SYSHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RSH_SYSHUTDOWN.COM
•
SYS$STARTUP:TCPIP$RLOGIN_SYSHUTDOWN.COM
17.2.2 Managing RLOGIN with Logical Names
Table 17–1 lists the logical names you can use for managing the RLOGIN
service.
17–2 Remote (R) Commands
Remote (R) Commands
17.2 Managing the R Command Servers
Table 17–1 RLOGIN Logical Names
Logical Name
Description
TCPIP$RLOGIN_VTA
Enables RLOGIN virtual terminals. For more
information, see Section 17.3.
TCPIP$RLOGIN_MESSAGE
Specifies the welcome message displayed by
the RLOGIN server. For more information,
see Section 17.4.
17.3 Security Considerations
Because R commands can bypass normal password verification, it is important to
configure these applications carefully to avoid compromising system security. In a
complex networking environment, improperly configured R commands can open
access to your host to virtually anyone on the network.
A properly configured environment grants remote access to preauthorized
clients. You can limit access by adding an entry to the proxy database
(TCPIP$PROXY.DAT) for each user authorized to access your host. This
entry, called a communication proxy, provides the user name and name of the
remote host. To add a communication proxy, enter:
TCPIP> ADD PROXY user /HOST=host /REMOTE_USER=user
For each host, be sure to define the host name and any aliases.
Users with communication proxies cannot use virtual terminals. Therefore, if the
logical name TCPIP$RLOGIN_VTA is set, users logging in by proxies will observe
that the terminal device they are assigned is displayed as TNAnnn rather than
VTAnnn. For more information, see Section 17.2.2.
17.3.1 Registering Remote Users
For users on UNIX hosts, the following information must be listed in at least one
of the following databases:
Database File
Type of Information
/etc/hosts.equiv
.rhosts
Host name and user name
Host name and user name
(in the user’s home directory)
For users on OpenVMS clients running TCP/IP Services, check that the
appropriate proxy information is in the remote system’s proxy database.
You can also restrict remote printing to specific users by entering:
TCPIP> SET SERVICE service /FLAGS=APPLICATION_PROXY
With this flag set, the R commands use the communication entries in the proxy
database for authentication.
To reject access from a remote host, use the SET SERVICE service /REJECT
command. For example:
TCPIP> SET SERVICE RLOGIN /REJECT=HOSTS=(loon,ibis,tern)
Remote (R) Commands 17–3
Remote (R) Commands
17.3 Security Considerations
17.3.2 Case-Sensitivity Flag
The proxy database is case sensitive for remote user names. The case you use for
communications entries affects the way users access your host, so use case in a
consistent fashion. In the proxy database, if the user name is in:
•
Uppercase, the user must use the /NOLOWERCASE qualifier.
•
Lowercase, RSH and RLOGIN default to /LOWERCASE.
If the flag CASE_INSENSITIVE is set, the server matches an incoming user
name with an all-lowercase or an all-uppercase remote user name in the proxy
database.
The case-sensitivity flag for RLOGIN, RSH, and RCP defaults to CASE_
INSENSITIVE. With this setting, the server accepts both all-uppercase and
all-lowercase user names.
Ensure that RSH is enabled, because no RCP service exists. Instead, RCP uses
the RSH server process. (RCP uses RSH or REXEC to do its work. RSH must be
configured properly for RCP to work.)
17.4 Creating a Welcome Message
To modify the welcome message displayed by the RLOGIN server, define the
TCPIP$RLOGIN_MESSAGE logical name and specify the text. For example, the
following command defines a welcome message for RLOGIN clients when they log
in to the server:
$ DEFINE /SYSTEM TCPIP$RLOGIN_MESSAGE "OpenVMS RLOGIN Server Version 5.4"
17.5 Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)
The Remote Magnetic Tape/Remote CD-ROM (RMT/RCD) server provides remote
system access to local OpenVMS magnetic tape and CD-ROM drives. The tape or
CD-ROM drives appear to the RMT client users as if they were mounted locally.
The RMT server fully implements the UNIX commands rdump and rrestore and
the OpenVMS commands MOUNT, BACKUP, COPY, and EXCHANGE.
This section assumes that you are familiar with device mounting and server
access conditions relevant to the R command services.
17.5.1 Preparing Drives for Remote Mounts
Perform the following tasks to make sure the remote client can access the tape or
CD-ROM drive:
1. Enable the RSH, REXEC, and RMT services.
2. Load a magnetic tape or CD-ROM into the device.
With a tape device, the client mounts and allocates the tape; you do not need
to perform this task.
With a CD-ROM device, you need to make the device accessible by entering a
MOUNT /SYSTEM command.
3. Make sure the remote shell command (RSH) works from the UNIX root
account.
•
Create the OpenVMS account named ROOT. This account must have
PHYIO and VOLPRO privileges.
17–4 Remote (R) Commands
Remote (R) Commands
17.5 Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)
•
Create a communication proxy that associates the remote RMT client user
with the OpenVMS account ROOT on the RMT server host. For example:
TCPIP> add proxy root /HOST=host /REMOTE=user
See Section 17.3 for more information about communication proxies.
4. Make sure the rsh command works from the user’s account on the remote
UNIX host.
5. For the OpenVMS account ROOT, suppress SYS$LOGIN and LOGIN.COM
output by entering the following commands:
$ RMT_VERIFY = ’F$VERIFY(0)
...
$ IF (F$MODE() .NES. "OTHER") THEN $RMT_VERIFY = F$VERIFY(RMT_VERIFY)
17.5.2 Client Utilities
On the remote host, a user can use rdump to dump files to OpenVMS tapes, or
rrestore to restore files from OpenVMS tapes. The functionality of rdump and
rrestore depends entirely on the type of UNIX system you use and not on the
RMT service. For example, not all UNIX systems let you restore files selectively
using rrestore.
When you enter these remote dump and restore commands, you must specify
either a valid OpenVMS magnetic-tape device name, or a file name.
See the sections on dump, rdump, restore, and rrestore in your client system’s
documentation for details. Be careful about the order in which you specify options
on the command line.
Here is an example of an rdump command:
> /etc/rdump 0f lilac:mua0:/nomount/density=1600 /usr
In the example, the remote user requests to remotely dump the /usr file system
onto device mua0: on system lilac and specifies the /nomount qualifier and a
tape density of 1600 bits per inch.
You can specify the qualifiers described in Table 17–2 with magnetic-tape device
names.
Table 17–2 RMT Magtape Qualifiers
Qualifier
Description
/[NO]ASSIST
Specifies whether to use operator assistance to mount the
volume. The default is /NOASSIST.
/BLOCKSIZE=n
Specifies the block size for magnetic tape volumes. The default
is 65534 bytes.
/CD
Indicates that the remote device is a CD-ROM device.
/COMMENT="string"
Specifies additional information included with the operator
request when the mount operation requires operator assistance
(/ASSIST). The comment appears in the OPCOM message for
the operator.
(continued on next page)
Remote (R) Commands 17–5
Remote (R) Commands
17.5 Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)
Table 17–2 (Cont.) RMT Magtape Qualifiers
Qualifier
Description
/DENSITY=n
Specifies the density (in bits per inch) at which to write a
foreign or unlabeled magnetic tape. The default is the current
density.
/[NO]MOUNT
Specifis whether to use the OpenVMS MOUNT service to
mount the tape. /NOMOUNT gains access to the tape directly
without mounting it. Use this for UNIX utilities that expect
the tape drive to hold its position (not rewind) if the utility
closes it. The default is /MOUNT.
/[NO]REWIND
Specifies whether to rewind the drive when it is closed. The
default is /REWIND.
/[NO]STREAM
Specifies whether to read the tape in record mode
(/NOSTREAM) or byte-stream mode (/STREAM). The default is
/STREAM.
/[NO]UNLOAD
Specifies whether to unload the drive when it is closed. The
default is /UNLOAD.
/[NO]WRITE
Specifies whether you can write to the magnetic tape. The
default is /WRITE.
17.5.3 Client Examples
The following steps perform rdump and rrestore functions from a UNIX client
system. These commands dump two UNIX directories to the tape with separate
rdump commands. These commands then restore files selectively from the tape to
the UNIX client system:
1. Put the directories on the tape by entering two rdump commands. Specify the
/nomount/norewind/nounload qualifiers to prevent OpenVMS from rewinding
the tape. Although the UNIX system reports that the tape was rewound, it
was not actually rewound. The commands are:
UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir1
UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir2
2. Restore the files selectively from the tape using rrestore. Be sure the tape
is loaded and rewound. Use either the interactive or noninteractive command
syntax.
The rrestore command might display messages such as "You have not read
any volumes yet" and then ask you to specify the next volume. Although these
messages might appear, rrestore should work properly.
In the following example, rrestore extracts the file specified by file_name from
dump file number 2 on the tape:
UNIX> /etc/rrestore fsx vax:device/nomount/nounload/norewind 2 file-name
In the following example, rrestore invokes the interactive utility to let the
user specify particular files that were put on the tape in dump file 2. The add
command then adds the files to the extraction list and the extract command
restores them:
UNIX> /etc/rrestore fis vax:device/nomount/nounload/norewind 2
restore> add file_name
restore> extract
17–6 Remote (R) Commands
18
Configuring and Managing SMTP
The Simple Mail Transfer Protocol (SMTP) is a standard protocol that provides
a reliable and efficient mail delivery system between systems communicating in
a TCP/IP network. SMTP specifies the format of control messages sent between
two machines to exchange electronic mail, but it does not specify the mail
interface.
The TCP/IP Services product implements SMTP as an OpenVMS symbiont that
works with the OpenVMS Mail utility.
This chapter reviews key concepts and describes:
•
How to configure SMTP (Section 18.2)
•
How to create a local alias file (Section 18.3)
•
How to manage SMTP (Section 18.4)
•
How to modify the SMTP configuration (Section 18.5)
•
How to configure the SMTP Antispam feature (Section 18.6)
•
How to manage the SMTP send-from-file (SFF) feature (Section 18.7)
•
How to disable the SMTP outbound alias feature (Section 18.8)
•
How to solve SMTP problems (Section 18.9)
See the HP TCP/IP Services for OpenVMS User’s Guide for information about
using SMTP to send and receive mail.
18.1 Key Concepts
To be reliable, electronic mail systems must be able to cope with situations where
the recipient is temporarily unavailable, for example, if the recipient’s host is
down or off line. Mail must also be able to handle situations where some of the
recipients on a distribution list are available and some are not.
SMTP is a store-and-forward mail protocol that accepts mail from an originating
host and forwards it through one or more intermediate hosts before it reaches
its final destination. Note that this behavior differs from OpenVMS Mail, where
mail is sent directly from the originating node to the destination node.
Local mail is mail destined for a local system. If SMTP receives mail for any
local systems, it delivers the mail using OpenVMS Mail rather than forwarding it
on to another system.
Configuring and Managing SMTP 18–1
Configuring and Managing SMTP
18.1 Key Concepts
18.1.1 How SMTP Clients and Servers Communicate
In most implementations, SMTP servers listen at port 25 for client requests. In
the TCP/IP Services implementation of SMTP, the SMTP receiver is invoked by
the auxiliary server when an inbound TCP/IP connect comes in to port 25 (if the
SMTP service is enabled). The auxiliary server runs the command procedure
specified in the SMTP service database entry that runs the receiver. The receiver
image is SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE. The receiver process
runs in the TCPIP$SMTP account.
The SMTP symbiont processes all mail on the host. It receives jobs one at a
time from the generic SMTP queue and delivers them either locally by means of
OpenVMS Mail, or remotely by means of SMTP.
The configuration procedure TCPIP$CONFIG sets up the SMTP queues for you.
See Section 18.2 for more information on configuring SMTP.
After receiving a client request, the SMTP server responds, indicating its status
(available or not available). If the server is available, it starts an exchange of
control messages with the client to relay mail. (Like FTP, SMTP does not define a
message format. SMTP commands are sent as ASCII text, and the SMTP server
at the remote host parses the incoming message to extract the command.)
The following steps occur:
1. The auxiliary server listens for requests, starts the SMTP receiver, and
accepts the TCP connection.
2. The client identifies itself by sending its fully qualified domain name.
3. The server replies with its own fully qualified domain name.
4. The client sends the full mail address of the sender enclosed in angle
brackets; if the server is able to accept the mail, it returns a readiness code.
5. The client sends the full mail address (also enclosed in angle brackets) of the
message’s intended recipients.
6. The client sends the body of the message.
A minimum of five control message commands are required to conduct the
preceding sequence. Table 18–1 describes these commands.
Table 18–1 SMTP Client Commands
Command
Description
HELO
Identifies the originating host to the server host. Use
the /DOMAIN qualifier to provide the name of the
originating host.
MAIL FROM:<reverse-path>
Identifies the address at which undeliverable mail
should be returned. Usually is the originating host.
RCPT TO:<forward-path>
Address of the intended receiver. If sending mail to
multiple recipients, use one RCPT TO command for
each recipient.
DATA
Signals the end of the RCPT TO commands and tells
the recipient to prepare to receive the message itself.
(continued on next page)
18–2 Configuring and Managing SMTP
Configuring and Managing SMTP
18.1 Key Concepts
Table 18–1 (Cont.) SMTP Client Commands
Command
Description
QUIT
Indicates no more commands.
These commands are described in RFC 821.
18.1.2 Understanding the SMTP Control File
With TCP/IP Services SMTP, each mail message is packaged into a specialpurpose binary file called a control file. This control file is submitted to a generic
SMTP queue to be processed by the SMTP symbiont. Each control file contains
one SMTP mail message. Note that an SMTP message addressed to multiple
recipients is stored in one control file.
Control file names provide information about the mail contained within. The
format for the control file name is as follows:
yymmddmmshh_user-name_pid.TCPIP_scnode
where:
yymmddmmshh
is the timestamp taken when the file is created.
user-name
is the user name of the process in which the control file was created.
Values for this name include:
•
TCPIP$SMTP — Inbound mail handled by the SMTP receiver.
Control files are stored in the directory referenced by the
TCPIP$SMTP_COMMON logical name.
•
MAIL$SERVER — Mail from DECnet. Control files are stored in
the user’s default OpenVMS Mail directory.
•
SYSTEM — Bounced messages. Control files are stored in the
directory referenced by the TCPIP$SMTP_COMMON logical name.
•
username — Mail directed by SFF (Send From File). Control files
are stored in the user’s default OpenVMS Mail directory.
pid
is the process identification.
scnode
is the value of the SYSGEN SCSNODE parameter.
18.1.3 Understanding OpenVMS Sender Headers
The OpenVMS Mail utility provides one sender mail header: the From: header.
However, SMTP supports a large set of sender headers, including:
•
Resent-Reply-To:
•
Resent-From:
•
Reply-To:
•
Resent-Sender:
•
Sender:
•
ReturnPath:
When it composes an OpenVMS Mail message from an SMTP mail message,
SMTP supplies the first SMTP header that it finds for the OpenVMS Mail From:
header.
Configuring and Managing SMTP 18–3
Configuring and Managing SMTP
18.1 Key Concepts
18.1.4 Understanding SMTP Addresses
SMTP addresses are of the form userID@domain.name, where domain.name
refers to a domain for which there is a DNS MX record. Mail Exchange (MX)
records tell SMTP where to route the mail for the domain.
18.1.5 How SMTP Routes Mail
To find a destination address, SMTP routing looks up addresses in this order:
1. Local MX database
2. BIND MX records
3. BIND A records
4. Local hosts database
Most messages are routed using the BIND records. Local MX records are
useful if you want to customize your system’s mail routing. DNS-based records
are networkwide. If you have local MX records, remember that they are case
sensitive and are available on the local node only.
18.1.5.1 Using MX Records
SMTP uses the information stored in MX records, if available, to route mail. MX
tells the SMTP where to route mail for a particular destination domain. The DNS
(such as BIND) maintains the MX records, but SMTP makes use of them. Each
MX record contains the following fields:
Destination domain
Matches the domain portion of the address. This is the key
field of the MX record. For example, if mail is to be sent to
jones@xyzcorp.com, MX lookup is done on the destination
domain xyzcorp.com.
Multiple MX records for the same destination are allowed.
Therefore, in a sense, the destination domain field allows
duplicate keys.
Gateway host name
Specifies the name of the host through which mail sent to the
destination domain should be routed.
Preference
Prioritizes multiple MX records for the same destination
domain. The lower the preference value, the higher the priority
for the MX record. That is, lower-preference MX records are
attempted before higher-preference records.
Multiple MX records to the same domain can have the same
preferences.
Creating multiple MX records for the same destination domain provides the
following advantages:
•
Enables load balancing between mail routers. In this case, use the same
preferences for all the MX records with the same destination domain.
•
Ensures that mail can still be delivered even if one of the routers becomes
unavailable.
•
Provides MX-based routes for mail inside and outside a firewall.
18–4 Configuring and Managing SMTP
Configuring and Managing SMTP
18.1 Key Concepts
18.1.5.2 Using SMTP Zones and Alternate Gateways
When you configure SMTP, you supply the name of the domain for your
environment with the /ZONE qualifier to the SET CONFIGURATION SMTP
command. If you do not include this qualifier, the zone defaults to your local
domain.
Mail for delivery outside of your zone is sent to its destination by the alternate
gateway, as defined by the /GATEWAY qualifier. If you define an alternate
gateway, SMTP routes mail to destinations outside the SMTP zone defined on the
alternate gateway. SMTP uses MX records for routing mail within the zone and,
if no alternate gateway is defined, elsewhere as well.
The following example defines the alternative gateway MY.ALT.MYZONE.COM
and the zone MYZONE.COM.
TCPIP> SET CONFIGURATION SMTP/GATEWAY=ALTERNATE=MY.ALT.MYZONE.COM
TCPIP> SET CONFIGURATION SMTP/ZONE=MYZONE.COM
See the HP TCP/IP Services for OpenVMS Management Command Reference
manual for a detailed desciption of the SET CONFIGURATION SMTP command.
To send mail to the alternate gateway, SMTP does an MX lookup on the alternate
gateway and uses the resulting list of MX records to get the mail to the alternate
gateway. To understand the advantages of this method over a simple lookup of A
records, consider the following example.
The alternate gateway and zone are configured as follows:
TCPIP> SHOW CONFIGURATION SMTP
...
Alternate gateway: relay.abc.com
...
Zone:
abc.com
...
Further, there is no A record configured for the destination domain
relay.abc.com. Therefore, relay.abc.com is not a valid host name. This is
demonstrated by the following command:
TCPIP> SHOW HOST RELAY.ABC.COM
%TCPIP-W-NORECORD, Information not found
-RMS-E-RNF, record not found
There is no such host as relay.abc.com because relay.abc.com is only an MX
destination domain with multiple records at the same preference.
MX records have been set up accordingly. For example:
TCPIP> SHOW MX RELAY.ABC.COM
BIND MX database
Server:
1.2.3.4
host.abc.com
Gate address
Preference
Gate name
1.3.4.5
1.3.5.6
2.4.5.6
2.4.5.7
3.4.5.6
3.4.6.7
100
100
200
200
300
300
mail11.abc.com
mail13.abc.com
mail2.abc.com
mail1.abc.com
mail21.abc.com
mail12.abc.com
Configuring and Managing SMTP 18–5
Configuring and Managing SMTP
18.1 Key Concepts
In this example, when SMTP receives a mail message destined for a domain
outside of the abc.com domain, it uses the list of MX records to send the mail to
the entity called relay.abc.com. Even when mail is routed through the alternate
gateway, the MX lookup list is used.
This type of configuration provides redundancy. Even if one or more of the
systems pointed to by the MX records is down, mail can be routed through one of
the systems that is running.
If the alternate gateway was reached through a simple A record (hostname)
lookup and the host was down or could not be reached, all outbound mail outside
the zone would have to wait until the host came back on line.
You can define the alternate gateway using an IP address; this bypasses the MX
lookup logic. For example:
TCPIP> SET CONFIGURATION SMTP/ALTERNATE=GATEWAY=1.2.3.4
In this case, all mail destined for the alternate gateway will go to the specified IP
address (1.2.3.4) with no MX lookup.
18.2 Configuring SMTP
Use the configuration procedure TCPIP$CONFIG to set up SMTP on your host.
If you need to reconfigure or further refine your SMTP environment, use the SET
CONFIGURATION SMTP command. With this command, you can change the
way SMTP:
•
Relays messages
•
Determines the route
•
Determines how many times it retries a relay and the length of time between
delivery attempts
•
Sends and receives timeouts
For a complete description of this command, its qualifiers, and options, see the
HP TCP/IP Services for OpenVMS Management Command Reference manual.
18.2.1 Mail Utility Files
Table 18–2 lists the utility files created during the SMTP configuration.
Table 18–2 Default SMTP Utility Files
File Name
Description
LOGIN.COM
Used by the auxiliary server.
TCPIP$SMTP_RECV_RUN.COM
Used by the auxiliary server, and stored in the
TCPIP$SYSTEM directory.
TCPIP$SMTP_LOGFILE.LOG
Log of mail queue and symbiont activities.
TCPIP$SMTP_RECV_RUN.LOG
Log of incoming mail.
To analyze the consistency of the SMTP queues against the directories containing
the SMTP utility files, enter the ANALYZE MAIL command.
18–6 Configuring and Managing SMTP
Configuring and Managing SMTP
18.2 Configuring SMTP
18.2.2 Creating a Postmaster Account
SMTP requires that the system be able to receive mail addressed to the user
name POSTMASTER. This user name is the destination for bounced mail
messages.
A bounced mail message is a mail message that has been returned by a remote
server because neither the recipient specified in the original mail message, nor
the original sender can be found by the local SMTP server.
By default, bounced mail is delivered to the following SMTP address:
TCPIP$SMTP@node.domain
To ensure that the POSTMASTER account is set up to receive SMTP mail, use
OpenVMS Mail to specify forwarding of mail addressed to POSTMASTER to the
SYSTEM account. For example:
$ SET PROC/PRIV=SYSPRV
$ MAIL
MAIL> SET FORWARD/USER=POSTMASTER SYSTEM
MAIL> SET FORWARD/USER=TCPIP$SMTP SYSTEM
MAIL> SET FORWARD/USER=UCX_SMTP SYSTEM
This ensures that bounced mail messages are sent to the SYSTEM user (usually
the system manager).
You can modify the user name associated with POSTMASTER by defining the
following logical name:
$ DEFINE /SYSTEM TCPIP$SMTP_POSTMASTER_ALIAS user-name
In this example, user-name is the user name. For more information, see
Section 18.5.
18.3 Creating a Local Alias File
You can used a local alias to define a list of domains that SMTP will interpret
as local. If SMTP receives mail for any of the domains specified as local aliases,
it will deliver the mail on the local system using OpenVMS Mail rather than
forward it on to another system.
This is useful in an OpenVMS Cluster environment, where you want mail sent
to any of the cluster hosts to be delivered locally rather than take the extra step
of relaying it from one cluster node to another. It is also useful if you want to
set up your OpenVMS host to receive inbound mail either for different domains
unrelated to the actual domain of your host or for alias names of your host.
For example, if your host was a.b.com and you had entries for x.y.com and
y.z.com in your local alias file, any mail to x.y.com and y.z.com would be
delivered locally on your host. (To implement this fully, set up DNS MX records
so that mail to the x.y.com and y.z.com domains is routed to your host.) For
more information about setting up DNS records, see Appendix D.
To define a list of domains that SMTP interprets as local, create the file
TCPIP$SMTP_LOCAL_ALIASES.TXT containing a list of domain names that
are to be recognized as local. The domain names should have a maximum of 64
characters with one line per name, up to a maximum of 255 names. For example:
Configuring and Managing SMTP 18–7
Configuring and Managing SMTP
18.3 Creating a Local Alias File
!
! This is the local alias file.
!
ourdomain.edu
ourdomain1.edu
ourdomain2.edu
ourdomain3.edu
Copy the TCPIP$SMTP_LOCAL_ALIASES.TXT file to one of the following
locations:
•
TCPIP$SMTP_COMMON, where each host listed in the
TCPIP$SMTP_LOCAL_ALIASES.TXT file receives clusterwide messages
•
SYS$SPECIFIC:[TCPIP$SMTP] (local system use)
Stop and then restart SMTP for the change to take effect.
If SMTP cannot locate the TCPIP$SMTP_LOCAL_ALIASES.TXT file, it looks
for the file TCPIP$SMTP_COMMON:UCX$SMTP_LOCAL_ALIASES.TXT. This
ensures functionality for mixed clusters (that is, clusters running the current
version of TCP/IP Services and earlier versions of the product (UCX)), where the
TCPIP$SMTP_COMMON and UCX$SMTP_COMMON logicals point to the same
directory. Note that when SMTP looks for UCX$SMTP_LOCAL_ALIASES.TXT
it looks for it in the TCPIP$SMTP_COMMON: directory rather than in the
UCX$SMTP_COMMON: directory.
18.4 Managing SMTP
Table 18–3 summarizes the commands you use to monitor and manage SMTP.
Table 18–3 SMTP Management Commands
Command
Function
Required Privilege
ANALYZE MAIL
Verifies the consistency of the
SMTP queues against the SMTP
working directory.
SYSPRV or BYPASS.
DISABLE SERVICE SMTP
Stops SMTP service.
Follows OpenVMS file protection
rules.
ENABLE SERVICE SMTP
Initializes communications for
SMTP.
Follows OpenVMS file protection
rules.
REMOVE MAIL
Deletes the specified mail entries
from the SMTP queues.
SEND MAIL
SMTP requeues a mail message
for delivery.
SYSPRV or BYPASS for messages
other than yours.
SET CONFIGURATION SMTP
Modifies the characteristics of
the SMTP sender and receiver.
SYSPRV or BYPASS.
SHOW CONFIGURATION
SMTP
Displays the system
characteristics for SMTP.
Follows OpenVMS file protection
rules.
SET SERVICE SMTP
Defines, modifies, or deletes the
SMTP service in the services
database.
SYSPRV or BYPASS.
(continued on next page)
18–8 Configuring and Managing SMTP
Configuring and Managing SMTP
18.4 Managing SMTP
Table 18–3 (Cont.) SMTP Management Commands
Command
Function
Required Privilege
SHOW MAIL
Displays information about mail
for the specified user.
SYSPRV or BYPASS.
SHOW SERVICE SMTP
Displays statistical information
about the SMTP server.
Follows OpenVMS file protection
rules.
START MAIL
Starts the SMTP queuing
mechanism.
SYSPRV or BYPASS.
STOP MAIL
Stops the SMTP queuing
mechanism.
SYSPRV or BYPASS.
18.4.1 Displaying Mail Queues
To monitor the mail queues, examine the TCPIP$SMTP_LOGFILE.LOG and the
TCPIP$SMTP_RECV_RUN.LOG files.
18.4.2 Changing the Number of Mail Queues
To change the number of SMTP queues, follow these steps:
1. Stop SMTP and MAIL on the root node by entering the following commands:
TCPIP> DISABLE SERVICE SMTP
TCPIP> STOP MAIL
2. Change the SMTP configuration by entering the following command:
TCPIP> SET CONFIGURATION SMTP/QUEUES=new_number
The maximum number of queues set with this command is 10.
3. Restart SMTP and MAIL by entering the following commands:
TCPIP> START MAIL
TCPIP> ENABLE SERVICE SMTP
18.4.3 Displaying SMTP Routing Information
To display SMTP routing information, use the SHOW MX_RECORDS command.
If you omit destination from the command line, you see the entries in the local
MX database.
If you specify destination, you see all the entries in all the databases that the
SMTP mailer would look at, if necessary, to route mail to the destination. The
local MX database and the DNS MX database are usually as far as TCP/IP
Services needs to search.
18.4.4 SMTP Logging
SMTP logs mail queue and mail symbiont events to the following files:
•
TCPIP$SMTP_LOGFILE.LOG
•
TCPIP$SMTP_RECV_RUN.LOG
The symbiont and receiver contain a feature called snapshot logging, which
allows you to run with full diagnostics enabled but to write the diagnostics to
the log file only if an error is signaled. This feature saves disk space and allows
the receiver or the symbiont, or both, to run at a normal speed. As each line of
diagnostic text is generated, it is saved in an internal snapshot buffer rather than
to the disk. The buffer is circular in that once it fills up, new lines of text start
Configuring and Managing SMTP 18–9
Configuring and Managing SMTP
18.4 Managing SMTP
to overwrite the old data already there. This functionality provides a snapshot of
the last lines of diagnostic text.
Logical names are available to modify the way SMTP logs information and the
type of information it reports. These are described in Section 18.5.
18.4.5 Starting and Stopping SMTP
SMTP consists of two components: the sender (the queuing mechanism) and the
receiver. You must start the sender before enabling the receiver. The receiver is
activated by the auxiliary server.
The SMTP can be shut down and started independently. This is useful when you
change parameters or logical names that require the service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$SMTP_STARTUP.COM allows you to start up the
SMTP independently.
•
SYS$STARTUP:TCPIP$SMTP_SHUTDOWN.COM allows you to shut down
the SMTP independently.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$SMTP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when the SMTP is
started.
•
SYS$STARTUP:TCPIP$SMTP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
SMTP is shut down.
The SMTP services can be started automatically using the TCPIP$CONFIG
configuration procedure, or manually using the following command:
$ @SYS$STARTUP:TCPIP$SMTP_STARTUP.COM
To stop SMTP, enter:
$ @SYS$STARTUP:TCPIP$SMTP_SHUTDOWN.COM
18.5 Modifying the SMTP Configuration
You can modify the SMTP configuration by defining logical names that are
translated at queue startup time. Characteristics you can control include:
•
Event-and error-logging diagnostics
•
How mail headers are displayed
•
How mail is routed
•
How SMTP interacts with OpenVMS Mail
To store the settings of logical names, include the DEFINE command in one of
the following command procedures:
•
SYS$STARTUP:TCPIP$SMTP_SYSTARTUP.COM, for setting logicals when
SMTP starts up
•
SYS$STARTUP:TCPIP$SMTP_SYSHUTDOWN.COM, for setting logicals
when SMTP shuts down
18–10 Configuring and Managing SMTP
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
When you redefine the value of a logical, you must restart SMTP. Use the
following command procedures to shut down and restart SMTP:
•
SYS$STARTUP:TCPIP$SMTP_STARTUP.COM
•
SYS$STARTUP:TCPIP$SMTP_SHUTDOWN.COM
For more information, see Section 18.4.5.
18.5.1 Defining SMTP Logical Names
Each SMTP logical name changes a configuration setting for handling SMTP mail
operations. Some SMTP logical names enable or disable configuration options. If
you define the logical name, the option is considered to be enabled. If the logical
name is not defined, the option is disabled.
To disable this type of configuration option, simply remove the logical name.
To define this type of logical, set its value to 1.
For example, to enable message logging for messages received from SMTP clients,
define the TCPIP$SMTP_RECV_TRACE as follows:
$ DEFINE/SYSTEM TCPIP$SMTP_RECV_TRACE 1
Other logical names require that you supply a value. For example, to enable
logging that provides information about symbiont activity during control file
processing, define the logical name TCPIP$SMTP_LOG_LEVEL with a value of 3.
For example:
$ DEFINE/SYSTEM TCPIP$SMTP_LOG_LEVEL 3
Note
Always use the /SYSTEM qualifier when you define an SMTP logical
name, except where noted in Table 18–4.
SMTP consists of three main components:
•
Receiver
•
Symbiont
•
MAIL$PROTOCOL (used to communicate with OpenVMS Mail)
Each logical name can be used by one or more of the SMTP components.
18.5.2 SMTP Logical Names
Table 18–4 lists the SMTP logical names and, for each, describes the purpose,
valid settings, and components that use it.
Configuring and Managing SMTP 18–11
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
Table 18–4 SMTP Logical Names
Name
Component
Explanation
TCPIP$SMTP_LOG_LEVEL
Symbiont
Sets the log level, according to the value you
supply:
2—Enables logging of all information
when the symbiont starts up. The Next
Open File message is printed, giving
the name of each control file before
processing begins. All mail headers and
mail recipients in a control file are logged
after control file processing is complete.
3—Provides additional information about
symbiont initialization and activity during
control file processing.
5—Enables full symbiont diagnostics. For
use only under the advice of HP customer
support.
TCPIP$SMTP_NOSEY
Symbiont
Used with TCPIP$SMTP_LOG_LEVEL to print
the full subject RFC headers information.
If not defined, the header is logged as
SUBJECT:<omitted>.
TCPIP$SMTP_LOG_LINE_
NUMBERS
Symbiont
Receiver
MAIL$PROTOCOL
Writes line numbers to SMTP logs.
TCPIP$SMTP_SYMB_TRACE
Symbiont
Logs all messages received from and
transmitted to remote SMTP servers. Used to
trace the SMTP application layer protocol. Any
nonprinting characters or control characters
that are sent or received are printed as \n,
where n is the hexadecimal value of the
character. For example, command lines and
replies are terminated with a <CR><LF> that
appear in the log file as follows:
send buf=MAIL FROM:<jones@acme.com>\d\a
recv buf=250 <jones@acme.com>... Sender OK\d\a
In this message, \ d\ a is the
<CR><LF>.
TCPIP$SMTP_RECV_TRACE
Receiver
Logs all messages received from and
transmitted to remote SMTP clients. Used
to trace the SMTP application layer protocol.
The same conventions for logging nonprinting
characters or control characters are used.
TCPIP$SMTP_RECV_DEBUG
Receiver
Logs full diagnostics, similar to the
TCPIP$SMTP_LOG_LEVEL 5 logical name.
TCPIP$SMTP_VMSMAIL_SEND
MAIL$PROTOCOL
Logs diagnostic messages to a file named
DEBUG.TXT in the default directory. This
logical name is reserved for use by HP.
TCPIP$SMTP_VMSMAIL_PARSE
Symbiont
Receiver
MAIL$PROTOCOL
Causes the SMTP address parsing code to log
diagnostics. This logical name is reserved for
use by HP.
(continued on next page)
18–12 Configuring and Managing SMTP
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
Table 18–4 (Cont.) SMTP Logical Names
Name
Component
Explanation
TCPIP$SMTP_SYMB_
SNAPSHOT_BLOCKS
Symbiont
Enables snapshot logging for the symbiont.
The value you assign to this logical specifies
the size of the snapshot buffer in OpenVMS
blocks (1 block = 512 bytes).
In addition to enabling snapshot logging, you
must also specify the type of logging using the
TCPIP$SMTP_LOG_LEVEL logical name.
When you enable snapshot buffering for the
symbiont, it takes some time for the symbiont
process to stop when you enter the STOP MAIL
command or when you stop the queue. The
delay depends on the size of the snapshot
buffer and the speed of the system and its
disks.
For example, the following command lines set
the log level to 5 and enable snapshot logging
for the SMTP symbiont with a snapshot buffer
of 200 blocks:
$ DEFINE/SYSTEM TCPIP$SMTP_LOG_LEVEL 5
$ DEFINE/SYSTEM TCPIP$SMTP_SYMB_SNAPSHOT_BLOCKS 200
TCPIP$SMTP_RECV_
SNAPSHOT_BLOCKS
Receiver
Enables snapshot logging for the receiver. The
value you assign to this logical name specifies
the size of the snapshot buffer in OpenVMS
blocks (1 block = 512 bytes). When you enable
snapshot buffering, you must also specify
the type of logging, using the TCPIP$SMTP_
RECV_DEBUG and TCPIP$SMTP_RECV_
TRACE logical names.
For example, the following command line
sets all of the receiver diagnostics on and
enables snapshot logging for the receiver with
a snapshot buffer of 200 blocks:
$ DEFINE/SYSTEM TCPIP$SMTP_RECV_DEBUG 1
$ DEFINE/SYSTEM TCPIP$SMTP_RECV_TRACE 1
$ DEFINE/SYSTEM TCPIP$SMTP_RECV_SNAPSHOT_BLOCKS 200
TCPIP$SMTP_NO_SUBS_
DOMAIN_INBOUND
Symbiont
Receiver
MAIL$PROTOCOL
Instructs SMTP not to consider mail that is
sent to the substitute domain as local mail.
By default, SMTP recognizes mail that is addressed to the substitute domain as local mail.
To change this default, define the logical name
TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND.
(continued on next page)
Configuring and Managing SMTP 18–13
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
Table 18–4 (Cont.) SMTP Logical Names
Name
Component
Explanation
TCPIP$SMTP_COMMON
Symbiont
Receiver
MAIL$PROTOCOL
Specifies the default SMTP common
directory for an OpenVMS Cluster. By
default, the SMTP common directory is
SYS$SPECIFIC:[TCPIP$SMTP]. This directory
is used to store bounced mail control files,
receiver control files, symbiont log files,
distribution lists, and the local aliases
(TCPIP$SMTP_LOCAL_ALIASES.TXT).
If you define a different directory to be used
as the SMTP common directory, make sure the
directory you specify allows read (R) and write
(W) access. Copy the distribution lists and the
local aliases files to the directory you specify.
If the directory is shared between a system
running a previous version of the product
(UCX) and this version, granting G:RWE
privilege is sufficient because the UCX_SMTP
and TCPIP$SMTP accounts are in the same
group.
TCPIP$SMTP_JACKET_LOCAL
Symbiont
Puts the SMTP jacket on local mail to provide
sufficient information to the POP server.
TCPIP$SMTP_INBOUND_
NOXVMS
Symbiont
Disables use of the the RFC X-VMS-To header
as the text of the OpenVMS Mail To: header
and the X-VMS-CC header as the text of the
CC: line. Instead, the RFC To: and CC:
headers are used.
If the TCPIP$SMTP_INBOUND_NOXVMS
option is not defined, the X-VMS-To and XVMS-CC headers (if present) are used for the
mail header lines.
TCPIP$SMTP_VMSDEF_TO
Symbiont
Causes OpenVMS callable mail to use the
default text for the To: field (the user name).
Overrides the TCPIP$SMTP_INBOUND_
NOXVMS option for the To: field.
TCPIP$SMTP_MTS_ALLIN1
Symbiont
Used for compatibility with older versions
of MR/MRGATE. When relaying mail from
the SMTP environment to MTS (the message
router), the symbiont puts TCPIP$SMTP into
the From: field. Otherwise, older versions
of MR/MRGATE send the mail back with a
Return path too complicated error. No
longer needed if you are running MR and
MRGATE Version 3.3A.
TCPIP$SMTP_POSTMASTER_
ALIAS
Symbiont
Enables mail bounced by the local host to
appear to be from a user name other than
TCPIP$SMTP@node.domain.
Specify the user name portion of the address,
not including the host name. For example:
$ DEFINE/SYSTEM TCPIP$SMTP_POSTMASTER_ALIAS "Postmaster"
(continued on next page)
18–14 Configuring and Managing SMTP
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
Table 18–4 (Cont.) SMTP Logical Names
Name
Component
Explanation
In this example, bounced mail sent
from the local host appears to be from
Postmaster@node.domain rather than from
TCPIP$SMTP@node.domain.
Be sure to set up a forwarding entry for the
user name you specify. (For more information,
see Section 18.2.2.)
TCPIP$SMTP_REWRITE_MTS_
FROM
Symbiont
If you have most or all of your users’ mail
forwarded to ALL-IN-1, use this logical name
to instruct the symbiont to parse the user name
out of the complex MTS address and append
the local host name instead. As a result, only a
simple address is sent to the Internet and any
replies are relayed correctly to MTS.
TCPIP$SMTP_ALTGATE_
ALWAYS
Symbiont
Sends all mail that is destined for another
system (nonlocal mail) to the alternate gateway.
A zone check is not performed.
TCPIP$SMTP_MX_IF_
NOALTGATE
Symbiont
Use MX records to connect to a host if the
alternate gateway cannot be reached.
TCPIP$SMTP_NO_MX
Symbiont
Does not use MX records to route mail.
Attempts to translate the domain part of each
SMTP address into a host name and send the
mail directly to that address. If the host name
does not translate to an address, the mail is
returned. If the host is not available, the mail
is queued again.
TCPIP$SMTP_LOCAL_ALIAS_
ONLY
Symbiont
Uses only the contents of the local alias file for
determining whether a mail message is local.
TCPIP$SMTP_PROHIBIT_USER_
HEADERS
MAIL$PROTOCOL
Disables outbound alias processing. This
prevents the use of the TCPIP$SMTP_FROM
logical.
TCPIP$SMTP_SFF_REQUIRES_
PRIV
MAIL$PROTOCOL
Requires users to set either SYSPRV, BYPASS
or OPER privileges before using the Send From
File (SFF) feature. For more information about
this feature, see Section 18.7.
TCPIP$SMTP_8BITMIME_HACK
Receiver
Enables SMTP to accept 8BITMIME requests
from SMTP clients, preventing remote clients
from converting the message into a 7-bit format
before sending the mail message to the SMTP
server. On some displays, such as that used
by OpenVMS Mail (a character-cell based
mailer), certain 8-bit strings, such as accented
characters, are converted and displayed in
coded sequences.
To prevent this behavior, set the following
logical:
$ DEFINE/SYS/EXEC TCPIP$SMTP_8BITMIME_HACK 1
(continued on next page)
Configuring and Managing SMTP 18–15
Configuring and Managing SMTP
18.5 Modifying the SMTP Configuration
Table 18–4 (Cont.) SMTP Logical Names
Name
Component
Explanation
When this logical is set, the SMTP receiver
tells remote SMTP clients that 8-bit characters
are supported. In this case, the client does not
convert them to 7-bit format.
TCPIP$SMTP_SUPPRESS_
VERSION_INFO
Symbiont
Receiver
Prevents SMTP from revealing TCP/IP Services
version information.
TCPIP$SMTP_SFF_REQUIRES_
PRIV
Symbiont
Receiver
Requires users to set either SYSPRV, BYPASS
or OPER privileges before using SFF.
18.6 Configuring SMTP Antispam
SPAM is the Internet equivalent of junk mail and is a growing source of
annoyance to Internet users. Antispam is a function of SMTP that is designed to
inhibit the transmission of spam.
SMTP Antispam is implemented in the SMTP receiver which, for the purposes of
this discussion, is called the SMTP server. The following sections describe how to
enable and configure SMTP Antispam.
18.6.1 Enabling and Managing SMTP Antispam
To enable and manage SMTP Antispam, create or edit the following file:
TCPIP$SMTP_COMMON:SMTP.CONFIG
The logical name TCPIP$SMTP_COMMON is defined at TCP/IP Services startup.
For more information, see Section 18.5.
The SMTP.CONFIG file should be owned by TCPIP$SMTP and protection should
be set to (W:RE).
The file SMTP_CONFIG.TEMPLATE is provided to help you create this file; it
contains guidelines on how to configure Antispam.
For guidelines about specifying configuration options in the SMTP.CONFIG file,
see Section 1.1.5.
18.6.1.1 SMTP Antispam Field Names
Table 18–5 describes the field names and values for Antispam configuration.
18–16 Configuring and Managing SMTP
.
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
Table 18–5 Antispam Configuration Options
Field Name
Value
Default
Allow-EXPN
Controls whether the EXPN
command can be used.
Specify one of the following:
LOCALLY
Allow-VRFY
Good-Clients
•
NEVER to prevent
use of the EXPN
command regardless of
the whether the client
is in the Good-Clients
list.
•
ALWAYS to allow use of
the EXPN command
regardless of the
whether the client
is in the Good-Clients
list.
•
LOCALLY to allow
use of the EXPN
command only if the
remote SMTP client’s
IP address matches the
Good-Clients list.
Controls whether the VRFY
command can be used.
Specify one of the following:
•
NEVER to prevent
use of the VRFY
command regardless of
the whether the client
is in the Good-Clients
list.
•
ALWAYS to allow use of
the VRFY command
regardless of the
whether the client
is in the Good-Clients
list.
•
LOCALLY to allow
use of the VRFY
command only if the
remote SMTP client’s
IP address matches the
Good-Clients list.
A list of the IP addresses,
IP nets, DNS hostnames,
and DNS MX domains of
known good SMTP clients.
LOCALLY
If not defined, SMTP will
not check IP address of
SMTP client against this
list.
(continued on next page)
Configuring and Managing SMTP 18–17
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
Table 18–5 (Cont.) Antispam Configuration Options
Field Name
Value
Default
Bad-Clients
A list of the IP addresses,
IP nets, DNS hostnames,
and DNS MX domains of
known bad SMTP clients.
If not defined, SMTP will
not check IP address of
SMTP client against this
list.
Relay-Zones
A list of the SMTP domains
to which the system will
relay mail even if it is from
an unknown client.
If not defined, SMTP
will not check recipient
address of mail against
this list.
RBLs
A list of domains that
maintain RBL lists. For
more information, see
Section 18.6.4.
If not defined, SMTP will
not check IP address of
SMTP client against any
RBL lists.
Relay-Based-On-Mx
TRUE or FALSE. If TRUE,
the SMTP server accepts
relays from unknown
clients to recipients where
the recipient’s domain has
an MX record naming the
local host as a gateway.
FALSE
Reject-Unbacktranslatable-IP
TRUE or FALSE.
FALSE
If TRUE, the SMTP
server rejects any mail
from an SMTP client
whose IP address cannot
be backtranslated to a
hostname.
Accept-Unqualified-Senders
TRUE or FALSE.
FALSE
If TRUE, the SMTP server
accepts mail for which the
sender address (the address
from the MAIL FROM
command) has no domain or
an unqualified domain.
Accept-Unresolvable-Domains
TRUE or FALSE.
FALSE
If TRUE, the SMTP server
accepts mail for which the
sender address (the address
from the MAIL FROM
command) has a domain
that cannot be resolved
using MX lookup.
Reject-Mail-From
A list of wildcarded
patterns that are matched
against the sender address.
If a match occurs, the
MAIL FROM command
is rejected and the link is
disconnected.
If not defined, SMTP
will not check the sender
address of the mail
against the list.
(continued on next page)
18–18 Configuring and Managing SMTP
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
Table 18–5 (Cont.) Antispam Configuration Options
Field Name
Value
Default
Accept-Mail-From
A list of wildcarded
patterns that are matched
against the sender address
if the sender address has
matched one of the entries
in the Reject-Mail-From
list. If the sender address
matches the Accept-MailFrom list, the message is
sent on.
If not defined, SMTP
will not check the sender
address of the mail
against the list.
SPAM-Action
Allows you to configure the
way SMTP reports a spam
event. Specify a commaseparated list including one
or more of the following:
OPCOM
Security
•
NONE
•
OPCOM
•
ACCOUNTING
FRIENDLY or SECURE.
SECURE
This value specifies the
type of error text sent to
the SMTP client when
disconnecting a link
because of a spam event. A
value of SECURE means to
send purposely unhelpful
error text. A value of
FRIENDLY means to send
helpful error text.
Unbacktranslatable-IP-Text
Bad-Clients-Text
Client-In-RBL-Text
Reject-Mail-From-Text
Unqualified-Sender-Text
Unresolvable-Domain-Text
SPAM-Relay-Text
EXPN-Used-Text
VRFY-Used-Text
These individual fields
(one for each type of SPAM
event) hold the error text to
be sent to the SMTP client.
These override values set in
the Security field.
The default for each of
these is set according
to the value of the
Security field. See
Section 18.6.7.3 for more
information.
The following sections provide further information about the configuration
options.
18.6.2 Preventing Spam Route-Through
Senders of spam routinely use unaware Internet hosts as route-through hosts
for their spam. This illicit use of other SMTP servers is known as SPAM
route-through.
Spam mailing lists contain the of addresses and sending a spam takes a great
deal of time. Therefore, senders of spam prefer to use hosts other than their
own to send the message. The victim is a host not protected by a firewall or
by software that is aware of spam. The SMTP client software that generates
spam connects to the victim SMTP server host and issues multiple RCPT TO
commands, which may number in the thousands. The SMTP client then sends
Configuring and Managing SMTP 18–19
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
the message to the victim host and closes the link. It is now left to the victim
host to do the real work of relaying the spam to the thousands of recipients.
Fortunately, the route-through attack can often be detected. Most or all of the
recipients of the spam will not be within the victim’s own domains or IP networks.
They will be somewhere outside in the expanse of the Internet. You must trap
for the situation where an unknown SMTP client is trying to use your system
to relay mail to recipients in domains outside its own. If you specify the ‘‘known
world’’ and the ‘‘unknown world,’’ the SMTP server can detect this type of spam
attack.
SMTP allows you to configure two lists:
•
Good-Clients, a list of the IP addresses, IP networks, DNS host names, and
DNS MX domains of known good SMTP clients.
•
Relay-Zones, a list of the SMTP domains to which SMTP will relay mail even
if it is from an unknown client.
Together, these lists define the ‘‘known good world’’ to the SMTP server for relay
purposes. They are used to prevent spam routing as follows:
1. The SMTP server checks the IP address of the client against the Good-Clients
list. If a match occurs, the client is considered ‘‘known good’’ and it is free to
use the local system to relay without further checking. However, if no match
against the Good-Clients list occurs, the client is considered ‘‘unknown’’ and
the process goes to step 2.
2. When the client is unknown, the domain of the address in each RCPT TO
command is checked against the Relay-Zones list. If a match occurs, the
RCPT TO command is accepted, because it is a relay from the unknown world
to the known world (for example, e-mail from the Internet). If a match does
not occur, the RCPT TO is considered unacceptable for route-through.
The SMTP server allows an SMTP client to attempt route-through twice; if
a third attempt is made, the SMTP server rejects the RCPT TO command,
disconnects the link, and reports a spam event. For more information about
spam event reporting, see Section 18.6.7.
If neither Good-Clients nor Relay-Zones is configured, relay checking depends on
the setting of the SMTP configuration relay flag. If the relay flag is set, all relays
are allowed; if it is not set, relays are not allowed.
To use Good-Clients and Relay-Zones lists, you must still set the SMTP
configuration relay flag. Use the following command:
TCPIP> SMTP SET CONFIGURATION/OPTION=RELAY
18.6.2.1 Specifying the Good-Clients List
The Good-Clients list is a comma-separated list of clients, specified as one of the
following:
•
IP address
•
IP network
•
DNS hostname
•
DNS MX domain
18–20 Configuring and Managing SMTP
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
To enter an IP network, use standard CIDR notation (n.n.n.n/m, where n.n.n.n is
the IP network and m is the number of bits in the subnet mask). For example:
Good-Clients: 1.2.0.0/16, 2.3.4.0/24,
2.3.4.5, relay.abc.com
This Good-Clients list contains two IP networks (1.2.0.0 and 2.3.4.0), an IP
address (2.3.4.5), and a DNS entry (relay.abc.com). An entry that does not
follow the standard IP address or network format is assumed to be a DNS entry.
18.6.2.2 Processing DNS Entries in the Good-Clients List
The SMTP server uses the Good-Clients list to match the IP addresses of SMTP
clients. Therefore, entries are stored internally as IP addresses. DNS hostname
and MX domain entries are stored as IP addresses, determined by the following
process:
1. An entry that is not apparently an IP address or IP network is assumed to be
a DNS host name, and the matching IP address is stored in the list.
2. For an entry that cannot be resolved as a DNS host name, the SMTP server
looks for MX records.
For configurations where the generic mail server name does not have an
associated DNS host name, the SMTP server uses the MX records, which specify
mail relay hosts. The following example demonstrates this configuration:
TCPIP> show host relay.abc.com
%TCPIP-W-NORECORD, information not found
-RMS-E-RNF, record not found
TCPIP> show mx relay.abc.com
BIND MX database
Server:
1.2.3.4
host.abc.com
Gate address
Preference
Gate name
1.3.4.5
1.3.5.6
2.4.5.6
2.4.5.7
3.4.5.6
3.4.6.7
100
100
200
200
300
300
mail11.abc.com
mail13.abc.com
mail2.abc.com
mail1.abc.com
mail21.abc.com
mail12.abc.com
To include the addresses listed as MX gateways in this example, enter
relay.abc.com in the Good-Clients list.
18.6.2.3 Mail Relay to MX Gateways
You can configure the SMTP server to relay mail from an unknown SMTP client
to a domain that does not match the entries Relay-Zones but that has an MX
record naming the local host as an MX gateway. To enable this feature, set the
Relay-Based-On-Mx option to TRUE in SMTP.CONFIG.
For example, the Relay-Zones list is not specified on example host
VMShost.abc.com. When an unknown host tries to relay mail to podunk.def.com
through VMShost, and the Relay-Based-On-Mx option is enabled, the SMTP
server on VMShost searches for MX records for podunk.def.com. If one of
PODUNK’s MX records lists VMShost as the MX gateway, the relay is accepted,
even though the SMTP client is unknown and the RCTP TO address did not
match the Relay-Zones list.
Configuring and Managing SMTP 18–21
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
18.6.2.4 Specifying the Relay-Zones List
The Relay-Zones list specifies the domains to which the SMTP server will relay
mail from unknown SMTP clients. Do not use wildcards in the entries in this list;
wildcarding is implicit (that is, *.domain is implied). For example:
Relay-Zones: def.com,
abc.com,
company.com
This example specifies the relay of mail from unknown SMTP clients to any
host within the def.com, abc.com, or company.com domain. Because of implied
wildcarding, domains like VMShost.abc.com match against this list.
18.6.2.5 Examples of Specifying Good-Clients and Relay-Zones
In the following examples, host.abc.com is the host, and Good-Clients and
Relay-Zones lists are configured as follows:
Good-Clients: 1.2.0.0/16, 2.3.0.0/16, relay.abc.com
Relay-Zones: def.com, abc.com, company.com
The Good-Clients list specifies clients whose IP addresses are in the 1.2 or 2.3
subnets or whose IP addresses match the relay.abc.com.
The following examples assume that host.abc.com is not protected by a firewall
and has direct Internet connectivity.
1. The following example explains the process of handling a mail message where
the client is unknown and RCPT TO address is unknown.
A host with the IP address 2.2.3.5 connects to VMShost’s SMTP server. The
client sends a RCPT TO address of jones@someplace.else.com. The SMTP
server:
a. Fails to find a matching IP address in the Good-Clients list. The client is
considered unknown.
b. Fails to find the domain of the RCPT TO address in the Relay-Zones list.
c. The RCPT TO command is rejected with the following message:
<<<RCPT TO:<jones@someplace.else.com>
>>>550 User not local, Relay disabled.
2. This example shows the process of handling a mail message for which the
client is unknown but the RCPT TO address is accepted.
A host with the IP address 2.2.3.5 connects to VMShost’s SMTP server. This
IP address does not match Good-Clients, so the client is considered unknown.
However, if the client sends a RCPT TO address of
smith@foobar.xxx.def.com, the domain of the RCPT TO address is matched
against the Relay-Zones list. The RCPT TO address foobar.xxx.def.com
matches the Relay-Zones list, so the RCPT TO command is accepted.
3. In this example, the client with IP address 1.2.1.2 connects to VMShost’s
SMTP server. This IP address matches Good-Clients (it is in subnet 1.2).
Therefore, the client is considered known. The SMTP server does not check
the domains of the RCPT TO addresses.
18–22 Configuring and Managing SMTP
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
18.6.3 Blocking Mail from Specified Clients
You can configure the SMTP server to automatically reject any mail transactions
with specified SMTP clients. To enable this feature, configure the Bad-Clients
list in SMTP.CONFIG. The syntax of the Bad-Clients list is the same as the
Good-Clients list. For example:
Bad-Clients: 1.2.3.5, 100.101.102.103
If Bad-Clients is configured, the SMTP server checks the IP address of the client
against the list. If a match occurs, the SMTP client is considered ‘‘known bad;’’
the server sends a failure message to the client and then disconnects the link.
18.6.3.1 Resolving Conflicts between Bad-Clients and Good-Clients
The Bad-Clients and Good-Clients lists are not mutually exclusive. If an SMTP
client’s IP address may be resolved in both lists, the entry that most closely
matches the client’s IP address is used.
For example, the following lists are configured:
Bad-Clients: 1.0.0.0/8
Good-Clients: 1.2.3.6
When an SMTP connection comes in from IP address 1.2.3.6, which is in the
1.0.0.0 subnet, the client may be considered a known bad client. But because the
specific IP address is specified in the Good-Clients list, the message is accepted.
18.6.4 Real-Time Black Hole Lists (RBL)
The Internet community maintains a list of IP addresses of senders of spam. This
is called the Real-time Blackhole List (RBL) and contains DNS A records. For
more information and to register to use the RBL, go to the following web site:
www.blackholes.mail-abuse.org
To use the RBL, configure the RBLs list in the SMTP.CONFIG file (described in
Section 18.6.1). The RBLs configuration option lists the domains providing RBL
services. You can specify a list of RBLs, thereby accommodating individual RBLs
and additional Internet-provided RBLs along with the current one.
For example:
RBLs: blackholes.mail-abuse.org, rbl.ourcompany.com
If the SMTP server matches the IP address of the client with an entry in any
of the RBLs in the list, the server sends a failure message to the client and
disconnects the link.
If a client IP address matches one in the Good-Clients list, the message is
accepted; the SMTP server does not check the RBLs.
18.6.5 Translating Client IP Addresses
You can configure SMTP to translate the client’s IP address to a host name,
and to disconnect the link if no host name exists. To enable this feature, set
the Reject-Unbacktranslatable-IP option in SMTP.CONFIG. Translation is not
performed if the SMTP client’s IP address matches an entry in the Good-Clients
list.
Configuring and Managing SMTP 18–23
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
18.6.6 Blocking Mail from Specified Senders
You configure SMTP to reject mail based on the address of the sender. The
sender’s address is specified in the MAIL FROM command. (The terms ‘‘sender
address’’ and ‘‘MAIL FROM address’’ are synonymous.) To specify sender
addresses from whom mail will always be rejected, include the Reject-Mail-From
list in the SMTP.CONFIG file.
The Reject-Mail-From list includes wildcarded patterns that are checked against
the sender address. If the SMTP server matches the sender address against a
pattern in the Reject-Mail_From list, the MAIL FROM command is rejected and
the link is disconnected. Wildcarded patterns may include the standard asterisk
(*) and percent sign (%) wildcard characters.
For example:
Reject-Mail-From: *.xyz.com, known.spammer@*, *the_internet*
To specify hosts from which to allow mail, even if the address matches that
specified in the Reject-Mail-From list, include them in the Accept-Mail-From list
in SMTP.CONFIG.
The Accept-Mail-From list includes wildcarded patterns that are checked against
the sender address. If the SMTP server finds that the MAIL FROM address
matches an entry in the Reject-Mail-From list, it then checks the Accept-MailFrom list also. You can use this list to allow mail from legitimate senders in the
domains listed in the Reject-Mail-From list.
For example:
Accept-Mail-From: *@notabadguy.xyz.com, the_internet_news@somehwere.com
In this example, the entry the_internet_news@somehwere.com allows mail
from the sender address the_internet_news@somehwere.com, even though it
matches the entry *the_internet* from the Reject-Mail-From list. Likewise, it
accepts mail from jones@notabadguy.xyz.com, even though it matches the entry
*.xyz.com in the Reject-Mail-From list.
In addition to the Accept-Mail-From list, you can specify the following
configuration options in SMTP.CONFIG to allow mail from senders in the
Reject-Mail-From list:
•
Accept-Unqualified-Senders
By default, if the TCP/IP Services SMTP server receives a message with an
unqualified sender address, or with a sender address with no domain at all, it
will reject the MAIL FROM command and disconnect the link.
For example, the following sender addresses would be rejected by default:
MAIL FROM:<somebody>
MAIL FROM:<somebody@someplace>
The first address has no domain and the second has an unqualified domain.
To accept mail with these types of sender addresses, set Accept-UnqualifiedSenders in SMTP.CONFIG, as follows:
Accept-Unqualified-Senders: TRUE
When the Accept-Unqualified-Senders option is set, the SMTP server does not
check whether the sender address either has a domain or is fully qualified.
18–24 Configuring and Managing SMTP
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
•
Accept-Unresolvable-Domains
By default, if the SMTP server fails to find an MX record for the sender
address, it rejects the MAIL FROM command and disconnects the link.
You can specify that messages with unresolvable domains be accepted by
setting the Accept-Unresolvable-Domains configuration option to TRUE in
SMTP.CONFIG, as follows:
Accept-Unresolvable-Domains: TRUE
When Accept-Unresolvable-Domains is set, the SMTP server will not perform
an MX lookup on the sender address.
18.6.7 Specifying Handling of Spam Events
Whenever the TCP/IP Services SMTP server disconnects a link with a client as a
result of the Antispam checking, it generates an event message. You can control
the way events are handled using the procedures in the following sections.
18.6.7.1 Reporting Spam Events
You can customize the SMTP server to report a spam event in the following ways.
The SMTP server can:
•
Send an OPCOM message.
•
Send a /TYPE=USER message to the accounting subsystem.
To configure the way SMTP reports the event, use the SPAM-Action field in
SMTP.CONFIG. The legal values are:
•
NONE
•
OPCOM (the default)
•
ACCOUNTING
You can specify multiple values for the SPAM-Action field. For example:
SPAM-Action: OPCOM, ACCOUNTING
This example causes both OPCOM and accounting messages to be sent for
each spam event. To disable spam event reporting, enter a value of NONE for
SPAM-Action in SMTP.CONFIG, as follows:
SPAM-Action: NONE
18.6.7.2 Configuring Spam Security
When the SMTP server disconnects the link with the client because of the
Antispam checking, it sends a message back to the client. The text of the message
is controlled by the Security field in SMTP.CONFIG. The legal values for this field
are:
•
SECURE (the default)
If Security is set to SECURE, the messages do not indicate the cause of the
disconnect.
•
FRIENDLY
If Security is set to FRIENDLY, the messages indicate the cause of the
disconnect.
Configuring and Managing SMTP 18–25
Configuring and Managing SMTP
18.6 Configuring SMTP Antispam
18.6.7.3 Specifying the Spam Rejection Text
You can specify the rejection text message to be sent to the client. The field
names for these options end in ‘‘-Text’’, and the values for them must be a single
line of text. These fields override the default text associated with the specific
spam event.
The following are the fields and default messages for the SECURE option:
•
Unbacktranslatable-IP-Text: Closing transmission channel.
•
Bad-Clients-Text: Closing transmission channel.
•
Client-In-RBL-Text: Closing transmission channel.
•
Reject-Mail-From-Text: Closing transmission channel.
•
Unqualified-Sender-Text: Closing transmission channel.
•
Unresolvable-Domain-Text: Closing transmission channel.
•
SPAM-Relay-Text: User not local, Relay disabled.
The following are the fields and default messages for the FRIENDLY option:
•
Unbacktranslatable-IP-Text: I can’t backtranslate your IP address to a host
name.
•
Bad-Clients-Text: Your IP address or subnet is in my list of bad ones.
•
Client-In-RBL-Text: Your IP address is in my RBL list.
•
Reject-Mail-From-Text: That sender address is in my list of bad ones.
•
Unqualified-Sender-Text: That sender address is unqualified.
•
Unresolvable-Domain-Text: That sender address is unresolvable into a host
name or MX domain.
•
SPAM-Relay-Text: Both you and the recipient are unknown to me. I will not
relay.
You can change one or more of the default messages by including the field and
your message for a value. This will override the default setting for that field. For
example:
Unbacktranslatable-IP-Text: Your IP address is unbacktranslatable. SPAMMER!
18.7 Managing SMTP Send-From-File (SFF)
SMTP allows you to create a mail message in a file and send it to the SMTP
mailer to be delivered with headers you specify. Using SFF, you can create
automated tools that compose and send mail messages.
SFF is also useful for forwarding nontext (MIME) files because it prevents the
mailer from encapsulating the MIME and SMTP headers in the body of a new
mail message. In this way, SMTP functions like the redirect command on your
personal computer.
18–26 Configuring and Managing SMTP
Configuring and Managing SMTP
18.7 Managing SMTP Send-From-File (SFF)
18.7.1 SFF Security Measures
The ability to create messages with arbitrary headers could be used to spoof
message headers. To limit this, SFF adds a Received: header to the headers you
supply. This tells you the origin of an attempted spoofed message.
You can invoke SFF from an application or from DCL, as described in the
following sections.
18.7.2 Invoking SFF from an Application
TCPIP$SMTP_MAILSHR.EXE contains a routine called TCPIP$SMTP_SEND_
FROM_FILE. This routine is declared as follows:
unsigned int TCPIP$SMTP_SEND_FROM_FILE(infile_name, logfd, log_level)
char *infile_name;
FILE *logfile_name;
int log_level;
The parameters for this routine are:
•
infile_name
Specifies the name of the text file that contains the RFC 822 mail message
and SMTP protocol information. For more information, refer to the HP
TCP/IP Services for OpenVMS User’s Guide.
•
logfile_name
The name of the file to which diagnostic messages will be logged. This file
must be opened by the caller before calling this routine. If no log file is
specified, output goes to SYS$OUTPUT. This parameter is optional.
•
log_level
The debug log level: either 1 (on) or 0 (off). The default is 0 (no logging). This
parameter is optional.
To call the routine, link with TCPIP$SMTP_MAILSHR.EXE/SHARE.
18.7.3 Invoking SFF from DCL
The SMTP_SFF command allows you to invoke SFF. To define SMTP_SFF as a
foreign command so that you can use it from DCL, enter the following command:
$ SMTP_SFF:==$TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE
This command takes UNIX style parameters and passes them to SFF.
The command format is:
SMTP_SFF infile_name [-log logfile_name] [-loglevel log_level]
The parameters to this command are:
•
infile_name
Specifies the name of the text file that contains the RFC 822 mail message
and SMTP protocol information. For more information, refer to the HP
TCP/IP Services for OpenVMS User’s Guide.
•
logfile_name
The name of the file to which to log diagnostic messages. If no log file is
specified, the default is SYS$OUTPUT. This parameter is optional.
Configuring and Managing SMTP 18–27
Configuring and Managing SMTP
18.7 Managing SMTP Send-From-File (SFF)
•
log_level
The debug log level: either 1 (on) or 0 (off). The default is 0 (no logging). This
parameter is optional.
18.8 Disabling SMTP Outbound Alias
Users can specify an outbound alias that is applied to mail as it is sent and
specifies the network address to which a reply will be sent. The outbound alias
is defined using the TCPIP$SMTP_FROM logical, which is described in the HP
TCP/IP Services for OpenVMS User’s Guide.
To disable outbound alias processing (preventing the use of the TCPIP$SMTP_
FROM logical), define the following system logical:
$ DEFINE/SYSTEM TCPIP$SMTP_PROHIBIT_USER_HEADERS 1
18.9 Solving SMTP Problems
To isolate an SMTP problem, follow these steps:
1. Check the directory SYS$SPECIFIC:[TCPIP$SMTP] for the following log
files:
•
TCPIP$SMTP_LOGFILE.LOG
This log file monitors queue activity.
•
TCPIP$SMTP_RECV_LOGFILE.LOG
This log file is created with every message received.
Purge the directory regularly.
2. Use the TCPIP$SMTP_LOG_LEVEL logical, as described in Section 18.5.
3. Check the mail in the TCPIP$SMTP account.
Forward TCPIP$SMTP mail to the SYSTEM account for monitoring. By
default, remote login to TCPIP$SMTP is not allowed.
4. Check the directory SYS$SPECIFIC:[TCPIP$SMTP] for lost mail.
If an incoming mail message was undeliverable and the error message was
also undeliverable, the SMTP control file is left in this directory, not in the
queue.
5. Check the consistency of the SMTP queues against the directories with the
SMTP utility files.
Enter the ANALYZE MAIL command (see Section 18.9.1).
18.9.1 Verifying SMTP Control Files
Use the ANALYZE MAIL command to verify the correspondence of the SMTP
queues with SMTP control files. This command does the following:
•
Checks that all the current entries in the SMTP queues have a supporting
control file in the mail directory of a user. You can specify a user or analyze
the mail of all users.
•
Checks that there are no lost control files in the SMTP working directory.
•
The /DELETE qualifier deletes each control file lacking a corresponding queue
entry.
18–28 Configuring and Managing SMTP
Configuring and Managing SMTP
18.9 Solving SMTP Problems
•
The /REPAIR qualifier fixes these errors:
Resubmits for delivery each valid control file in the SMTP directory with
no entry in an SMTP queue.
Deletes each invalid control file (fails the internal consistency check) and
the corresponding queue entry.
Either requeues or deletes messages placed on hold.
The following examples show how to use the ANALYZE MAIL command:
1. The following command encounters a problem, displays a description and
solution, and then requests confirmation before fixing each record.
TCPIP> ANALYZE MAIL /REPAIR /CONFIRM
%TCPIP-E-ANA_SUP_BADIICGSIZE, Problem: Bad initial inode cell
group size: bad_value
Solution: Will be replaced by
default size: good_value
CONFIRM [Y/N/G]:
2. The following command creates a summary of SMTP entries and control files
for user DRAKE.
TCPIP> ANALYZE MAIL DRAKE
%TCPIP-I-ANA_RUNING, ANALYZE runs on node DODO
%TCPIP-I-ANA_NOENTR, no queue entry found for file
NEST3$:[DRAKE]93042311394417_DRAKE.UCX_DODO;1
%TCPIP-I-ANA_COMPLE, ANALYZE completed on node DODO
%TCPIP-I-ANA_FEPAIR,
%TCPIP-I-ANA_DELQEN,
%TCPIP-I-ANA_FILNOQ,
%TCPIP-I-ANA_FILHLD,
%TCPIP-I-ANA_FILDEL,
%TCPIP-I-ANA_SUBFIL,
%TCPIP-I-ANA_FILACE,
%TCPIP-I-ANA_NONCFF,
%TCPIP-I-ANA_FILCOR,
found 0 file-queue entry pairs
deleted 0 queue entries
found 1 files with no queue entries
holding 0 files in directory
deleted 0 files from the Postmaster directory
submitted 0 files to the generic queue
encountered 0 file access errors
found 0 non-unknown files in Postmaster directory
found 0 corrupted CF files in Postmaster directory
3. The following command:
•
Creates a summary of SMTP entries and control files for user DRAKE.
•
Requeues control files lacking corresponding queue entries.
•
Deletes control files created before November 24, 1999.
TCPIP> ANALYZE MAIL DRAKE /REPAIR /DELETE=BEFORE=24-NOV-1999
18.9.2 Slow Antispam Checking
The operational speed of the SMTP Antispam feature depends on the relative
health of the DNS server. A malfunctioning DNS server can slow the operation of
SMTP Antispam checking.
Configuring and Managing SMTP 18–29
19
Configuring and Managing the POP Server
The Post Office Protocol (POP) server and the Simple Mail Transfer Protocol
(SMTP) server software work together to provide reliable mail management in a
client/server environment.
The POP server acts as an interface to the mail repository. It accepts and stores
mail messages for you, even when your client system is not connected, and
forwards those messages to you at your request. POP is used mostly by PC
clients to ensure that mail is received and retained even when the system is not
connected to the network.
After the POP server is enabled on your system, you can modify the default
characteristics by defining logical names.
This chapter reviews key POP concepts and describes:
•
How to start up and shut down the POP server (Section 19.2)
•
How to modify POP server characteristics (Section 19.3)
•
How to enable MIME mail using POP (Section 19.4)
•
How to configure and use secure POP (Section 19.5)
•
How to solve POP problems (Section 19.6)
19.1 Key Concepts
The POP server is an implementation of the Post Office Protocol Version 3 server
(the public domain IUPOP3 server) specified in RFC 1725.
The POP server is intended to be used as a mail repository for:
•
PC systems that may not be connected to a network for periods of time
•
Smaller nodes that may not have sufficient resources to keep an SMTP server
and associated local mail delivery system resident and continuously running
With POP, mail is delivered to a shared mail server, and a user periodically
downloads unread mail. Once delivered, the messages are deleted from the
server.
The POP server is assigned port 110, and all POP client connections are made to
this port.
The following sections review the POP process and describe how the TCP/IP
Services software implements POP. If you are not familiar with POP, refer to RFC
1725 or introductory POP documentation for more information.
Configuring and Managing the POP Server 19–1
Configuring and Managing the POP Server
19.1 Key Concepts
19.1.1 POP Server Process
The POP server is installed with SYSPRV and BYPASS privileges and runs in the
TCPIP$POP account, which receives the correct quotas from the TCPIP$CONFIG
procedure. The POP server is invoked by the auxiliary server.
The POP server uses security features provided in the protocol and in the
OpenVMS operating system, as well as additional security measures. These
methods provide a secure process that minimizes the possibility of inappropriate
access to a user’s mail file on the served system.
You can modify the POP server default characteristics and implement new
characteristics by defining the system logical names outlined in Section 19.3.
19.1.2 How to Access Mail Messages from the POP Server
To access mail messages from the POP server, you configure a user name and
password, or the POP shared secret-password string, into your client mail
application.
Your client system opens the TCP connection and attempts to access the server
by entering applicable POP commands such as USER (user name) and PASS
(password), or APOP (shared secret password). In addition, POP supports the
UID command, which some POP clients use, where the UID (user identification)
that POP creates for each mail message is a concatenation of the user name and
the date of arrival.
Once your client system opens the TCP connection, the POP server issues the
following greeting:
+OK POP server ready TCPIP V5.1 [hostname and IP_Address]
By default, the POP server reads mail from the user’s OpenVMS NEWMAIL
folder. If you do not instruct the POP server to delete the mail, the server
either moves the mail to the MAIL folder (if the logical name TCPIP$POP_USE_
MAIL_FOLDER is defined) or keeps it in the NEWMAIL folder (if the logical
name TCPIP$POP_LEAVE_IN_NEWMAIL is defined). These logical names are
described in Section 19.3.
19.1.3 How the POP Server Initiates and Manages a TCP Connection
The POP server starts the service by listening on TCP port 110. The client
initiates a connection when it wants to make use of the POP service. The POP
server sends either a greeting message confirming the connection (a message with
the +OK prefix) or a message that the connection was not successful (a message
with the -ERR prefix).
POP permits only two user name and password authorization attempts per TCP
connection. After the second failure, POP closes the connection. Once connected,
the client and server exchange commands and responses.
When the POP server detects a blocked TCP connection, it suspends output to
the connection for 2 seconds to allow it to unblock. Upon retry, if the connection
is still blocked, the POP server waits 4 seconds before trying again, and so on up
to 32 seconds. If the connection is still blocked after 32 seconds, the POP server
shuts down the connection and sends an error message to the log file, allowing
other client connections to continue to operate.
19–2 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.1 Key Concepts
19.1.4 How the POP Server Handles Foreign Message Formats
POP contains minimal support for mail messages that contain foreign formats.
Such messages are usually binary and therefore are not transferred to the POP
client. Instead, the POP server transfers the message headers, along with a brief
message instructing the user to log in and extract the foreign message into a file.
Foreign messages are moved into your MAIL folder; they are never deleted by the
POP server.
19.1.5 How the POP Server Authorizes Users
Table 19–1 outlines the methods the POP server process uses to authorize user
access.
Table 19–1 POP User Authorization Methods
Method
Description
Shared secret-password
string
Most secure POP server access method. Initiated by the client system
through the APOP command.
Allows a user to become authorized by the POP server without the need
to send a password over the network. Eliminates a potential path for
unauthorized users to obtain a password and break into the system.
POP requires a shared secret string from any user who wants to read mail
using the APOP authorization method. For information about creating
the shared secret string, see the HP TCP/IP Services for OpenVMS User’s
Guide.
User name and password
Least secure POP server access method. Initiated by the client system
through the USER and PASS commands.
The POP server authorizes the client to access the desired mailbox based
on receipt of a valid user name and password.
OpenVMS SYSUAF settings
on user accounts
Ability to disable the USER
and PASS commands
1.
The user configures a user name and password into the POP client
system. Each POP client has its own method of configuring. Note that
the user name and password pair is the user name and password for
the TCP/IP Services system, not for the POP client system.
2.
The POP client sends the user name and password pair to the server,
and the server confirms the pair against that in the OpenVMS
SYSUAF file. Note that the password is sent unencrypted over
the TCP connection, which might cause security problems for some
environments. Upon authorization, the POP server allows access to
the user’s OpenVMS mailbox.
Access to the POP server is not permitted if:
•
Either the DISMAIL or DISUSER flags are set for the account.
•
The account has expired according to the SYSUAF expiration date.
•
Access has been denied because of an incorrect user name and
password.
Allows the system manager to use the APOP authorization method for
all POP clients, the more secure means of user authorization. When you
disable the USER and PASS commands (by defining the logical name
TCPIP$POP_DISUSERPASS), the POP server responds to the commands
with a failure message.
Configuring and Managing the POP Server 19–3
Configuring and Managing the POP Server
19.1 Key Concepts
19.1.6 Understanding POP Message Headers
Mail message headers sent by the POP server must conform to the standard
specified for SMTP in RFC 822. Because many of the messages received on an
OpenVMS system are not in the SMTP format (for example, DECnet mail or
mail from another message transport system), the POP server builds a new set of
headers for each message based on the OpenVMS message headers.
The headers on mail messages forwarded by the POP server are as follows:
POP Message Header
Obtained From
Date:
From:
Arrival date of message. Changed to UNIX format.
To:
CC:
Subject:
X-VMS-From:
X-POP3-Server:
OpenVMS Mail
X-POP3-ID:
Message UID. Sent only if logical name
TCPIP$POP_SEND_ID_HEADERS is defined.
OpenVMS message From: field. Rebuilt to ensure RFC 822
compatibility. See Section 19.1.6.1.
To: field. Not rebuilt.
CC: field. Not rebuilt.
OpenVMS Mail Subj: field. Not rebuilt.
OpenVMS Mail From: field. Not rebuilt.
OpenVMS Mail
Server host name and POP version information. Sent only if
logical name TCPIP$POP_SEND_ID_HEADERS is defined.
The POP server sends these message headers to the POP client unless all of the
following conditions are true:
•
The TCPIP$POP_IGNORE_MAIL11_HEADERS logical name is defined (see
Section 19.3).
•
The From: address is an SMTP address.
•
The SMTP qualifier /OPTION=TOP_HEADERS is set.
Note that the POP server checks the SMTP configuration database to ensure
that it has been configured with the qualifier /OPTION=TOP_HEADERS so that
headers print at the top of the message. If the POP logical name TCPIP$POP_
IGNORE_MAIL11_HEADERS is defined, the SMTP option TOP_HEADERS must
also be set. If not, the POP server issues a warning in the log file and does not
acknowledge the TCPIP$POP_IGNORE_MAIL11_HEADERS definition.
19.1.6.1 How POP Rebuilds the OpenVMS Mail From: Field
The most important message header is the From: header, because it can be used
as a destination address if a reply is requested from the POP client. Therefore,
the POP server rebuilds the OpenVMS Mail From: field in compliance with RFC
822 before sending the header to the POP client.
The different types of addresses that can appear in the OpenVMS Mail From:
field are as follows:
19–4 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.1 Key Concepts
Address Type
Address Format
SMTP
SMTP%"legal-address," where legal-address is an
address that is compliant with RFC 822 and is
commonly in the user@domain format
DECnet
node::username
User name
username
DECnet address within quotation
marks
node::"user@host"
Cluster-forwarding SMTP address
node::SMTP%"user@domain"
A host name is local if one of the following is true:
•
The host name is the same as the substitute domain specified in the SMTP
configuration.
•
The host name is found in the TCPIP$SMTP_LOCAL_ALIASES.TXT file.
Some POP client systems are confused by the use of personal names when you
attempt to reply to a mail message or when the name contains commas or other
special characters. If you define the TCPIP$POP_PERSONAL_NAME logical
name outlined in Section 19.3, make sure you test the configuration carefully
with your POP client systems.
The following sections describe how POP rebuilds the message From: field for
each type of address.
19.1.6.1.1 SMTP Address The POP server uses the SMTP address within the
quotation marks to rebuild the From: field of an SMTP address. For example,
message header From: SMTP%"james.jones@federation.gov" becomes:
From: james.jones@federation.gov
SMTP hides nested quotation marks by changing them to cent sign (¢) characters
before passing them to OpenVMS Mail and then changing them back after a
reply. The POP server removes any cent signs that designate double quotation
marks. For example, the following message header:
From: SMTP%"¢ABCMTS::MRGATE::\¢ABCDEF::VIVALDI \¢¢@xyz.org"
Becomes:
From: "ABCMTS::MRGATE::\"ABCDEF::VIVALDI\""@xyz.org"
19.1.6.1.2 DECnet Address The TCPIP$POP_DECNET_REWRITE logical
name values define how the POP server rebuilds a DECnet address, as shown in
the following list:
•
GENERIC
The entire address is changed to the SMTP format. For example, from host
widgets.xyzcorp.com, the message header From: ORDERS::J_SMITH becomes:
From: "ORDERS::J_SMITH"@widgets.xyzcorp.com
•
NONE
The From: line is sent to the POP client unmodified. For example:
From: ORDERS::J_SMITH
You cannot reply to this type of message because the SMTP server does not
accept an address in this form.
Configuring and Managing the POP Server 19–5
Configuring and Managing the POP Server
19.1 Key Concepts
•
TRANSFORM
The POP server attempts to translate the DECnet node name to a TCP/IP
host name. If the name can be translated, the POP server checks to see
whether the translated host name is local. If so, the From: header becomes
an address in the form user@substitute-domain. If not, the From: header
becomes an address in the form user@hostname. Note that the POP and
SMTP servers call the same routine to determine if a host name is local.
The following examples show some ways the POP server translates DECnet
node names to TCP/IP node names. In these examples:
The local host name is orders.acme.widgets.com
ORDERS translates to "orders.acme.widgets.com"
*
The message header From: ORDERS::J_SMITH becomes:
From: j_smith@orders.acme.widgets.com
*
For a substitute domain of acme.widgets.com, the message header
From: ORDERS::J_SMITH becomes:
From: j_smith@acme.widgets.com
*
If HOST12 translates to host12.acme.widgets.com, which is not
local on orders.acme.widgets.com, the message header From:
HOST12::J_JONES becomes:
From: j_jones@host12.acme.widgets.com
*
If HOST13 does not translate and host orders.acme.widgets.com
has no substitute domain defined, the message header From:
HOST13::J_JONES becomes:
From: "HOST13::J_JONES"@orders.acme.widgets.com
19.1.6.1.3 User Name-Only Address If an SMTP substitute domain is defined,
the POP server appends it to the user name, followed by a commercial at sign (@).
Otherwise, POP uses the local host name.
For example, with a substitute domain defined as acme.widgets.com, the message
header From: Smith becomes:
From: smith@acme.widgets.com
19.1.6.1.4 DECnet Address That Contains Quotation Marks The values
assigned to the TCPIP$POP_QUOTED_DECNET_REWRITE logical name define
how the POP server rebuilds a DECnet address that contains quotation marks.
The values are:
•
GENERIC
The address is changed to the SMTP format. For example,
on host widgets.xyzcorp.com, the message header From:
ORDERS::"j_smith@acme.com" becomes:
From: "ORDER::\"j_smith@acme.com\""@widgets.xyzcorp.com
•
NONE
The From: line is passed to the POP client without being modified. For
example:
From: ORDERS::"j_smith@acme.com"
19–6 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.1 Key Concepts
You cannot reply to this type of mail message because the SMTP server does
not accept an address of this form.
•
TRANSFORM
The POP server uses the text inside the quotation marks. For example, the
message header From: ORDERS::"j.smith@acme.com" becomes:
From: j.smith@acme.com
19.1.6.1.5 Cluster-Forwarding SMTP Address With a clusterforwarding SMTP address, the POP server uses the SMTP address
within the quotation marks. For example, the message header From:
ABCDEF::SMTP%"james.jones@federation.gov" becomes:
From: james.jones@federation.gov
19.1.6.1.6 All Other Addresses For all other address formats, the POP server
changes the entire address to the SMTP format:
•
Quotation marks in the address are prefixed with the backslash (\) escape
character.
•
The entire address is placed within quotation marks.
•
A commercial at sign (@) is appended.
•
If the SMTP substitute domain is configured, it is appended. Otherwise, the
name of the local host is appended.
For example, if the substitute domain is xyz.org, the message header
From: ABCMTS::MRGATE::"ORDERS::SPECIAL" becomes:
From: "ABCMTS::MRGATE::\"ORDERS::SPECIAL\""@xyz.org
If the logical name TCPIP$POP_IGNORE_MAIL11_HEADERS is defined and the
address is an SMTP address, the rebuilt From: field is not displayed to the user.
In this case, the POP server sends the actual headers from the body of the mail
as the mail headers.
19.2 POP Server Startup and Shutdown
The POP server process starts automatically if you specified automatic startup
during the configuration procedure (TCPIP$CONFIG.COM).
The POP server can be shut down and started independently of TCP/IP Services.
This is useful when you change parameters or logical names that require the
service to be restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$POP_STARTUP.COM allows you to start up the POP
server independently.
•
SYS$STARTUP:TCPIP$POP_SHUTDOWN.COM allows you to shut down the
POP server independently.
To preserve site-specific parameter settings and commands, create the following
files. These files are not overwritten when you reinstall TCP/IP Services:
•
SYS$STARTUP:TCPIP$POP_SYSTARTUP.COM can be used as a repository
for site-specific definitions and parameters to be invoked when the POP
server is started.
Configuring and Managing the POP Server 19–7
Configuring and Managing the POP Server
19.2 POP Server Startup and Shutdown
•
SYS$STARTUP:TCPIP$POP_SYSHUTDOWN.COM can be used as a
repository for site-specific definitions and parameters to be invoked when the
POP server is shut down.
19.3 Modifying POP Server Characteristics
To modify the default POP server settings and configure additional
characteristics, define TCPIP$POP logical names in the POP_SYSTARTUP.COM
file. If you modify the POP startup file, restart the POP server to make the
changes take effect.
You can modify the following POP server characteristics:
•
Security levels
•
Error-message logging
•
Maximum number of mail messages downloaded per connection
•
Link idle time
•
Mail header options
•
Ability to set the size of the TCP flow control buffer
•
Ability to disable the USER and PASS commands
•
Ability to purge mail messages
Table 19–2 outlines the POP logical names, default settings, and characteristic
options.
19–8 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.3 Modifying POP Server Characteristics
Table 19–2 POP Logical Names
Logical Name
Description
TCPIP$POP_SECURITY value
Defines a level of security for the POP server. Determines
the timing and text of error messages sent from the POP
server to the POP client when authorization errors occur
(for example, when an invalid user name or password is
sent):
•
FRIENDLY (default)
The error messages provide information about a
particular error. For example, if a password is incorrect,
the client receives the following error message:
-ERR password supplied for "jones" is incorrect
•
SECURE
One error message is sent in response to all
authorization errors except when an invalid user name
is specified. For example:
Access to user account "jones" denied
When the POP server receives an invalid user name,
it replies to the POP client with a +OK message. After
the POP client sends the password, the POP server
sends the -ERR access denied message. This method
prevents an unauthorized user from knowing whether
the access was denied because of an incorrect user name
or password.
TCPIP$POP_DISABLE_CLEARTEXT
If defined, the POP server process does not serve incoming
connections to the cleartext POP port (port 110). It will
listen on port 110 and respond to any client that tries to
connect with a failure message. See Section 19.5.3 for more
information.
TCPIP$POP_DISABLE_SSL
If defined, the POP server process does not serve incoming
connections to the Secure POP port (port 995). The POP
server does not listen on port 995. Clients trying to connect
have their connections rejected. See Section 19.5.3 for more
information.
TCPIP$POP_CERT_FILE
Specifies the name of the certificate file that
POP uses for SSL. If not defined, the default is
SSL$CERTS:SERVER.CRT. See Section 19.5.3 for more
information.
TCPIP$POP_KEY_FILE
Specifies the name of the key file that POP uses for SSL.
If not defined, the default is SSL$KEY:SERVER.KEY. See
Section 19.5.3 for more information.
TCPIP$POP_TRACE
If defined, the POP server records all messages sent to and
received from the POP client in a log file.
(continued on next page)
Configuring and Managing the POP Server 19–9
Configuring and Managing the POP Server
19.3 Modifying POP Server Characteristics
Table 19–2 (Cont.) POP Logical Names
Logical Name
Description
TCPIP$POP_LOG_LEVEL value
Defines the type of messages logged by the POP server:
•
ERROR
Logs only error messages.
•
INFORMATIONAL (default)
Logs informational messages and error messages.
•
THREAD
Logs information about client and server interactions as
well as informational and error messages.
•
DEBUG
Logs full diagnostic information. This is used for
problem diagnosis.
TCPIP$POP_POSTMASTER value
Defines a person or persons to receive a failure mail
message from the POP server startup procedure
(TCPIP$POP_STARTUP.COM) when the POP server
exits with an error. For example, to have the failure mail
message sent to users JONES and SMITH, define the logical
name as follows:
$ DEFINE/SYSTEM TCPIP$POP_POSTMASTER "JONES, SMITH"
TCPIP$POP_MESSAGE_MAXIMUM n
Defines the maximum number of mail messages that a
single client can download per connection, where n is a
number from 0 to 65,535. If not defined, the POP server
uses the default value of 0 (no maximum).
TCPIP$POP_LINK_IDLE_TIMEOUT n
Determines the length of time the server allows a link to a
POP client to remain idle, where n is a number specified in
OpenVMS delta time delimited by quotation marks. A POP
link remains active until it is released by the POP client.
If not defined, the POP server does not set a link idle value
(0 00:00:00.00).
TCPIP$POP_PERSONAL_NAME
If defined, the POP server provides the POP clients with
the message header From: fields that include the sender’s
personal name, if one appeared in the sender’s From: field.
TCPIP$POP_LEAVE_IN_NEWMAIL
If defined, mail that has been read by the PC client but not
deleted remains in the NEWMAIL folder. Allows users to
access mail from different systems and determine when to
move or delete the mail from the POP server. If not defined,
mail that has been read but not deleted is moved to the
MAIL folder.
TCPIP$POP_USE_MAIL_FOLDER
If defined, moves all mail to the MAIL folder and displays
this folder instead of the NEWMAIL folder.
TCPIP$POP_FAST_SCAN
If defined, the POP server estimates the number of bytes for
the size of the mail message based on the number of lines in
the message instead of counting the exact number of bytes.
Setting this logical may improve performance.
(continued on next page)
19–10 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.3 Modifying POP Server Characteristics
Table 19–2 (Cont.) POP Logical Names
Logical Name
Description
TCPIP$POP_MAXIMUM_THREADS
Allows you to define the number of process threads that
POP can activate. The default is 15. If you set this logical
to 1, the POP server becomes single threaded. This logical
is recommended only as a temporary solution to system
resource problems.
TCPIP$POP_IGNORE_MAIL11_HEADERS
If defined, the POP server ignores the OpenVMS message
headers when the OpenVMS Mail From: field contains an
SMTP address, which indicates that the message has come
from SMTP.
For information about how POP forms message headers, see
Section 19.1.6.
TCPIP$POP_SEND_ID_HEADERS
If defined, the POP server sends X-POP3-Server and
X-POP3-ID headers for each mail message. If not defined,
the ID headers are not sent for any mail from an SMTP
address. For information about how POP handles message
headers, see Section 19.1.6.
TCPIP$POP_DECNET_REWRITE value
Determines how the POP server rebuilds a simple DECnet
address (of the form node::user) in the OpenVMS Mail
From: field when it sends the mail to the POP client; value
is one of the following:
•
GENERIC
Simple DECnet addresses are changed to the SMTP
address format.
•
NONE
Simple DECnet addresses are sent unmodified to the
POP client.
•
TRANSFORM (default)
The POP server attempts to transform the DECnet
address into an SMTP address by translating the
DECnet node name to a TCP/IP host name.
For more information about how POP rebuilds the message
headers, see Section 19.1.6.1.2.
(continued on next page)
Configuring and Managing the POP Server 19–11
Configuring and Managing the POP Server
19.3 Modifying POP Server Characteristics
Table 19–2 (Cont.) POP Logical Names
Logical Name
Description
TCPIP$POP_QUOTED_DECNET_
REWRITE
value
Determines how the POP server rebuilds a DECnet address
that contains quotation marks (an address of the form
node::"user@host") in the OpenVMS Mail From: field when
it sends the message to the POP client; value is one of the
following:
•
GENERIC
DECnet addresses that contain quotation marks are
changed to the SMTP address format.
•
NONE
DECnet addresses that contain quotation marks are
sent unmodified to the POP client.
•
TRANSFORM (default)
The POP server uses the text within the quotation
marks in the From: field it sends to the POP server.
For more information about how POP rebuilds the message
headers, see Section 19.1.6.1.4.
TCPIP$POP_SNDBUF n
Allows you to increase or decrease the size of the TCP flow
control buffer. Sets the SO_SNDBUF socket option to a
specific number; n is the number 512 or greater. If not
defined, the POP server uses the value specified in the
SHOW PROTOCOL/PARAMETERS command.
TCPIP$POP_DISUSERPASS
Disables the client USER and PASS commands and
sends a failure message to the POP client on receipt of
either command. For more information about POP user
authorization methods, see Section 19.1.5.
TCPIP$POP_PURGE_RECLAIM
If defined, the POP server performs a PURGE/RECLAIM
command action after it deletes messages.
19.4 Enabling MIME Mail
The MIME (Multipurpose Internet Mail Extensions) specification provides a set
of additional headers you can use so users can send mail messages composed of
more than simple ASCII text. MIME is an enhancement to RFC 822.
For MIME mail to be decoded correctly, follow these guidelines:
•
Configure the SMTP server with the /OPTION=TOP_HEADERS qualifier,
because the first lines of mail text after the four OpenVMS message header
lines and the initial separating line must be the MIME headers.
•
Configure the POP server with the TCPIP$POP_IGNORE_MAIL11_
HEADERS logical name. Otherwise, MIME headers are not parsed as
message headers.
•
The OpenVMS Mail From: field must be recognized as an SMTP address.
Otherwise, the POP server sends the headers it creates from OpenVMS
message headers as the headers of the mail message. For information about
POP message headers, see Section 19.1.6.
19–12 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.4 Enabling MIME Mail
Define the logical name TCPIP$SMTP_JACKET_LOCAL to 1 for all SMTP
cluster systems, which ensures that the mail will be delivered if the domain
in the From: or To: fields appears local. For example:
$ DEFINE/SYSTEM TCPIP$SMTP_JACKET_LOCAL 1
If MIME mail does not decode, check the mail headers on the client system. If
you see multiple blocks of headers and the MIME version header is not in the
first block, confirm that you have followed these guidelines.
19.5 Secure POP
Secure POP provides secure retrieval of mail.
The secure POP server accepts connections on port 995. Secure POP encrypts
passwords, data, and POP commands and is compatible with clients that use the
Secure Sockets Layer (SSL), such as Microsoft Outlook.
To use this feature, you must download the HP SSL kit for OpenVMS Alpha
from the HP OpenVMS web site. If the OpenVMS SSL software is not installed,
the POP server will communicate in non-SSL mode. It is easy to configure the
SSL POP server. You can use self-signed certificates or CA-issued certificates
for greater security. For more information, see the HP Open Source Security for
OpenVMS, Volume 2: HP SSL for OpenVMS manual.
The POP client must also be configured to use the secure POP server. Refer to
your client documentation for procedures.
19.5.1 Installing SSL Shareable Images
The POP server image is installed with privileges, requiring that the shareable
images that it loads be installed. Therefore, the following images must be
installed before the POP server:
$ INSTALL CREATE SYS$LIBRARY:SSL$LIBCRYPTO_SHR32.EXE
$ INSTALL CREATE SYS$LIBRARY:SSL$LIBSSL_SHR.EXE
The secure POP startup procedure does not install these images. You must
ensure they are installed before the TCP/IP Services startup procedure runs.
The POP server is implemented with links to the OpenVMS SSL software,
thereby allowing new versions of the SSL software to be installed and utilized
by the POP server automatically. The SSL software must be loaded with the
OpenVMS INSTALL command for any changes to affect the POP server.
19.5.2 Starting SSL before TCP/IP Services
The SSL logical names are defined by the SSL startup procedure. Therefore,
if you have POP configured to use SSL logical names to locate the certificate
and key files, you must ensure that the SSL startup procedure is run before the
TCP/IP Services startup procedure.
19.5.3 Controlling Secure POP With Logical Names
You can use the following logical names to control the way the POP server works:
•
TCPIP$POP_DISABLE_CLEARTEXT
If this logical name is defined, the POP server process does not serve incoming
connections to the cleartext POP port (port 110). It will listen on port 110 and
respond to any client that tries to connect with a failure message.
Configuring and Managing the POP Server 19–13
Configuring and Managing the POP Server
19.5 Secure POP
The text of the message depends on the value of the TCPIP$POP_SECURITY
logical name, as follows:
If the TCPIP$POP_SECURITY logical name is defined to SECURE, the
error message sent to the client is terse.
If the TCPIP$POP_SECURITY logical name is defined to FRIENDLY,
the error message informs the client that the cleartext POP service at
port 110 is not running and that the client should be reconfigured to use
Secure POP at port 995.
If the TCPIP$POP_DISABLE_CLEARTEXT logical name is not defined, the
POP server will listen on port 110.
•
TCPIP$POP_DISABLE_SSL
If this logical name is defined, the POP server process does not serve incoming
connections to the Secure POP port (port 995). The POP server does not listen
on port 995. Clients trying to connect have their connections rejected.
If the TCPIP$POP_DISABLE_SSL logical name is not defined, the POP
server will listen on port 995 if the SSL shareable images listed in
Section 19.5.1 are present on your system and installed with the OpenVMS
INSTALL command.
•
TCPIP$POP_CERT_FILE
Specifies the name of the certificate file that POP uses for SSL. If this logical
name is not defined, the default is SSL$CERTS:SERVER.CRT.
•
TCPIP$POP_KEY_FILE
Specifies the name of the key file that POP uses for SSL. If this logical name
is not defined, the default is SSL$KEY:SERVER.KEY.
19.5.4 Specifying Certificate and Key Files
You can use logical names to specify the location of certificate and key files. The
values assigned to these logical names may be full or partial file specifications.
That is, you may specify the directory, the file name, or both. The parts of the file
specification that you do not specify are supplied from the defaults.
The following examples show how to use these logical names. Each example
shows the logical name, its value, and the full file specification that the secure
POP server uses for the associated file.
1. This example allows you to keep the files in the SSL directories but make
them unique for the exclusive use of the secure POP server.
Logical Name
Defined To
File Specification
TCPIP$POP_CERT_FILE
"TCPIP$POP"
SSL$CERTS:TCPIP$POP.CRT
TCPIP$POP_KEY_FILE
"TCPIP$POP"
SSL$KEY:TCPIP$POP.KEY
19–14 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.5 Secure POP
2. This example allows you to move the files to the TCPIP$POP account’s home
directory for exclusive use by the secure POP server.
Logical Name
Defined To
File Specification
TCPIP$POP_CERT_FILE
"SYS$LOGIN:SSL"
SYS$LOGIN:SSL.CRT
TCPIP$POP_KEY_FILE
"SYS$LOGIN:SSL"
SYS$LOGIN:SSL.KEY
3. This example assumes that CLUSTERDEV points to a device that is visible
across the OpenVMS Cluster and allows you to have single copies of the files.
Make sure the device is mounted before starting the POP server.
Logical Name
Defined To
File Specification
TCPIP$POP_CERT_FILE
"CLUSTERDEV:[CERTS]"
CLUSTERDEV:[CERTS]SERVER.CRT
TCPIP$POP_KEY_FILE
"CLUSTERDEV:[CERTS]"
CLUSTERDEV:[CERTS]SERVER.KEY
If you use the full defaults for the POP certificate and key files, any use of the
SSL certificate tool to create a new certificate or key file might affect Secure POP
because the POP server and certificate tool use the same default file names.
19.5.5 Security Recommendations for the SSL Key File
To maximize security, you should restrict access to the .KEY file to users who
need to use it. You can use a combination of file protections, file ownership, and
ACLs to accomplish this. For the POP server to access the .KEY file, read access
to the file must be granted to the TCPIP$POP account. If you are sharing the
.KEY file between different SSL-enabled applications, those applications must
also have access to the .KEY file.
Because the information in the certificate file is public, it does not require the
same security restrictions.
19.5.6 Encrypted Private Keys
Secure POP does not support encrypted private keys. When you generate a
private key, you can choose to have the key encrypted in a passphrase that
you provide. This requires all users of the private key to have access to the
passphrase. The Secure POP server cannot access the passphrase.
19.6 Solving POP Problems
The following sections describe ways to troubleshoot problems associated with
using the POP server. Some of these include:
•
Reviewing error and OPCOM messages sent to the log file
•
Simulating a POP client and entering XTND commands
19.6.1 POP Server Messages
Many of the problems encountered using POP pertain to failed or misinterpreted
commands or authorization errors. As the first step toward solving problems, you
should review the messages provided by the POP server.
The POP server logs command error and OPCOM (authorization) messages in the
file SYS$SYSDEVICE:[TCPIP$POP]POP_RUN.LOG. By default, the POP server
sends informative error messages to the client about specific errors.
Configuring and Managing the POP Server 19–15
Configuring and Managing the POP Server
19.6 Solving POP Problems
If the SERVICE database log option REJECT is set, the POP server sends
OPCOM messages when it rejects POP client commands because of authorization
failures. These errors include the receipt of a client’s USER command with an
invalid user name, or a PASS command with an invalid password.
By default, OPCOM messages are displayed on the client system and are listed in
the log file. To disable OPCOM messages, disable the REJECT logging option for
the POP service, as follows:
$ TCPIP SET SERVICE POP/LOG=NOREJECT
19.6.2 Using POP Extension Commands
For troubleshooting purposes, you can simulate a POP client and enter the XTND
commands listed in Table 19–3 to obtain information.
Table 19–3 POP Extension (XTND) Commands
Command
Action
XTND CLIENT
Logs POP client information (if the client supplies it). Helpful
for troubleshooting if you use POP with a variety of POP
clients that identify themselves.
XTND LOGLEVEL
Dynamically adjusts POP logging level. Supported levels are
INFORMATIONAL (default), ERROR, THREAD, and DEBUG.
XTND STATS
Displays POP statistics in the following format:
+OK Statistics follow
Version Number
Logging Level
Current Time
Start Time
CPU Seconds
Current Threads
Total Threads
Max Threads
Too Many Threads
Normal Disconnects
Abnormal Disconnects
Client Timeouts
Blocked Socket Count
Retrieved Messages
Retrieved Octets
Average Octets
Minimum Octets
Maximum Octets
Auth Failures
Current Users
0. smith
XTND SHUTDOWN
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
TCPIP X5.0, OpenVMS V7.1 Alpha
DEBUG
1999-04-06 06:13:46
1999-04-04 06:42:17
7.89
(0 mins, 7 secs)
1
6
1
0
5
0
0
0
4
1102
275
222
319
1
Performs an orderly shutdown of POP. Waits for current
client connections to disconnect. Recommended over the DCL
command STOP.
To simulate a POP client and obtain information:
1. Enter the TELNET command to the POP port (110).
2. Using the USER and PASS command, enter your user name and password.
3. Enter an XTND command.
19–16 Configuring and Managing the POP Server
Configuring and Managing the POP Server
19.6 Solving POP Problems
For example:
$ TELNET UCXSYS 110
%TELNET-I-TRYING, Trying ... 16.20.208.53
%TELNET-I-SESSION, Session 01, host ucxsys, port 110
+OK POP server TCPIP Version 5.0, OpenVMS V7.1 Alpha at ucxsys.acme.com, up
since 1999-04-04 06:42:17 <24A00E61._6_APR_1999_06_02_31_15@ucxsys.acme.com>
USER username
+OK Password required for "username"
PASS password
+OK Username/password combination ok
XTND LOGLEVEL DEBUG
+OK logging level changed to debug
QUIT
+OK TCPIP POP server at ucxsys.acme.com signing off.
Configuring and Managing the POP Server 19–17
20
Configuring and Managing the IMAP Server
The IMAP server for OpenVMS Mail and the Simple Mail Transfer Protocol
(SMTP) server software work together to provide reliable mail management in a
client/server environment.
The IMAP server allows users to access their OpenVMS Mail mailboxes by clients
such as Microsoft Outlook so that they can view, move, copy and delete messages.
The SMTP server provides the extra functionality of allowing the clients to create
and send mail messages.
After the IMAP server is enabled on your system, you can modify the default
characteristics by editing the configuration file (described in Section 20.2.3).
This chapter reviews key IMAP concepts and describes:
•
How to start up and shut down the IMAP server (Section 20.2.1)
•
How to view the server event log file (Section 20.2.2)
•
How to modify IMAP server characteristics (Section 20.2.3)
•
How to enable MIME mail using IMAP (Section 20.3)
For information about setting up your client PC and using IMAP, refer to the HP
TCP/IP Services for OpenVMS User’s Guide.
20.1 Key Concepts
IMAP stands for Internet Message Access Protocol. The IMAP server allows
users to access their OpenVMS Mail mailboxes by clients communicating with
the IMAP4 protocol as defined in RFC 2060. The supported clients used to access
email are PC clients running Microsoft Outlook or Netscape Communicator.
The IMAP server is by default assigned port number 143, and all IMAP client
connections are made to this port.
The following sections review the IMAP process and describe how the TCP/IP
Services software implements IMAP. If you are not familiar with IMAP, refer to
RFC 2060 or introductory IMAP documentation for more information.
20.1.1 IMAP Server Process
The IMAP server is installed with SYSPRV, BYPASS, DETACH, SYSLCK,
SYSNAM, NETMBX, and TMPMBX privileges. It runs in the TCPIP$IMAP
account, which receives the correct quotas from the TCPIP$CONFIG procedure.
The IMAP server is invoked by the auxiliary server.
The IMAP server uses security features provided in the protocol and in the
OpenVMS operating system, as well as additional security measures. These
methods provide a secure process that minimizes the possibility of inappropriate
access to a user’s mail file on the served system.
Configuring and Managing the IMAP Server 20–1
Configuring and Managing the IMAP Server
20.1 Key Concepts
You can modify the IMAP server default characteristics and implement new
characteristics by defining the configuration options described in Section 20.2.3.
20.2 IMAP Server Control
The system manager controls the management functions of the IMAP server.
These functions include:
•
Starting and stopping the server
•
Viewing event logs for each server
•
Modifying options that control server behavior
•
Tuning the server
The following sections describe these management functions.
20.2.1 Starting Up and Shutting Down the Server
The IMAP server process starts automatically if you specified automatic startup
during the configuration procedure (TCPIP$CONFIG.COM).
The IMAP server can be shut down and started independently of TCP/IP Services.
This is useful if you change configuration options that require the service to be
restarted.
The following files are provided:
•
SYS$STARTUP:TCPIP$IMAP_STARTUP.COM allows you to start the IMAP
server.
•
SYS$STARTUP:TCPIP$IMAP_SHUTDOWN.COM allows you to shut down
the IMAP server.
To preserve site-specific parameter settings and commands, create the following
files:
•
SYS$STARTUP:TCPIP$IMAP_SYSTARTUP.COM — to be used as a
repository for site-specific definitions and parameters to be invoked when
the IMAP server is started.
•
SYS$STARTUP:TCPIP$IMAP_SYSHUTDOWN.COM — to be used as a
repository for site-specific definitions and parameters to be invoked when the
IMAP server is shut down.
Note that these files are not overwritten when you reinstall TCP/IP Services.
20.2.2 Viewing Server Event Log Files
The IMAP server records start and stop server events in an event log file. Other
events, such as failed user authentication events, are also recorded in this log file.
The file is called TCPIP$IMAP_HOME:TCPIP$IMAP_EVENT$node.LOG, where
node is the name of the node on which the server is running.
20.2.3 Modifying IMAP Server Characteristics
To modify the default IMAP server settings and to configure
additional characteristics, edit the configuration file TCPIP$IMAP_
HOME:TCPIP$IMAP.CONF. If you modify the IMAP server configuration file,
restart the IMAP server to make the changes take effect.
You can modify the following IMAP server characteristics:
•
Server port number
20–2 Configuring and Managing the IMAP Server
Configuring and Managing the IMAP Server
20.2 IMAP Server Control
•
Mail header options
•
Number of live connections per server process
For guidelines about specifying configuration options in the IMAP.CONF
configuration file, see Section 1.1.5.
Table 20–1 describes the IMAP option names, default settings, and characteristics
that you can modify.
Table 20–1 IMAP Configuration Options
Option Name
Description
Server-Port
TCP/IP port number for connection between IMAP clients
and the IMAP Server. The default value is 143.
Ignore-Mail11-Headers
If set to True, the default, the IMAP server ignores the
OpenVMS message headers when mail is sent via SMTP,
which contains an SMTP address in the From: field. For
information about how IMAP forms message headers, see
Section 19.1.6.
Send-ID-Headers
If set to True, the IMAP server sends X-IMAP4-Server and
X-IMAP4-ID headers for each mail message. If not defined
or if set to False (the default), the ID headers are not sent
for any mail from an SMTP address. For information about
how IMAP handles message headers, see Section 19.1.6.
Decnet-Rewrite
Determines how the IMAP server rebuilds a simple DECnet
address (of the form node::user) when it sends the mail to
the IMAP client The value of this option can be one of the
following:
•
GENERIC
Simple DECnet addresses are changed to the SMTP
address format.
•
NONE
Simple DECnet addresses are sent unmodified to the
IMAP client.
•
TRANSFORM (default)
The IMAP server attempts to transform the DECnet
address into an SMTP address by translating the
DECnet node name to a TCP/IP host name.
For more information about how IMAP rebuilds the
message headers, see the HP TCP/IP Services for
OpenVMS User’s Guide.
(continued on next page)
Configuring and Managing the IMAP Server 20–3
Configuring and Managing the IMAP Server
20.2 IMAP Server Control
Table 20–1 (Cont.) IMAP Configuration Options
Option Name
Description
Quoted-Decnet-Rewrite
Determines how the IMAP server rebuilds a DECnet
address that contains quotation marks (of the form
node::"user@host") in the OpenVMS Mail From: field
when it sends the message to the IMAP client. The value of
this option may be one of the following:
•
GENERIC
DECnet addresses that contain quotation marks are
changed to the SMTP address format.
•
NONE
DECnet addresses that contain quotation marks are
sent unmodified to the IMAP client.
•
TRANSFORM (default)
The IMAP server uses the text within the quotation
marks in the From: field it sends to the IMAP server.
For more information about how IMAP rebuilds the
message headers, see Section 19.1.6.1.4.
Personal-Name
If defined, the IMAP server provides the IMAP clients with
the message header From: fields that include the sender’s
personal name, if one appeared in the sender’s From: field.
Some IMAP client systems are confused by the use of
personal names when you attempt to reply to a mail
message or when the name contains commas or other
special characters. If you define the configuration option
Personal-Name described in the HP TCP/IP Services
for OpenVMS Management guide, then before going live
make sure you test the configuration carefully with your
IMAP client systems to ensure that message replies work
successfully.
Gateway-Node
If defined, the local node or cluster name is superseded by
the value of this configuration option, when supplying a
route from SMTP into DECnet as part of an address. The
Gateway-Node value should be an Internet address of a
TCP/IP Services SMTP server node.
For example, suppose a Decnet node name of ORDERS
cannot be mapped, and the address is ORDERS::J_SMITH
and Gateway-Node is defined to be widgets.xyzcorp.com,
then the resulting address will be "ORDERS::J_
SMITH"@widgets.xyzcorp.com.
(continued on next page)
20–4 Configuring and Managing the IMAP Server
Configuring and Managing the IMAP Server
20.2 IMAP Server Control
Table 20–1 (Cont.) IMAP Configuration Options
Option Name
Description
Max-Connections
Each time the number of live connections to the server
reaches the Max-Connections parameter (default = 25),
a new process is started. The old server does not accept
new connections and will shut down as soon as all existing
connections are closed by the client or after 20 minutes,
whichever comes first. Service may be interrupted for up to
5 seconds while one process takes over from the other.
The service limit default value (currently 16) should not
be less than the application limit of 25. Use the TCP/IP
management command SET SERVICE IMAP/LIMIT to
increase the server limit to a large number, such as 1600.
You should avoid changing the value of this option unless
instructed by HP support personnel. Too low a setting
will result in unnecessary delays, and too high a setting
will result in too many connections contesting per-processlimited OpenVMS Mail resources.
Message-Cap
The IMAP server has a configurable limit on the number of
messages displayed in a folder, defined by the Message-Cap
parameter. If this parameter is not defined, or if it is set to
the default of 0, then no limit is applied.
If a user tries to list a folder containing more messages
than the limit, then only the first n messages will be
displayed, where n is the value of the Message-Cap
parameter. To display more messages, delete or move
mail messages, and purge the folder of deleted messages.
Server-Trace
The default for this setting is False. If set to True, a trace
file is created as TCPIP$IMAP_HOME:TCPIP$IMAP_node_
mmddhhmmssTRACE.LOG, where node is the node name
where the IMAP server is running and mmddhhmmss is
the time that the trace log is created. All communication
between IMAP clients and the IMAP server is logged, with
the exception of passwords. Since a large amount of data is
recorded on a busy system, it is recommended that tracing
be turned on only for short periods. To turn tracing on or
off, it is necessary to restart the IMAP server.
(continued on next page)
Configuring and Managing the IMAP Server 20–5
Configuring and Managing the IMAP Server
20.2 IMAP Server Control
Table 20–1 (Cont.) IMAP Configuration Options
Option Name
Description
Trace-Synch
This setting only applies when the setting Server-Trace is
set to True. Trace-Synch governs the frequency with which
the trace log is flushed.
Trace-Synch is a non-negative integer value which specifies
the number of trace log writes between each full flush of the
trace log output to disk. Flushing the log more frequently
lowers the number of log writes that could be lost at the
end of the log in the event of a server process crash but it
also means slower performance. Conversely less frequent
flushing means better performance but more lines possibly
lost at the end of the log on a server crash.
A value of 0, which is the default, means not to flush to disk
until the server process exits, though OpenVMS Record
Management Services (RMS) will flush to disk periodically
anyway. This is the highest performance option but in the
event of a server crash many lines of trace log information
might be lost.
If you want the server to flush on each log write set TraceSynch to 1. This is the slowest performer but safest
regarding potential loss of trace log data in the event of
a server crash.
Benchmark testing has proven that a value of 100 strikes a
good balance between performance and data loss.
20.2.4 Tuning the Server
This section is intended for system managers who want to know more detailed
information about the IMAP server.
20.2.4.1 Tuning Issues
The only tuning issue pertains to the server’s use of Virtual Memory (VM). The
IMAP server can use large amounts of VM and might require some tuning to get
dependable performance.
The exhaustion of virtual memory can be manifested in different ways including
the server process crashing with error messages that could appear to be caused by
different problems such as access violations, ROPRAND as well as INSVIRMEM
errors. Some crashes produce PTHREAD_DUMP.LOG files in TCPIP$IMAP_
HOME.
Although the process crashes might appear to be from different causes, memory
exhaustion can be confirmed by examining the job termination information at
the end of the TCPIP$IMAP_RUN.LOG. If the "Peak virtual size" value is at or
above the TCPIP$IMAP account’s PGFLQUO value, then the process probably
terminated due to insufficient virtual memory.
The IMAP server process sometimes hangs rather than exits when it consumes all
of its dynamic memory. Use the following commands to examine the PAGFILCNT
of the IMAP server process. If the value is at or near zero then the hang is caused
by insufficient virtual memory.
20–6 Configuring and Managing the IMAP Server
Configuring and Managing the IMAP Server
20.2 IMAP Server Control
$!
$! This shows the PID(s) of the IMAP process(es)...
$ SHOW SYSTEM/PROCESS=*IMAP*
$!
$! To show the process’s PAGFILCNT do
$ WRITE SYS$OUTPUT "’’F$GETJPI("insert-pid-here","PAGFILCNT")’"
20.2.4.2 Tuning Options
The use of virtual memory by the IMAP server can be controlled by one or both of
the following actions:
•
Give more dynamic memory to an IMAP server process
If sufficient memory is available, increase the PGFLQUO of the TCPIP$IMAP
account (adjusting any SYSGEN parameters that limit PGFLQUO). Take into
account that multiple server processes might need to run concurrently on a
heavily loaded system when assigning a high PGFLQUO.
The amount of memory an IMAP server can use at peak is the sum of the
following elements:
Memory required at start-up: 10000 blocks
Memory per connection: 1500 blocks. The number of connections per
Server is limited by the Max-Connections configuration option, default 25.
Thus in a default configuration the amount required is 37500 blocks.
Memory per message: If a user lists a large folder, then the Server
requires an extra 3 blocks per message. If you estimate that your users
are opening, at peak, folders with an average of 1000 messages, then the
amount of memory required is the following:
Max-Connections * 3 * 1000
This is 75,000 blocks in a default configuration. The Message-Cap
configuration option can be used to limit the maximum number of
messages in a folder that can be viewed. If Message-Cap is defined,
then the formula is:
Max-Connections * 3 * Message-Cap
For more information about these configuration options, see Table 20–1.
•
Reduce IMAP server demand for memory
There are two IMAP configuration options that can be used to reduce each
IMAP server process’s consumption of dynamic memory: Max-Connections
and Message-Cap.
Because Max-Connections limits the number of connections that can be served
simultaneously, it implicitly limits the quantity of VM consumed by each
IMAP server process. Note that while reducing Max-Connections reduces the
dynamic memory consumption of each IMAP server process it results in more
IMAP server processes; there will be more processes each using less dynamic
memory.
Message-Cap limits the number of messages passed back to the client when a
folder is selected.
Configuring and Managing the IMAP Server 20–7
Configuring and Managing the IMAP Server
20.3 Enabling MIME Mail
20.3 Enabling MIME Mail
The MIME (Multipurpose Internet Mail Extensions) specification provides a set
of additional headers you can use so that users can send mail messages composed
of more than simple ASCII text. MIME is an enhancement to RFC 822.
For MIME mail to be decoded correctly, follow these guidelines:
•
Configure the SMTP server with the /OPTION=TOP_HEADERS qualifier,
because the first lines of mail text after the four OpenVMS message header
lines and the initial separating line must be the MIME headers.
•
Configure the IMAP server with the option Ignore-Mail11-Headers set
to True, or leave this option undefined, since True is the default value.
Otherwise, MIME headers are not parsed as message headers.
•
The OpenVMS message From: field must be recognized as an SMTP address.
Otherwise, the IMAP server sends the headers it creates from OpenVMS
message headers as the headers of the mail message. For information about
IMAP message headers, see Section 19.1.6.
Define the logical name TCPIP$SMTP_JACKET_LOCAL to 1 for all SMTP
cluster systems. This ensures that the mail is delivered if the domain in the
From: or To: field appears local. For example:
$ DEFINE/SYSTEM TCPIP$SMTP_JACKET_LOCAL 1
If MIME mail does not decode, check the mail headers on the client system.
If you see multiple blocks of headers and the MIME version header is not in
the first block, confirm that you have followed these guidelines. Note that the
headers of messages forwarded over OpenVMS Mail are mapped only if there is
no cover note (that is, if the headers of a forwarded message are at the top of the
message immediately following the headers of the forwarding message).
20–8 Configuring and Managing the IMAP Server
21
Configuring XDMCP-Compatible X Displays
The X Window System, developed by the Massachusetts Institute of Technology,
is a network-based graphics window system based on the client/server application
model. The X protocol, through which the client and server communicate, runs
on TCP/IP Services or DECnet. This means that an X display on one system can
display information output from an application running on another system in the
network.
An X display is a graphic output device that is known by The X Display Manager
(XDM), such as:
•
An X terminal
•
A workstation that has the X Window System software installed and
configured
•
A PC running Windows or Windows NT and some X Window System software,
such as eXcursion or Exceed
This chapter reviews key concepts, discusses how to configure an XDMCPcompatible X display using the TCP/IP Services XDM server, and covers the
following topics:
•
XDMCP queries (Section 21.2)
•
XDM configuration files (Section 21.3)
•
XDM log files (Section 21.4)
•
XDM server startup and shutdown (Section 21.5)
•
Configuring the XDM server (Section 21.6)
•
Configuring other X displays (Section 21.8)
21.1 Key Concepts
The X Display Manager (XDM) is an X client that manages the login process of
a user’s X window session. XDM is responsible for displaying a login screen on a
display specified by an X server, establishing an X window session, and running
scripts that start other X clients. When the user logs out of the X session, XDM
is responsible for closing all connections and resetting the terminal for the next
user session.
An earlier version of XDM had limitations that were resolved with the
introduction of the XDM Control Protocol (XDMCP). Before XDMCP, XDM
used the XSERVERS file to keep track of the X terminals for which it managed
the login process. At startup, XDM initialized all X terminals listed in the
XSERVERS file. If the X terminal was turned off and then on again, XDM had
no way of knowing that a new login process should be initiated at the X terminal.
Configuring XDMCP-Compatible X Displays 21–1
Configuring XDMCP-Compatible X Displays
21.1 Key Concepts
To reinitialize the X terminal, the XDM process had to be restarted. This problem
was solved through the development of the XDM Control Protocol.
Now, because of XDMCP, XDM can listen for management requests from X
terminals as well as use the XSERVERS file for the X terminals that were not
XDMCP compatible. Most X terminals today are XDMCP compatible.
The TCP/IP Services implementation of XDM is based on the X11R6.1 release
from X Consortium.
21.2 XDMCP Queries
XDMCP provides the following methods to query XDM for service:
•
Direct
X terminals, configured for the direct request method, send a connection
request to a specific host.
•
Broadcast
X terminals, configured for a broadcast request, send out a general query to
ask for service from all nodes running XDM. A list of the responding no