Sangoma's frame relay implementation complies with ANSI Annex D specification. Make sure your frame realy provider supports ANSI Annex D link management. FLIP CANNOT BE USED WITH FRAME RELAY NETWORKS USING LMI SPECIFICATION! Refer to Appendix A "Frame Relay Basics" for more information on frame realy protocol.
WANPIPE FLIP subsystem takes full advantage of frame relay multiplexing capabilities, i.e. Linux network interfaces are created on per-DLCI basis, alowing you perform DLCI-based routing.
Setting up FLIP subsystem involves creating configuration file for each frame relay link and defining network interfaces for each DLCI. Here we assume that at least one frame relay link was defined during WANPIPE configuration by binding SDLA card to frame relay protocol (refer to Chapter 4, "Configuring WANPIPE" for details).
FLIP configuration files are plain ASCII text files that can by created and edited with any text editor, such as vi. They are placed into directory /usr/lib/wanpipe/cfg and named flip.N, where 'N' is an SDLA card number (0 through 7). I.e. configuration file flip.0 defines configuration for the frame relay link connected to SDLA #0 (/dev/sdla0), flip.1 - for SDLA #1 (/dev/sdla1) and so on. Sample configuration files are included with the distribution.
Configuration file consists of single-line records of the following format:
keyword=value
where
The syntax above shows an equal sign ('=') used as a separator between the {keyword} and {value} fields. In fact, you can use any number of whitespace characters (Space or Tab) instead or in addition to it to separate these fields.
Valid keywords and corresponding configuration options are listed below:
This parameter specifies whether the adapter should operate as a Customer Premises Equipment (CPE) or emulate a Frame Relay switch (Access Node). The options are:
This parameter specifies the type of physical interface. The options are:
This parameter specifies whether the adapter should use the trasmit/receive clock signal provided by the external communication equipment such as CSU/DSU or generate the clock itself. The options are:
This parameter specifies the speed (in bits per second) at which the communication is taking place. The minimum baud rate is 1200 kbps and the maximum one depends on the adapter type. It should be noted, that this parameter is required even if external clocking is used. The typical values are:
This is your Committed Information Rate. Its value (in bps) should not exceed your baud rate or 512000, whichever is less.
This is Maximum Transmit Unit size. Its value (in bytes) determines the maximum size of data packet you can send over the Frame Relay link. Note that this also includes header information required for encapsulating higher level protocols such as TCP/IP and IPX. The maximum MTU size supported by the adapter is 4096 bytes.
This is the Link Integrity Verification Timer value in seconds. It should be within a range from 5 to 30 and is relevant only if adapter is configured as CPE.
This is the Polling Verification Timer value in seconds. It should be within a range from 5 to 30 and is relevant only if adapter is configured as Access Node.
This is the Full Status Polling Cycle Counter. Its value should be within a range from 1 to 255 and is relevant only if adapter is configured as CPE.
This is the Error Threshold Counter. Its value should be within a range from 1 to 10 and is relevant for both CPE and Access Node configurations.
This is the Monitored Events Counter. Its value should be within a range from 1 to 10 and is relevant for both CPE and Access Node configurations.
To define define frame relay network interfaces start WANPIPE configuration script as described in Chapter 4, "Configuring WANPIPE", selecl "configure link" from the main menu, then select the adapter used by the link you are configuring. This will take you to the FLIP confiration script. Alternatively, you can start this script by entering the following command:
/usr/lib/wanpipe/conf/flip
Select "add interface" from the FLIP configuration menu. A list of SDLA cards defined as frame relay links during the WANPIPE configuration appears. Select a card you want this interface to be defined for. Enter DLCI number for this interface. And finally, enter a number that will be used to construct interface name.
All FLIP interfaces are named flipN, where N is an arbitrary decimal number from 0 to 999 you assign to this interface. An interface named 'flip' (without a number appended to it) is always created when FLIP module is loaded. This interface is used exclusively by the FLIP configuration utility (flipcfg) located in /usr/sbin directory to dynamically configure FLIP driver and can not be used to transmit and receive data.
Repeat these steps until all interfaces for all frame relay links are defined then enter "q" to exit the configuration script.
Note that FLIP configuration script merely modifies subsystem configuration file (/etc/flip.conf) and does not affect current state of configured links and interfaces. For the configuration changes to take an effect FLIP subsystem must be restarted by executing the following commands:
/usr/lib/wanpipe/init/flip stop
/usr/lib/wanpipe/init/flip start
Note that if there already were FLIP network interfaces configured, you have to down them before restarting FLIP subsystem.
Alternatively, you can restart entire WANPIPE as described in Chapter 4, "Configuring WANPIPE".
When used in native synchronous communications enviroment, the benefits of PPP are even greater. The main is speed. Asynchronous protocols need at least 10 bits to transfer a byte (8 bits of data + 1 start bit + at least 1 stop bit), while synchronous protocols transfer data as a stream of bits, without a need to mark byte boundaries. This alone makes synchronous protocols at least 20% faster than asychronous protocols with the same line speed.
Consider 19.2 kbps line. The maximum data transfer rate you can achive with asynchronous protocol is 1.92 kilobytes per second (19.2 divided by 10). With synchronous communications the maximum data trasfer rate is 2.4 kilobytes per second (19.2 devided by 8), resulting in additional 3.26 kbps throughput. The higher the line speed, the bigger the savings. With 64 kbps line, switching to synchronous protocol saves the bandwidth of 12.8 kbps.
Sangoma's PPP implementation is compliant with RFCs 1661, 1662, 1663 and can be used to connect to many PPP routers or to another Sangoma card running PPP firmware (drivers for SCO Unix, Novell NetWare (tm), Windows NT (tm) and Windows (tm) 95 are available). Although synchronous PPP is most suited for communications over the leased lines, regular telephone lines can also be used (provided that modem supports synchronous mode).
Since PPP, unlike frame relay, is not multiplexing protocol (i.e. only one logical channel exists for each physical link), SPPP subsystem configuration is much simplier than that of the FLIP subsystem. Setting up SPPP subsystem is limited to creating configuration files for each PPP link. Single Linux network interface is created for each link atomatically. (Mind you that data links are defined by binding SDLA cards to protocol-specific modules using WANPIPE configuration script. Refer to Chapter 4, "Configuring WANPIPE" for details.)
Syncronous PPP network interfaces are named 'spppN', where 'N' is a number of SDLA card (0 - 7) used by this interface. I.e. if synchronous PPP link was defined for SDLA card #3 (/dev/sdla3), the corresponding interface is named sppp3.
SPPP configuration files are plain ASCII text files that can by created and edited with any text editor, such as vi. They are placed into directory /usr/lib/wanpipe/cfg and named 'sppp.N', where 'N' has the same meaning as in interface names (i.e. configuration file sppp.3 defines configuration for the PPP link connected to SDLA #3, i.e. /dev/sdla3). Sample configuration files are included with the distribution.
Configuration file consists of single-line records of the following format:
keyword=value
where
It also may include comments, identified by the '#' character. In fact, all characters following '#' are ignored, so you can append comments to the configuration records. Empty lines are ignored as well.
The syntax above shows an equal sign ('=') used as a separator between the {keyword} and {value} fields. In fact, you can use any number of whitespace characters (Space or Tab) instead or in addition to it to separate these fields.
Valid keywords and corresponding configuration options are listed below:
This parameter specifies the type of physical interface. The options are:
This parameter specifies whether the adapter should use the trasmit/receive clock signal provided by an external communication equipment such as CSU/DSU or generate the clock itself. The options are:
This parameter specifies the speed (in bits per second) at which the communication is taking place. The minimum baud rate is 1200 kbps and the maximum one depends on the adapter type. It should be noted, that this parameter is required even if external clocking is used. The typical values are:
This is time in 10ths of a second between successive retransmissions of Configure-Request or Terminate-Request packets.
Range: 1-2621. Recommended value is 30.
This is time in 10ths of a second between successive retransmissions of Authenticate-Request or Challenge packets (PAP and CHAP).
Range: 1-2621. Recommended value is 30.
This is time in 10ths of a second for PAP or CHAP to wait for a reply or a request before terminating the link.
Range: 1-2621. Recommended value is 300.
This is time in 10ths of a second to wait since DCD or CTS dropped before declaring the link disconnected.
Range: 1-2621. Recommended value is 10.
This is minimum time in 10ths of a second to keep DTR and CTS low during disconnection. This is normally greater than ModemTimeout.
Range: 1-2621. Recommended value is 15.
This is time in 10ths of a second to wait for DCD to go high during a connection attempt before dropping DTR to hang up. If this peer must wait for incoming connections, this should be set to zero.
Range: 0-2621.
This is number of Configure-Request packets sent without receiving a reply before terminating the link.
Range: 1-65535. Recommended value is 10.
Number of Terminate-Request packets sent without receiving a reply before terminating the link.
Range: 1-65535. Recommended value is 2.
Number of Configure-Nak packets sent without sending a Configure-Ack before assuming the configuration is not converging. In some cases, the Configure-Nak packets are then converted to Configure-Reject packets; otherwise the link will be immediately terminated.
Range: 1-65535. Recommended value is 5.
Number of Authenticate-Request or Challenge packets sent without receiving a reply before terminating the link.
Range: 1-65535. Recommended value is 10.