0817 00 Los5 - NG

3
LynxOS Networking Guide

LynxOS Release 5.0
DOC-0817-00
Product names mentioned in the LynxOS Networking Guide are trademarks of their respective manufacturers and are
used here for identification purposes only.
Copyright ©1987 - 2008, LynuxWorks, Inc. All rights reserved.

U.S. Patents 5,469,571; 5,594,903; 6,075,939; 7,047,521
Printed in the United States of America.
All rights reserved. No part of the LynxOS Networking Guide may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photographic, magnetic, or otherwise, without the
prior written permission of LynuxWorks, Inc.
LynuxWorks, Inc. makes no representations, express or implied, with respect to this documentation or the software it
describes, including (with no limitation) any implied warranties of utility or fitness for any particular purpose; all such
warranties are expressly disclaimed. Neither LynuxWorks, Inc., nor its distributors, nor its dealers shall be liable for any
indirect, incidental, or consequential damages under any circumstances.
(The exclusion of implied warranties may not apply in all cases under some statutes, and thus the above exclusion may
not apply. This warranty provides the purchaser with specific legal rights. There may be other purchaser rights which
vary from state to state within the United States of America.)
Contents
PREFACE .............................................................................................................. VII

For More Information .................................................................................... vii
Typographical Conventions ..........................................................................viii
Special Notes .................................................................................................. ix
Technical Support ............................................................................................ x
How to Submit a Support Request ........................................................... x
Where to Submit a Support Request ....................................................... xi
CHAPTER 1 TCP/IP AND NETWORKING UTILITIES ......................................................... 1

Transmission Control Protocol/Internet Protocol ............................................ 1
Enabling/Disabling TCP/IP Support ........................................................ 1
Configuring Ethernet Cards with ifconfig ....................................................... 1
rc.network ................................................................................................. 2
Common TCP/IP Utilities ............................................................................... 2
Testing TCP/IP (ping) .............................................................................. 4
Using traceroute ....................................................................................... 8
Logging On to a Remote Computer (telnet, rlogin, ssh) .......................... 8
Executing Commands Remotely (rsh) ................................................... 11
Transferring Files between Machines (ftp, tftp, rcp, scp) ...................... 13
DNS Client Configuration ............................................................................. 17
NTP ................................................................................................................ 18
xntpd ....................................................................................................... 19
openntpd ................................................................................................. 19
SNTP ...................................................................................................... 20
Divert Sockets ................................................................................................ 20
Support for PF_PACKET .............................................................................. 21
Driver Defaults .............................................................................................. 21
LynxOS Networking Guide iii

Contents
CHAPTER 2 NETWORK SECURITY ............................................................................... 25

IPFW .............................................................................................................. 25
Enabling IPFW ....................................................................................... 25
Changing IPFW Rules ............................................................................ 26
Listing IPFW Rules ................................................................................ 27
Removing IPFW Rules ........................................................................... 27
Clearing IPFW Counters ........................................................................ 28
IPsec .............................................................................................................. 28
AH and ESP Security Protocols ............................................................. 28
Tunnel Mode and Transport Mode ......................................................... 29
Setting the Security Policy Database ..................................................... 29
Setting the Security Association Database ............................................. 29
Using setkey ........................................................................................... 29
OpenSSH ....................................................................................................... 33
ssh daemon configuration ....................................................................... 33
ssh client configuration .......................................................................... 35
hosts.allow and hosts.deny files ............................................................. 37
CHAPTER 3 DHCP .................................................................................................... 39

Introduction ................................................................................................... 39
LynxOS DHCP Components ......................................................................... 40
LynxOS DHCP Files .............................................................................. 40
DHCP Man Pages ................................................................................... 40
Online Resources .................................................................................... 41
Installing DHCP ............................................................................................ 41
The DHCP Server .......................................................................................... 41
dhcpd ...................................................................................................... 41
dhcpd.conf .............................................................................................. 42
dhcpd.leases ............................................................................................ 43
Relay Agents .......................................................................................... 43
The DHCP Client .......................................................................................... 43
dhclient ................................................................................................... 43
CHAPTER 4 NFS ....................................................................................................... 45

Overview ....................................................................................................... 45
Enabling NFS Support ................................................................................... 46
Enabling/Disabling NFS Server Support ............................................... 46
iv LynxOS Networking Guide

Enabling/Disabling NFS Client Support ................................................ 46
NFS Server .................................................................................................... 46
Configuring the NFS Server ................................................................... 46
Tuning the NFS Server Kernel ............................................................... 48
NFS Server Tunable Parameters ............................................................ 48
Exporting/Unexporting Directories ........................................................ 49
Starting/Stopping the NFS Server .......................................................... 49
CHAPTER 5 MULTICASTING ....................................................................................... 51

Overview ....................................................................................................... 51
Addressing .............................................................................................. 52
Registration ............................................................................................ 53
IGMP ............................................................................................................. 53
IGMP version 3 ...................................................................................... 54
IGMPv1 and IGMPv2 ............................................................................ 54
Socket options ........................................................................................ 54
sysctl() variables ..................................................................................... 56
netstat output .......................................................................................... 57
CHAPTER 6 TRAFFIC MANAGEMENT AND QUALITY OF SERVICE ................................... 59

Layer 2 (Ethernet) .......................................................................................... 59
Bridging .................................................................................................. 59
802.1 Standards ...................................................................................... 59
Spanning Tree ......................................................................................... 60
VLAN ..................................................................................................... 62
Layer 3 (IP) .................................................................................................... 63
IP QoS .................................................................................................... 65
CHAPTER 7 NET-SNMP ............................................................................................ 91

Introduction ................................................................................................... 91
SNMP Overview ............................................................................................ 92
net-SNMP Documentation ............................................................................ 93
net-SNMP Components ................................................................................. 94
Extending the Agent with MIB Modules ...................................................... 95
License & Copyright ..................................................................................... 95
LynxOS Networking Guide v

Contents
CHAPTER 8 OPENSSL ............................................................................................... 97

Overview ....................................................................................................... 97
OpenSSL Components ........................................................................... 97
OpenSSL Documentation ....................................................................... 99
Installing OpenSSL ....................................................................................... 99
Cross-Development Installation ............................................................. 99
Native Installation .................................................................................. 99
Examples of Using the OpenSSL Tool ....................................................... 100
Encrypting and Decrypting Data .......................................................... 100
Calculating Message Digest for Data ................................................... 101
Creating a Self-signed Certificate ........................................................ 101
Connecting to the Secure Server Using SSL ........................................ 102
Creating the SSL Server from the Command Line .............................. 103
Using OpenSSL in LynxOS Applications ................................................... 104
net-SNMP ............................................................................................. 104
bind ....................................................................................................... 104
racoon ................................................................................................... 104
OpenSSL Legal Issues ................................................................................. 104
License & Copyright ................................................................................... 105
APPENDIX A SUPPORTED NETWORKING STANDARDS ................................................. 107
APPENDIX B IPV6 ..................................................................................................... 119

Overview ..................................................................................................... 119
Enabling IPv6 .............................................................................................. 120
rc.network6 Configuration File ............................................................ 120
rc.ipv6.conf Configuration File ............................................................ 120
Setting an IPv6 Address Statically .............................................................. 120
Setting up Hostname Resolution for IPv6 Addresses .................................. 121
Setting up Routes with route6d ............................................................ 121
Using faithd to Connect IPv6 and IPv4 Networks ...................................... 122
Hostname Resolution Between IPv6 and IPv4 Hosts .................................. 123
INDEX ............................................................................................................ 125
vi LynxOS Networking Guide

Preface
The LynxOS Networking Guide contains information about configuring LynxOS

network components.
This manual assumes that users have a basic understanding of UNIX and is
intended primarily for system administrators, network administrators, developers,
and end-users of LynxOS. Many tasks in this manual include system
administration and configuration tasks that require root privileges.
For More Information

For information on the features of LynxOS, refer to the following printed and
online documentation.
• Release Notes
This printed document contains details on the features and late-breaking
information about the current release.
• LynxOS Installation Guide
This manual details the installation instructions and configurations of
LynxOS.
• LynxOS User’s Guide
This manual details system administration concepts, building custom
LynxOS kernels, and additional features available in LynxOS.
• Writing Device Drivers for LynxOS
This guide contains details on writing device drivers for LynxOS.
LynxOS Networking Guide vii

Preface
• Online information
The complete LynxOS documentation set is available on the
Documentation CD-ROM. Books are provided in both HTML and PDF
formats.
Updates to these documents are available online at the LynuxWorks
website: http://www.lynuxworks.com.
Additional information about commands and utilities is provided online
with the man command. For example, to find information about the GNU
gcc compiler, use the following syntax:
man gcc
Typographical Conventions
The typefaces used in this manual, summarized below, emphasize important
concepts. All references to filenames and commands are case-sensitive and should
be typed accurately.
Kind of Text Examples
Body text; italicized for emphasis, new Refer to the LynxOS User’s Guide.
terms, and book titles
Environment variables, filenames, ls

functions, methods, options, parameter -l
names, path names, commands, and myprog.c
computer data /dev/null
Commands that need to be highlighted login: myname
within body text, or commands that must be # cd /usr/home
typed as is by the user are bolded.
Text that represents a variable, such as a cat filename

filename or a value that must be entered by mv file1 file2
the user is italicized.
viii LynxOS Networking Guide

Special Notes
Kind of Text Examples
Blocks of text that appear on the display Loading file /tftpboot/shell.kdi

into 0x4000
screen after entering instructions .....................
or commands File loaded. Size is 1314816
Copyright 2000 LynuxWorks, Inc.
All rights reserved.
LynxOS (ppc) created Mon Jul 17

17:50:22 GMT 2000
user name:
Keyboard options, button names, and Enter, Ctrl-C

menu sequences
Special Notes
The following notations highlight any key points and cautionary notes that may
appear in this manual.
NOTE: These callouts note important or useful points in the text.
CAUTION! Used for situations that present minor hazards that may interfere with
or threaten equipment/performance.
LynxOS Networking Guide ix

