This chapter describes how to configure and start Frame Relay. It provides descriptions of the commands, configuration files, and configuration parameters within the configuration files. The sections are:
“Configuring the Frame Relay Network”—the configurable parameters that can be used to dynamically tune the network protocol drivers. This tuning may take place at network startup time and, in some cases, while the network is already up.
“Starting and Stopping Frame Relay”—how Frame Relay is controlled by the network daemon snetd.
“Installation Verification”—how to verify that your installation and configuration is correct.
Additional information on Frame Relay is available in the online reference pages, which describe all programs, utilities, and system files. References to these pages include the section number, for example, ifrstat(1M).
The Frame Relay network configuration is held in the file /etc/config/snetd.options. The following example shows the MFE driver is configured to support the IP network layer protocols.
wan01 d /dev/vsc/wan01
wan03 d /dev/vsc/wan03
wan11 d /dev/vsc/wan11
wan13 d /dev/vsc/wan13
wan21 d /dev/vsc/wan21
wan23 d /dev/vsc/wan23
wan31 d /dev/vsc/wan31
wan33 d /dev/vsc/wan33
ip_mfe dc /dev/ip_mfe
ifr dc /dev/ifr
mfe dc /dev/mfe
%%
ip_mfe mfe
IP_NET={192.26.76.10,255.255.255.0,forwb=n,kalive=y,1500,fr,192.26.76.12} \
SHELL="mfevc -sB -c40 -d /dev/ip_mfe -A def.mfe"
mfe ifr SHELL="mfevc -sB -c40 -A def.mfe" \
SHELL="mfeproto -p40 -d /dev/mfe -A ip.mfe"
ifr wan31 IFR_SET_SNID=B \
SHELL="ifrtune -sB -P def.dte.ifr" \
SHELL="ifrdlci -sB -c40 -A def.dlci"
|
In this example, snetd configures the network as follows:
Configures MFE to support the IP network layer protocols.
Links a single stream between IFR and the WAN driver and assigns it the subnetwork identifier B.
Configures the stream with the default WAN and IFR subnetwork parameters.
Links a single stream between MFE and IFR and binds them to VCID 40 on subnetwork B.
Frame Relay implements a comprehensive range of configurable parameters for IFR and MFE. These are described in this section.
The parameters are held in template files. Most of the parameters are configurable and can be changed by editing the file with a text editor.
 | Note: It is recommended that you use the default parameters, as supplied by Silicon Graphics. Unless you are familiar with Frame Relay or are working under the direction of Silicon Graphics support personnel, care should be used when modifying parameters. |
