Frame Relay был создан в начале 1990-х в качестве замены протоколу X.25 для быстрых надёжных каналов связи, технология FR архитектурно основывалась на X.25 и во многом сходна с этим протоколом, однако в отличие от X.25, рассчитанного на линии с достаточно высокой частотой ошибок, FR изначально ориентировался на физические линии с низкой частотой ошибок, и поэтому большая часть механизмов коррекции ошибок X.25 в состав стандарта FR не вошла. В разработке спецификации принимали участие многие организации; многочисленные поставщики поддерживают каждую из существующих реализаций, производя соответствующее аппаратное и программное обеспечение.
Frame relay обеспечивает множество независимых виртуальных каналов (Virtual Circuits, VC) в одной линии связи, идентифицируемых в FR-сети по идентификаторам подключения к соединению (Data Link Connection Identifier, DLCI). Вместо средств управления потоком включает функции извещения о перегрузках в сети. Возможно назначение минимальной гарантированной скорости (CIR) для каждого виртуального канала.
В основном применяется при построении территориально распределённых корпоративных сетей, а также в составе решений, связанных с обеспечением гарантированной пропускной способности канала передачи данных (VoIP, видеоконференции и т. п.).
Содержание
Формат кадра
Наименования и значения полей:
Имя поля
Назначение
DLCI
Data Link Connection Identifier — идентификатор виртуального канала (PVC), мультиплексируемого в физический канал. DLCI имеют только локальное значение и не обеспечивают внутрисетевой адресации.
C/R
Command / Response — признак «команда-ответ», по аналогии с протоколом HDLC.
EA
Address Field Extension Bit — бит расширения адреса. DLCI содержится в 10 битах, входящих в два октета заголовка, однако возможно расширение заголовка на целое число дополнительных октетов с целью указания адреса, состоящего более чем из 10 бит. EA устанавливается в конце каждого октета заголовка; если он имеет значение «1», то это означает, что данный октет в заголовке последний.
FECN
Forward Explicit Congestion Notification — извещение о перегрузке канала в прямом направлении.
BECN
Backward Explicit Congestion Notification — извещение о перегрузке канала в обратном направлении.
DE
Discard Eligibility Indicator — индикатор разрешения сброса кадра при перегрузке канала. Выставляется в «1» для данных, подлежащих передаче в негарантированной полосе (EIR) и указывает на то, что данный кадр может быть уничтожен в первую очередь.
CIR и EIR
CIR (англ. Committed Information Rate ) — гарантированная полоса пропускания виртуального канала PVC в сетях Frame Relay (FR).
В первоначальном наборе стандартов (ANSI T1S1) CIR как отдельный параметр отсутствует, но для отдельного виртуального канала были определены параметры B(c) (bits committed, Committed Burst Size), B(e) (bits excess) и T(c) (Committed Rate Measurement Interval). B(c) при этом определяется как количество бит, гарантированно передаваемых за время T(c) даже при перегрузке сети, B(e) — максимальное количество бит, которые могут быть переданы за время T(c) при недогрузке сети, то есть без гарантии доставки: заголовки пакетов, отправляемые после превышения B(c) метятся битом DE (discard eligible, аналогичен CLP в ATM) и в случае возникновения в сети перегрузки уничтожаются на коммутаторах перегруженного участка.
Таким образом, для виртуального канала могут быть определены две полосы пропускания:
Возможна настройка и работа FR-каналов со значением CIR, равным нулю.
В ANSI T1S1 значение T(c) не было определено, так как значения T(c), B(c) и B(e) являются связанными параметрами, зависящими от скоростей физических интерфейсов, агрегированных полос пропускания виртуальных каналов, размеров буферов FR-коммутатора и других параметров, зависящих от реализации и настроек коммутатора.
Однако CIR и EIR оказались удобными показателями для описания параметров каналов при заключении соглашений между операторами FR-сетей и потребителями их услуг, более того, во многих случаях T(c) может динамически пересчитываться в зависимости от характера трафика, поэтому в RFC 3133 (Terminology for Frame Relay Benchmarking) CIR является первичным параметром и T(c) определяется как временной интервал, необходимый для поддержания CIR, то есть T(c)=B(c)/CIR, выступая в качестве аналога TCP Sliding Window.
В сетевых технологиях при множественном доступе к разделяемому каналу с двухуровневой приоритизацией (некоторые беспроводные и спутниковые сети и т. д.) также используют термин CIR для приоритезируемой клиентской полосы пропускания, при этом CIR является одним из целевых параметров конфигурации шейперов (shapers) — подсистем сглаживания трафика с буферизацией (RFC 2963, A Rate Adaptive Shaper for Differentiated Services), в этом случае вместо EIR используется комбинация параметров MIR (Maximum Information Rate) и PIR (Peak Information Rate).
Виртуальные каналы (PVC и SVC)
Для передачи данных от отправителя к получателю в сети Frame Relay создаются виртуальные каналы, VC (англ. Virtual Circuit), которые бывают двух видов:
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Results
Chapter: Configuring Frame Relay
Configuring Frame Relay
Frame Relay is a high-performance Wide Area Network (WAN) protocol that operates at the physical and data link layers. The Cisco IOS XE Frame Relay implementation currently supports routing for IPv4, IPv6, and Multiprotocol Label Switching (MPLS).
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Restrictions for Configuring Frame Relay
Cisco IOS XE software does not support the following:
Multipoint permanent virtual circuits (PVCs)
Switched virtual circuits (SVCs)
Frame relay switching
4-byte extended addresses
FRF.9 payload compression
Data stream compression
Packet by packet encapsulation payload compression
MQC based frame relay traffic shaping is not supported on frame relay main interface.
Function «set fr-de» for HQos configuration
Information About Frame Relay
Frame Relay Hardware Configurations
You can create Frame Relay connections using one of the following hardware configurations:
Devices and access servers connected directly to the Frame Relay switch
Devices and access servers connected directly to a channel service unit/digital service unit (CSU/DSU), which then connects to a remote Frame Relay switch
Note
Devices can connect to Frame Relay networks either by direct connection to a Frame Relay switch, through a direct connection to a Point of sale (POS) interface or a T1/T3 interface, or through CSU/DSUs. However, a single device interface configured for Frame Relay can be configured for only one of these methods.
The CSU/DSU converts V.35 or RS-449 signals to the properly coded T1 transmission signal for successful reception by the Frame Relay network. The figure below illustrates the connections among the components.
Figure 1. Typical Frame Relay Configuration
The Frame Relay interface actually consists of one physical connection between the network server and the switch that provides the service. This single physical connection provides direct connectivity to each device on a network.
Frame Relay Encapsulation
Frame Relay supports encapsulation of all supported protocols in conformance with RFC 1490, Multiprotocol Interconnect over Frame Relay, allowing interoperability among multiple vendors. Use the IETF form of Frame Relay encapsulation if your device or access server is connected to another vendor’s equipment across a Frame Relay network. IETF encapsulation is supported either at the interface level or on a per-VC basis.
Shut down the interface prior to changing encapsulation types. Although shutting down the interface is not required, it ensures that the interface is reset for the new encapsulation.
Dynamic or Static Address Mapping
Dynamic Address Mapping
Dynamic address mapping uses Frame Relay Inverse Address Resolution Protocol (ARP) to request the next-hop protocol address for a specific connection, given its known Data link connection identifier (DLCI). Responses to Inverse ARP requests are entered in an address-to-DLCI mapping table on the device or access server. The DLCI mapping table is then used to supply the next-hop protocol address or the DLCI for outgoing traffic.
Inverse ARP is enabled by default for all protocols it supports. However, it can be disabled for specific protocol-DLCI pairs. As a result, you can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can explicitly disable Inverse ARP for a protocol-DLCI pair if you know that the protocol is not supported on the other end of the connection. For more information, see the Disabling or Reenabling Frame Relay Inverse ARP section.
Note
Because Inverse ARP is enabled by default, no additional command is required to configure dynamic mapping on an interface and packets are not sent out for protocols that are not enabled on the interface.
Static Address Mapping
A static map links a specified next-hop protocol address to a specified Data link connection identifier (DLCI). Static mapping removes the need for Inverse Address Resolution Protocol (ARP) requests; when you supply a static map, Inverse ARP is automatically disabled for the specified protocol on the specified DLCI. You must use static mapping in the any of the following scenarios:
If the device at the other end does not support Inverse ARP at all
If the device does not support Inverse ARP for a specific protocol that you want to use over Frame Relay.
You can simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task. Refer to the frame-relay map command description in the Cisco IOS Wide-Area Networking Command Reference and the examples at the end of this chapter for more information about using the broadcast keyword.
The software supports Local Management Interface (LMI) autosense, which enables the interface to determine the LMI type supported by the switch. Support for LMI autosense means that you need not configure the LMI explicitly.
LMI autosense is active in the following situations:
The device is powered up or the interface changes state to up.
The line protocol is down but the line is up.
The interface is a Frame Relay Data Terminal Equipment (DTE).
The LMI type is not explicitly configured.
Activating LMI Autosense
Status Request
When Local Management Interface (LMI) autosense is active, it sends out a full status request in all three LMI types to the switch. The order which is implemented in rapid succession is as follows:
software provides the ability to listen in on both DLCI 1023 (cisco LMI) and DLCI 0 (ANSI and ITU) simultaneously.
Status Messages
One or more of the status requests will prompts a reply (status message) from the switch. The device decodes the format of the reply and configures itself automatically. If more than one reply is received, the device configures itself with the type of the last received reply. This is to accommodate intelligent switches that can handle multiple formats simultaneously.
LMI Autosense
The only visible indication to the user that LMI autosense is in progress is that debug frame lmi is enabled. At every N391 interval, the user sees 3 rapid status inquiries from the serial interface one in each of the following LMI-type:
Configuration Options
No configuration options are provided; LMI autosense is transparent to the user. You can turn off LMI autosense by explicitly configuring an Local Management Interface (LMI) type. The LMI type must be written into NVRAM so that next time the device powers up, LMI autosense will be inactive. At the end of autoinstall, a frame-relay lmi-type xxx statement is included within the interface configuration. This configuration is not automatically written to NVRAM; you must explicitly write the configuration to NVRAM by using the copy system:running-config or copy nvram:startup-config command.
MQC-Based Frame Relay Traffic Shaping
Legacy frame-relay traffic shaping is not supported. Cisco IOS XE software only supports policy map based MQC.
Traffic-Shaping Map Class for the Interface
Specifying Map Class with Queueing and Traffic-Shaping Parameters
When defining a map class for Frame Relay, you can specify the average and peak rates (in bits per second) allowed on virtual circuits (VCs) associated with the map class. You can also specify either a custom queue list or a priority queue group to use on VCs associated with the map class.
Defining Access Lists
You can specify access lists and associate them with the custom queue list defined for any map class. The list number specified in the access list and the custom queue list tie them together. See the appropriate protocol chapters for information about defining access lists for the protocols you want to transmit on the Frame Relay network.
Understanding Frame Relay Subinterfaces
Frame Relay subinterfaces provide a mechanism for supporting partially meshed Frame Relay networks. Most protocols assume transitivity on a logical network; that is, if station A can communicate with station B, and station B can communicate to station C, then station A should be able to communicate to station C directly. Transitivity is true on LANs, but not on Frame Relay networks unless A is directly connected to C.
Configuring Frame Relay subinterfaces ensures that a single physical interface is considered as multiple virtual interfaces. Hence, packets received on one virtual interface can be forwarded to another virtual interface even if they are configured on the same physical interface.
Subinterfaces address the limitations of Frame Relay networks by providing an option to subdivide a partially meshed Frame Relay network into a number of smaller, fully meshed (or point-to-point) subnetworks. Each subnetwork is assigned its own network number and appears to the protocols as if it were reachable through a separate interface. (Note that point-to-point subinterfaces can be unnumbered for use with IP, thus reducing the addressing burden that might otherwise result.)
Note
Cisco IOS XE software supports configuration of point-to-point subinterfaces.
The figure below shows a five-node Frame Relay network that is partially meshed (network A). If the entire network is viewed as a single subnetwork (with a single network number assigned), most protocols assume that node A can transmit a packet directly to node E, when, in fact it must be relayed through nodes C and D. This network can work with certain protocols (for example, IP). However, this network does not work with other protocols (for example, AppleTalk), because nodes C and D do not relay the packet out at the same interface on which it was received. To make this network fully functional, we need to created a fully meshed network (network B). However, a fully meshed network requires a large number of permanent virtual circuits (PVCs), which may not be economically feasible.
Figure 2. Using Subinterfaces to Provide Full Connectivity on a Partially Meshed Frame Relay Network
By using subinterfaces, you can divide the Frame Relay network into 3 smaller subnetworks (network C) with separate network numbers. Nodes A, B, and C are connected to a fully meshed network, and nodes C and D, as well as nodes D and E, are connected via point-to-point networks. In this configuration, nodes C and D can access 2 subinterfaces and can therefore forward packets without violating split horizon rules. If transparent bridging is being used, each subinterface is viewed as a separate bridge port.
Subinterface Addressing
For point-to-point subinterfaces, the destination is presumed to be known and is identified or implied in the frame-relay interface-dlci command.
Note
The frame-relay interface-dlci command is typically used on subinterfaces; however, it can also be applied to main interfaces. The command is used to enable routing protocols on main interfaces that are configured to use Inverse ARP. This command is also helpful for assigning a specific class to a single permanent virtual circuit (PVC) on a multipoint subinterface.
If you define a subinterface for point-to-point communication, you cannot reassign the same subinterface number to be used for multipoint communication without first rebooting the device or access server. Instead, you can simply avoid using that subinterface number and use a different subinterface number.
Backup Interface for a Subinterface
Both point-to-point and multipoint Frame Relay subinterfaces can be configured with a backup interface. This approach allows individual permanent virtual circuit (PVCs) to be backed up in case of failure rather than depending on the entire Frame Relay connection to fail before the backup takes over. You can configure a subinterface for backup on failure only, not for backup based on loading of the line.
If the main interface has a backup interface, it has a precedence over the backup interface of the subinterface in the case of complete loss of connectivity with the Frame Relay network. As a result, a subinterface backup is activated only in the following cases:
If a subinterface fails while its backup interface is in use, and the main interface goes down, the backup subinterface remains connected.
Disabling or Reenabling Frame Relay Inverse ARP
Frame Relay Inverse Address Resolution Protocol (ARP) is a method of building dynamic address mappings in Frame Relay networks that run DECnet, IP, and Novell IPX. Inverse ARP allows the device or access server to discover the protocol address of a device associated with the virtual circuit (VC).
Inverse ARP creates dynamic address mappings, as contrasted with the frame-relay map command, which defines static mappings between a specific protocol address and a specific data link connection identifier (DLCI) (see the section Configuring Static Address Mapping for more information).
Inverse ARP is enabled by default but can be disabled explicitly for a given protocol and DLCI pair. Disable or reenable Inverse ARP under the following conditions:
Disable Inverse ARP for a selected protocol and DLCI pair when you know that the protocol is not supported at the other end of the connection.
Reenable Inverse ARP for a protocol and DLCI pair if conditions or equipment change and the protocol is then supported at the other end of the connection.
Note
If you change from a point-to-point subinterface to a multipoint subinterface, change the subinterface number. Frame Relay Inverse ARP will be on by default, and no further action is required.
You do not need to enable or disable Inverse ARP if you have a point-to-point interface.
Frame Relay Fragmentation
End-to-End FRF.12 Fragmentation
The purpose of end-to-end Frame Relay Fragmentation 12 (FRF.12) is to support real-time and non-real-time data packets on lower-speed links without causing excessive delay to the real-time data transmission. FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. This standard was developed to allow long data frames to be fragmented into smaller pieces (fragments) and interleaved with real-time frames. In this way, real-time and non-real-time data frames can be carried together on lower-speed links without causing excessive delay to the real-time traffic.
End-to-end FRF.12 fragmentation is recommended for use on permanent virtual circuits (PVCs) that share links with other PVCs that are transporting voice and on PVCs transporting Voice over IP (VoIP). Although VoIP packets should not be fragmented, they can be interleaved with fragmented packets.
FRF.12 is configured on a per-PVC basis using a Frame Relay map class. The map class can be applied to one or many PVCs. Frame Relay traffic shaping must be enabled on the interface for fragmentation.
Note
Setting the Fragment Size
Set the fragment size so that voice packets are not fragmented and do not experience a serialization delay greater than 20 ms.
To set the fragment size, the link speed must be taken into account. The fragment size should be larger than the voice packets, but small enough to minimize latency on the voice packets. Turn on fragmentation for low speed links (less than 768 kbps).
Set the fragment size based on the lowest port speed between the routers. For example, if there is a hub and spoke Frame Relay topology where the hub has a T1 speed and the remote routers have 64 kbps port speeds, the fragment size needs to be set for the 64 kbps speed on both routers. Any other PVCs that share the same physical interface need to configure the fragmentation to the size used by the voice PVC.
If the lowest link speed in the path is 64 kbps, the recommended fragment size (for 10 ms serialization delay) is 80 bytes. If the lowest link speed is 128 kbps, the recommended fragment size is 160 bytes.
For more information, refer to the » Fragmentation (FRF.12)» section in the VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority) document.
TCP IP Header Compression
TCP/IP header compression, as described by RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links is designed to improve the efficiency of bandwidth utilization over low-speed serial links. A typical TCP/IP packet includes a 40-byte datagram header. Once a connection is established, the header information is redundant and need not be repeated in every packet that is sent. Reconstructing a smaller header that identifies the connection, indicates the fields that have changed and the amount of change reduces the number of bytes transmitted. The average compressed header is 10 bytes long.
For this algorithm to function, packets must arrive in order. If packets arrive out of order, the reconstruction will appear to create regular TCP/IP packets but the packets will not match the original. Because priority queueing changes the order in which packets are transmitted, enabling priority queueing on the interface is not recommended.
Note
If you configure an interface with Cisco-proprietary encapsulation and TCP/IP header compression, Frame Relay IP maps inherit the compression characteristics of the interface. However, if you configure the interface with IETF encapsulation, the interface cannot be configured for compression. Frame Relay maps will have to be configured individually to support TCP/IP header compression.
Specifying an Individual IP Map for TCP IP Header Compression
An interface configured to support TCP/IP header compression does not also support priority queuing or custom queuing.
TCP/IP header compression requires Cisco-proprietary encapsulation. If you need to have IETF encapsulation on an interface as a whole, you can still configure a specific IP map to use Cisco-proprietary encapsulation and TCP header compression. In addition, if you configure the interface to perform TCP/IP header compression, you can still configure a specific IP map not to compress TCP/IP headers.
You can specify whether TCP/IP header compression is active or passive. Active compression subjects every outgoing packet to TCP/IP header compression. Passive compression subjects an outgoing TCP/IP packet to header compression only if a packet had a compressed TCP/IP header when it was received.
Specifying an Interface for TCP IP Header Compression
You can configure the interface with an active or passive TCP/IP header compression. Active compression, the default, subjects all outgoing TCP/IP packets to header compression. Passive compression subjects an outgoing packet to header compression only if the packet had a compressed TCP/IP header when it was received on that interface.
Note
If an interface configured with Cisco-proprietary encapsulation is later configured with IETF encapsulation, all TCP/IP header compression characteristics are lost. To apply TCP/IP header compression over an interface configured with IETF encapsulation, you must configure individual IP maps, as described in the Configuring an Individual IP Map for TCP IP Header Compression section.
Real-Time Header Compression with Frame Relay Encapsulation
The commands for configuring this feature are available in the Cisco IOS IP Multicast Command Reference.
Discard Eligibility
Frame Relay packets can be set with low priority or low time sensitivity. These packets will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the discard eligibility (DE) bit.
Discard eligibility requires the Frame Relay network to be able to interpret the DE bit. Some networks take no action when the DE bit is set, and others use the DE bit to determine which packets to discard. The best interpretation is to use the DE bit to determine which packets should be dropped first and also which packets have lower time sensitivity.
You can create DE lists that identify the characteristics of packets to be eligible for discarding, and you can also specify DE groups to identify the data link connection identifier (DLCI) that is affected.
You can create DE lists based on the protocol or the interface, and on characteristics such as fragmentation of the packet, a specific TCP or UDP port, an access list number, or a packet size.
DLCI Priority Levels
Data Link Connection Identifier (DLCI) priority levels allow you to separate different types of traffic and provides a traffic management tool for congestion problems caused by the following:
Mixing batch and interactive traffic over the same DLCI
Queuing traffic from sites with high-speed access to destination sites with lower-speed access
Before you configure the DLCI priority levels, you must:
Enable Frame Relay encapsulation.
Define dynamic or static address mapping.
Ensure that you define each of the DLCIs to which you intend to apply levels. You can associate priority-level DLCIs with subinterfaces.
Note
DLCI priority levels provide a way to define multiple parallel DLCIs for different types of traffic. DLCI priority levels do not assign priority queues within the device or access server. In fact, they are independent of the priority queues of the device. However, if you enable queuing and use the same DLCIs for queuing, then high-priority DLCIs can be put into high-priority queues.
How to Configure Frame Relay
Enabling Frame Relay Encapsulation on an Interface
Frame Relay encapsulation is a prerequisite for any Frame Relay commands on an interface.
To enable Frame Relay encapsulation on the interface level, use the following commands beginning in global configuration mode: SUMMARY STEPS
2. configure terminal
4. encapsulation frame-relay [ ietf ]
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Enters global configuration mode.
Step 3
interface type number
Specifies the interface, and enters interface configuration mode.
Step 4
encapsulation frame-relay [ ietf ]
Enables and specifies the Frame Relay encapsulation method.
Returns to privileged EXEC mode.
Configuring Static Address Mapping
To establish static mapping according to your network requirements, use the following command in interface configuration mode:
Enables and specifies the Frame Relay encapsulation method.
Returns to privileged EXEC mode.
Explicitly Configuring the LMI
Setting the LMI Type
If the device or access server is attached to a public data network (PDN), the LMI type must match the type used on the public network. Otherwise, the LMI type can be set to suit the requirements of your private Frame Relay network. You can set one of the following three types of LMIs on Cisco devices:
To do so, use the following commands beginning in interface configuration mode:
2. configure terminal
6. copy nvram:startup-config destination
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Enters global configuration mode.
Step 3
interface type number
Specifies the interface, and enters interface configuration mode.
Returns to privileged EXEC mode.
Step 6
copy nvram:startup-config destination
Writes the LMI type to NVRAM.
Setting the LMI Keepalive Interval
A keepalive interval must be set to configure the Local Management Interface (LMI). By default, this interval is 10 seconds. According to the LMI protocol, the keepalive interval must be less than the corresponding interval on the switch. To set the keepalive interval, use the following command in interface configuration mode:
2. configure terminal
4. keepalive keepalive period
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Enters global configuration mode.
Step 3
interface type number
Specifies the interface, and enters interface configuration mode.
Step 4
keepalive keepalive period
Sets the keepalive interval.
To disable keepalives on networks that do not utilize LMI, use the no keepalive command.
Returns to privileged EXEC mode.
Setting the LMI Polling and Timer Intervals
You can set various optional counters, intervals, and thresholds to fine-tune the operation of your Local Management Interface data terminal equipment (LMI DTE) and data communications equipment (DCE) devices. Set these attributes by using one or more of the following commands in interface configuration mode:
Sets the DCE and Network-to-Network Interface (NNI) error threshold.
Sets the DCE and NNI monitored events count.
Sets the polling verification timer on a DCE or NNI interface.
Sets a full status polling interval on a DTE or NNI interface.
Sets the DTE or NNI error threshold.
Sets the DTE and NNI monitored events count.
Configuring MQC-Based Frame Relay Traffic Shaping
Specifying a Traffic-Shaping Map Class for the Interface
To specify a map class for the specified interface, use the following command beginning in interface configuration mode:
1. Router(config-if)# frame-relay class map-class-name
DETAILED STEPS
Command or Action
Purpose
Step 1
Router(config-if)# frame-relay class map-class-name
Specifies a Frame Relay map class for the interface.
Defining a Map Class with Queueing and Traffic-Shaping Parameters
To define a map class, use the following commands beginning in global configuration mode:
Specifies a map class to define QoS values for a Frame Relay SVC or PVC. The map class can be applied to one or many PVCs.
Configures Frame Relay fragmentation for the map class. The fragment_size argument defines the payload size of a fragment; it excludes the Frame Relay headers and any Frame Relay fragmentation header. The valid range is from 16 to 1600 bytes, and the default is 53.
Verifying the Configuration of End-to-End FRF.12 Fragmentation
To verify FRF.12 fragmentation, use one or more of the following EXEC commands:
Displays Frame Relay fragmentation information.
Displays statistics about PVCs for Frame Relay interfaces.
Configuring TCP IP Header Compression
Configuring an Individual IP Map for TCP IP Header Compression
To configure an IP map to use Cisco-proprietary encapsulation and TCP/IP header compression, use the following command in interface configuration mode:
Configures an IP map to use TCP/IP header compression. Cisco-proprietary encapsulation is enabled by default.
Configuring an Interface for TCP IP Header Compression
To apply TCP/IP header compression to an interface, you must use the following commands in interface configuration mode:
1. Router(config-if)# encapsulation frame-relay
2. Router(config-if)# frame-relay ip tcp header-compression [ passive ]
DETAILED STEPS
Command or Action
Purpose
Step 1
Router(config-if)# encapsulation frame-relay
Configures Cisco-proprietary encapsulation on the interface.
Enables TCP/IP header compression.
Disabling TCP IP Header Compression
You can disable TCP/IP header compression by using either of two commands that have different effects, depending on whether Frame Relay IP maps have been explicitly configured for TCP/IP header compression or have inherited their compression characteristics from the interface.
Frame Relay IP maps that have explicitly configured TCP/IP header compression must also have TCP/IP header compression explicitly disabled.
To disable TCP/IP header compression, use one of the following commands in interface configuration mode:
Disables TCP/IP header compression on all Frame Relay IP maps that are not explicitly configured for TCP header compression.
Disables RTP and TCP/IP header compression on a specified Frame Relay IP map.
Configuring Discard Eligibility
Defining a DE List
To define a DE list specifying the packets that can be dropped when the Frame Relay switch is congested, use the following command in global configuration mode:
1. Router(config)# frame-relay de-list list-number < protocol protocol | interface type number >characteristic
DETAILED STEPS
Command or Action
Purpose
Step 1
Router(config)# frame-relay de-list list-number < protocol protocol | interface type number >characteristic
Defining a DE Group
To define a DE group specifying the DE list and DLCI affected, use the following command in interface configuration mode:
Defines a DE group.
Configuring DLCI Priority Levels
To configure DLCI priority levels, use the following command in interface configuration mode:
Enables multiple parallel DLCIs for different Frame Relay traffic types; associates and sets level of specified DLCIs with same group.
If you do not explicitly specify a DLCI for each of the priority levels, the last DLCI specified in the command line is used as the value of the remaining arguments. At a minimum, you must configure the high-priority and the medium-priority DLCIs.
Monitoring and Maintaining the Frame Relay Connections
To monitor Frame Relay connections, use any of the following commands in EXEC mode:
Clears dynamically created Frame Relay maps, which are created by the use of Inverse ARP.
Displays information about Frame Relay DLCIs and the LMI.
Displays LMI statistics.
Displays the current Frame Relay map entries.
Displays PVC statistics.
Displays configured static routes.
Displays Frame Relay traffic statistics.
Displays information about the status of LAPF.
Displays all the SVCs under a specified map list.
Configuration Examples for Frame Relay
Example IETF Encapsulation
Example IETF Encapsulation on the Interface
The following example sets IETF encapsulation at the interface level. The keyword ietf sets the default encapsulation method for all maps to IETF.
Example IETF Encapsulation on a Per-DLCI Basis
The following example configures IETF encapsulation on a per-DLCI basis. This configuration has the same result as the configuration in the first example.
Example Static Address Mapping
Example Two Routers in Static Mode
The following example shows how to configure two routers for static mode:
Configuration for Router 1
Configuration for Router 2
Example Subinterface
Example Basic Subinterface
In the following example, subinterface 1 is configured as a point-to-point subnet and subinterface 2 is configured as a multipoint subnet.
Example Frame Relay Traffic Shaping
Example Configuring Class-Based Weighted Fair Queueing
The following example provides a sample configuration for Class-Based Weighted Fair Queueing (CBWFQ) with FRTS:
Example Configuring Class-Based Weighted Fair Queueing with Fragmentation
The following example provides a sample configuration for CBWFQ and fragmentation with FRTS. This configuration example is exactly the same as the example shown in the Example Configuring Class-Based Weighted Fair Queueing section, with the addition of the frame-relay fragment command to configure fragmentation.
Example Backward Compatibility
The following configuration provides backward compatibility and interoperability with versions not compliant with RFC 1490. The ietf keyword is used to generate RFC 1490 traffic. This configuration is possible because of the flexibility provided by separately defining each map entry.
Example Booting from a Network Server over Frame Relay
When booting from a TFTP server over Frame Relay, you cannot boot from a network server via a broadcast. You must boot from a specific TFTP host. Also, a frame-relay map command must exist for the host from which you will boot.
For example, if file «gs3-bfx» is to be booted from a host with IP address 131.108.126.2, the following commands would need to be in the configuration:
The frame-relay map command is used to map an IP address into a DLCI address. To boot over Frame Relay, you must explicitly give the address of the network server to boot from, and a frame-relay map entry must exist for that site. For example, if file «gs3-bfx.83-2.0» is to be booted from a host with IP address 131.108.126.111, the following commands must be in the configuration:
In this case, 100 is the DLCI that can get to host 131.108.126.111.
The remote router must be configured with the following command:
This entry allows the remote router to return a boot image (from the network server) to the router booting over Frame Relay. Here, 101 is a DLCI of the router being booted.
Example Frame Relay Fragmentation Configuration
Example FRF.12 Fragmentation
The following example shows the configuration of pure end-to-end FRF.12 fragmentation and weighted fair queueing in the map class called «frag». The fragment payload size is set to 40 bytes. The «frag» map class is associated with DLCI 100 on serial interface 1.
Example TCP IP Header Compression
Example IP Map with Inherited TCP IP Header Compression
Shut down the interface or subinterface prior to adding or changing compression techniques. Although shutdown is not required, shutting down the interface ensures that it is reset for the new data structures.
The following example shows an interface configured for TCP/IP header compression and an IP map that inherits the compression characteristics. Note that the Frame Relay IP map is not explicitly configured for header compression.
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has inherited passive TCP/IP header compression:
This example also applies to dynamic mappings achieved with the use of Inverse ARP on point-to-point subinterfaces where no Frame Relay maps are configured.
Example Using an IP Map to Override TCP IP Header Compression
The following example shows the use of a Frame Relay IP map to override the compression set on the interface:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has not inherited TCP header compression:
Example Disabling Inherited TCP IP Header Compression
In this example, following is the initial configuration:
Enter the following commands to enable inherited TCP/IP header compression:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics:
As a result, header compression is disabled for the first map (with DLCI 177), which inherited its header compression characteristics from the interface. However, header compression is not disabled for the second map (DLCI 178), which is explicitly configured for header compression.
Example Disabling Explicit TCP IP Header Compression
In this example, the initial configuration is the same as in the preceding example, but you must enter the following set of commands to enable explicit TCP/IP header compression:
Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics:
The result of the commands is to disable header compression for the first map (with DLCI 177), which inherited its header compression characteristics from the interface, and also explicitly to disable header compression for the second map (with DLCI 178), which was explicitly configured for header compression.