Preface
Technical Support
LynuxWorks Support handles support requests from current support subscribers.
For questions regarding LynuxWorks products or evaluation CDs, or to become a
support subscriber, our knowledgeable sales staff will be pleased to help you
(http://www.lynuxworks.com/corporate/contact/sales.php3).
How to Submit a Support Request

When you are ready to submit a support request, please include all the following
information:
• First name
• Last name
• Your job title
• Phone number
• Fax number
• E-mail address
• Company name
• Address
• City, state, ZIP
• Country
• LynxOS or BlueCat Linux version you are using
• Target platform (for example, PowerPC or x86)
• Board Support Package (BSP)
• Current patch revision level
• Development host OS version
• Description of problem you are experiencing
x LynxOS Networking Guide

Where to Submit a Support Request
Where to Submit a Support Request
By E-mail:
Support, Europe tech_europe@lnxw.com

Support, worldwide except Europe support@lnxw.com
Training and courses USA: training-usa@lnxw.com
Europe: training-europe@lnxw.com
By Phone:
Training and courses USA: +1 408-979-4353

Europe: +33 1 30 85 06 00
Support, Europe +33 1 30 85 93 96
(from our Paris, France office)
Support, worldwide except Europe and Japan +1 800-327-5969 or
(from our San José, CA, USA headquarters) +1 408-979-3940
Support, Japan +81 33 449 3131
By Fax:
Support, Europe +33 1 30 85 06 06

(from our Paris, France office)
Support, worldwide except Europe and Japan +1 408-979-3945
(from our San José, CA, USA headquarters)
Support, Japan +81 22 449 3803
LynxOS Networking Guide xi

Preface
xii LynxOS Networking Guide

6
CHAPTER 1 TCP/IP and Networking Utilities
Transmission Control Protocol/Internet Protocol

LynxOS supports Transmission Control Protocol/Internet Protocol (TCP/IP)
networks. By default, TCP/IP is installed during the initial installation of LynxOS.
TCP/IP can be configured, installed, or removed at any time.
LynxOS TCP/IP is an enhanced version of the FreeBSD 4.11 TCP/IP stack and
includes support for the BSD socket interface system and networking library
functions needed to access the TCP/IP and UDP network protocols. The LynxOS
TCP/IP stack is enhanced for real-time determinism and performance.
Enabling/Disabling TCP/IP Support

In LynxOS, TCP/IP support is enabled or disabled by default. For PC/AT-
compatible systems, TCP/IP is enabled by default.
To disable TCP/IP support, make sure that the lines for TCP/IP in the
config.tbl file read as follows:
I:nullnux.cfg
#I:hbtcpip.cfg
#I:em.cfg
Configuring Ethernet Cards with ifconfig

To assign an address to a network interface for each interface present on the
system, use the ifconfig command. (This is handled automatically if
LynxOS is installed with network support.) The ifconfig command can be
issued to reconfigure the network interface or to obtain configuration information.
LynxOS Networking Guide 1

Chapter 1 - TCP/IP and Networking Utilities
To use ifconfig to configure a network interface, place the command in

/net/rc.network (see“rc.network” below for more information on this file) in
order for the network interface to be properly configured at boot time.
To display the current configuration information of the network interface, issue the
ifconfig command without parameters. Refer to the ifconfig man page for
more information.
rc.network
To configure a network interface, remove the comment character at the beginning
of the corresponing ifconfig entry or add a new entry for a network interface.
Then supply the appropriate hostname and IP address.
To use a network interface driver not supplied with LynxOS, insert an ifconfig
entry into rc.config to specify the device driver filename, hostname, and IP
address.
Use rc.network also to enable or disable network services, such as NFS.
Common TCP/IP Utilities

The following table lists common LynxOS TCP/IP commands and files.
Table 1-1: LynxOS TCP/IP Components
Component Definition
ping Sends a packet of data to a system to determine if it is on the

network. The ping command is used to test that TCP/IP is
installed correctly and that a system is up on a network.
hosts The hosts database. This can be the /etc/hosts file, the
Network Information Service (NIS) hosts map, the Internet
domain name server, or any combination of these.
rlogin Allows the user to log on to a remote host on the network.
This requires that the user name be the same on both the local
and remote machine. If the /etc/hosts.equiv file is set
up, a password is not needed when performing a remote log
on. rlogin requires the host computer to have a UNIX-
compatible operating system.
/etc/hosts.equiv This file contains the list of acceptable remote hosts.
2 LynxOS Networking Guide

Common TCP/IP Utilities
Table 1-1: LynxOS TCP/IP Components (Continued)
/etc/hosts This file contains the list of hosts on the network.

/etc/resolv.conf The resolv.conf file is used to determine a system’s
domain name, domain search paths, and IP addresses for name
servers and routers.
telnet A protocol that allows for remote access to a system. The
system can run any operating system, UNIX-compatible or
not.
.rhosts A file that provides the remote authentication database for the
rlogin, rsh, and rcp commands.
rsh Allows users to connect and execute commands on a remote
host. This command expects that the /etc/hosts.equiv
and .rhosts files are configured properly. The rsh
command works only when users are considered equivalent
on the local and remote machine.
rcp A command that copies files and directories between different
hosts. The remote copy command or rcp is a fast and
efficient way to exchange data quickly between
UNIX-compatible hosts. The /etc/hosts.equiv
and .rhosts files must be correctly configured to use this
command. Note that rcp does not copy symbolic links.
ftp A file transfer program that uses the File Transfer Protocol.
The ftp program transfers files to and from a remote
network site. Passwords are required to access user
directories.
ifconfig Allows users to view and configure TCP/IP network interface
parameters. The ifconfig command is not hardware-
dependent.
netstat A command that lets users know the status of the network. It
displays the contents of various network-related data
structures.
tcpdump Displays TCP/IP activity on a particular interface.
For more information on these components, see the appropriate man pages.
The next sections provide an overview of some of the most common TCP/IP
utilities. These sections introduce basics of common TCP/IP utilities such as the

ping command, remote computer access (telnet, rlogin), and file transfer
between computers (ftp).
Testing TCP/IP (ping)

The simplest way to test the TCP/IP configuration of the system is to use the ping
utility. Users can send a test message to any host on the network with the ping
command. Users can ping either the IP address or hostname of the machine. This
test verifies the correct operation of hardware and TCP/IP software connecting the
hosts. The ping command continues to send packets to the addressed host once
every second until the command is terminated with a Ctrl-C.
The following figure shows the ping command testing TCP/IP configuration by
sending data packets to the IP address of a system:
$ ping 192.168.1.102
PING 192.168.1.102: 56 data bytes
64 bytes from 192.168.1.102: icmp_seq=0.time=10. ms
^C
---- 192.168.1.102 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/2/10
$
Figure 1-1: Testing TCP/IP with ping

Troubleshooting ping
The following figure shows the ping command testing TCP/IP configuration by
sending data packets to the hostname of a system.
$ ping shark
PING shark (192.168.1.101): 56 data bytes
^C
----shark PING Statistics----
$
Figure 1-2: Using ping to test TCP/IP
Once the correct host setup is verified, every host on the network can use the ping
command on other members of the network as shown in the following figure.
$ ping orca
PING orca (192.168.1.102): 56 data bytes
^C
----orca PING Statistics----
$
Figure 1-3: Pinging Other Hosts on a Network
Problems related to testing TCP/IP configurations with ping sometimes occur
due to host lookup failures or problems in connectivity between the systems, not
necessarily with the TCP/IP configuration on the local system.
The /etc/hosts File

Host lookup failures with ping can sometimes be attributed to incorrect
/etc/hosts or /etc/resolv.conf files. For example, if the host named

fish in the /etc/hosts file is not defined, the ping command fails as shown
in the following figure.
[bash: /] $ ping fish

Error: cannot resolve fish: Unknown host
[bash: /]$
Figure 1-4: Host Not Defined in /etc/hosts
Because the hostname fish is not defined on the local system, ping returns a
hostname lookup failure. The /etc/hosts file provides a means of mapping IP
addresses to hostnames. In larger networks, however, a Domain Name Service
(DNS) server is typically used. The DNS server maintains a database of hostnames
and IP addresses. If a user pings a system that is not defined in a local
/etc/hosts file, the system then sends a request to a DNS server to translate the
hostname to the IP address.
A preferred method to test TCP/IP functionality is to first ping the IP address of a
system, then attempt to ping the hostname of a system. If the IP address of a host is
found, but the hostname lookup fails, TCP/IP is correctly configured, but the
hostname resolution needs to be corrected. To resolve the hostname lookup failure,
the correct IP address and hostname must be added to the /etc/hosts file.
The following table shows an example /etc/hosts configuration file:
#loopback address
127.0.0.1 localhost
#localhost address
192.168.1.103 stingray
#other host addresses

192.168.1.101 shark
192.168.1.102 orca
Figure 1-5: /etc/hosts example file
In this example, the localhost entry is called a “loopback” address and is used to
point to the local system. An entry also exists for the IP address and hostname of
the local system. Any other IP address and hostname definitions point to other
systems on the network.

The /etc/resolv.conf file

In addition to the /etc/hosts file, the /etc/resolv.conf file provides the
domain name for the local system, domain search paths used when looking up
hosts, and IP addresses for Domain Name Service (DNS) servers.
Users can ping a host without providing a domain name by entering the following
command:
# ping fish
If fish is not defined in /etc/hosts, the local system uses the search paths and
DNS servers provided in /etc/resolv.conf to determine a fully-qualified
domain name and IP address. The system uses the search entries in the
resolv.conf file to determine a fully qualified domain name (for example,
fish.domain1.com). For the system to find the IP address of a host, it must have
access to one or more DNS servers. These DNS servers contain indexes of fully
qualified domain names and valid IP addresses.
The structure of the /etc/resolv.conf file is as follows:
domain domain1.com
search domain1.com
search domain2.com
nameserver 192.168.1.254
Figure 1-6: /etc/resolv.conf example file:
In this example, the domain definition provides the domain of the local system. If
the hostname is stingray, for example, the fully qualified hostname would be
stingray.domain1.com.
The search definitions provide a means to resolve the fully qualified domain
name for hosts. For example, a system searching for the host fish first attempts
to resolve the fully qualified domain name to the first search entry or
fish.domain1.com by sending a request to the local DNS server. If no entry
exists in the DNS table for the system fish.domain1.com, the local system
resolves the fully qualified domain name to the second search entry in
resolv.conf, or fish.domain2.com. A second request is sent to the DNS
server for the IP address of fish.domain2.com. This process continues until a
valid host and domain is found or there are no more search paths. There is no limit
to the number of search paths that can be used in /etc/resolv.conf.

nameserver definitions in /etc/resolv.conf are IP addresses pointing to

local DNS servers. These DNS servers are used to translate the fully qualified
domain name to a valid IP address.
NOTE: LynxOS 5.0 distribution does not contain the resolv.conf or

resolv.conf.sample file. User has to create the file.
ping Not Responding

If the ping command fails to respond with any output, terminate the program by
pressing Ctrl-C. Common reasons for ping failure include:
• The machine orca is not connected to the network.
• The machine orca is down or powered off.
• The /etc/hosts file on shark has the wrong Internet address for
orca.
• TCP/IP is not properly configured for orca.
Using traceroute
To follow the route an IP packet takes to reach its destination, use the
traceroute utility. By sending simple UDP probe packets, traceroute
displays the names and response times of the different gateways a packet traverses
before reaching its destination. The traceroute syntax is as follows:
# traceroute <host>
where <host> is the hostname or IP address of the destination system. Additional
usage information is available in the traceroute man page.
Logging On to a Remote Computer (telnet, rlogin, ssh)

Users can log on to another host on the network using any of the following utilities:
• telnet
• rlogin
• ssh

telnet
telnet
The telnet utility allows users to log on to any type of computer that supports
TCP/IP. The computer can run any operating system, UNIX-compatible or not.
This utility allows a LynxOS user to access a system from anywhere on the
network.
telnet is invoked with the hostname of a remote computer, as shown in the
following figure.
jones@orca$ telnet shark

Trying...
Connected to shark.
Escape character is '^]'.
LynxOS (shark)
user name: jones

password:
jones@shark$
Figure 1-7: Using telnet to Remotely Log in
To access the system, users must supply a user name and password.
To terminate a telnet session, log out of the system with the exit command,
as shown in the following figure.
jones@shark$ exit
Connection closed by foreign host.
jones@orca$
Figure 1-8: Terminating a telnet Session
rlogin
Users can use rlogin to remotely log on another computer similar to telnet.
Unlike telnet, rlogin requires the host computer to have a UNIX-compatible
operating system.

rlogin is invoked with the hostname of the remote computer, as shown in the
figure below:
jones@orca$ rlogin shark

login shark vt100
password:
jones@shark$
Figure 1-9: Using rlogin
In the previous example, no user name is passed to rlogin. In this case, the user
name on the local machine is used to log on the remote machine (for example, user
jones on host shark logged on remote host orca as user jones).
If the user wants to log on to a system that does not have an identical user account,
the login argument -l followed by the desired user account must be added, as
shown in the following figure.
jones@orca$ rlogin shark -l doc

login shark vt100
password:
doc@shark$
Figure 1-10: Remote Log in as Another User
Unlike telnet, the rlogin utility lets users take advantage of the information
in /etc/hosts.equiv and.rhosts files. Users on machines that are set up to
be considered local are not prompted for a password.
ssh
ssh is a secure program for logging on to a remote computer and for executing
commands on a remote computer. It is intended to replace rlogin and rsh, and
provides secure encrypted communications between two untrusted hosts over an
insecure network. ssh allows users to log on to any type of computer that
supports ssh.
Unlike telnet, rlogin, and ftp, which present passwords “in the clear” over a
nonsecure network, ssh encrypts userid and password interchange between two
computers and then encrypts the network traffic between the two computers. Both
the password exchange and the data passing between the two computers is
encrypted with strong encryption.

Executing Commands Remotely (rsh)
For more information, see “OpenSSH” on page 33.

When connecting to a host for the first time, the user must establish the authenticity
of that host and acknowledge that he or she wants to connect. In the following
example, user jones uses ssh to remotely log on to orca.
jones@shark$ ssh orca

The authenticity of host 'orca (192.168.30.2)' can't be
established.
RSA fingerprint is
18:30:50:46:ac:98:3c:93:1a:56:35:09:8d:97:e3:1d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'orca,192.168.30.2' (RSA) to the
list of known hosts.
jones@shark’s password:
Last login: Sat Dec 28 13:29:19 from shark
jones@orca$
The user can log in as a different user by using the -l option. For example,
jones@orca$ ssh shark -l doc

doc@shark’s password:
doc@shark$
The user can use ssh to execute a command on a remote computer and display
the results on the local host. For example,
jones@orca$ ssh shark who

jones
Executing Commands Remotely (rsh)

Another utility included with TCP/IP is rsh, the remote shell command. This
utility allows users to perform the following tasks:
• Access remote hosts and redirect output to the local machine.
• Execute a command on that host.

Accessing Remote Hosts and Redirecting Output to the

Local Machine
The syntax for the rsh command is as follows:
rsh host [-l <user_name>] <command>
An optional user name can be given to execute the command as a specific user.
This is useful if the current user account is not considered equivalent on the remote
machine. rsh redirects standard input, standard output, and standard error from
the remote machine to the local host.
The who utility displays users who are currently logged on to a remote host, as
davis@shark$ rsh orca who

rootatc0 Mon Dec 23 10:40:54
rootttyp0:0.0Mon Dec 23 10:41:19
davis@shark$
Figure 1-11: Using who to Query Log ins on a Remote System
Executing a Command on a Remote Host

Also, commands can be invoked on a remote host as another user. In the following
figure, user jones on host orca invokes the whoami command. This utility
reports the current login account.
davis@shark$ rsh orca -l jones whoami

jones
davis@shark$
Figure 1-12: Using rsh to Remotely Execute a Utility

Transferring Files between Machines (ftp, tftp, rcp, scp)
Transferring Files between Machines (ftp, tftp, rcp, scp)

There are several ways to copy files between hosts:
• ftp for hosts of differing operating systems.
• rcp for UNIX compatible operating systems.
• scp for secure remote copying.
File Transfer Protocol (ftp)

The File Transfer Protocol, or ftp, allows users numerous configuration options.
In addition to the options provided in this document, review the ftp man page for
setting advanced options.
Starting ftp
In its simplest invocation, ftp is called with the hostname of the remote machine.
ftp prompts for a user login and password. A password must be provided to
access user accounts.
In the following figure user davis on host orca connects to host shark and
logs on as user jones.
davis@shark$ ftp orca

Connected to orca.
220 orca FTP server (Version 4.162 Tue Nov 1 10:50:37 PST
1988) ready.
Name (orca:davis): jones
331 Password required for jones.
Password:
230 User jones logged in.
ftp>
Figure 1-13: Connecting to a System with ftp

Retrieving Files from a Remote Host (get)

Once logged in, files can be retrieved from the remote host using the get
command, as shown in the following figure.
ftp> get .login

200 PORT command successful.
150 Opening ASCII mode data connection for .Login (209
bytes).
226 Transfer complete.
218 bytes received in 0.01 seconds (21.29KB/s)
ftp>
Figure 1-14: Downloading Files with ftp
Sending Files to a Remote Host (put)

Alternatively, files can be sent to the remote host using the put command, as
ftp> put hosts.equiv

200 PORT command successful.
150 Opening ASCII mode data connection for hosts.equiv.
226 Transfer complete.
12 bytes sent in 0.07 seconds (0.17KB/s)
ftp>
Figure 1-15: Uploading Files with ftp
NOTE: By default, the ftp transfer program operates in an ASCII text mode. Set
the transfer mode to binary by entering binary at the ftp prompt.
Transferring Binary Files

To transfer binary files, the transfer mode must be changed by entering the
binary command at the ftp prompt. For example:
ftp> binary
200 Type set to I.
ftp>
Transferring a binary file in ASCII mode results in a corrupt file. To preserve the
integrity of the file, be sure to set FTP to binary mode before the transfer. Note that
binary file transfers are a little slower than ASCII file transfers.

Trivial File Transfer Protocol (tftp)
Listing ftp Commands

ftp commands are displayed by entering a question mark (?) at the ftp prompt.
The following list describes some common ftp commands
Table 1-2: Common ftp Commands
Command Description
ascii Sets file transfer type to ASCII.

binary Sets file transfer type to binary.
bye Terminates the ftp session and exits.
cd Changes directory on the remote system.
delete Deletes file on the remote system.
get Retrieves remote files to the local system
help Displays a list of ftp commands. If a command is provided as an
argument, displays specific command information.
lcd Changes working directory on the local system.
ls Lists contents of remote directory
mdir Lists contents of multiple remote directories.
mget Retrieves multiple files.
mkdir Makes directory on the remote system.
mput Sends multiple files.
put Sends one file.
pwd Prints remote system working directory.
Trivial File Transfer Protocol (tftp)

tftp (Trivial File Transfer Protocol) is a simple UDP transfer protocol. Typically,
tftp is used for bootstrapping diskless clients and installing firmware into ROM.
tftp does not require client authentication, which may pose a security risk for
some systems. LynxOS supports two tftp transfer methods: Simple and Secure.
• Simple: The client can access the entire file system. This is a simpler
configuration, but it presents a larger security hole (anyone can access the
password file). In Simple mode, only files open to the public can be read.

Simple is the default tftp mode.

• Secure: Secure mode allows tftp access for a single directory. When
invoked, the TFTP server uses a chroot(2) system call to change its
root directory. All other directories are inaccessible to the client.
To use tftp on a LynxOS machine, uncomment the following line in the
/etc/inetd.conf file:
tftp dgram udp wait root /net/tftpd tftpd
For the tftp secure mode, update the above line as follows:
tftp dgram udp wait root /net/tftpd tftpd -s /tftpboot
Remote Copy (rcp)

The remote copy command, or rcp, is an efficient way to exchange data between
UNIX-compatible hosts. To access files using rcp, users must have already set up
the /etc/hosts.equiv and .rhosts files correctly. Files can be copied
between hosts using a syntax similar to the UNIX cp command.
The only difference is that the remote host’s filename must be indicated properly.
In the following example, file /etc/hosts is copied from host orca to host
shark:
jones@shark$ rcp orca:/etc/hosts /tmp
Like the cp command, multiple files can be transferred to a directory:
jones@shark$ rcp /etc/passwd /etc/printcap orca:/tmp
Finally, the rcp command can be used to transfer files between two hosts that are
different than the host currently logged into (assuming proper configuration).
In the following example, the /etc/passwd file is copied from host orca to
host fish from a user on host shark:
jones@shark$ rcp orca:/etc/passwd fish:/tmp/passwd
Secure Remote Copy (scp)

The secure remote copy command, or scp, is a secure alternative to the rcp
command. It can be used to copy files from any computer that supports ssh. The
computer can run any operating system, UNIX-compatible or not. scp uses ssh
for data transfer, uses the same encryption and authentication, and provides the
same security as ssh. Unlike rcp, scp will ask for passwords or passphrases if
they are needed for authentication.

DNS Client Configuration
Like rcp, scp can be used to copy files to or from a host, or transfer files
between two remote hosts.
In the following example, file /etc/hosts is copied from host orca to host
shark:
jones@shark$ scp orca:/etc/hosts /tmp
The user will be prompted for his or her password. Upon successful completion of
the login process, an encrypted session will be set up between the local machine
and remote machine and the file will be copied to host shark.
DNS Client Configuration

The following three configuration files together provide the information necessary
for translating hostnames into IP addresses and vice versa:
• /etc/host.conf
• /etc/hosts
• /etc/resolv.conf
/etc/host.conf is the first file that is read, and it describes which services to
use and in what order.
The following figure shows an example of the /etc/host.conf file. It specifies
that /etc/hosts should be consulted first and then bind, if necessary. Refer to
the host.conf (5) man page for more information.
# $FreeBSD: src/etc/host.conf,v 1.6 1999/08/27 23:23:41

peter Exp $
# First try the /etc/hosts file
hosts
# Now try the nameserver next.
bind
# If you have YP/NIS configured, uncomment the next line
# nis
Figure 1-16: /etc/host.conf example file
The /etc/hosts file lists the known hosts on the network. At a minimum, this
file should list the local system and the IP address and hostname of the local host.
For further details and examples of this file, see “The /etc/hosts File” on page 5.

The /etc/resolv.conf file provides the domain name for the local system,
domain search paths used when looking up hosts, and IP addresses for DNS
servers. For further details and examples of this file, refer to “The /etc/resolv.conf
file” on page 7.
NTP
Network Time Protocol (NTP) is a protocol built on top of TCP/IP that is used to
synchronize system clocks across a network and maintain the system time of day in
synchronization with Internet standard time servers.
NTP operates by exchanging messages with one or more time servers at designated
poll intervals. It compares timestamp information and calculates how much to
adjust the system clock to bring it into synchronization. It can provide an accuracy
of time down to a few milliseconds, although the real accuracy will also depend on
the operating system and network performance.
NTP servers are organized in a hierarchical client-server model with the top-level
hierarchy consisting of a few systems known as reference clocks. A reference
clock is known as stratum 0 and is typically a cesium clock or a Global
Positioning System (GPS) that receives time from satellites. Attached to these
machines are the next level of stratum 1 servers (that is, stratum 0 clients),
which are the top level time servers available to the Internet. Below these are the
servers in hierarchy levels stratum 2 down to stratum 16.
Every system gets synchronized with a server at the next higher stratum and finally
to the reference clocks with use UTC (Universal Time Coordinated, Temps
Universel Coordonné) as the reference time.
NPTD is a utility that sets the system clock and keeps it synchronized with a
network time server or works as the time server itself. There are two NTPD
daemons in LynxOS 5.0: openntpd (the OpenNTPD daemon) and xntpd.
openntpd has the lower requirements to the system memory and is more secure.
It also has a smaller choice of the features and rarely-needed capabilities than the
xntpd daemon. xntpd may be needed, if a program that is large, but powerful
and loaded with many features is required. Otherwise, it is better to use the
openntpd daemon.
Both daemons can slowly reduce the time difference between the client and the
NTP time server.
Also, the xntdp and openntpd daemons both try to adjust the clock in small
steps and will continue until the client gets the accurate time. In the case of too

xntpd
large a time difference (more than a few seconds usually), however, xntpd prints
an error and exits, and the openntpd daemon just writes an error to a log file and
continues working without adjusting the time.
xntpd
When the xntpd daemon is started, it reads the configuration file
/etc/ntp.conf to determine synchronization sources and operating modes. It
also checks the drift file /etc/ntpd.drift that contains the latest estimate of
clock frequency error.
Once xntpd is up and running, it operates by exchanging packets that contain
time information as well as sanity checks with its time servers at poll intervals.
When a time server receives the packet, it will in turn store its own timestamp and
a transmit timestamp into the packet and send it back to the client (the system on
which ntpd is running). The client will in turn log its receipt time and estimate
the travelling time of the packet.
The packet exchange takes place until a NTP server is accepted as a
synchronization source, which takes about five minutes. If the delay between both
the server and client is big enough, the daemon will terminate and you will need to
adjust the time manually and start the daemon again.
ntpd is usually invoked without any options:
# xntpd
What follows is an example of the /etc/ntp.conf configuration file:
# Get the time from a remote server
server time.lnxw.com
# default drift file location
driftfile /etc/ntpd.drift
For more detailed information, see the ntpd and ntp.conf man pages.
openntpd
At start up, openntpd reads the configuration file /etc/ntpd.conf to
determine its synchronization sources and operating modes. It also reads the latest
estimate of clock frequency error from the drift file /var/db/ntpd.drift.
Once openntpd is up and running, it operates by exchanging packets that contain
time information as well as sanity checks with its time servers at poll intervals.

First, the client sends a request to the time server and also logs the request time.
When a time server receives the packet, it will in turn store its own receive
timestamp, reply timestamp into the packet and send it back to the client. The
client will in turn log its receipt time and estimate the local clock offset and
travelling time of the packet using the four time values.
OpenNTPD is usually invoked without any options:
# ntpd
What follows in an example of the $ENV_PREFIX/etc/ntpd.conf
configuration file:
# $OpenBSD: ntpd.conf,v 1.7 2004/07/20 17:38:35 henning Exp $
# sample ntpd configuration file, see ntpd.conf(5)
# Addresses to listen on (ntpd does not listen by default)

#listen on *
#listen on 127.0.0.1
#listen on ::1
# sync to a single server

#server ntp.example.org
# use a random selection of 8 public stratum 2 servers

# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
servers pool.ntp.org
For more detailed information, see the openntpd and openntpd.conf man
pages.
SNTP
Simple Network Time Protocol (SNTP) is a simplified version of the NTP
protocol. It uses the same structure as NTP, but due to simpler algorithms, it
provides a lower level of accuracy. It is often used on systems with limited
capacity.
Divert Sockets
divert provides a kernel packet diversion mechanism. Divert sockets are similar
to raw IP sockets except that they can be bound to a specific divert port with the
bind system call. A divert socket bound to a divert port receives all packets
diverted to that port.

Support for PF_PACKET
Divert sockets are normally used in conjunction with packet filtering. By reading
from and writing to a divert port, matching packets can be passed through a filter as
they travel through host machine.
Support for PF_PACKET

PF_PACKET is a popular standard, used by Linux to support raw Ethernet. Though
AF_RAWETH is still supported in this release, it is recommended that customers use
the new PF_PACKET interface when developing applications that require raw
Ethernet. PF_PACKET provides the same functionality as AF_RAWETH.
To create a PF_PACKET socket with link level header, use:
fd=socket(PF_PACKET, SOCK_DGRAM, 0);
To create a PF_PACKET socket without link level header, use:

fd=socket(PF_PACKET, SOCK_RAW, 0);
Then use the standard socket read / write calls to send / receive data.
Driver Defaults
The following table shows the default values within the driver information files.
These files are located in either $ENV_PREFIX/sys/devices or
$ENV_PREFIX/sys/devices<bsp_name>.
To change the defaults, edit the file, compile it, and install TCP/IP support again.
For more information, see “Enabling/Disabling TCP/IP Support” on page 1.
Table 1-3: Default Values within Driver Information Files
Info File Platform Defaults Notes

All Mbufs (multiple of 4): 4096 This file contains info about memory
clusters=(1/4 of mbufs)1024
tcp_sendspace=16384
usage and other control args for the
tcp_receivespace=16384 TCP/IP stack. Please see the
udp_sendspace=16384 hbtcpip0(4) man page for
udp_receivespace=41984
cluster_size=2048 detailed information on configuration
hbtcpip_info.c
clshift_bits=11 options.
ipforwarding=1
tcprexmtthresh=3
tcp_mssdflt=512
tcp_keepintvl=150
tcp_do_rfc1323=0
tcpip_max_prio=255

Table 1-3: Default Values within Driver Information Files (Continued)
Info File Platform Defaults Notes

x86 None used TCP/IP driver for Intel 82235 Gigabit
Ethernet chip. Please refer to the
LynxOS Board Support Guide for
if_eminfo.c
PC/AT-compatible Systems for
detailed chipset information.
x86/ppc None used TCP/IP driver for Intel pro controller

(82557/82558/82559). Please refer to
if_fxpinfo.c the LynxOS Board Support Guide
for PC/AT-compatible Systems for
X86 None Used TCP/IP driver for Broadcom Ehternet
Controller. Please refer to the
if_bgeinfo.c LynxOS Board Support Guide for
x86 None Used TCP/IP driver for Realtek Ethernet
if_rlinfo.c
detailed chipset information
None Used TCP/IP for Marvell Ethernet

if_skinfo.c LynxOS Board Support Guide for
Radppc7d None Used TCP/IP driver for Marvell MV 64360
Discovery II. Please refer to the
if_gt_info.c
Curtiss None Used TCP/IP driver for GT-64460

Wright DY-4
183 Boards
Discovery III Ethernet GbE. Please
refer to the LynxOS Board Support
if_gt_info.c
Guide for PC/AT-compatible
Systems for detailed chipset
information.

Driver Defaults
Additional Device Drivers may be included with the LynxOS ODE or BSP
packages. Refer to the driver file or man page for additional tunable information.
NOTE: On the x86, if RAMBase is changed, make sure that the selected RAM area
lies within the supported address range by the Ethernet card (ideally, within a
0xC0000 to 0xDFFFF range). Also, be sure to use BIOS-SETUP (where
applicable) to disable the “Adaptor ROM shadow” for the RAM address range
used by the Ethernet card.
NOTE: In the hbtcpip_info.c file, the checksum calculation for UDP packets
can be enabled/disabled by setting the udpcksum filed to 1 (enable) or 0
(disable). Disabling the checksum increases the throughput for UDP packets.
For specific information on adding device drivers to a LynxOS system, please refer
to the LynxOS User’s Guide.
Additional information on creating device drivers is available in Writing Device
Drivers for LynxOS.


6
CHAPTER 2 Network Security
This chapter provides information about the following network security

components provided with LynxOS:
• IPFW
• IPsec
• OpenSSH
IPFW
IPFW is a legacy kernel-based utility that provides an alternative way to manage
packet filtering and counting. Using a set of user-defined rules, IPFW controls
whether or not network packets are forwarded or blocked. These user-defined
rules, also called a firewall chain (or rule chain), can block or allow specific
requests from specific hosts.
The user utility ipfw(8) is used as an interface to the IPFW kernel component.
ipfw can be set up to monitor both incoming and outgoing connections.
Enabling IPFW
IPFW is enabled with sysctl:
# sysctl -w net.inet.ip.fw.enable=1
NOTE: When enabled, IPFW leaves all ports open by default.

Chapter 2 - Network Security
Changing IPFW Rules

The ipfw user command is used to set the packet filter rules. Adding a rule with
the ipfw command updates the current firewall chain. The simplest usage syntax
is as follows:
# ipfw <command> <action> <protocol> <address> <options>
The following table defines each of the arguments for ipfw.
Table 2-1: Changing ipfw Rules
Option Command & Description
<command> add—Adds an entry to the firewall chain.
delete—Deletes an entry to the firewall chain.
<action> reject—Drops packet and sends ICMP host unreachable to source.
allow—Allows packet to pass.

deny—Drops packet and does not notify source.
count -- Update packet counter
<protocol> all—Sets rule for all protocols.

icmp—Sets rule for ICMP packets only.
tcp—Sets rule for TCP packets only.
udp—Sets rule for UDP packets only.
<address> Defines the IP address, mask, and (if required, port. Both From and To addresses can be
specified, as well as the interface used (eth0, for example):
from <address/mask>[<port>] to <address/mask>[<port>] \
[via <interface>]
Specific ports, or a range of ports can be set:

<port>, <port>, <port>
<port>-<port>

Listing IPFW Rules
Table 2-1: Changing ipfw Rules (Continued)
Option Command & Description
<options> via <if>—Packet must be going through interface <if>.

via <if*>—Packet must be going through interface <ifX>, where X is a unit number.
via <any>—Packet must be going through some interface.
via <ip>—Packet must be going through the interface with the IP address <ip>.
frag—Matches if the packet is a fragment.
in—Matches if packet is incoming.
out—Matches if packet is outgoing.
ipoptions <spec>—Matches if IP header contains options specified in <spec>.
established—Matches if the packet is part of an established TCP connection.
setup—Matches if the packet is attempting to setup a TCP connection (syn bit set, ack
not set).
tcpflags <flags>—Matches if the TCP header contains the flags specified

in <flags>. Supported flags include fin, syn, rst, psh, ack, and urg.
icmptypes <types>—Matches if the ICMP type is specified in <types>.
For example, to set up a rule to deny all incoming packets from the address
192.168.1.1 to the address 192.168.2.2 over TCP/IP, enter the following:
# ipfw add deny tcp from 192.168.1.1 to 192.168.2.2 in
To deny packets from the Ethernet port 1 to the telnet port (port 23) of 192.168.1.1,
the command is:
# ipfw add deny tcp from 192.168.1.1 to 192.168.2.2 23 \
via eth1
Listing IPFW Rules

The current set of IPFW rules is displayed with the list argument:
# ipfw list
Removing IPFW Rules

The flush argument to ipfw removes all rules currently set for packet filtering.
# ipfw flush

Clearing IPFW Counters

IPFW counters set up with the count option can be cleared with the zero
argument to ipfw:
# ipfw zero [<index>]
<index> affects only the counter at the index number specified. If <index> is
not used, all packet counters are cleared.
IPsec
IPsec is a security protocol in the IP layer that provides a secure means of
communications between two hosts. IPsec can create a tunnel between subnets
(tunnel mode) or provide security between two hosts directly (transport mode).
Hosts resolve the encryption keys and certification allowing for encrypted packets
to be exchanged. Security information can be exchanged manually or automated
with the racoon daemon. Only IPv4 is supported. IPv6 is not supported in this
version of LynxOS.
NOTE: The IPsec protocol for LynxOS is not included with the standard LynxOS
package. This components is available for purchase separately. For information on
this product, please contact your LynuxWorks sales representative.
IPsec policies are configured with the setkey(8) utility. See “Using setkey” on
page 29 for additional information.
AH and ESP Security Protocols

IPsec uses two security protocols:
• AH (Authentication Header)
AH contains hashes of data identification in the header, protecting the
source and destination addresses of the packet. A shared secret between
hosts ensure that packets are sent and received from the right system.
• ESP (Encapsulated Security Payload)
The ESP header allows for encryption or decryption of the packet by a
shared secret between hosts.

Tunnel Mode and Transport Mode
Tunnel Mode and Transport Mode

IPsec includes two modes of communicating packets:
• Tunneling—A connection between two systems on the same subnet.
Typically, IPsec is used in tunnel mode to establish a VPN. In tunnel
mode, IPsec encrypts the payload and encapsulates it in a packet before
sending it to the host.
• Transport—A connection between two systems, where the payload for
IPsec packets is encrypted. In transport mode, IPsec appends outgoing IP
packets with a security protocol header. The IPsec header is determined
by the original packet, and security information is included by the packet
header.
Setting the Security Policy Database

A Security Policy Database (SPD) is kept in the kernel that determines what
encryption algorithms should be used, the security protocol to use (AH or ESP),
and what packets to encrypt. The utility setkey(8) is used to modify the
policies kept in the SPD.
Setting the Security Association Database

The encryption keys used in secure transactions are kept in the kernel table called
the Security Association Database (SAD). The SAD contains the list of keys that
are required for secure communications. The SAD can be manually updated with
the setkey(8) utility. For hosts supporting Internet Key Exchange (IKE), the
SAD can be automatically updated with the racoon daemon.
Using setkey
The setkey utility, invoked with the -c option, reads commands from standard
input. Invoked with the -f option, setkey reads commands from a filename.
The syntax used with setkey is as follows:
# setkey -f <filename>
or:
# setkey -c
... <rules>
<Ctrl-C>

Using IPFW with IPsec

The ipfw syntax is as follows:
<command> <src_addr> <dest_addr> <protocol> <spi> \
[<extension>] <algorithm> [-P <policy>]
NOTE: If using IPsec behind a firewall, be sure to open any required ports required
by ESP. For UDP, for example:
# ipfw add pass esp from any to any
The following table describes the available commands and arguments.
Table 2-2: setkey Command Options and Descriptions
Option Commands and Descriptions
<command> add—Adds an SAD entry.
spdadd—Adds an SPD entry.
get—Shows an SAD entry.
delete—Removes an SAD entry.
flush <protocol>—Clears all SAD entries matching <protocol>.
dump <protocol>—Dumps all SAD entries matching <protocol>.
<src_addr> IP address of source system.
<dest_addr> IP address of destination system.
<protocol> esp—ESP based on RFC-2405.
esp-old—ESP based on RFC-1827.

ah—AH based on RFC-2402.
ah-old—AH based on RFC-1826.
ipcomp—IP COMP.
<spi> Security Parameter Index (SPI) for the SAD and SPD. A decimal or hexadecimal number.

Using IPFW with IPsec
Table 2-2: setkey Command Options and Descriptions (Continued)
Option Commands and Descriptions
[<extension>] -m <mode>—Specifies a security protocol mode for use. <mode> is one of following:
transport, tunnel, or any. The default value is any.
-r <size>—Specifies size of bytes for replay prevention.

<size> must be a 32-bit decimal number. If <size> is zero or not specified, replays are
not checked.
-u <id>—Specifies the identifier of the policy.
-f <pad_option>—where <pad_option> is one of following: zero-pad,

random-pad, or seq-pad.
-f nocyclic-seq—Doesn’t allow cyclic sequence numbers.
-lh <time>—Specifies hard lifetime.
-ls <time>—Specifies soft lifetime.
<algorithm> -E <ealgo key>—Specifies encryption algorithm.
-A <aalgo key>—Specifies authentication algorithm. If -A is used for ESP, it will be

treated as ESP payload authentication algorithm.
-C <calgo>—Specifies compression algorithm.
[-P <policy>] -P <direction> discard—Discards packet matching index.

<direction> is in or out.
-P <direction> none—Specifies IPsec not to operate on packet. <direction> is

in or out.
-P <direction> ipsec <protocol>/<mode>/<src>-<dst>/

<level>
—Specifies a Policy for IPsec to operate on a packet.
<protocol> is ah, esp, or ipcomp.
<mode> is transport or tunnel.
<src>-<dst> is the beginning and end point addresses used to specify the SAD.
<level> is default, use, or require. default means the kernel consults with
the system-wide default against the protocol specified when the kernel processes the packet.
use means that the kernel uses an SA if it’s available; otherwise the kernel operates
normally. require means SA is required whenever the kernel deals with the packet.
<direction> is in or out.
The following commands and files provide an example of using setkey for
updating the SAD and SPD kernel tables. The following instructions must be
completed for both systems using IPsec.
1. Flush the current SAD and SPD:
# setkey -F

2. Create a file that contains the policies for SAD. In the example file below,
two hosts (192.168.0.1 and 192.168.0.2) are enabled to use the 3des-cbc
encryption algorithm using ESP. The first two lines enable the source and
destination addresses; the last line updates the SPD table
For Host A, use the following:
# IPv4 ESP
# local system: 192.168.0.1
# remote system: 192.168.0.2
add 192.168.0.1 192.168.0.2 esp 1234 -E 3des-cbc “123456781234567812345678”;

add 192.168.0.2 192.168.0.1 esp 9999 -E 3des-cbc “123456781234567812345678”;
spdadd 192.168.0.1 192.168.0.2 any -P out ipsec esp/transport//use;
Figure 2-1: Sample Configuration File (hostA.sample.policies)
For Host B, use the following (note the spdadd change):
# IPv4 ESP
# local system: 192.168.0.1
# remote system: 192.168.0.2
add 192.168.0.1 192.168.0.2 esp 1234 -E 3des-cbc “123456781234567812345678”;

add 192.168.0.2 192.168.0.1 esp 9999 -E 3des-cbc “123456781234567812345678”;
spdadd 192.168.0.2 192.168.0.1 any -P out ipsec esp/transport//use;
Figure 2-2: Sample Configuration File (hostB.sample.policies)
3. Point setkey to the SAD file for each host:

- For Host A:
# setkey -f hostA.sample.policies
- For Host B:
# setkey -f hostB.sample.policies
setkey reads in the file and updates the SPD and SAD, as necessary.
Additional configuration details are available in the setkey(8) man page. Also,
refer to the racoon utility man page for information on automating the SAD
update.

OpenSSH
OpenSSH
OpenSSH (Open Secure Shell) is a set of computer programs that provide
encrypted communications over a computer network. It is an open version of the
SSH protocol suite of network connectivity tools and includes ssh, scp, sftp,
and sshd.
OpenSSH has two different sets of configuration files: one for client programs
(ssh, scp, and sftp) and one for the server daemon (sshd).
ssh daemon configuration

/etc/ssh/sshd_config is the system-wide configuration file for the sshd
daemon. It allows you to set options that modify the operation of the client
daemon.
Sample Configuration File

An example /etc/ssh/sshd_config configuration file follows.
#$OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $
# This is the sshd server system-wide configuration file.

# See sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config

# shipped with OpenSSH is to specify options with their default value
# where possible, but leave them commented. Uncommented options
# change a default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key
#HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile.ssh/authorized_keys
# For this to work you will also need host keys

# in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication

# (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
# and 'PermitEmptyPasswords'
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

ssh client configuration
# no default banner path

#Banner /some/path
# override default of no subsystems

Subsystemsftp/usr/libexec/sftp-server
Some of the options for the sshd_config configuration file are described below:
• AllowUsers
This option allows you to restrict login to specified users. By default,
login is allowed for all users.
• Port
Specifies the port number that sshd listens on. The default is 22.
• PasswordAuthentication
Specifies whether password authentication is allowed. The default is
yes.
• HostKey
Specifies a file containing a private host key used by SSH. The default is
/etc/ssh/ssh_host_key for protocol version 1 and
/etc/ssh/ssh_host_dsa_key for protocol version 2.
• X11Forwarding
Specifies whether X11 forwarding is permitted. The argument must be
yes or no. The default is yes.
ssh client configuration

/etc/ssh/ssh_config is the system-wide default SSH client configuration file.
It allows you to set options that modify the operation of the client programs.
It can be overridden by a local configuration file in the user’s home directory
(~/.ssh/config).
Sample Configuration File

An example /etc/ssh/ssh_config configuration file follows.
#$OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $
# This is the ssh client system-wide configuration file. See

# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files

# or on the command line.
# Configuration data is parsed as follows:

# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.

# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for various options
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128cbc,
# arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
Some of the options for the ssh_config configuration file are described below:
• Host *
The option Host restricts all forwarded declarations and options in the
configuration file to be only for those hosts that match one of the patterns
given after the keyword. The pattern * means for all hosts up to the next
Host keyword. With this option, you can set different declarations for
different hosts in the same ssh_config file.
• ForwardAgent no
The option ForwardAgent specifies which connection authentication
agent, if any, should be forwarded to the remote machine.
• UseRsh no
The option UseRsh specifies that rlogin/rsh services should be
used on this host. It must always be set to no because the rsh service
is insecure.
• IdentityFile ~/.ssh/identity

hosts.allow and hosts.deny files
The option IdentityFile specifies an alternate RSA authentication

identity file to read. Also, multiple identity files may be specified in the
configuration file ssh_config.
• Port 22
The option Port specifies on which port number ssh connects to on
the remote host. The default port is 22.
Additional configuration details are available in the sshd_config(5) and
ssh_config(5) man pages. Also, refer to the OpenSSH website:
http://www.OpenSSH.org.
hosts.allow and hosts.deny files

For access control rules, tcpd first searches the /etc/hosts.allow file,
followed by the /etc/hosts.deny file, and stops at the first match that it finds.
These files have a simple format:
servicename: hosts
The recommended setting is to deny anything that is not explicitly allowed. This is
done by adding the following line to /etc/hosts.deny:
ALL:ALL
Then, explicitly list in the /etc/hosts.allow file all the hosts and domains that
are allowed access. For example:
ALL: send mail
ALL: lnxw.com, LOCAL.
This allows everyone to connect to sendmail, all hosts in the lnxw domain, as well
as all local traffic.


CHAPTER 3 DHCP
Dynamic Host Configuration Protocol (DHCP) enables systems to request network

configuration information (IP address, local name servers, and routers) from a
DHCP server. This chapter details DHCP concepts, installation, and configuration.
Introduction
DHCP enables individual clients on an IP network to receive network
configurations from a DHCP server. The DHCP server provides predefined
network configuration information dynamically, including client IP addresses,
name servers, and routers. DHCP reduces the amount of overhead in administering
a large IP network by freeing the system administrator from having to reconfigure
each system individually.
DHCP also enables the storage and distribution of network parameters for clients
and groups. Additionally, DHCP allows for recovery and reallocation of these
network addresses through a leasing mechanism. Client network configurations
expire after a designated period of time, after which the client system’s network
configuration is either renewed or reissued from the DHCP server. Another feature
of this protocol is that it can be routed. DHCP support consists of a server daemon,
client utility, a relay daemon, and a diagnostic utility and a set of configuration
database files. DHCP support requires TCP/IP.

Chapter 3 - DHCP
LynxOS DHCP Components

LynxOS uses the ISC (Internet Software Consortium) Open Source DHCP version
2.0 distribution. DHCP consists of two software components:
• DHCP server
• DHCP client
The DHCP client sends a request to a DHCP server, which responds with particular
network parameters for the client to use. The following sections describe DHCP
files and configurations.
LynxOS DHCP Files

This table details the various configuration files used to configure a LynxOS
system for DHCP.
Table A-1: LynxOS DHCP Files
/bin/dhclient DHCP client configuration binary

/etc/dhcpd.conf DHCP configuration file
/etc/dhcpd.leases DHCP lease configuration file
/etc/dhclient-script DHCP client configuration script
/net/dhcpd DHCP daemon
/net/dhcrelay DHCP relay agent
DHCP Man Pages

Additional DHCP configuration information is available in these man pages:
Table A-2: DHCP Man Pages
man page Description
dhcpd(1) The DHCP server

dhcpd.conf(5) The DHCP server configuration file
dhcp-options(1) DHCP option statements

Online Resources
Table A-2: DHCP Man Pages (Continued)
man page Description
dhclient(1) DHCP client for LynxOS

dhclient.conf(5) DHCP client for LynxOS config file
dhrelay(1) DHCP relay agent
dhclient.leases(5) DHCP lease file
Online Resources
Additional information on DHCP is available at the ISC web page:
http://www.isc.org
Installing DHCP
DHCP is included with the LynxOS base product and is installed by default.
Configuring DHCP is explained in the following sections.
The DHCP Server

The DHCP server responds to requests from DHCP clients with network
configuration information. DHCP server components include: dhcpd and
dhcpd.conf.
dhcpd
The DHCP server daemon (dhcpd) serves DHCP client requests based on the
configuration file dhcpd.conf. The server also monitors the lease details of the
client IP addresses, facilitating the recovery and reallocation of IP addresses
through predefined lease agreements. Additionally, the server also services BOOTP
clients. The DHCP server maintains all current client configurations in the
dhcpd.leases file. For more information on dhcpd.leases, see
“dhcpd.leases” on page 43.

Chapter 3 - DHCP
By default, dhcpd uses UDP port 67 to receive and UDP port 68 to send DHCP
information.
NOTE: It is recommended that the DCHP server be incorporated into system

startup scripts to automate this functionality (for example, adding a line executing
dhcpd in /etc/rc.network).
dhcpd.conf
The DHCP configuration file, dhcpd.conf, must be created by hand. This
configuration file sets specific network topologies and parameters the DHCP
server uses to assign IP addresses, name servers, and routers to clients. In addition
to a range of available IP addresses, dhcp.conf must provide the IP address
subnet mask and at least one router and name server on the network.
Network topology declarations include the shared-network and subnet
declarations. Dynamically assigned addresses must include the range declaration
with a subnet declaration. DHCP options are declared per subnet. lease
durations are expressed in seconds.
The following is an example of a dhcpd.conf file:
# shared-network
subnet 192.168.11.0 netmask 255.255.255.0 {
range 192.168.11.1 192.168.11.251;
option routers 192.168.11.254;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.11.253;
# default lease time=30 Days
default-lease-time 2592000;
# max lease time=45 Days
max-lease-time 3888000;
}
Figure 3-1: example dhcpd.conf file
Additional information on specific options in configuring dhcpd.conf can be

found in the dhcpd.conf(5) man page.
After editing the dhcpd.conf file, restart the DHCP daemon:
1. Find the Process ID (PID) of the DHCP daemon (dhcpd) with the
following command:
# ps -axon | grep dhcpd

dhcpd.leases
2. Use the kill command to stop the process.

# kill <PID>
3. Restart the DHCP daemon:
# /net/dhcpd
NOTE: x86 systems that netboot LynxOS use RARP and TFTP. PXE-compatible
devices, however, must use DHCP.
NOTE: PPP server and client IP address allocation are not integrated with DHCP
and continue to work independently.
NOTE: Dynamic DNS update is not currently supported.
dhcpd.leases
dhcpd.leases is a generated file that contains lease expirations for client
network configurations. The DHCP server maintains up-to-date information on
client leases in this file. In the event of a system reboot, the DHCP server can
resume all current connections without having to reconfigure each client on the
network. This file should not be edited.
Relay Agents
Relay agents allow a DHCP server to configure systems on more than one network
segment. Relay agents forward DHCP requests from clients to the DHCP server,
allowing a single DHCP server to serve multiple clients in multiple network
segments. Using relay agents provides flexibility in configuring a DHCP network.
The DHCP Client
dhclient
The DHCP client (dhclient) sends requests to a DHCP server for network
configuration information. The primary information sought from the server is the
client IP address. The IP address is issued for a specific “lease” period, varying

Chapter 3 - DHCP
between a few hours up to a year. Initially, dhclient broadcasts DHCP requests

using the UDP protocol over a chosen network interface (passed as an argument) to
the DHCP server.
Once it establishes contact with the server, the network configuration is applied to
the client. The client network configuration is valid until the lease period expires,
after which, the client attempts to renew the lease or to obtain a lease on new
network configurations. After configuring the client, the dhclient script
becomes a background process to continue to contact the DHCP server.
While configuring a netbooted client to use bootp and DHCP, choose the
DHCP option in the scripts. If not, the traditional RARP is used to netboot the
client.
In addition, online man pages contain detailed information.
Starting dhclient
Start the dhclient script by entering:
# dhclient
NOTE: It is recommended that dhclient be incorporated into system startup

scripts to automate this functionality; for example, adding a line executing
dhclient in /net/rc/network.

CHAPTER 4 NFS
During initial installation of LynxOS, NFS client support is disabled by default.

NFS, however, can also be configured, installed, or removed at any time after
initial installation. Note that NFS requires TCP/IP to function. This section
describes NFS basics, as well as advanced NFS configuration options.
Overview
NFS is a suite of user programs and kernel functionality that allow access to a
remote host’s file systems as if they were local. All or part of a remote host’s file
system is mounted into the local host’s file system, allowing transparent access to
remote files by local users. Once mounted, any file on the remote file system is
accessible. Such files can be operated on by most utilities, functioning no
differently than a file located on the local disk.
When attempting to access a file in an NFS-mounted directory, the NFS client
sends a request to the NFS server on the remote system. The NFS server accepts
and manages these requests from the remote NFS client for access to the local disk.
The server enforces permissions and performs the actual manipulations to the local
disk.
LynxOS supports the NFSv2 protocol. NFS software is divided into two parts
• NFS server
• NFS client
When attempting to access a file in an NFS-mounted directory, the NFS client
sends a request to the NFS server on the remote system. The NFS server accepts
and manages these requests from the remote NFS client for access to the local disk.
The server performs the actual manipulations to the local disk.

Chapter 4 - NFS
Enabling NFS Support
Enabling/Disabling NFS Server Support

In LynxOS, NFS server is disabled by default.
To enable NFS server support, make sure that the line for NFS in config.tbl
reads as follows:
I:nfssvc.cfg
To disable NFS server support, make sure that the line for NFS in config.tbl
reads as follows:
#I:nfssvc.cfg
Enabling/Disabling NFS Client Support

In LynxOS, NFS client support is disabled by default.
To enable NFS client support, make sure that the lines for NFS in the
config.tbl file read as follows:
#I:nullnfs.cfg
I:nfs.cfg
To disable NFS support, make sure that the lines for NFS in the config.tbl file
read as follows:
I:nullnfs.cfg
#I:nfs.cfg
NFS Server
Configuring the NFS Server

The only file that must be modified to allow other systems to access data on the
system is /etc/exports. This file is a database used by the NFS server to
determine if the requesting host is authorized to share the system’s data. The syntax
for each entry is as follows:
<directory> [option] [,option]...

Configuring the NFS Server
The first field is the directory that is to be exported. If no options are given, any
host may mount this directory and access the files for reading and writing.
Access to the directory may be given only to specific hosts. In the following
example, the directory /mydata is exported for access by hosts shark and
orca.
/mydata access=shark:orca
Permission to access an NFS-mounted directory as root must be explicitly
declared. An attempt by a remote system to write to an NFS-mounted directory as
root fails, even if the directory is mounted read/write. To allow the remote
system orca to have root access to the directory /mydata, the following line
should be added to /etc/exports:
/mydata root=orca
All directories are exported as read/write unless otherwise specified. The -ro flag
is used to export a directory as read-only to everyone. The -rw flag is used to
export a directory as read/write to specific users; all other users have read-only
access. In the following example, /mydata is exported read-only.
/mydata ro
To restrict the read/write access of /mydata to only the hosts shark and orca,
but allow read-only access to everyone else, the following entry would be added to
/etc/exports:
/mydata rw=shark:orca
Any of the previous examples may be grouped, giving multiple accesses:
/mydata access=shark:orca:fish,root=shark,rw=shark:orca
In the above example, access of the exported directory is limited to hosts shark,
orca, and fish. Only users with root access on shark have root access to the
exported directory, and only users on shark and orca have read/write
capabilities. Users on fish can access the files only in a read-only state.
Please note that no space is allowed in the option string. The portion after the space
is ignored should a space be present in an option string. In the example above, no
space is expected between the comma and "root".

Chapter 4 - NFS
Tuning the NFS Server Kernel

The NFS server is tuned by increasing or decreasing the values of five parameters.
These parameters are in the structure nfssvc_info located in
/sys/devices/nfssvc_info.c.
To change any of these parameters, edit the file

/sys/devices/nfssvc_info.c. After editing, the device library must be
updated and the kernel rebuilt.
NOTE: The /etc/exports file specifies the directories to be exported and the
corresponding access list.
NFS Server Tunable Parameters

Tunable parameters include:
• The maximum number of directories that can be exported.
The default is 16. If the system is used as a file server, this parameter may
need to be increased.
• The maximum number of hosts that can be specified in the access list of
an exported directory.
The default is 16.
• The maximum number of hosts that can be specified with root access
for an exported directory.
The default is 16. For security reasons, this parameter can be decreased.
• The maximum number of hosts that can be specified with read and write
access for an exported directory.
The default is 16. For security reasons, this parameter can be decreased.
• The maximum number of NFS server daemons that can be started at any
time.
The default is 8. If the system is used as a file server, multiple daemons
should be started. This is done by adding a count parameter to the line
/net/nfsd in /net/rc.network. For example, to start three NFS
server daemons, modify the line to read as follows:
/net/nfsd 3

Exporting/Unexporting Directories
Exporting/Unexporting Directories
To export or unexport directories, use the exportfs utility. exportfs -a is
used to export directories, and exportfs -ua is used to unexport directories.
Starting/Stopping the NFS Server

The binary image for the NFS server is nfsd. It is usually located in the /net
directory. The usage of nfsd is as follows:
nfsd <server_count>
The server_count specifies the number of NFS servers to run.
To stop the server, send the KILL signal to the server:
kill -KILL <nfsd_pid>

Chapter 4 - NFS

CHAPTER 5 Multicasting
Overview
Multicasting typically refers to IP Multicasting, which is a protocol for delivering
the same data to large numbers of clients on a TCP/IP network while minimizing
network traffic and bandwidth. It is different from unicasting which requires
sending a copy of the data from the sender to each recipient, as shown in the
following diagram.
Figure 5-1: Unicasting
In multicasting, the sender transmits the data only once, regardless of the number
of recipients. Whenever this stream of data traverses a multicast-enabled switch or
router, it is simply copied, but only to branches of the network where clients who

Chapter 5 - Multicasting
have requested the data are located. This dramatically reduces overall bandwidth
consumption, as illustrated in the following diagram.
Figure 5-2: Multicasting
Addressing
When a sender (host) initiates an IP multicast, it assigns to it an IP address in the
range 224.0.0.0 to 239.255.255.255. The assigned address will define a multicast
host group, and end users (other hosts) can tune in or out of the group at any time.
The receiving host translates the IP multicast address to its hardware Ethernet
(MAC) address in order to identify and receive a multicast. The following figure
shows the mapping between an IPv4 multicast address and an Ethernet multicast
address.

Registration
e Multicast Address IP Address
23 bits
copied
01 00 5e Multicast Address Ethernet Address
Figure 5-3: Address Mapping
The range of IPv4 multicast addresses is 224.0.0.0 to 239.255.255.255.

Some IPv4 multicast addresses have special meanings as described in the
following table.
Table 5-1: Special IPv4 Multicast Addresses
Address Description
224.0.0.1 The all-hosts group. All multicast interfaces of all multicast-

capable hosts must join this group.
224.0.0.2 The all-routers group. All multicast interfaces of all multicast
routers must join this group.
Registration
Registration is a method for letting the network know that any given host wants to
be a part of a multicast group. Registration is accomplished using the Internet
Group Management Protocol (IGMP), which is described in the next section.
IGMP
IGMP allows an IPv4 host to report its multicast group membership to a
multicasting router. The following sections describe the host behavior of IGMP.

IGMP version 3
The new feature added to IGMPv3 is the support for source filtering, a feature that
allows a host to receive from a list of specific source nodes, or from all but specific
addresses, after joining a multicast group.
IGMPv1 and IGMPv2

Since IGMPv3 was designed to interoperate with Version 1 and Version 2,
applications written for IGMPv1 and IGMPv2 are supported on LynxOS.
Socket options
All the behaviors are controllable through calls to setsockopt(). The following
table describes socket options.
Table 5-2: Socket Options
Version
Option Name Datatypes Available Description
In
IP_ADD_MEMBERSHIP struct ip_mreq All Allows calling thread to join a
multicast group.
IP_DROP_MEMBERSHIP struct All Allows calling thread to leave a
ip_mgreq
multicast group.
IP_BLOCK_SOURCE struct New in IG Specifies an address from which
ip_mreq_source
MPV3 multicast group will not receive
(blacklist).
IP_UNBLOCK_SOURCE struct New in Reverses the effect of
ip_mreq_source
IGMPV3 IP_BLOCK_SOURCE.
IP_ADD_SOURCE_MEMBERSHIP struct New in Specifies an address from which
ip_mreq_source
IGMPV3 multicast group will receive
(whitelist).
IP_DROP_SOURCE_MEMBERSHIP struct New in Reverses the effect of
ip_mreq_source
IGMPV3 IP_DROP_SOURCE_MEMBERSHIP.

Socket options
The data structures are contained in header file

$ENV_PREFIX/usr/include/bsd/in.h:
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_interface; /* IP address of interface */
};
struct ip_mreq_source {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_sourceaddr; /* IP address of source */
struct in_addr imr_interface; /* IP address of interface */
};
Socket options that are prefixed with MCAST_ rather than IP_ serve the same
purpose, but they take different data structures as arguments:
Table 5-3: Socket Options Prefixed with MCAST_
Version
Option Name Datatypes Available Description
In
MCAST_JOIN_GROUP struct group_req New in Same as IP_ADD_MEMBERSHIP
IGMPV3
MCAST_DROP_GROUP struct group_req New in Same as
IGMPV3 IP_DROP_MEMBERSHIP
MCAST_BLOCK_SOURCE struct New in Same as IP_BLOCK_SOURCE
group_source_req
IGMPV3
MCAST_UNBLOCK_SOURCE struct New in Same as IP_UNBLOCK_SOURCE
group_source_req
IGMPV3
The data structures are as follows:
struct group_req {
uint32_t gr_interface; /* interface index */
struct sockaddr_storage gr_group; /* group address */
};
struct group_source_req {
uint32_t gsr_interface; /* interface index */
struct sockaddr_storage gsr_group; /* group address */
struct sockaddr_storage gsr_source; /* source address */
};

sysctl() variables
The following table shows the sysctl variables that control the behavior of IGMP
on the system.
Table 5-4: Sysctrl Variables for IGMP
Variable name Acceptable range Description

net.inet.igmp.always_v3 0 (false) or 1 (true). Default is 0. If 0, the system will maintain
“Host compatibility mode”
by responding to IGMPv2
and IGMPv1 queries per the
RFC requirement.
If 1, the system will respond

to IGMPv3 query only.
Recommend to set to 0 if
connected to multicast router
that supports older version of
IGMP.
net.inet.igmp.somaxsrc Default is 64. No hard upper limit. Specifies the maximum
number of source addresses
per multicast group allowed
per opened socket.
net.inet.igmp.maxsrcfilter Default is 128. Must be larger than Specifies the maximum
net.inet.igmp.maxsrcfilter. number of source addresses
No hard upper limit. per multicast group the
kernel can keep.

netstat output
netstat output
Users can use the network utility netstat to get a glimpse of the number of
IGMP packets received and sent on the system, as shown in the following figure.
[LynxOS-500: /] $ netstat -p igmp

igmp:
0 messages received
0 messages received with too few bytes
0 messages received over MTU size
0 messages received with bad checksum
0 membership queries received with invalid field(s)
0 messages received with no router alert
0 v1 membership queries received
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 v1/v2 membership reports sent
0 v3 membership reports sent


CHAPTER 6 Traffic Management and Quality
of Service
The networking stack has a face-lift in the latest version of LynxOS: based on the
latest FreeBSD 4.11, which is known for its performance and stability, and the
KAME patch, which has a long history of providing extended network capabilities,
the new stack offers the latest networking technology without sacrificing the real-
time responsiveness.
Layer 2 (Ethernet)
This section describes the Traffic Management concepts at the Ethernet layer.
Bridging
A bridge is a Layer 2 device that connects two or more networks. Two bridged
network segments would appear to be one segment to the network nodes on either
segment.
An interface that has been bridged may or may not possess an IP address.
802.1 Standards
This version of LynxOS supports the following IEEE standards:
• 802.1D – MAC bridges.
• 802.1Q – VLAN support

Chapter 6 - Traffic Management and Quality of Service
Spanning Tree
With the spanning tree algorithm, bridges can discover dynamically a loop-free
topology so that any pair of connected LANs can reach each other. The spanning
tree protocol is supported in LynxOS, and the user can configure it using the utility
brconfig.
An interface needs to be bought up before it can be used in a bridge. Execute the

following on a system with 3 em instances, if necessary:
$ ifconfig em0 up; ifconfig em1 up; ifconfig em2 up
brconfig operates on a pseudo network device called bridge0. The following
figure shows an example configuration script for bridge0.
#
# adds 3 interfaces to bridge0
brconfig bridge0 add em0 add em1 add em2
#
# enable STP on each bridged interface
brconfig bridge0 stp em0 stp em1 stp 3m2
#
# bring up the bridge
brconfig bridge0 up
Figure 6-1: Example configuration script for bridge0
The following figure shows an example output of brconfig –a after the

commands listed above are executed.
bridge0: flags=41<UP,RUNNING>
Configuration:
priority 32768 hellotime 2 fwddelay 15 maxage 20
Interfaces:
em0 flags=7<LEARNING,DISCOVER, STP>
port 6 priority 128 path cost 55 disabled
Address cache (max cache: 100, timeout: 300):
Figure 6-2: Example output of brconfig -a

Forwarding Cache Management
Forwarding Cache Management

If a bridge sees a packet with an unknown MAC address, it will flood to all ports in
the bridge except where the packet comes from—this is called flooding. If the
learning is enabled on the interface on which the packet is received, the bridge
keeps a quartet for each MAC address it sees, as shown below.
<MAC_address> <interface_name> <time_to_live> <flag>
<MAC_address> is the source MAC address of the packet.

<interface_name> is the receiving interface.
<time_to_live> is the number of seconds remaining until the entry expires (and
gets purged). If the entry is static (permanent), <time_to_live> is irrelevant.
If flag is 0, the entry is dynamic and will expire; if its value is 1, the entry is static
and permanent
• <flag> : 0x00—Dynamic address
• <flag> : 0x01—Static address
By default, learning is enabled on any bridged interface. To enable MAC-learning
on an interface explicitly, enter the following command:
> brconfig bridge0 learn em1
To disable MAC-learning on an interface, enter the following command:
> brconfig bridge0 –learn em1
To add a static entry 00:00:00:0a:0b:0c to the interface em0 of the bridge,
enter the following command:
> brconfig bridge0 static em0 0:0:0:a:b:c
To clean out all dynamically learned addresses of a bridge, enter the following
command:
> brconfig bridge0 flush
To clean out the forwarding cache of a bridge (dynamic and static), enter the
following command:
> brconfig bridge0 flushall

VLAN
Virtual Local Area Network (VLAN) is a way to segregate a network into
segments.
The following figure shows the layout of the 16-bit VLAN identifier.
3 bits 1 bit 12 bits
User CFI VID to identify a VLAN

Priority
Figure 6-3: Layout of the 16bit VLAN identifier
Each VLAN device must be associated with a VLAN ID and a physical network
device (most probably an Ethernet interface) to be operational. By default the
number of virtual VLAN interfaces is 3 (tcpip/include/vlan.h)
For example:
fconfig vlan0 vlan 100 vlandev fxp0
ifconfig vlan1 vlan 200 vlandev fxp0
ifconfig vlan2 vlan 300 vlandev fxp0
fxp0 will be able to recieve traffic belonging to VLAN ID 100, 200 and 300. In
order to do this the following command should be performed:
$ ifconfig fxp0 172.17.0.19
$ ifconfig vlan0 vlan 100 vlandev fxp0
$ ifconfig vlan0 172.18.0.1
You will see the VLAN configuration output as follows:

$ ifconfig
lo0: flags=8008<LOOPBACK,MULTICAST> mtu 16384
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496
inet 172.18.0.1 netmask 0xffff0000 broadcast 172.18.255.255
ether 00:d0:b7:b0:06:fb
media: Ethernet 100baseTX (100baseFX <full-duplex>)
supported media:
media 100baseTX
vlan: 100 802.1p: 0 CFI: 0 parent interface: fxp0

Layer 3 (IP)

supported media:
media 100baseTX

supported media:
media 100baseTX
bridge0: flags=0<> mtu 1500
ether ac:de:48:b2:40:3f
vlan: 0 802.1p: 0 CFI: 0 parent interface: <none>
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
supported media:
media 100baseTX mediaopt full-duplex
media 100baseTX mediaopt half-duplex
media 100baseTX
media 10baseT/UTP mediaopt half-duplex
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP
Optionally, the user may specify the priority bit and the CFI bit for a given VLAN.
$ ifconfig vlan0 vlan 100 vlandev fxp0 vlanpri 6 vlancfi 0
The following example shows how to disassociate a network interface from a
VLAN.
$ ifconfig vlan0 vlan 100 –vlandev fxp0
Layer 3 (IP)
One of the major features offered by the new stack is the support for Differentiated
Service Code Point (DSCP) of the Quality of Service (QoS) infrastructure.
Multiple queues are introduced to the network interface module of the network
stack to form a basis of QoS. A new utility daemon called altqd is introduced to
configure the queuing disciplines and associated parameters of the network
interfaces. Class-based queuing and random early drop, among other disciplines,
can be configured through altqd. altqd also gathers queuing-related statistics.
Users can classify packets into different priorities by source IP addresses and ports,
by destination IP addresses and ports, and by protocols.
The other aspect of QoS is the capability to shape traffic by the use of a rate-
limiter. The token bucket algorithm is used to realize a rate-limiter for any QoS-

enabled network interface. Parameters such as bucket size and token-refilling rate
can be tuned for various scenarios.
The QoS infrastructure is constructed with network driver compatibility in mind.
The existing network driver written for previous LynxOS release can be ported to
LynxOS 5.0 with minimal changes, attributed to the highly compatible set of
function interfaces to the kernel.
Explicit Congestion Notification

The principle function of Explicit Congestion Notification (ECN) is to indicate
congestion explicitly in the IP header, rather than relying passively on the TCP
layer to detect congestion in the manner of packet drop or packet retransmission.
This version of LynxOS supports ECN-capable TCP, the benefits of which are high
throughput and low delay during network congestion.
ECN is a 2-bit subfield in the Type of service field in the IP header, as shown
in the following figure.
0 1 2 3 4 5 6 7
(other use) ECN Field
Figure 6-4: ECN: Explicit Congestion Notification

IP QoS
For reference, the following figure shows a depiction of the IP header.

0 16 31
version ihl type of service total length

identification flags fragment offset
time to live protocol header checksum
source address
destination address
Figure 6-5: IP Header
The transport mechanism of LynxOS is already ECN-capable, and there is no

configuration needed. In addition to the transport layer, the user may use the ECN
keyword in ALTQ daemon configuration to set up additional triggers to turn the
ECN bit on. The ALTQ mechanism is described in detail in the next section.
The netstat command keeps track of TCP-ECN statistics. To view the
statistics, type the following command:
# netstat –p tcp
For more details, refer to RFC-3168, The Addition of Explicit Congestion
Notification (ECN) to IP.
IP QoS
LynxOS makes use of the ALTQ mechanism to implement IP QoS. The following
sections describe the theory of operations and details of configuration.
[The following is an adaptation of documentation accompanied by the KAME
project and FreeBSD.]

QoS concepts
Queuing Disciplines
A queuing discipline controls outgoing traffic by packet scheduling and/or queue
buffer management. CBQ is the most well engineered among the implemented
disciplines.
Token-bucket Regulator
A token-bucket regulator is used to control the behavior of a network device driver.
Most ALTQ users do not need to tune the token-bucket regulator, but if you want to
rate-limit the interface or minimize the delay, here is how to tune the token-bucket
regulator.
In order to separate the effect of a token-bucket regulator from that of a queuing
discipline, it is recommended to tune the token-bucket regulator first with FIFOQ
and then to use the resulting setting for other queuing disciplines.
The utility to tune token-bucket regulator is called tbrconfig.
The purpose of a token-bucket regulator is to limit the amount of packets that a
driver can dequeue. A token bucket has token rate and bucket size. Tokens
accumulate in a bucket at the average token rate up to the bucket size. A driver can
dequeue a packet as long as there are positive tokens, and after a packet is
dequeued, the size of the packet is subtracted from the tokens. Note that this
implementation allows the token to be negative as a deficit in order to make a
decision without prior knowledge of the packet size. It differs from a typical token
bucket that compares the packet size with the remaining tokens beforehand.
The bucket size controls the amount of burst that can be dequeued at a time and
controls a greedy device trying dequeue packets as much as possible. This is the
primary purpose of the token-bucket regulator, and, thus, the token rate should be
set to the actual maximum transmission rate of the interface.
On the other hand, if the rate is set to a smaller value than the actual transmission
rate, the token bucket regulator becomes a shaper that limits the long-term output
rate. Another important point is that, when the rate is set to the actual transmission
rate or higher, transmission complete interrupts can trigger the next dequeue.
However, if the token rate is smaller than the actual transmission rate, the rate limit
would be still in effect at the time of transmission complete interrupt, and the rate
limiting falls back to the kernel timer to trigger the next dequeue. In order to
achieve the target rate under timer-driven rate limiting, the bucket size should be
increased to fill the timer interval.

Interface Rate-Limiting
Interface Rate-Limiting
Simple Rate-limiting by tbrconf

If you want to limit the outgoing bandwidth of an interface, but you don’t need a
queuing discipline, you can set up a token-bucket regulator without any queuing
discipline by using tbrconfig.
For example, to limit the outgoing traffic of em0 up to 30 Mbps, enter the
following:
# tbrconfig em0 30M auto
fxp0: tokenrate 30.00M(bps) bucketsize 36.62K(bytes)
The auto keyword is used to automatically calculate the required bucket size. In
the above example, 36.62 KB is selected. The following formula is used to
compute the bucket size:
bucket_size = desired_rate(in bps) / 8 /
kernel_timer_frequency;
The computed bucket size is conservative in the sense that it is large enough to be
able to satisfy the specified rate only by the kernel timer events. In many cases, one
half of the computed size is still able to achieve the rate.
To remove the installed token-bucket regulator, enter the following:
# tbrconfig -d em0
deleted token bucket regulator on fxp0
Interface Rate-limiting with a Queuing Discipline

By default, altqd selects a small bucket size for nonrate-limiting operations. If
you want to use a queuing discipline with interface rate-limiting, you need to
explicitly specify the bucket size with tbrsize in the interface command of
altq.conf. bandwidth specifies the token rate, and tbrsize specifies the
bucket size.
The following FIFOQ setting has an effect similar to the previous example for
tbrconfig.
[altq.conf]
interface em0 bandwidth 30M tbrsize 36K fifoq
It is recommended to tune the bucket size with FIFOQ and then use the resulting
size for other queuing disciplines.

Note that if a token-bucket regulator is already installed on the interface when

altqd is started, altqd does not install a new token-bucket regulator (that is,
the existing setting is respected).
CBQ
CBQ Configuration File

Most of the CBQ parameters are automatically set by the system unless they are
explicitly specified in the configuration file.
Basic commands
Though there are many commands and options, most likely you just need to use the
commands and their corresponding options listed in the following table.
Table 6-1: Examples of Basic CBQ commands
Command interface if_name [bandwidth bps] cbq
Example interface em0 bandwidth 10M cbq
Command class cbq if_name class_name parent [borrow] [pbandwidth percent] [red]
[default|control]
Example class cbq em0 my_ftp tcp_class borrow pbandwidth 30 red
Command filter if_name class_name dst_addr dst_port src_addr src_port proto
Example filter em0 my_ftp 133.138.1.83 0 0 20 6
The interface command sets up the interface; one can specify the interface
bandwidth in bits per second.
The class command creates a class. Set the bandwidth of the class with 81
pbandwidth as the percent of the interface bandwidth.
Set borrow when the class can borrow bandwidth from its parent class. Set red
if you use random early detection (RED) dropper (good for TCP).
The filter command sets a packet filter to a class. A basic filter has the
following syntax (all fields are numeric):
dst_addr dst_port src_addr src_port proto
Table 6-2: Filter syntax

CBQ
NOTE: dst comes first. Use the value 0 if you don't care about the field.
Filter-Matching Rule
The CBQ (and HFSC/PRIQ) classifier performs filter matching for every packet.
The classifier goes through the filters starting from the last entry in the
configuration file, which means you have to list a more generic filter first in the
configuration file.
For example, two filters, one for all TCP and the other for HTTP, should be listed
in the following order:
filter em0 TCP_class 0 0 0 0 6

filter em0 HTTP_class 0 0 0 80 6
If the order is reversed, all HTTP packets match TCP_class first. In other words,
the HTTP filter is a “subset” of the TCP filter. All packets matched by the HTTP
filter are matched by the TCP filter.
On the other hand, if two filters have different values in the same field, there’s no
packet to match both filters. Such two filters are “disjointed.” For example, a
packet has a single source port number and never matches both of the following
filters:
filter em0 TELNET_class 0 0 0 23 6

Another filter relationship is “intersecting.” If two filters have a shared region

(intersection) but they are not a subset of each other, the order of applying the
filters is very important.
For example, a filter by the destination address and a filter by the source port.
HTTP Packets to 133.138.1.83 match both filters.
filter em0 my_class 133.138.1.83 0 0 0 6

It is recommended to avoid the use of “intersecting” filters.

The last filter relationship is a special case of “intersecting” called “port
intersecting.” This occurs when two filters have the following relation:
• Intersection is only port numbers.

• One specifies src port, and the other specifies dst port.
The well-known ports are used by the system processes, and there must be no
packet with well known port numbers in both src and dst ports. As a consequence,
this special “intersection” must be handled differently. For example:
filter em0 TELNET_class 0 23 0 0 6

The altqd configuration file parser will

• Provide an error message and exit when a “subset” filter has a wrong
order.
• Provide a warning message when an “intersecting” filter is detected. This
can be suppressed with keyword dontwarn.
Sample Setting Using CBQ

The following graph shows a sample class hierarchy in which traffic is divided into
three metaclasses (bulk, interactive, misc). The metaclasses are defined in order to
control hierarchical distribution of the available bandwidth under congestion.
Filters are set only to the leaf classes.
(100%)
root
(95%)
def_class
(30%) (30%) (30%)

bulk misc intr
tcp ftp http udp dns telnet ctl_class

(10%) (10%) (10%) (10%) (10%) (10%) (4%)
Figure 6-6: Sample Class Hierarchy

CBQ
The figure below shows a sample altq.conf configuration file.
1 #
2 # sample configuration file for 1Mbps link
3 #
4 interface sr0 bandwidth 1M cbq
5 class cbq sr0 root NULL pbandwidth 100
6 #
7 # meta classes
8 #
9 class cbq sr0 ctl_class root pbandwidth 4 control
10 class cbq sr0 def_class root borrow pbandwidth 95 default
11 #
12 class cbq sr0 bulk def_class borrow pbandwidth 30
13 class cbq sr0 misc def_class borrow pbandwidth 30
14 class cbq sr0 intr def_class borrow pbandwidth 30
15
16 #
17 # leaf classes
18 #
19
20 #
21 # bulk data classes
22 #
23 class cbq sr0 tcp bulk borrow pbandwidth 10 red
24 filter sr0 tcp 0 0 0 0 6# other tcp
25 class cbq sr0 ftp bulk borrow pbandwidth 10 red
26 filter sr0 ftp 0 0 0 20 6# ftp-data
27 filter sr0 ftp 0 20 0 0 6# ftp-data
28 class cbq sr0 http bulk borrow pbandwidth 10 red
29 filter sr0 http 0 0 0 80 6# http
30 filter sr0 http 0 80 0 0 6# http
31 #
32 # misc (udp) classes
33 #
34 class cbq sr0 udp misc borrow pbandwidth 10 red
35 filter sr0 udp 0 0 0 0 17# other udp
36 #
37 # interactive classes
38 #
39 class cbq sr0 dns intr borrow pbandwidth 10 red
40 filter sr0 dns 0 0 0 53 17
41 filter sr0 dns 0 0 0 53 6
42 class cbq sr0 telnet intr borrow pbandwidth 10 red
43 filter sr0 telnet 0 0 0 23 6# telnet
44 filter sr0 telnet 0 23 0 0 6# telnet
45 filter sr0 telnet 0 0 0 513 6# rlogin
46 filter sr0 telnet 0 513 0 0 6# rlogin
Figure 6-7: Sample altq.conf Configuration File
Please note the following about the above file:

• Line 4: Interface is sr0. Bandwidth is 1 Mbps. Use CBQ.
• Line 5: Create root class. Set NULL to parent and 100 (percent) to
pbandwidth (bandwidth in percent).

• Line 9: Create control class using keyword control. The system uses
the control class to send control packets (RSVP, ICMP, IGMP). This rule
is built-in and provided for backward compatibility. This feature will be
removed in the future.
If a control class is not defined by the time the default class is created, the
system will automatically create one with 2 percent bandwidth. The
bandwidth is taken out of the default class.
• Line 10: Create default class. If a packet doesn’t match the filters, the
packet is put into the default class.
• Line 12-14: Create 3 metaclasses as children of the default class. They
can borrow bandwidth from the default class.
• Line 23: Create a class for TCP as a child class of the bulk class.
Bandwidth can be borrowed from the parent. Also, this class uses RED
dropper.
• Line 24: Add a filter to the TCP class. This filter will match all TCP
packets (proto=6) and, thus, should be listed earlier than other filters for
packets using TCP.
Here are some TIPS for CBQ setting:
• Don't try to borrow too much.
For example, parent: 90 percent, child: 2 percent. The child should be
able to use up to 90 percent, but it may not work as you expect depending
other conditions involved.
• Keep the depth of the leaf classes equal from the root class.
• Setting high priority for a class won't help much, and high priority has
some side effect to borrowing mechanism. Don’t use priority unless
the link is less than 1 Mbps.
• CBQ has error margins of several percent against the REAL interface
speed.
• Use the altqstat tool to see the various statistics of a class.
CBQ Setting for Slow Interfaces

It may be difficult to set the right parameters when the link is slow (for example,
less than 512 Kbps).
If the default doesn’t work well, try maxburst 2 or maxburst 1.

CBQ
Also, assigning more than 10 percent of the link bandwidth to each class is
recommended.
Setting high priority to an interactive class could improve the response time.
See also “Token-bucket Regulator” on page 66.
Shaping the Aggregated Traffic of an Interface

CBQ was not originally designed to shape the aggregated traffic. Having said that,
if you still want to shape the total traffic, there are two ways to do so.
Do not expect accurate rate control. CBQ has error margins of several percent
against the REAL interface speed.
• Use a class as a shaper
Create a common ancestor class that limits the total bandwidth, as shown
in the following example.
interface em0 bandwidth 10M cbq

class cbq em0 root_class NULL pbandwidth 100
# use def_class as a 1Mbps shaper. don't borrow from root
class cbq em0 def_class root_class pbandwidth 10 default
class cbq em0 tcp_class def_class pbandwidth 5
Limitation: The minimum unit is 1 percent of the linkbandwidth

1. Set a low value to interface bandwidth, as shown in the following
example.
# set 512Kbps to the 10Mbps interface

interface em0 bandwidth 512K cbq
# don't borrow from the root class
class cbq em0 def_class root_class pbandwidth 95 default
class cbq em0 tcp_class def_class pbandwidth 50
Limitations:
- Real traffic becomes bursty (try maxburst 2 or maxburst 1).
- Borrowing may not work very well.
See also “Token-bucket Regulator” on page 66.

CBQ Monitoring
The altqstat program reports the statistics and the internal state of the classes.
The following table shows a sample output for a class.
Class 0 on Interface fxp0:

priority: 1 depth: 0 offtime: 8664 [us] wrr_allot: 1016 bytes
nsPerByte: 2666 (3.00 Mbps), Measured: 8.22 [Mbps]
pkts: 9735, bytes: 13381264
overs: 9662, overactions: 520
borrows: 9142, delays: 520
drops: 2, drop_bytes: 3008
QCount: 1, (qmax: 30)
AvgIdle: -125 [us], (maxidle: 1843 minidle: -125 [us])
The following table describes the contents of the sample output file.
File Output priority: 1 depth: 0 offtime: 8664 [us] wrr_allot: 1016 bytes
Description Priority is 1, depth is 0 (it’s a leaf node), offtime is 8664 usec, and allotment
of weighted round robin is 1016B.
File Output nsPerByte: 2666 (3.00 Mbps), Measured: 8.22 [Mbps]
Description The bandwidth of the class is 3.00 Mbps; currently 8.22 Mbps is used.
File Output pkts: 9735, bytes: 13381264
Description 9735 packets were transmitted (total 13381264 bytes).

File Output overs: 9662, overactions: 520
Description Exceeded the assigned bandwidth 9662 times; overlimit actions were called
520 times
File Output borrows: 9142, delays: 520
Description Borrowed bandwidth from its ancestor 9142 times; suspended for rate-
control 520 times.
File Output drops: 2, drop_bytes: 3008
Description Two packets were dropped (total 3008 bytes).

File Output QCount: 1, (qmax: 30)
Description Current queue length is 1 (the limit is 30).

CBQ
File Output AvgIdle: -125 [us], (maxidle: 1843 minidle: -125 [us])
Description Current average idle is -125 usec.

(maxidle is 1843 usec, and minidle is -125 usec)
Limitations of Borrowing
The borrowing mechanism is useful, but it has limitations:
1. A small class cannot borrow the entire bandwidth of its parent.
A class gets suspended when it is over limit. A smaller class has a longer
suspension period (off time). When borrowing is enabled, a child also
borrows the off time of the parent, but when the parent also gets over
limit, the child has to use its own off time to avoid overloading the
system. (Otherwise, all the classes use the minimum off time even under
a heavy load.)
As a result, a small class is not able to make full use of the bandwidth of
the parent.
2. Competing TCPs equally share the bandwidth even when their bandwidth
allocations are not equal.
When borrowing is enabled, the bandwidth allocation is enforced only
when the queues have enough backlog, but TCPs can reach the
equilibrium without creating backlog in the queues. In this case, the
bandwidth share is made by the TCP mechanism, not by CBQ.
If there are many TCP flows, TCP will not be able to reach the
equilibrium and the allocation will be done by CBQ.
3. UDP beats TCP when both are set to borrow from the same parent.
The situation is similar to Case 2. TCP backs off before the allocation is
enforced by CBQ. Again, if there are many flows, the situation will be
improved.
4. UDP is very bursty when borrowing is enabled.
As explained in Case 1, a child has to be suspended longer when the
parent gets over limit. This leads to the bursty behavior of UDP. On the
other hand, TCP adapts better to avoid overloading the parent.

Hierarchical Fair Service Curve
Hierarchical Fair Service Curve Basics

The following paper is a good reference, but it is a bit too theoretical, so the
Hierarchical Fair Service Curve (HFSC) basics are summarized here.
“A Hierarchical Fair Service Curve Algorithm for Link-Sharing, Real-Time
and Priority Service” by Ion Stoica, Hui Zhang, and T. S. Eugene Ng.
SIGCOMM’97.
Service Curve
HFSC maintains two service curves: one for real-time criteria and the other for
link-sharing criteria.
A service curve of HFSC consists of two segments. m1 and m2 are slopes of the
two segments, and d is the x-projection of the intersection that specifies the length
of the first segment. Intuitively, m2 specifies the long-term throughput guaranteed
to a flow, while m1 specifies the rate at which a burst is served. When the slope of
the first segment is larger than that of the second segment, it is called concave. A
service curve is either convex or concave. The following figure shows examples of
concave and convex service curves.
m2
m2
m1
m1 = 0
d d
concave convex
Figure 6-8: Examples of Concave and Convex Service Curves
A concave service curve provides a bounded burst similar to a token bucket. The
triangular area made by the first segment roughly corresponds to the depth of a
token bucket, and the slope bounds the peak rate. The difference is that the peak
rate of a token bucket is an upper bound of the sending rate and is often set to the
wire speed. On the other hand, HFSC guarantees the rate defined by the first
segment, and, thus, it cannot be the wire speed.

A convex service curve, however, surpasses the initial traffic volume. m1 of a

convex curve must be 0 in the current implementation. A linear service curve is a
special case of a convex curve with a NULL first segment. A linear service curve
corresponds to a traditional virtual clock model and is a good starting point for
novice users.
Virtual Time
Each class keeps the total byte count already sent. When a class is backlogged,
virtual time (vt) is calculated for the packet at the head of the class queue. vt is the
x-projection of the service curve corresponding to (total + packet_len). As a result,
vt of a class monotonically increases. By scheduling a packet with the smallest vt,
the bandwidth allocation becomes proportional to the service curve slope of each
class. The following figure shows and example of virtual time.
bytes
next
packet service curve
length
total
bytes
already time
sent vt for next packet
vt for previous packet
Figure 6-9: Example of virtual time
A service curve is updated every time a class becomes backlogged. The update
operation takes the minimum of:
1. The service curve used in the previous backlogged period
2. The original service curve starting at (current_time, total_bytes)
When a class has been idle long enough, the updated curve is equal to (2). On the
other hand, when the class has been using bandwidth much more than its share, the
updated curve is equal to (1). (1) and (2) can intersect when the class has been
using bandwidth a little less than its share. In this case, the updated curve could
have a different value of d. The operation is illustrated in the following two figures.
It might be easier to see it as a half-filled token bucket.

total + new coordinate
service curve
of +
previous period current time
Figure 6-10: Update Operation
total + new coordinate
+
current time
Figure 6-11: New Service Curve
HFSC Scheduling
HFSC has two independent scheduling mechanisms.
• Real-time scheduling is used to guarantee the delay and the bandwidth
allocation at the same time.
• Hierarchical link-sharing is used to distribute the excess bandwidth
available.
When dequeuing a packet, HFSC always tries real-time scheduling first. If no
packet is eligible for real-time scheduling, link-sharing scheduling is performed.
HFSC does not use class hierarchy for real-time scheduling.

Hierarchical Link-sharing
In HFSC, only leaf classes have real packets, but vt of an intermediate class is also
maintained by summing up the total byte count used by its descendants. When
dequeuing a packet, HFSC’s hierarchical scheduler walks through the class
hierarchy from the root to a leaf class. At each level of the class hierarchy, the
scheduler selects a class with the smallest vt among its child classes. When the
scheduler reaches a leaf class, this leaf class is scheduled.
Note that the scheduler looks at only direct children at each level. Thus, the
bandwidth allocation is proportional to the service curve slopes among the sibling
classes, but is not proportional among classes with different parents. For example,
four leaf classes in the following figure will have the same bandwidth allocation,
although A, B and C, D have different slopes. In other words, the ratio among
siblings controls the bandwidth allocation, and absolute slope values do not matter.
(Similarly, vt values should be consistent only among sibling classes.)
root (100 Mbps)
E (20 Mbps) F (20 Mbps)
A B C D
(10Mbps) (10Mbps) (1 Mbps) (1 Mbps)
Figure 6-12: Hierarchical Link-sharing Example
Real-time scheduling
As opposed to link-sharing scheduling, single consistent time is used for real-time
scheduling. Each class keeps the cumulative byte count that is similar to the total
byte count, but only for packets scheduled by the real-time scheduling.
HFSC computes the eligible time and deadline for each class. The eligible time and
deadline are the x-projections of the head and tail of the next packet. A class
becomes eligible for real-time scheduling when the current time becomes greater
than the eligible time of the class. The real-time scheduler selects a class with the
smallest deadline among eligible classes.

bytes
service curve
next
packet
length
cumulative
bytes
already sent
time
eligible time deadline
Figure 6-13: Real-time Scheduling Example
In the original HFSC paper, a single service curve is used for both real-time
scheduling and link-sharing scheduling. LynuxWorks has extended HFSC to have
independent service curves for real-time and link-sharing.
Decoupling service curves allows the user to independently control the guaranteed
rate and the distribution of excess bandwidth. For example, it is possible to
guarantee the minimum bandwidth of 2 Mbps to two classes, but the excess
bandwidth is distributed with a different ratio.
It is also possible to set either of the service curves to be 0. When the real-time
service curve is 0, a class receives only excess bandwidth. When the link-sharing
service curve is 0, a class cannot receive excess bandwidth. Note that 0 link-
sharing makes the class nonwork-conserving.
Note that the link-sharing scheduling alone can guarantee the assigned bandwidth
as long as the real-time service curve is equal to or smaller than the link-sharing
service curve for all classes. But if the link-sharing service curve is smaller,
assigned link-sharing bandwidth may not be provided.
Notes on HFSC
Root class
The root class is automatically created by the interface command. Both service
curves are initialized with a linear curve of the interface speed.
Default class
One default (leaf) class is required for an interface.

Only leaf classes can have filters. Because of the hierarchical link-sharing
algorithm, only a leaf class can have packets. Thus, you will need to explicitly
create a leaf class to represent an intermediate class.
For example, in order to distribute the bandwidth of CMU to its departments,
create a leaf class other and attach a filter for CMU to this leaf class as shown in
the following figure.
CMU
CS EE other
Figure 6-14: Intermediate Class Example
Admission Control
The sum of the service curves of the children should be less than the service curve
of the parent. In particular, you have to be careful when assigning concave service
curves since the sum of the peak rates could be large.
Reserved Real-time Bandwidth
Many network cards are not able to saturate the wire, and if one allocates real-time
traffic more than the actual maximum transmission rate, all classes become eligible
and HFSC is no longer able to meet the delay bound requirements. Thus, 20
percent of the real-time bandwidth is reserved for safety. Link-sharing does not
have reserved bandwidth.
Specifying Service Curves in altq.conf
To specify the same service curve to both real-time and link-sharing, use:
[sc <m1> <d> <m2>]
To specify only the real-time service curve, use:
[rt <m1> <d> <m2>]

To specify only the link-sharing service curve, use:

[ls <m1> <d> <m2>]
The keywords pshare and grate are shorthand expression to specify a linear
service curve.
pshare specifies a linear link-sharing service curve by percentage of the interface
bandwidth.
pshare <percent> is equivalent to:
[ls 0 0 m2]
where m2 = interface_bandwidth * percent/100.
grate specifies a linear real-time service curve.
grate <m2> is equivalent to:

[rt 0 0 m2]
Shaping by HFSC
NULL link-sharing service curve can be used to limit the bandwidth of a class.
When a link-sharing service curve is zero, packets more than the assigned real-time
rate remain in the queue until the class becomes eligible again.
Shaping of HFSC is more accurate than CBQ because HFSC does not use a
suspension period (called off time in CBQ) and packet length is considered.
Note that delay requirement cannot be guaranteed when in the shaping mode since
an eligible packet could be held until the next timer tick in the worst case.
Also note that, if a NULL link-sharing service curve is assigned to a parent class,
its children also cannot have link-sharing.

Sample configuration
#
# hfsc configuration for hierarchical sharing
#
interface pvc0 bandwidth 45M hfsc
#
# (10% of the bandwidth share goes to the default class)
class hfsc pvc0 def_class root pshare 10 default
#
# bandwidth share guaranteed rate
# CMU: 45% 15Mbps
# PITT: 45% 15Mbps
#
class hfsc pvc0 cmu root pshare 45 grate 15M
class hfsc pvc0 pitt root pshare 45 grate 15M
#
# CMU bandwidth share guaranteed rate
# CS: 20% 10Mbps
# other: 20% 5Mbps
#
class hfsc pvc0 cmu_other cmu pshare 20 grate 10M
filter pvc0 cmu_other 0 0 128.2.0.0 netmask 0xffff0000 0 0
class hfsc pvc0 cmu_cs cmu pshare 20 grate 5M
filter pvc0 cmu_cs 0 0 128.2.242.0 netmask 0xffffff00 0 0
#
# PITT bandwidth share guaranteed rate
# CS: 20% 10Mbps
# other: 20% 5Mbps
#
class hfsc pvc0 pitt_other pitt pshare 20 grate 10M
filter pvc0 pitt_other 0 0 136.142.0.0 netmask 0xffff0000 0 0
class hfsc pvc0 pitt_cs pitt pshare 20 grate 5M
filter pvc0 pitt_cs 0 0 136.142.79.0 netmask 0xffffff00 0 0
Figure 6-15: Sample HFSC Configuration File for Hierarchical Sharing

Random Early Detection

To enable a simple RED, specify red in altq.conf as follows:
interface em0 bandwidth 10M red
RED parameters can be specified as follows:
interface em0 bandwidth 10M red thmin 10 thmax 20 invpmax
15 qlimit 80
Note that RED never shapes the traffic by itself.
To test RED, run multiple TCP streams from src to sink.
% altqstat
This will show the statistics (among other things, the average queue length).
To enable ECN by RED, add ecn to the interface command line.
RED can be enabled for a CBQ/HFSC/PRIQ class.
Explicit Congestion Notification (ECN)

By default, ECN is disabled. To turn it on, use sysctl as follows:
# sysctl -w net.inet.tcp.ecn=1
Below is a sample of altq.conf that makes use of ECN.
interface em0 bandwidth 10M cbq

class cbq em0 def_class root_class borrow pbandwidth 95 default
# Syntax for filter is as follows:

# filter dst_addr [netmask mask] dport src_addr [netmask
# mask] sport proto [tos value [tosmask value]] [gpi value]
#
#
# ecn enabled
class cbq em0 tcp_333 def_class priority 5 pbandwidth 10 red ecn
filter em0 tcp_3333 0 3333 0 0 6
# no ecn
class cbq em0 tcp_4444 def_class priority 7 pbandwidth 10
filter em0 tcp_4444 0 4444 0 0 6

Diffserv
ALTQ supports the following:
• Traffic conditioning at ingress interfaces
CDNR (conditioner) supports
- Token-bucket meter
- 2-rate three-color marker
- Time-sliding window three-color marker
• Preferential scheduling at egress interface
Extension of RIO to support three drop precedence values
Combination of RIO and CBQ/HFSC/PRIQ to support multiple classes
You can build Assured Forwarding (AF) and Expedited Forwarding (EF) services
using ALTQ.
The following figure shows what ALTQ can do for diffserv.
diffserve network
src ingress core egress sink

diffedge diffedge
- MF classifier - BA classifier - BA classifier

- meter / marker - meter / marker - meter / marker
- AF / EF PHB - AF / EF PHB - AF / EF PHB
-clear dscp
Sample configuration files can be found in

$ENV_PREFIX/etc/altq.conf.samples/.
Note that the performance of the AF and EF services depends on the method to
provide those services and the configuration of the network. ALTQ just provides
mechanisms in order to build services.

References
• RFC-2474, Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers
• RFC-2475, An Architecture for Differentiated Services
• RFC-2597, Assured Forwarding PHB Group
• RFC-2598, An Expedited Forwarding PHB
• RFC-2697, A Single Rate Three Color Marker
• RFC-2698, A Two Rate Three Color Marker

#
# null interface command
#
interface pvc1
#
# simple dropper
#
conditioner pvc1 dropper <drop>
filter pvc1 dropper 0 0 172.16.4.173 0 0
#
# simple marker to clear dscp
#
conditioner pvc1 clear_marker 
filter pvc1 clear_marker 0 0 172.16.4.174 0 0
#
# EF style conditioner (a simple token bucket)
#
conditioner pvc1 ef_cdnr <tbmeter 6M 64K <pass><drop>>
filter pvc1 ef_cdnr 0 0 172.16.4.176 0 0
#
# AF style conditioners (trTCM)
#
conditioner pvc1 af1x_cdnr \
<trtcm 3M 32K 10M 64K colorblind>
filter pvc1 af1x_cdnr 0 0 172.16.4.177 0 0
#
# color-blind trTCM is equivalent to a dual tokenbucket meter
#
conditioner pvc1 dual_tb \
<tbmeter 10M 64K \
<tbmeter 3M 32K >>
filter pvc1 dual_tb 0 0 172.16.4.178 0 0
Figure 6-16: Sample Configuration for Traffic Conditioner

#
# output interface
#
interface pvc0 bandwidth 45M hfsc
class hfsc pvc0 def_class root pshare 10 default
#
# EF class
# real-time: 6Mbps
# link-sharing: 0%
#
class hfsc pvc0 ef_class root grate 6M
filter pvc0 ef_class 0 0 0 0 0 tos 0xb8 tosmask 0xfc
#
# AF classes
# real-time: 3Mbps
# link-sharing: 10% (4.5Mbps)
#
# rio threshold values
rio 40 50 10 20 30 10 5 15 10
#
class hfsc pvc0 af1x_class root grate 3M pshare 10 rio
class hfsc pvc0 af3x_class root grate 3M pshare 10 rio cleardscp
filter pvc0 af1x_class 0 0 0 0 0 tos 0x20 tosmask 0xe4

Figure 6-17: Sample Queuing Configuration Using HFSC

#
# output interface
#
interface pvc0 bandwidth 45M cbq
class cbq pvc0 root_class NULL pbandwidth 100
class cbq pvc0 def_class root_class borrow pbandwidth 86 default
#
# EF class
#
class cbq pvc0 ef_class root_class pbandwidth 14 priority 5
filter pvc0 ef_class 0 0 0 0 0 tos 0xb8 tosmask 0xfc
#
# AF classes
#
# rio threshold values
rio 40 50 10 20 30 10 5 15 10
#
class cbq pvc0 af1x_class def_class borrow pbandwidth 20 rio
class cbq pvc0 af3x_class def_class borrow pbandwidth 20 rio cleardscp

Figure 6-18: Sample Queuing Configuration Using CBQ
WFQ
Weighted Fair Queuing (WFQ) is implemented as a sample implementation.
WFQ is easy to use since it requires no configuration. By default, WFQ allocates
256 queues, and packets are mapped into one of the queues by hashing the
destination address. So, packets for the same host will be put in the same queue.
To enable WFQ on interface vx0 and vx1, add the following lines to
altq.conf:
interface vx0 bandwidth 10M wfq

interface vx1 bandwidth 10M wfq

The following command can be used to monitor the WFQ statistics:
% altqstat -i vx1
FIFOQ
First-In First-out Queuing (FIFOQ) is implemented as a template for those who
want to write their own queuing schemes on the ALTQ framework.
So, there would be no reason to use FIFOQ unless you want to modify the FIFOQ
implementation.
Using FIFOQ
To enable FIFOQ on interface vx0, add the following line to altq.conf:
interface vx0 bandwidth 6M fifoq

CHAPTER 7 net-SNMP
Introduction
net-SNMP (previously known as UCD-SNMP) is an implementation of the Simple
Network Management Protocol (SNMP).
NOTE: Although the UCD-SNMP project has been renamed to net-SNMP, the
current distribution of net-SNMP files is still called UCD-SNMP.
SNMP is used to deliver network management information between networked

hosts. Administrators can manage certain aspects of networking using net-SNMP,
including performance management and problem detection. net-SNMP is made up
of various tools related to SNMP management, including:
• An extensible agent
• An SNMP library
• Tools to request or set information from SNMP agents
• Tools to generate and handle SNMP traps
• A version of the UNIX netstat command, using SNMP
• A Tk/perl Management Information Base (MIB) browser

Chapter 7 - net-SNMP
LynxOS includes net-SNMP version 4.1.1, which supports SNMPv2 and SNMPv3
(see following note), and MIBI and MIBII.
NOTE: The SHA authentication and DES encryption components of SNMPv3

require the OpenSSL package. This OpenSSL package is an unmodified version of
the open-source distribution built on LynxOS and is provided for the SNMPv3
encryption functionality only.
Use of OpenSSL outside of SNMPv3 is unsupported. Refer to “OpenSSL Legal

Issues” on page 104 for additional legal restrictions.
net-SNMP sends and receives information through UDP ports 161 (SNMP) and
162 (SNMP Traps).
SNMP Overview
SNMP architecture is made up of three elements: managed devices, agents, and
network management stations (NMSs).
Managed devices can be any device node on a network, including PCs, hubs,
routers, and printers. Agents are software modules that are responsible for
maintaining information on a specific device node. Agents collect and store
information about a particular device in a local management database for use by an
NMSs. The NMSs provide a user interface to applications and network
information. NMSs collect information from agents for the MIB and can set the
types of data the agents report. The MIB is a hierarchical database of all managed
devices on a network managed by SNMP.

net-SNMP Documentation
The following figure shows the communication between managed devices, agents,
and the network management station.
Network Management Station (NMS)
Managment
Information
Base (MIB)
Ethernet
Agent Agent Agent

management management management
database database database
Managed Device Managed Device Managed Device
Figure 7-1: SNMP Basic Architecture
In this example, agents act as an interface between the NMS and the managed
devices on the network. Each agent resides on the device as a software module and
provides information to the NMS. The NMS maintains the MIB, the hierarchical
table of all entities on the network.
net-SNMP Documentation
Included with the net-SNMP distribution for LynxOS are several documents,
including:
• FAQ
• README
• PORTING
• EXAMPLE.conf
• AGENT.txt
• man pages for individual tools, files, and the API

Additional resources and documentation are also available online at:

• http://net-snmp.sourceforge.net
net-SNMP Components
The following tables describe the net-SNMP daemons and applications included
with the LynxOS distribution. Each of the following components is described in its
respective man page.
Table 7-1: net-SNMP Daemon Components
Component Description
snmpd SNMP agent daemon that responds to SNMP requests

snmpd.conf SNMP agent configuration file
snmptrapd SNMP trap daemon
snmptrapd.conf SNMP trap configuration file
snmpcmd Common options used with SNMP commands
snmp.conf Configuration file for SNMP applications
Table 7-2: net-SNMP Application Components
snmpget Queries information from managed devices.

snmpset Sets network information.
snmpwalk Queries for a tree of information from managed
devices.
snmptrap Uses TRAP to send network information.
snmpbulkwalk Uses BULK requests to query for a tree of
information from managed devices.
snmpdelta Monitors changes in SNMP variables.
snmpgetnext Uses GET NEXT to query for information on a
managed device.

Extending the Agent with MIB Modules
Table 7-2: net-SNMP Application Components (Continued)
snmpnetstat Show. network status through SNMP.

snmpstatus Retrieves status from a managed device.
snmptable Outputs an SNMP table.
snmptest Tests network connectivity with SNMP requests.
snmptranslate Translates SNMP values to other formats.
snmpusm Creates and maintains SNMPv3 users on a remote
managed device.
snmpbulkget Communicates with managed device with BULK
GET requests.
NOTE: The snmpd.conf, snmptrapd.conf and snmp.conf files are not

supplied with the net-SNMP package and need to be created manually.
Extending the Agent with MIB Modules

Custom modules can be added to extend the functionality of Agents. Refer to the
documentation on AgentX, SMUX and proxied SNMP included with the
net-SNMP distribution for more details. All three mechanisms use the same
module API, which is described in the AGENT.txt file included with the
distribution. There is also an HTML version accessible from the net-SNMP project
web page (http://net-snmp.sourceforge.net).
The mib2c tool can be used to facilitate writing MIB modules. mib2c generates
most of the necessary skeleton code from the description in the MIB file. Note that
the net-SNMP suite does not currently include support for SMUX subagents.
License & Copyright

net-SNMP is free software distributed under the GNU General Public License
(GPL). Other Documents and product updates related to net-SNMP are available

from: http://net-snmp.sourceforge.net. Some of the documentation in

this guide is taken from the net-SNMP FAQ, man pages, and Readme files. In
some cases, content has changed for LynxOS specific environments. Unmodified
versions of these documents can be found on the net-SNMP homepage.
Copyright 1989, 1991, 1992 by Carnegie Mellon University Derivative Work
Copyright 1996, 1998, 1999, 2000 The Regents of the University of California All Rights Reserved Permission to use,
copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appears in all copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of CMU and The Regents of the University of California
not be used in advertising or publicity pertaining to distribution of the software without specific written permission.
CMU AND THE REGENTS OF THE UNIVERSITY OF CALIFORNIA DISCLAIM ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL CMU OR THE REGENTS OF THE UNIVERSITY OF CALIFORNIA BE
LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM THE LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THIS SOFTWARE.

CHAPTER 8 OpenSSL
This chapter provides information on the OpenSSL feature for the LynxOS
operating system.
Overview
OpenSSL is a toolkit implementing the Secure Sockets Layer (SSL v2/v3) and
Transport Layer Security (TLS v1) protocols as well as a full-strength general
purpose cryptography library.
OpenSSL Components
OpenSSL contains the following components:
• The OpenSSL library used to export cryptographic-related functions for
applications
• The OpenSSL tool used to provide cryptographic functionalities for users

Chapter 8 - OpenSSL
The following diagram shows interaction of the OpenSSL components and

LynxOS applications
.
OpenSSL Library
OpenSSL Tool
openssl
Symmetrical Message Asymmetrical Other

Encryption Digest Encryption Functionality
Functions Functions Functions
Application DES MD5 RSA
...
3DES SHA1
Application ...
Applications that AES
use the OpenSSl library ...
...
Application
The OpenSSL Library

The OpenSSL library provides the following functionalities:
• Encryption and decryption of data
• Calculating message digest for data
• Signing data and verifying the data signature
• Creating, signing, verifying, and other operations with certificates
The OpenSSL Tool

openssl is an OpenSSL command line tool that allows the user to access
functionalities provided by the OpenSSL library from a command line.
Refer to the openssl man page for additional information about the description
of this command options.

OpenSSL Documentation
OpenSSL Documentation
Included with the OpenSSL distribution for LynxOS are several documents,
including:
• FAQ
• README
• man pages for individual tools, files, and the API
Additional resources and documentation are also available online at:
• http://www.openssl.org
Installing OpenSSL
Cross-Development Installation
OpenSSL includes two types of components:
• Cross-development components included in the cross-development kit
(CDK)
• Native components included in the LynxOS distribution
To install cross-development OpenSSL components, perform installation of the
cross-development kit. Refer to Chapter 3, “Installing LynxOS” of the
LynxOS Installation Guide for the instructions on how to install the CDK on a
cross-development host.
Native Installation
To install native OpenSSL components on the cross-development host, refer to the
LynxOS Installation Guide.
The OpenSSL Library

The OpenSSL library is present only in a static form. LynxOS native applications
should be linked statically with the OpenSSL library.

Chapter 8 - OpenSSL
Adding the OpenSSL Tool to a LynxOS KDI

To include the OpenSSL tool in a KDI, make the following corrections in the
SPEC file:
• Add the openssl application to the /bin directory section as follows:
file=openssl source=$(ENV_PREFIX)/usr/bin/openssl owner=0
group=0 mode=-r-xr-xr-x
• Add openssl.cnf into the /usr/local/ssl directory section as

follows:
directory=/usr/local/ssl owner=0 group=0 mode=drwxr-xr-x
file=openssl.cnf source=$(ENV_PREFIX)/usr/share/ssl/openssl.cnf
owner=0 group=0 mode=-rw-r--r--
Examples of Using the OpenSSL Tool

The section provides some examples of using the OpenSSL tool.
The OpenSSL tool can be used in both the cross-development and the target
environment. The results of using a cross-development version of the OpenSSL
tool can be used on the target and visa-versa. For example, the certificate created
once with the OpenSSL tool in the cross-development environment can be used by
an application in the target environment using the OpenSSL library.
Encrypting and Decrypting Data

The examples in this section show how to encrypt and decrypt data using the
OpenSSL tool.
• To encrypt the file.txt file using Triple DES in CBC mode with salt
to create the encrypted file file.enc, use the enc option in the
openssl command line:
$ openssl enc -des-ede-cbc -salt -in file.txt -out \
file.enc
enter -des-ede-cbc encryption password: <password>
Verifying - enter aes-256-cbc encryption password: <password>
where <password> is the encryption password.

Calculating Message Digest for Data
• To decrypt the file.enc file, use the following openssl command

line:
$ openssl enc -d -des-ede-cbc -in file.enc -out
file.dec
enter -des-ede-cbc decryption password: <password>
The result of this command is the decrypted file file.dec.

Refer to the enc man page for additional information about using the OpenSSL
tool for data encryption and decryption.
Calculating Message Digest for Data

To calculate the data message digest, the dgst option is used in the openssl
command line.
To calculate the MD5 message digest for the file.txt file, use the following
command:
$ openssl dgst -md5 -hex file.txt
The OpenSSL tool will calculate and print the message digest:
MD5(file.txt)= e3577c206a2f8eb4ef57f8b7ece4c44d
Creating a Self-signed Certificate

To create and sign certificates using the OpenSSL tool, perform the following
steps:
1. Create a new public/private keys pair using the following command:
$ openssl req -x509 -nodes -days 365 \
-newkey rsa:1024 -keyout mycert.pem -out mycert.pem
OpenSSL generates an RSA private key:
Generating a 1024 bit RSA private key
............................................++++++
...................................................++++++
writing new private key to 'mycert.pem'
-----
The user is asked to enter information that will be included into the
certificate:
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.

Chapter 8 - OpenSSL
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Oregon
Locality Name (eg, city) [Newbury]:Portland
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname)
[]:www.madboa.com
Email Address []:
2. Create a self-signed certificate by executing the following command:

$ openssl req -x509 -nodes -days 365 -subj \
'/C=US/ST=Oregon/L=Portland/CN=www.madboa.com' \
-newkey rsa:1024 -keyout mycert.pem -out mycert.pem
OpenSSL generates an RSA private key and writes a new certificate:
Generating a 1024 bit RSA private key
................................................................++
++++
...........++++++
writing new private key to 'mycert.pem'
-----
Connecting to the Secure Server Using SSL

The OpenSSL tool can be used to connect to a secure server using Secure Sockets
Layer (SSL).
To connect to the remote.host host and the 465 port (smtps, SMTP over
SSL), use the following command:
$ openssl s_client -connect remote.host:465
The OpenSSL tool will connect to the server, get and verify the server certificate,
and establish a secure connection between the local host and the secure server:
CONNECTED(00000003)
depth=0 /C=US/ST=Oregon/L=Portland/CN=www.madboa.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Oregon/L=Portland/CN=www.madboa.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Oregon/L=Portland/CN=www.madboa.com
i:/C=US/ST=Oregon/L=Portland/CN=www.madboa.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICrzCCAhigAwIBAgIBADANBgkqhkiG9w0BAQQFADBKMQswCQYDVQQGEwJVUzEP
MA0GA1UECBMGT3JlZ29uMREwDwYDVQQHEwhQb3J0bGFuZDEXMBUGA1UEAxMOd3d3

Creating the SSL Server from the Command Line
Lm1hZGJvYS5jb20wHhcNMDYwMjA3MTI1MzM3WhcNMDcwMjA3MTI1MzM3WjBKMQsw
CQYDVQQGEwJVUzEPMA0GA1UECBMGT3JlZ29uMREwDwYDVQQHEwhQb3J0bGFuZDEX
MBUGA1UEAxMOd3d3Lm1hZGJvYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAONagFq3W3MTx5Y1ivYkECS+UysWNYF5RT7uzHFuwv0Gnjsgt+lkVj1x1upe
FHfZqDNkhMrPJdJxUrJz/cBBEubHmsc7jgCyMJqO2G+OJYQNB+NFB8ljrhrBOkAo
sOIWr1tptGrFCj97jwFlX2sv6Dinz87O6t/kROaOAPsKi5kjAgMBAAGjgaQwgaEw
HQYDVR0OBBYEFNKMnkQ09H4GxtD5wAzu8dePdzFWMHIGA1UdIwRrMGmAFNKMnkQ0
9H4GxtD5wAzu8dePdzFWoU6kTDBKMQswCQYDVQQGEwJVUzEPMA0GA1UECBMGT3Jl
Z29uMREwDwYDVQQHEwhQb3J0bGFuZDEXMBUGA1UEAxMOd3d3Lm1hZGJvYS5jb22C
AQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQBhBaFlR16n+xfXrkrT
b2fqwMiJnQ9X35w29AOiCStDL6fvvb7t4icUWm6vTWT2ZRACJCNwLTZaGPFZAbwr
JZOHvIdGZzPPQef0KQX5DFfcHmIA0bL+qNNsrE6YK8Ic4rTNjljualSdNOyvdsPW
xGFV7udl2YXLrr0kmSD+4AMfLA==
-----END CERTIFICATE-----
subject=/C=US/ST=Oregon/L=Portland/CN=www.madboa.com
issuer=/C=US/ST=Oregon/L=Portland/CN=www.madboa.com
---
No client certificate CA names sent
---
SSL handshake has read 1127 bytes and written 276 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
9913374A448061858BDEDA865CBC15B09B14D9EDC067A84A04841430AB3A3856
Session-ID-ctx:
Master-Key:
ECE1C3E97969AF40432C1F2D492645C2A7C73C742080B3FC73E4B7420A560A91
64F9743F7590E6D3F09BBB793BC3923F
Key-Arg : None
Krb5 Principal: None
Start Time: 1139317822
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
Creating the SSL Server from the Command Line

To use the OpenSSL tool to create an SSL server from the command line, perform
the following steps:
1. Create a self-signed certificate as described in “Creating a Self-signed
Certificate” on page 101.
2. Run the server, using the following command:
$ openssl s_server -cert mycert.pem -accept 2345
The OpenSSL tool will be listen for connections to 2345 port. When a new
incoming connection comes, the SSL handshake will be initiated and a new secure
connection will be established:
Using default temp DH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----

Chapter 8 - OpenSSL
MHUCAQECAgMBBAIAOQQgmRM3SkSAYYWL3tqGXLwVsJsU2e3AZ6hKBIQUMKs6OFYE
MOzhw+l5aa9AQywfLUkmRcKnxzx0IICz/HPkt0IKVgqRZPl0P3WQ5tPwm7t5O8OS
P6EGAgRD6Jw+ogQCAgEspAYEBAEAAAA=
-----END SSL SESSION PARAMETERS-----
Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-
DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-
DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:EXP1024-DHE-
DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-
SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-
SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-
DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
CIPHER is DHE-RSA-AES256-SHA
Using OpenSSL in LynxOS Applications
net-SNMP
net-SNMP is the is an implementation of SNMP. net-SNMP uses the OpenSSL
library for SNMPv3 authentication, encryption, and some other tasks.
Refer to Chapter 7, “net-SNMP” for more information about net-SNMP.
bind
bind is the DNS (Domain Name System) server. bind uses the OpenSSL library
to support the DNSSEC (signed zones) feature.
racoon
racoon is the IKE (Internet Key Exchange) daemon. It is a part of KAME
(http://www.kame.net) IPSec implementation. racoon uses the OpenSSL
library to implement cryptography-related functionality required by IPSec.
OpenSSL Legal Issues

The OpenSSL package uses strong cryptography, which may fall under certain
import/export restrictions in certain countries. Use of strong cryptography, use of
cryptography hooks, or communicating technical details about cryptography
software is illegal in some countries. Please be aware of any import/export and/or
use laws which apply.

License & Copyright
License & Copyright

OpenSSL is free software distributed under a dual license (that is, both the
conditions of the OpenSSL License and the original SSLeay license apply to the
toolkit).
Some information for this chapter is taken from the OpenSSL documentation
sources and modified to match LynxOS specifics. Unmodified versions of these
documents can be found on the OpenSSL homepage.
PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG
CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR
EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT
CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE
WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY,
RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL
SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR
OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE
ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH
APPLY TO YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR
ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR
RESPONSIBILITY.

Chapter 8 - OpenSSL

APPENDIX A Supported Networking Standards
The following table describes the supported RFCs for this release of LynxOS.The
Table A-1: Supported RFCs
RFCs Title
3418 Management Information Base (MIB) for SNMP

3414 User-based Security Model (USM) for version 3 of SNMP
3413 Simple Network Management Protocol (SNMP) Applications
3376 Internet Group Management Version 3
3168 Explicit Congestion Notification for TCP/IP
3008 Domain Name System Security (DNSSEC)
3007 Secure Domain Name System (DNS) Update
2931 DNS Request and Transaction Signatures (SIG(0)s)
2930 Secret Key Establishment for DNS (TKEY RR)
2929 Domain Name System (DNS)
2915 The Naming Authority Pointer (NAPTR) DNS Resource Record
2863 The Interface Group MIB
2845 Secret Key Transaction Authentication for DNS (TSIG)
2819 Remote Network Monitoring Management Information Base
2796 BGP Route Reflection
2790 Host Resource MIB
2789 Mail Monitoring MIB
2788 Network Services Monitoring MIB

Appendix A - Supported Networking Standards
Table A-1: Supported RFCs (Continued)
RFCs Title
2742 Definitions of Managed Objects for Extensible SNMP Agents

2741 Agent Extensibility (AgentX) Protocol version 1
2737 Entity MIB (version 2)
2672 Non-Terminal DNS Name Redirection
2671 Extension Mechanisms for DNS (EDNSO)
2667 IP Tunnel MIB
2593 Script MIB Extensibility Protocol Version 1.0
2592 Definitions of Managed Objects for the Delegation of Management Script
2591 Definitions of Managed Objects for Scheduling Management Operations
2588 IP Multicast and Firewalls
2581 TCP Congestion Control
2580 Conformance Statement for SMIv2
2579 Textual Conventions for SMIv2
2578 Structure of Management Information Version 2 (SMIv2)
2576 Coexistence between version 1, version 2, version 3 of the Internet-standard Network
Management Framework
2575 View-based Access Control Model (VACM) for the Simple Management Protocol
(SNMP)
2574 User-based Security Model (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)
2573 SNMP Applications
2572 Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP)
2571 An Architecture for Describing SNMP Management Frameworks
2564 Application Management MIB
2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)

