Dynamic address mapping uses Frame Relay Inverse ARP to request the next-hop protocol address for a specific connection, given its known DLCI. Responses to Inverse ARP requests are entered in an address-to-DLCI mapping table on the router or access server; the 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, but 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.

A static map links a specified next-hop protocol address to a specified DLCI. Static mapping removes the need for Inverse 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 if the router at the other end either does not support Inverse ARP at all or 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 broadcastkeyword.

• Status Request
  
• Status Messages
  
• LMI Autosense
  
• Configuration Options
  

If you specify a Frame Relay map class for a main interface, all the VCs on its subinterfaces inherit all the traffic-shaping parameters defined for the class. You can override the default for a specific DLCI on a specific subinterface by using the class VC configuration command to assign the DLCI explicitly to a different class. See the section Configuring Frame Relay Subinterfaces for information about setting up subinterfaces.

When defining a map class for Frame Relay, you can specify the average and peak rates (in bits per second) allowed on 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.

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.

You can define a priority list for a protocol and you can also define a default priority list. The number used for a specific priority list ties the list to the Frame Relay priority group defined for a specified map class. For example, if you enter the frame relay priority-group 2 command for the map class "fast_vcs" and then you enter the priority-list 2 protocol decnet high command, that priority list is used for the "fast_vcs" map class. The average and peak traffic rates defined for the "fast_vcs" map class are used for DECnet traffic.

You can define a queue list for a protocol and a default queue list. You can also specify the maximum number of bytes to be transmitted in any cycle. The number used for a specific queue list ties the list to the Frame Relay custom queue list defined for a specified map class.

For example, if you enter the frame relay custom-queue-list 1 command for the map class "slow_vcs" and then you enter the queue-list 1 protocol ip list 100 command, that queue list is used for the "slow_vcs" map class; access-list 100 definition is also used for that map class and queue. The average and peak traffic rates defined for the "slow_vcs" map class are used for IP traffic that meets the access list 100 criteria.

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 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 router or access server. Instead, you can simply avoid using that subinterface number and use a different subinterface number.

Both point-to-point and multipoint Frame Relay subinterfaces can be configured with a backup interface. This approach allows individual 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 will have precedence over the subinterface's backup interface in the case of complete loss of connectivity with the Frame Relay network. As a result, a subinterface backup is activated only if the main interface is up, or if the interface is down and does not have a backup interface defined. If a subinterface fails while its backup interface is in use, and the main interface goes down, the backup subinterface remains connected.

The purpose of end-to-end FRF.12 fragmentation is to support real-time and non-real-time data packets on lower-speed links without causing excessive delay to the real-time data. 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 in order for fragmentation to work.

Note

When Frame Relay fragmentation is configured, WFQ or LLQ is mandatory. If a map class is configured for Frame Relay fragmentation and the queueing type on that map class is not WFQ or LLQ, the configured queueing type is automatically overridden by WFQ with the default values. To configure LLQ for Frame Relay, refer to the Cisco IOS XE Quality of Service Solutions Configuration Guide .

• Setting the Fragment Size
  

Note	An interface configured to support TCP/IP header compression cannot also support priority queueing or custom queueing.

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, even 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.

You can configure the interface with 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.

1.    Router(config-if)# frame-relay lmi-type {ansi | cisco | q933a}

2.    Router# copy nvram:startup-config destination

1.    Router(config-if)# keepalive number

You can set various optional counters, intervals, and thresholds to fine-tune the operation of your LMI DTE and DCE devices. Set these attributes by using one or more of the following commands in interface configuration mode:

frame-relay lmi-n392dce  threshold 

frame-relay lmi-n393dce  events 

frame-relay lmi-t392dce  seconds 

frame-relay lmi-n391dte  keep-exchanges 

frame-relay lmi-n392dte  threshold

frame-relay lmi-n393dte  events

1.    Router(config-if)# frame-relay class map-class-name

1.    Router(config)# map-class frame-relay map-class-name

2.    Router(config-map-class)# frame-relay traffic-rate average [peak]

3.    Router(config-map-class)# frame-relay custom-queue-list list-number

4.    Router(config-map-class)# frame-relay priority-group list-number

5.    Router(config-map-class)# frame-relay adaptive-shaping {becn | foresight}

• Configuring Subinterfaces
  
• Defining Subinterface Addressing on Point-to-Point Subinterfaces
  
• Configuring a Backup Interface for a Subinterface
  

To select or disable Inverse ARP, use one of the following commands in interface configuration mode:

 frame-relay inverse-arp  protocol dlci

no frame relay inverse-arp protocol dlci 

• Configuring End-to-End FRF.12 Fragmentation
  
• Verifying the Configuration of End-to-End FRF.12 Fragmentation
  

• Configuring an Individual IP Map for TCP IP Header Compression
  
• Configuring an Interface for TCP IP Header Compression
  
• Disabling TCP IP Header Compression
  

• Defining a DE List
  
• Defining a DE Group
  

To configure DLCI priority levels, use the following command in interface configuration mode:

frame-relay priority-dlci-group group-number high-dlci medium-dlci normal-dlci low-dlci

The following example shows how to configure two routers for static mode:

interface serial0
 ip address 131.108.64.2 255.255.255.0
 encapsulation frame-relay
 keepalive 10
 frame-relay map ip 131.108.64.1 43

interface serial1
 ip address 131.108.64.1 255.255.255.0
 encapsulation frame-relay
 keepalive 10
 frame-relay map ip 131.108.64.2 43

The following example provides a sample configuration for Class-Based Weighted Fair Queueing (CBWFQ) with FRTS:

class-map voice
 match ip dscp ef
policy-map llq
 class voice
  priority 32
policy-map shape-policy-map
 class class-default
  shape average 64000
  shape adaptive 32000
  service-policy llq
map-class frame-relay shape-map-class
 
service-policy output shape-policy-map
interface serial 0/0
encapsulation frame-relay
interface serial 0/0.1 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 100
class shape-map-class

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.

class-map voice
 match ip dscp ef
policy-map llq
 class voice
  priority 32
policy-map shape-policy-map
 class class-default
  shape average 64000
  shape adaptive 32000
  service-policy llq
map-class frame-relay shape-map-class
 frame-relay fragment 80
 service-policy output shape-policy-map
interface serial 0/0
 encapsulation frame-relay
interface serial 0/0.1 point-to-point
 ip address 192.168.1.1 255.255.255.0
 frame-relay interface-dlci 100
  class shape-map-class