Using files to store parameters has two advantages:
You can switch quickly between different network setups, if the files already exist, without having to directly modify any parameters.
If you do have to change one parameter, there's no need to set all the rest. You can keep their existing values.
A number of default template files are provided with Frame Relay. These are:
You can also create your own files, based on the template files, to suit your own network topologies.
All template files, default or otherwise, must be located in the directory /var/opt/snet/template.
The IFR subnetwork parameters are described in ifrtplate(4). Each stream between IFR and the WAN driver represents a subnetwork. IFR subnetworks are configured using the ifrtune(1M) utility.
The IFR DLCI parameters are described in ifrdlciconf(4). IFR can support multiple PVCs (there is a compile-time configurable limit), each being identified by its DLCI. PVCs are configured using the ifrdlci(1M) utility.
| CIR | Committed information rate. The committed rate (in bits per second) at which the Frame Relay network accepts information from the user system under normal conditions. IFR uses this value to flow control PVC users. This value must be configured in accordance with your line speed. | |
| Bc | Committed burst size. The maximum amount of data (in bits) that the Frame Relay network agrees to transfer, under normal conditions, during a measurement interval. This data may or may not be contiguous (that is, it may appear in one or more frames). The measurement interval is defined as T = Bc/CIR, where CIR is the committed information rate and Bc is the committed burst size. This value must be configured in accordance with your line speed. Typically, Bc is 1/10 of CIR. | |
| Be | Excess burst size. The maximum amount of data (in bits), in excess of the committed burst size, that the Frame Relay network attempts to deliver during a measurement interval. This data may or may not be contiguous (that is, it may appear in one or more frames). Excess burst is marked discard–eligible (DE bit) by the IFR driver. This value must be configured in accordance with your line speed. If set to 0, IFR will not mark any data as discard-eligible. | |
| STEPCOUNT | Step count. The value is used by IFR when transmitting frames to increase or reduce the committed information rate. If IFR receives this number of consecutive frames with the BECN bit set, it reduces its CIR to the “next step” rate below the current offered rate. If it receives this number of consecutive frames and the BECN bit is not set, it increases its CIR. | |
| FLOWSTYLE | Flow control style. This value determines the type of congestion control used by IFR. The value is a bit mask, so both types can be enabled by adding the values (for example, 3 enables FECN and BECN). FECN-based control alters the CIR based on the number of frames received with the FECN bit set versus the number of frames received without the FECN bit set over a given period. BECN-based control alters the CIR based on the number of consecutive frames received with or without the BECN bit set during a given period. Permitted values are: 0 No flow control 1 FECN 2 BECN |
The MFE PVC parameters are described in mfetemplate(4). Each stream between MFE and IFR represents a PVC to be used for multiprotocol encapsulation and is configured with the mfevc(1M) utility.
| ADRLEN | Address length. The length (in bytes) of the Frame Relay address field (DLCI) to assume if no other information is received from the IFR driver. Only 2-byte addresses are supported by IFR. | |
| MAXSDU | Maximum DLSDU size. The maximum Data Link Service Data Unit (DLSDU) size (in bytes) to assume no other information is received from the IFR driver. Any maximum DLSDU size indicated by IFR is always used in preference. This value is used by MFE to determine when to fragment outgoing PDUs. | |
| MAXPDU | Maximum PDU size. The maximum size (in bytes) of a PDU that can be reassembled by MFE. This value is used to limit the length of the reassembly queue for incoming fragmented PDUs. PDUs longer than this are discarded. | |
| FRGSEQ | Sequence number. The initial sequence number to use in outgoing fragmented PDUs. A value of 0 means choose a random value, which is the recommended behavior. |
The MFE protocol parameters are described in mfeprotoconf(4). MFE can support a number of protocols (there is a compile-time upper limit). Protocols are configured using the mfeproto(1M) utility.
| MINPDUSZ | Minimum PDU size. The minimum PDU size required by the network layer. The actual value conveyed by MFE to the upper datalink service user is the greater of this value and the maximum DLSDU size supported by the attached subnetwork or virtual circuit, less the MFE encapsulation header length. This value is configurable to support network layer protocols, which require a reasonably large maximum DLSDU size. For example, the OSI IS-IS routing protocol requires at least 512 bytes to work, which means some IS-IS PDUs are fragmented and reassembled by MFE if the maximum DLSDU size supported by the network is less than 512 bytes. | |
| ENCAPS | Encapsulation header. The encapsulation header (as a hexadecimal string) to prepend to all outgoing PDUs. The string must have an even number of digits. A zero length string is indicated by two dashes (--). OSI PDUs have no encapsulation header; IP packets use CC. | |
| RETAIN | An indication as to whether or not the encapsulation header should be retained in incoming PDUs. Use Y to retain the header, N to remove it. OSI PDUs retain their headers; IP packets do not. | |
| COUNT | The number of encapsulation headers to be used for demultiplexing. Up to 3 are supported. This allows OSI CLNP, ES-IS, and IS-IS PDUs to be received on the same upper stream. | |
| DEMUX | Demultiplexing header. The encapsulation headers (as hexadecimal strings) to be used for demultiplexing. The strings must have an even number of digits. A zero-length string is indicated by two dashes. Only the first Count strings are significant. |
The Frame Relay networking software is initialized by a network daemon program called snetd (see snetd(1M)). snetd links the network drivers and configures them, as defined by various Frame Relay network configuration files. It supports the network by keeping open the STREAMS file descriptor(s) used for linking the stack.
The snetd daemon sleeps silently while the network is up.
Killing snetd closes all STREAMS file descriptors used for linking the stack, reinitializes all Frame Relay kernel data structures, and frees any resources.
| Note: Killing snetd also kills all other communications services it supports such as X.25, SNA, and Frame Relay. |
To start Frame Relay, follow these steps:
Change directories to /etc/config. Type:
cd /etc/config
Edit the file snetd.options to reflect your site configuration. Refer to “Configuring the Frame Relay Network” if necessary.
Start the snetd daemon. Type:
snetd
The snetd daemon reads the file snetd.options and uses the configuration parameters to start Frame Relay.
This section describes how to verify a correct installation and check that IFR is correctly communicating with the remote site.
The installed software can be verified using the netstat command, as follows:
#netstat -ia |
An example of the output, based on the sample configuration in the snetd.options file used in Chapter 2, follows:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
et0 1500 150.166.43 whoopi.engr.sgi 20002 0 3849 0 32
allhosts-mcast
08:00:69:02:4b:b6
fv0 4472 150.166.13 tr-whoopi.engr. 1466 0 1449 1 0
allhosts-mcast
40:00:70:00:00:02
lo0 8304 loopback localhost 2538 0 2538 0 0
allhosts-mcast
fr0 1500 (pt-to-pt) fr-barrow.engr 426 0 1324 0 0
allhosts-mcast
|
The ifconfig command can be used to verify the setup of the Frame Relay interface, fr0, as follows.
#ifconfig fr0 |
An example of the output, based on the sample configuration snetd.options file used in Chapter 2, follows:
fr0: flags=851<UP,POINTOPOINT,RUNNING,MULTICAST>
inet 192.26.76.10 --> 192.26.76.12 netmask 0xffffff00
|
The ifrstat(1M) utility can be used to check the status with the remote site. The following output shows the network is OK and two PVCs are ACTIVE. The values in the txpkts and rxpkts columns should be incrementing if Frame Relay is running correctly.
#../bin/ifrstat -sA -S
#########################################################################################
# Statistics for PPA A #
#########################################################################################
PPA txpkts rxpkts txbytes rxbytes wanflows date cleared
A 10 10 140 160 0 May 15 15:41:05
rxtoobig rxinvDLCI rxunaDLCI txstops txnobuffs txinvrq rxdrops rxinvrq
0 0 0 0 0 0 0 0
LMItxpoll LMIwnflow rxfull rxseqonly rxasynch rxBECN rxLMIerr LMItimout
10 0 2 8 0 0 0 0
LMIrxpoll txfull txseqonly txasynch txBECN rxpollerr
0 0 0 0 0 0
#########################################################################################
# Status Report for PPA A #
#########################################################################################
Network status (LMI):ALL OK
DLCIs :
40 : ACTIVE
32 : ACTIVE
|
You can check on the current configuration of a particular network driver by running the appropriate tuner application (see ifrtune(1M), ifrdlci(1M), mfevc(1M), mfeproto(1M)).