RFCs Title
2538 Storing Certificates in the Domain Name System (DNS)

2535 Domain Name System Security Extensions
2474 Definition of Differentiated Services (DiffServ) field for IPv4 and IPv6 headers
2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
2453 RIP Version 2
2437 PKCS #1: RSA Cryptography Specifications Version 2.0
2411 IP Security Document Roadmap
2410 The NULL Encryption Algorithm and Its Use With IPsec
2409 The Internet Key Exchange (IKE)
2406 IP Encapsulating Security Payload (ESP)
2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
2404 The Use of HMAC-SHA-1-96 within ESP and AH
2403 The Use of HMAC-MD5-96 within ESP and AH
2402 IP Authentication Header
2401 Security Architecture for the Internet Protocol
2396 Uniform Resource Identifiers (URI): Generic Syntax
2367 PF_KEY Key Management API, Version 2
2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
2358 Definitions of Managed Objects for the Ethernet-like Interface Types
2308 Negative Caching of DNS Queries (DNS NCACHE)
2275 View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)
2257 Agent Extensibility (AgentX) Protocol Version 1
2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names
2247 Using Domains in LDAP/X.500 Distinguished Names

RFCs Title
2246 The TLS Protocol version 1.0

2236 Internet Group Management Protocol, Version 2
2233 The Interfaces Group MIB using SMIv2
2230 Key Exchange Delegation Record for the DNS
2210 The Use of RSVP with IETF Integrated Services
2207 RSVP Extensions for IPSEC Data Flows
2205 Resource ReSerVation Protocol (RSVP) --Version 1 Functional Specification
2181 Clarifications to the DNS Specification
2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping
(MCGAM)
2144 The CAST-128 Encryption Algorithm
2137 Secure Domain Name System Dynamic Update
2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
2132 DHCP Options and BOOTP Vendor Extensions
2131 Dynamic Host Configuration Protocol
2119 Key words for use in RFCs to Indicate Requirement Levels
2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
2104 HMAC: Keyed-Hashing for Message Authentication
2096 IP Forwarding Table MIB
2074 Remote Network Monitoring MIB Protocol Identifiers
2072 Router Renumbering Guide
2071 Network Renumbering Overview: Why would I want it and what is it anyway?
2065 Domain Name System Security Extensions
2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
2013 SNMPv2 Management Information Base for the User Datagram Protocol using
SMIv2
2012 SNMPv2 Management Information Base for the Transmission Control Protocol using
SMIv2

RFCs Title
2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2
2003 IP Encapsulation within IP
2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms
1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
1995 Incremental Zone Transfer in DNS
1982 Serial Number Arithmetic
1950 ZLIB Compressed Data Format Specification version 3.3
1918 Address Allocation for Private Internets
1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network
1907 Management Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2)
1906 Transport Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)
1905 Protocol Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)
1904 Conformance Statements for Version 2 of the Simple Network Management Protocol
(SNMPv2)
1903 Textual Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2)
1902 Structure of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)
1901 Introduction to Community-based SNMPv2
1893 Enhanced Mail System Status Codes
1876 A Means for Expressing Location Information in the Domain Name System
1858 Security Considerations for IP Fragment Filtering
1853 IP in IP Tunneling
1829 The ESP DES-CBC Transform
1828 IP Authentication using Keyed MD5

RFCs Title
1827 IP Encapsulating Security Payload (ESP)

1826 IP Authentication Header
1825 Security Architecture for the Internet Protocol
1812 Requirements for IP Version 4 Routers
1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed
Pages, DLSw Standard Version 1
1779 A String Representation of Distinguished Names
1771 Lightweight Directory Access Protocol
1770 IPv4 Option for Sender Directed Multi-Destination Delivery
1769 Simple Network Time Protocol (SNTP)
1750 Randomness Recommendations for Security
1724 RIP Version 2 MIB Extension
1723 RIP Version 2 - Carrying Additional Information
1722 RIP Version 2 Protocol Applicability Statement
1721 RIP Version 2 Protocol Analysis
1716 Towards Requirements for IP Routers
1712 DNS Encoding of Geographical Location
1706 DNS NSAP Resource Records
1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using
SMIv2
1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2
1658 Definitions of Managed Objects for Character Stream Devices using SMIv2
1644 T/TCP -- TCP Extensions for Transactions Functional Specification
1623 Definitions of Managed Objects for the Ethernet-like Interface Types
1612 DNS Resolver MIB Extensions
1611 DNS Server MIB Extensions
1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0

RFCs Title
1591 Domain Name System Structure and Delegation

1573 Evolution of the Interfaces Group of MIB-II
1572 Telnet Environment Option
1571 Telnet Environment Option Interoperability Issues
1542 Clarifications and Extensions for the Bootstrap Protocol
1534 Interoperation Between DHCP and BOOTP
1533 DHCP Options and BOOTP Vendor Extensions
1532 Clarifications and Extensions for the Bootstrap Protocol
1525 Definitions of Managed Objects for Source Routing Bridges
1514 Host Resources MIB
1497 BOOTP Vendor Information Extensions
1493 Definitions of Managed Objects for Bridges
1452 Coexistence between version 1 and version 2 of the Internet-standard Network
1451 Manager-to-Manager Management Information Base
1450 Management Information Base for version 2 of the Simple Network Management
Protocol (SNMPv2
1449 Transport Mappings for version 2 of the Simple Network Management Protocol
(SNMPv2)
1448 Protocol Operations for version 2 of the Simple Network Management Protocol
(SNMPv2)
1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)
1446 Security Protocols for version 2 of the Simple Network Management Protocol
(SNMPv2)

RFCs Title
1445 Administrative Model for version 2 of the Simple Network Management Protocol
(SNMPv2)
1444 Conformance Statements for version 2 of the Simple Network Management Protocol
(SNMPv2)
1443 Textual Conventions for version 2 of the Simple Network Management Protocol
(SNMPv2)
1442 Structure of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)
1441 Introduction to version 2 of the Internet-standard Network Management Framework
1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and
Related Services
1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and
Identifiers
1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key
Management
1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and
Authentication Procedures
1389 RIP Version 2 MIB Extensions
1388 RIP Version 2 Carrying Additional Information
1387 RIP Version 2 Protocol Analysis
1382 SNMP MIB Extension for the X.25 Packet Layer
1381 SNMP MIB Extension for X.25 LAPB
1354 IP Forwarding Table MIB
1350 The TFTP Protocol (Revision 2)
1348 DNS NSAP RRs
1340 Assigned Numbers
1337 TIME-WAIT Assassination Hazards in TCP
1327 Mapping between X.400(1988) / ISO 10021 and RFC 822
1323 TCP Extensions for High Performance
1321 The MD5 Message-Digest Algorithm

RFCs Title

1315 Management Information Base for Frame Relay DTEs
1305 Network Time Protocol (Version 3) Specification, Implementation
1286 Definitions of Managed Objects for Bridges
1282 BSD Rlogin
1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3
1258 BSD Rlogin
1256 ICMP Router Discovery Messages
1229 Extensions to the generic-interface MIB
1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface
1227 SNMP MUX protocol and MIB
1215 Convention for defining traps for use with the SNMP
1213 Management Information Base for Network Management of TCP/IP-based
internets:MIB-II
1212 Concise MIB definitions
1191 Path MTU discovery
1186 MD4 Message Digest Algorithm
1184 Telnet Linemode Option
1183 New DNS RR Definitions
1157 Simple Network Management Protocol (SNMP)
1156 Management Information Base for network management of TCP/IP-based internets
1155 Structure and identification of management information for TCP/IP-based internets
1122 Requirements for Internet Hosts - Communication Layers
1119 Network Time Protocol (version 2) specification and implementation
1116 Telnet Linemode option

RFCs Title
1098 Simple Network Management Protocol (SNMP)

1094 NFS: Network File System Protocol specification
1091 Telnet terminal-type option
1084 BOOTP vendor information extensions
1067 Simple Network Management Protocol
1066 Management Information Base for network management of TCP/IP-based internets
1065 Structure and identification of management information for TCP/IP-based internets
1063 IP MTU discovery options
1058 Routing Information Protocol
1057 RPC: Remote Procedure Call Protocol specification: Version 2
1050 RPC: Remote Procedure Call Protocol specification
1048 BOOTP vendor information extensions
1035 Domain names - implementation and specification
1034 Domain names - concepts and facilities
1010 Assigned numbers
1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed
specifications
1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and
methods
0988 Host extensions for IP multicasting
0961 Official ARPA-Internet protocols
0959 File Transfer Protocol
0958 Network Time Protocol (NTP)
0951 Bootstrap Protocol
0950 Internet Standard Subnetting Procedure
0922 Broadcasting Internet datagrams in the presence of subnets
0919 Broadcasting Internet Datagrams
0904 Exterior Gateway Protocol formal specification

RFCs Title
0903 Reverse Address Resolution Protocol

0894 Standard for the transmission of IP datagrams over Ethernet networks
0893 Trailer encapsulations
0887 Resource Location Protocol
0877 Standard for the transmission of IP datagrams over public data networks
0861 Telnet Extended Options: List Option
0860 Telnet Timing Mark Option
0859 Telnet Status Option
0858 Telnet Suppress Go Ahead Option
0857 Telnet Echo Option
0856 Telnet Binary Transmission
0855 Telnet Option Specifications
0854 Telnet Protocol Specification
0826 Ethernet Address Resolution Protocol: Or converting network protocol addresses to
48.bit Ethernet address for transmission on Ethernet hardware
0822 Standard for the format of ARPA Internet text messages
0815 IP datagram reassembly algorithms
0793 Transmission Control Protocol
0792 Internet Control Message Protocol
0791 Internet Protocol
0790 Assigned numbers
0777 Internet Control Message Protocol
0768 User Datagram Protocol
0765 File Transfer Protocol specification
0764 Telnet Protocol specification

Following table describes the supported IEEE standards for this release of
LynxOS.
Table A-2: Supported IEEE Standards
IEEE
Title
Standards
802.1Q Virtual LANs

802.1D MAC bridges

APPENDIX B IPv6
Overview
The IPv6 protocol addresses technical limitations of IPv4. Most notably is the
increase in IP address space, which has changed from 32 to 128 bits per address.
IPv4 32-bit addresses are represented in dotted-decimal format divided along 8-bit
boundaries. IPv6 IP addresses are 128-bit address divided along 16-bit boundaries,
and each 16-bit block is converted to a 4-digit hexadecimal number and separated
by colons. For example:
200A:00A3:2C5B:0000:02FF:FF00:FE38:934A
The IPv6 address representation can be further simplified with features such as
leading zero suppression and zero compression. Detailed information on these
features as well as other information regarding the IPv6 addressing architecture are
described in RFC 2373.
Other notable improvements is the inclusion of the following services that were
optional under IPv4:
• Auto configuration--IPv6 specifies a stateless host auto configuration
mechanism which is an improvement on the optional DHCP mechanism
used with IPv4.
• Security--IPv6 mandates support for IPsec. This guarantees that a secure
IP connection can be established when communicating with IPv6
devices.
• Multicast--Muliticast is now mandatory under IPv6.
In addition, IPv6 has simpler packet header structures and also introduces a
protocol header chain that allow for more flexible protocol extensions

Appendix B - IPv6
Additional information on the specifications of IPv6 can be found at

www.ipv6.org.
Enabling IPv6
To enable the IPV6 in the Lynxos kernel, user must uncomment (by removing #
sign) the line n:hbtcpipv6:@hbtcpip0:: in the
$ENV_PREFIX/sys/bsp.<bsp_name>/config.tbl file.
rc.network6 Configuration File

The rc.network6 file is called at boot time and configures basic IPv6 functions.
This file starts IPv6, configures Ethernet interfaces, and starts IPv6 services (such
as ip6fw). This file is used for IPv6 networks only. If a system is configured for
IPv6, the rc.network6 file is used in place of rc.network IPv4
configuration file.
The default location of this file is /net/inetd/rc.network6.
rc.ipv6.conf Configuration File

The rc.ipv6.conf file includes basic configurations for the IPv6 network;
including configuration values for interfaces, routing, firewalls, and gateways. This
configuration file is sourced in by the rc.network6 file during init.
The default location of this file is /net/rc.ipv6.conf
Setting an IPv6 Address Statically

Use the following steps to configure and test the system for assigning a static IP
address. It is important to note that manually setting and maintaining IPv6 IP
addresses can be complicated. Due to the complex nature of address notation,
mistakes are more likely to occur with IPv6 than IPv4. Users are cautioned to
double check addresses set manually.

Setting up Hostname Resolution for IPv6 Addresses
1. Update /etc/hosts to include the IPv6 loopback address, the IPv6

address for the host, and an external IPv6 host address.
127.0.0.1 localhost #IPv4 Loopback Address

::1 localhost #IPv6 Loopback Address
192.168.0.1 myhost #IPv4 Hostname Address

3ffe:0501:1234:ffff:: myhost #IPv6 Hostname Address
3ffe:0501:1111:ffff:: otherhost #entry for external IPv6 host
Figure 0-1: Example IPv6 /rtc/hosts File
2. Assign an interface an IPv6 address with ifconfig. Note that for IPv6
addresses, the switch inet6 must be used:
# ifconfig <if> inet6 <address>
3. Use ping6 to ping additional IPv6 networks:
# ping6 otherhost
To ping an IPv6 host with a Link-Layer address (prefixed with fe80), the host
Ethernet interface must be specified. The following example uses the pro100
interface:
# ping6 fe80::230:65ff:fef2:7868%pro0
Setting up Hostname Resolution for IPv6 Addresses

Hostname resolution is configured by the /etc/resolv.conf file.
IPv6 addresses can be used along with IPv4 address to perform
hostname resolution. The following provides an example
resolv.conf file:
nameserver 3ffe:0501:1111:ffff::
Figure 0-2: Example IPV6 resolv.conf File
Setting up Routes with route6d

The route6d daemon is an extension of routed that includes support for RIP
over IPv6. Refer to the route6d(8) man page for syntax and usage information.

Appendix B - IPv6
Additionally, other routing demons that support IPv6 can be used; zebra, for
example. For additional information, see the GNU Zebra User’s Guide.
Using faithd to Connect IPv6 and IPv4 Networks

The faithd daemon is used to provide a IPv6 to IPv4 relay. faithd performs
TCP relay similar to firewall gateways, but with the addition of address translation.
faithd is used only to translate IPv6 addresses to IPv4.
The following provides an example of setting up and configuring faithd relay

for telnet. On the translating router where faithd runs, perform the following:
1. Use sysctl to allow for route advertising, IP6 forwarding, and faith:
# sysctl -w net.inet6.ip6.accept_rtadv=0
# sysctl -w net.inet6.ip6.forwarding=1
# sysctl -w net.inet6.ip6.keepfaith=1
2. Start the faith0 interface, and create a route to faith0:

# ifconfig faith0 up
# route add -inet6 3ffe:501:1234:ffff:: \
-prefixlen 96 ::1
# route change -inet6 3ffe:501:1234:ffff:: \
-prefixlen 96 -ifp faith0
3. Execute faithd for the telnet port as follows:
# faithd telnet /net/telnetd
The first argument is a service name for TCP relay. The service can be specified
either by the port number (23) or by service name (telnet). The second argument
is a path name for the local IPv6 TCP server. If there is a connection to the router
itself, this program is invoked.
Note that faithd must be invoked for each service required.

Hostname Resolution Between IPv6 and IPv4 Hosts
Hostname Resolution Between IPv6 and IPv4 Hosts

The simplest way to translate an IPv4 address to IPv6 address is to add an entry to
the /etc/hosts file. On the IPv6 host, add a line that resolves the IPv6 and IPv4
addresses:
3ffe:0501:1234:ffff:: 192.168.0.1 hostname
Figure 0-3: /etc/hosts Example

Appendix B - IPv6

Index
brconfig utility 60
bridging 59
Symbols
??–25
C
calculating message digest for data 101
Numerics CBQ 68
CBQ classifier 69
802.1 standards 59
CBQ configuration file 68
CBQ monitoring 74
CBQ setting for slow interface 72
class command 68
A commands
access control rules 37 ftp 15
addressing 52 ping 2
administration files rlogin 2
/etc/exports 46 rsh 3
admission control 81 telnet 3
aggregated traffic 73 concave service curve 76
aggregated traffic limitations 73 connecting to the secure server using SSL 102
altq.conf 81 contacting LynuxWorks x
altq.conf configuration file 71 Contents iii
altqd 63 creating a self-signed certificate 101
altqd config file 70 creating the SSL server from the command
altqd utility daemon 63 line 103
altqstat program 74 cryptography library 97
B D
basic CBQ commands 68 database
bind 104 hosts 2
borrow 68 default class 80
borrowing dhclient 43
limitations 75 DHCP 39

Index
about 39 firewalls
client 43 ipfw 25
dhclient 43 forwarding cache management 61
dhcpd 41 ftp
dhcpd.conf 42 commands
leases 43 getting a list of 15
LynxOS files 40 putting files on a remote host 14
man pages 40 transferring binary files 14
server 41 transferring files with 13
storage of parameters 39
using DHCP and bootp 44
dhcpd 41
dhcpd.conf 42 H
Differentiated Service Code Point 63
diffserv 85 HFSC 76
DNS client configuration 20 HFSC hierarchical link-sharing 78
documents HFSC real-time scheduling 78
online viii HFSC scheduling 78
DSCP 63 HFSC service curve 76
Dynamic Host Configuration Protocol 39 Hierarchical Fair Service Curve 76
hierarchical link-sharing 79
hostname databases
.rhosts 3, 16
E /etc/hosts.equiv 10
Hosts
ECN 64, 84 remote, executing commands 3
ECN-capable TCP 64 hosts
encrypted communications 33 database 2
encrypting and decrypting data with setting up for remote access 3
OpenSSL 100 hosts.allow and hosts.deny files 37
Ethernet interface
configuring 1
Explicit Congestion Notification 64, 84
I
ifconfig 1
F IGMP 53
IGMPv1 54
FIFOQ (First-In First-Out Queuing) 90 IGMPv2 54
FIFOQ, using 90 installing OpenSSL 99
files interface command 68
binary, transferring 14 interface rate-limiting 67
getting from a remote host 14 interface rate-limiting with a queuing
host database 2 discipline 67
host, setting up 3 Internet Group Management Protocol 53
resolv.conf 7 IP Multicasting 51
resolv.conf, setting up 3 IP QoS 65
transferring with ftp 13 IPsec 28
filter command 68 AH, ESP security protocols 28
filter-matching rule 69 SAD (Security Association Database) 29

setkey 29 AH, ESP security protocols 28
SPD (Security Policy Database) 29 SAD (Security Association
IPv4 multicast addresses 53 Database) 29
setkey 29
SPD (Security Policy Database) 29
Network Time Protocol 18
L NFS client, enable/disable 46
NFS server
Layer 2 (Ethernet) 59 configuring 46
Layer 3 (IP) 63 exporting/unexporting directories 49
limitations of borrowing 75 starting/stopping 49
logging on tuning 48
remotely 2 NFS server tunable parameters 48
remotely with telnet 3 NFS server, enable/disable 46
LynuxWorks, contacting x NFS support in LnyxOS 46
LynxOS NTP 18
reference manuals viii NTP daemons 19
LynxOS support 59, 64
O
M
online help viii
MAC address 52 Open Secure Shell 33
man pages viii openntpd 19
multicast address 52 OpenSSH 33
multicasting 51 OpenSSH configuration files 33
OpenSSL 97
SNMPv3 requirements 92
OpenSSL components 97
N OpenSSL cross-development installation 99
OpenSSL documentation 99
net-SNMP 104 OpenSSL legal issues 104
adding custom modules 95 OpenSSL library 98, 99
components 94 OpenSSL license & copyright 105
documentation 93 OpenSSL native installation 99
known limitations 95 OpenSSL tool 98
license & copyright 95 OpenSSL tool, adding to a LynxOS KDI 100
SNMP protocol overview 92
v3 OpenSSL requirements 92
netstat command 65
netstat output 57 P
network card
configuring 1 IPFW (legacy utility) 25
network connectivity tools 33 ping command 2
network device driver behavior 66 testing TCP/IP 4
network security 25 protocols
firewalls ftp 13
IPFW 25 telnet 3
IPsec 28 tftp 16

Index
SNTP 20
socket options 54
Q spanning tree 60
ssh client configuration 35
QoS 63
ssh daemon configuration 33
Quality of Service 59, 63
SSH protocol suite 33
ssh utility 10
ssh_config 35
ssh_config configuration file example 35
R sshd_config 33
racoon 104 sshd_config configuration file example 33
Random Early Detection 84 sysctl variables 56
rc.network 2
real-time scheduling 79
RED 84
reference manuals viii T
registration 53
tbrconfig utility 66
remote
TCP 1
utilities, ping 4
TCP/IP
remote host
resolv.conf 7
putting files on a 14
testing 4
retrieving files from 14
TCP/IP components
reserved real-time bandwidth 81
/etc/hosts file 3
resolv.conf 7
/etc/resolv.conf file 3
RFCs
hosts file 2
supported 107
ping 2
rlogin utility 10
rlogin command 2
root class 80
rsh command 3
rsh utility 12
telnet command 3
Technical Support x
Telnet utility 8
testing
S TCP/IP 4
sample setting using CBQ 70 TFTP
scp 13, 16, 20 overview 15
Secure Remote Copy 20 secure transfers 16
Secure Sockets Layer 97 simple transfers 15
secure tftp 16 token-bucket regulator 66
security Traffic Management 59
network 25 transport layer 65
service curve, concave 76 Transport Layer Security 97
service curve, convex 77 troubleshooting
service curves in altq.conf 81 TCP/IP 4
setsockopt() 54 tune token bucket 66
shaping by HFSC 82 typographical conventions viii
Simple Network Time Protocol 20
simple rate-limiting by tbrconf 67
SNMP
protocol overview 92

U
UCD-SNMP 91
unicasting 51
using OpenSSL in LynxOS applications 104
utilities
telnet 8
V
Virtual Local Area Network 62
virtual time 77
VLAN 62
VLAN identifier 62
W
Weighted Fair Queuing 89
WFQ 89
X
xntpd 19

Index

0817 00 Los5 - NG

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0817 00 Los5 - NG

Uploaded by

Copyright:

Available Formats

3

LynxOS Networking Guide

Copyright ©1987 - 2008, LynuxWorks, Inc. All rights reserved.

Printed in the United States of America.

PREFACE .............................................................................................................. VII

CHAPTER 1 TCP/IP AND NETWORKING UTILITIES ......................................................... 1

LynxOS Networking Guide iii

CHAPTER 2 NETWORK SECURITY ............................................................................... 25

CHAPTER 3 DHCP .................................................................................................... 39

CHAPTER 4 NFS ....................................................................................................... 45

iv LynxOS Networking Guide

CHAPTER 5 MULTICASTING ....................................................................................... 51

CHAPTER 6 TRAFFIC MANAGEMENT AND QUALITY OF SERVICE ................................... 59

CHAPTER 7 NET-SNMP ............................................................................................ 91

LynxOS Networking Guide v

CHAPTER 8 OPENSSL ............................................................................................... 97

APPENDIX A SUPPORTED NETWORKING STANDARDS ................................................. 107

APPENDIX B IPV6 ..................................................................................................... 119

INDEX ............................................................................................................ 125

vi LynxOS Networking Guide

The LynxOS Networking Guide contains information about configuring LynxOS

For More Information

LynxOS Networking Guide vii

Kind of Text Examples

Environment variables, filenames, ls

Text that represents a variable, such as a cat filename

viii LynxOS Networking Guide

Kind of Text Examples

Blocks of text that appear on the display Loading file /tftpboot/shell.kdi

LynxOS (ppc) created Mon Jul 17

Keyboard options, button names, and Enter, Ctrl-C

NOTE: These callouts note important or useful points in the text.

LynxOS Networking Guide ix

How to Submit a Support Request

x LynxOS Networking Guide

Where to Submit a Support Request

Support, Europe tech_europe@lnxw.com

Training and courses USA: +1 408-979-4353

Support, Europe +33 1 30 85 06 06

LynxOS Networking Guide xi

xii LynxOS Networking Guide

CHAPTER 1 TCP/IP and Networking Utilities

Transmission Control Protocol/Internet Protocol

Enabling/Disabling TCP/IP Support

Configuring Ethernet Cards with ifconfig

LynxOS Networking Guide 1

To use ifconfig to configure a network interface, place the command in

Common TCP/IP Utilities

Table 1-1: LynxOS TCP/IP Components

ping Sends a packet of data to a system to determine if it is on the

2 LynxOS Networking Guide

Table 1-1: LynxOS TCP/IP Components (Continued)

/etc/hosts This file contains the list of hosts on the network.

LynxOS Networking Guide 3

Testing TCP/IP (ping)

Figure 1-1: Testing TCP/IP with ping

4 LynxOS Networking Guide

Figure 1-2: Using ping to test TCP/IP

Figure 1-3: Pinging Other Hosts on a Network

The /etc/hosts File

LynxOS Networking Guide 5

[bash: /] $ ping fish

Figure 1-4: Host Not Defined in /etc/hosts