2-9 Frame Relay Interfaces | Cisco Field Manual[c] Router Configuration

A router communicates with a Frame Relay switch through Local Management Interface (LMI).
The Frame Relay circuit is identified to the router as a Data Link Circuit Identifier (DLCI) number.
Inverse ARP is enabled by default for protocols configured on an interface. A dynamic mapping occurs between a protocol address and a DLCI.
Frame Relay supports either Permanent Virtual Circuits (PVCs) or Switched Virtual Circuits (SVCs) between endpoints.
Frame Relay is supported on major interfaces (interface serial 0, for example) for fully meshed connections between routers, where each router has a circuit to every other router.
Frame Relay is supported on subinterfaces (interface serial 0.1, for example) for partially meshed or point-to-point connections.
Data transmission over a circuit is described and controlled by the following terms:
- Data Link Connection Identifier (DLCI) A 10-bit number (0 to 1023) that uniquely identifies a virtual circuit (VC) to the local router. DLCI numbers can be reused on the far end of a VC. In addition, DLCI numbers can be globally unique across the Frame Relay cloud if desired by the service provider. In practice, you will probably find that DLCI numbers are not globally unique but are duplicated for convenience and simplicity.
- Committed Information Rate (CIR) The throughput rate that the service provider normally supports. It is possible to exceed the CIR, but only as defined by the sampling interval (Tc) and the committed burst rate (Bc). When the CIR is defined as a 0 value (for lowest cost), attention should be paid to congestion management on the router. In general, the CIR equals Bc/Tc, as defined next .
- Committed Rate Measurement Interval (Tc) The time interval or "bandwidth interval" used to control traffic bursts on a VC.
- Committed Burst Rate (Bc) The maximum amount of traffic that the Frame Relay network will allow into the VC during the time interval Tc.
- Excess Burst Rate (Be) The maximum amount of traffic on a VC that can exceed the Bc value in a time interval Tc.
- Discard-Eligible (DE) A bit in the Frame Relay header that is set to indicate that the frame is more eligible than others to be discarded in case of switch congestion. The DE bit is set by the router and is passed to the Frame Relay switch for discarding if necessary.
- Forward Explicit Congestion Notification (FECN) A bit in the Frame Relay header that is set to indicate Frame Relay switch congestion. The FECN bit is set in frames traveling toward the destination, or in the "forward" direction.
- Backward Explicit Congestion Notification (BECN) A bit in the Frame Relay header that is set to indicate Frame Relay switch congestion. The BECN bit is set in frames traveling toward the source, or in the "backward" direction. In this manner, both FECN and BECN bits are set to notify both upstream and downstream nodes of switch congestion.
End-to-end keepalives can be used to provide monitoring of a PVC by exchanging keepalive information between two routers. Normally, a router can only monitor a PVC based on LMI messages from its local Frame Relay switch.
Frame Relay Inverse ARP can be used to dynamically discover the network protocol address (an IP address, for example) given a specific DLCI number. Inverse ARP is based on RFC 1293 and is enabled on Frame Relay interfaces by default.

NOTE

DLCI 0 is used for LMI under ANSI and ITU encapsulations , whereas DLCI 1023 is used under the Cisco encapsulation.

Configuration

Select a major interface:
```
 (global)  interface serial   number  
```
Many Frame Relay circuits can be supported on a single major interface. The active DLCI numbers can be determined automatically through LMI.
Enable Frame Relay encapsulation:
```
 (interface)  encapsulation frame-relay  {  cisco   ietf  } 
```
The type of encapsulation can be set for the major interface. Any subinterfaces defined inherit this encapsulation unless they are overridden. The cisco type (the default) should be used when the router is connected to another Cisco router across the Frame Relay cloud. The ietf type is based on IETF RFC 1490 and provides vendor interoperability. Use this type when a Cisco router connects to non-Cisco equipment across the frame cloud.
Configure LMI.
1. Configure LMI autosensing.
  
  By default, LMI autosensing is enabled unless a specific LMI type is configured. LMI autosensing sends out full status requests in all three LMI types (ANSI T1.617 Annex D, Cisco, and ITU-T Q.933 Annex A). The LMI type is set to match the only or last reply received from the Frame Relay switch.
  
  -OR-
2. Configure a specific LMI type.
  - Choose an LMI type:
```
 (interface)  frame-relay lmi-type  {  ansi   cisco   q933a  } 
```
  The LMI type must be set to match that of the Frame Relay switch. The type can be ansi (ANSI T1.617 Annex D), cisco, or q933a (ITU-T Q.933 Annex A).
  - (Optional) Set the LMI keepalive time:
```
 (interface)  keepalive   seconds  
```
  The LMI keepalive interval (the default is 10 seconds) must be set to a value less than the interval used by the Frame Relay switch.
(Optional) Configure subinterfaces.
1. Define the subinterface:
```
 (global)  interface serial   number.subinterface  {  multipoint   point-to-   point  } 
```
  A logical or virtual subinterface is defined as a part of the physical major interface number. The subinterface number can be arbitrarily chosen . The type of circuit must be identified as either multipoint (multiple routers connect to the local router through one virtual circuit) or point-to-point (one router connects to the local router).
2. Define a DLCI for the subinterface:
```
 (subinterface)  frame-relay interface-dlci   dlci  [  ietf   cisco  ] 
```
  Because multiple logical interfaces can be defined under one physical interface, each subinterface must be identified with its DLCI, dlci. The encapsulation type can also be set per subinterface if necessary. If the type is left off, it is inherited from the type of the major physical interface.
(Optional) Configure static address mappings.
1. Map a DLCI to a protocol address:
```
 (interface)  frame-relay map   protocol address dlci  [  broadcast  ]   [  ietf   cisco  ] 
```
  By default, Frame Relay Inverse ARP is used to resolve a next-hop protocol address given a DLCI number. If desired, static mappings can be configured instead. A protocol can be given as ip, decnet, appletalk, xns, ipx, vines, or clns, along with the protocol address and the DLCI.
  
  The broadcast keyword causes broadcasts for the protocol to be forwarded on the DLCI. The Frame Relay encapsulation can also be defined for this protocol on this DLCI if desired. If not specified, the encapsulation is inherited from the major interface or subinterface.
2. Map a DLCI to a transparent bridge:
```
 (interface)  frame-relay map bridge   dlci  [  broadcast   ietf  ] 
```
  The DLCI given is used to forward packets for transparent bridging. The broadcast keyword allows broadcasts to be forwarded on the DLCI. If desired, the encapsulation can be set to ietf for the bridged DLCI.
3. Map a DLCI to ISO CLNS:
```
 (interface)  frame-relay map clns   dlci  [  broadcast  ] 
```
  The DLCI given is used to forward packets for CLNS routing. The broadcast keyword allows broadcasts to be forwarded on the DLCI.
(Optional) Configure Switched Virtual Circuits (SVCs).
1. Create an SVC map class.
  - Define the map class:
```
 (global)  map-class frame-relay   map-class  
```
    A map class named map-class (a text string) is created. Parameters defined to the map class can be used as a template for SVC definitions, QoS, and so forth.
  - (Optional) Define custom queuing.
    
    Begin by defining a custom queue list:
```
 (global)  queue-list   list-number   queue   queue-number  ... 
```
    Next, assign the custom queue list to the Frame Relay map class:
```
 (map-class)  frame-relay custom-queue-list   custom-list  
```
    See Section 10-7 for more information about configuring custom queuing.
    
    If custom queuing is not defined, first-in-first-out (FIFO) queuing is used by default.
  - (Optional) Define priority queuing.
    
    Begin by defining a priority queue list:
```
 (global)  priority-list   list-number   protocol   protocol  {  high   medium   low   default  } 
```
    Next, assign the priority queue list to the Frame Relay map class:
```
 (map-class)  frame-relay priority-group   priority-list  
```
    See Section 10-6 for more information about configuring priority queuing.
    
    If priority queuing is not defined, first-in-first-out (FIFO) queuing is used by default.
  - (Optional) Define Frame Relay quality of service (QoS) parameters.
    
    Begin by selecting a response to congestion:
```
 (map-class)  frame-relay adaptive-shaping  {  becn   foresight  } 
```
    Two methods of congestion notification are available: Backward Explicit Congestion Notification ( becn ) and Foresight ( foresight ). BECN relies on setting a bit in a user packet to inform the router of congestion, a method that is sometimes unreliable. The Foresight method passes periodic messages between the Frame Relay switch and routers, independent of user data packets.
    
    Next, set the CIR for an SVC:
```
 (map-class)  frame-relay cir  {  in   out  }  bps  
```
    The CIR for incoming and outgoing traffic on an SVC can be independently set to bps bits per second (the default is 56000).
    
    Next, set the minimum acceptable CIR:
```
 (map-class)  frame-relay mincir  {  in   out  }  bps  
```
    The minimum acceptable CIR for incoming and outgoing traffic on an SVC can be independently set to bps (the default is 56000).
    
    Next, set the committed burst size , Bc:
```
 (map-class)  frame-relay bc  {  in   out  }  bits  
```
    The Bc parameter for incoming and outgoing traffic on an SVC can be set independently to bits (the default is 7000 bits).
    
    Next, set the excess burst size, Be:
```
 (map-class)  frame-relay be  {  in   out  }  bits  
```
    The Be parameter for incoming and outgoing traffic on an SVC can be set independently to bits (the default is 7000 bits).
    
    Next, set the SVC idle timer:
```
 (map-class)  frame-relay idle-timer  [  in   out  ]  seconds  
```
    An SVC is released after seconds (the default is 120 seconds) of time passes without sending or receiving frames. The idle timer value should be set according to the applications that are in use.
2. Create a map list to trigger SVCs.
  - Set the E.164 or X.121 addresses for the SVC:
```
 (global)  map-list   map-list   source-addr  {  e164   x121  }  source-addr   dest-addr  {  e164   x121  }  dest-addr  
```
    For an SVC, a local source address and a remote destination address must be defined. A map list named map-list is created, containing a list of protocols that will trigger the SVC.
    
    Addresses can be given in either E.164 ( e164 ) or X.121 ( x121 ) format, as they are defined on the Frame Relay switch. An E.164 address has a variable length, up to 15 digits, in the format Country Code (one, two, or three digits), National Destination Code and Subscriber Number (National ISDN number, a maximum of 12 to 14 digits), and ISDN Subaddress (a device number at the termination point). An X.121 address is 14 digits long and has the format Zone code (one digit), Country code (two digits), Public data network code (one digit), and a ten-digit number.
  - Set the protocol address that will trigger SVC setup:
```
 (map-list)  protocol protocol-address   class   map-class  [  ietf  ]   [  broadcast  [  trigger  ]] 
```
    The SVC, defined by the addresses in the map list, is triggered for setup by protocol type traffic destined for the protocol-address. The map class named map-class is used to give SVC parameters. Valid protocols include ip, ipx, appletalk, decnet, bridge (for transparent bridging), dlsw, bstun, stun, cdp, arp, and so forth. The ietf keyword enables RFC 1490 encapsulation rather than the Cisco default. The broadcast keyword causes broadcast packets for the protocol to be sent over the SVC. If the trigger keyword is included, broadcast traffic is allowed to trigger the SVC setup.
3. Enable SVC support on an interface.
  - Enable SVC on the major interface:
```
 (interface)  frame-relay svc  
```
    SVC support is inherently enabled for all subinterfaces under the major interface.
  - Assign a map group to an interface:
```
 (interface)  map-group   map-list  
```
    A map list named map-list is bound to the interface (or subinterface) to define and trigger an SVC. More than one map-group command can be configured on an interface so that multiple SVCs can be used.
(Optional) Set other Frame Relay parameters.
1. Use end-to-end keepalives.
  - Create or add to a map class:
```
 (global)  map-class frame-relay   map-class  
```
    End-to-end keepalives can be configured only from a Frame Relay map class.
  - Enable end-to-end keepalives:
```
 (map-class)  frame-relay end-to-end keepalive mode  {  bi-directional   request   reply   passive-reply  } 
```
    Under bi-directional mode, the router has a sender and receiver to handle keepalive messages. The request mode enables only the sender such that keepalive responses are requested but none are answered . The reply mode enables only the receiver, which waits for requests and answers them. The passive-reply mode operates like the reply mode but does not keep any timer or event states.
    
    By default, keepalive requests are sent every 10 seconds. If requests aren't received within 15 seconds, an error counter is incremented. Only the last three keepalive events are checked for errors: If two or more requests were missed, the keepalive state moves from up to down; if two or more requests are seen again, the keepalive state moves from down to up. These values can be changed from the default with the frame-relay end-to-end keepalive {error-threshold event-window success-events timer} command.
2. Disable Frame Relay inverse ARP:
```
 (interface) [  no  ]  frame-relay inverse-arp  [  protocol  ] [  dlci  ] 
```
  Frame Relay inverse ARP is enabled by default. It can be disabled if desired using the no form of the command. Inverse ARP can also be enabled or disabled for a particular protocol and/or DLCI number.
3. Create a broadcast queue:
```
 (interface)  frame-relay broadcast-queue   size byte-rate packet-rate  
```
  Broadcast packets must be replicated and sent out to all DLCIs related to a protocol or bridge group. A queue can be used to hold and forward broadcasts to within a specified rate limit. The broadcast queue length is given as size in packets (the default is 64 packets). The size should be large enough to hold a complete routing update for each protocol over each DLCI. The maximum number of broadcast bytes to send per second is given as byte-rate (the default is 256000 bytes per second; this number is generally set to less than both the number of DLCIs divided by 4 and one-fourth of the local access rate in bytes per second). The maximum number of broadcast packets per second is given as packet-rate (the default is 36 packets per second).
4. Enable Frame Relay fragmentation.
  - Use end-to-end FRF.12 fragmentation:
```
 (map-class)  frame-relay fragment   fragment-size  
```
    FRF.12 fragmentation is used on a per-PVC basis through a map class. The fragment-size is the payload size, excluding Frame Relay headers (16 to 1600 bytes; the default is 53 bytes). Use fragmentation so that time-critical packets such as voice can be interleaved with fragments of larger packets. Set the fragment size less than the MTU but not larger than a voice packet.
  - Use FRF.11 Annex C fragmentation.
    
    This type of fragmentation is used when Voice over Frame Relay (VoFR) is configured, but it should not be used for Voice over IP (VoIP). See Section 12-3 for further details.
  - Use Cisco proprietary fragmentation.
    
    If Voice over Frame Relay is configured and a map class is used for the PVC, Cisco proprietary fragmentation can be used. See Section 12-3 for further details.
5. Enable payload compression.
  - Use packet-by-packet compression:
```
 (interface)  frame-relay payload-compression packet-by-packet  
```
    -OR-
```
 (interface)  frame-relay map   protocol address dlci   payload-compression packet-by-packet  
```
    The Stacker method is used to predict the next character in a frame, one packet at a time. This command can be used for the entire data stream on an interface or on a specified protocol and DLCI using the frame-relay map command.
  - Use FRF.9 or Cisco proprietary data-stream compression:
```
 (interface)  frame-relay payload-compression  {  frf9   data-stream  }  stac  [  distributed   ratio   software  ] 
```
    -OR-
```
 (interface)  frame-relay map   protocol address dlci   payload-compression frf9 stac  [  distributed   ratio   software  ] 
```
    The standards-based FRF.9 compression can be used with the frf9 keyword, whereas the Cisco proprietary method can be used with the data-stream keyword. Compression can be configured either directly on the interface or through a frame-relay map command. The distributed keyword enables compression in a VIP2 module (if available). The ratio keyword weighs compression against throughput: high (high compression, low throughput) or low (low compression, high throughput; this is the default). The software keyword enables compression in IOS software on the router CPU.
6. Enable TCP/IP header compression:
```
 (interface)  frame-relay ip tcp header-compression  [  passive  ] 
```
  TCP/IP headers can be compressed within frames. By default, this is enabled only for the Cisco Frame Relay encapsulation. Packets must arrive in order, or the packet headers will not be re-created properly. (Do not use priority queuing, which can cause packets to arrive out of order.) The passive keyword causes headers to be compressed only if an incoming packet had a compressed header.
7. Flag discard-eligible (DE) frames.
  - Identify DE frames with a DE list:
```
 (global)  frame-relay   de-list   list-number  {  protocol   protocol   interface   type number  }  characteristic  
```
    The DE list identifies frames that can be dropped by the Frame Relay network in case a switch is congested . Frames chosen should be those with a low time sensitivity or a low importance. The list-number is used to group multiple DE list commands as a single list.
    
    The protocol keyword can be used to specify a protocol as discard-eligible. Possible protocol names are arp, apollo, appletalk, bridge, clns, clns_es, clns_is, compressedtcp, decnet, decnet_ node, decnet_router-L1, decnet_router-L2, ip, ipx, vines, and xns. For the ip protocol, the characteristic field can be given as tcp port or udp port to flag specific port numbers, or as fragments for fragmented IP packets. The characteristic field can also be used to reference an access list ( list access-list, a standard or extended IP access list numbered 1 to 199 or 1300 to 2699) that can further define DE frames, or to identify frames that are less than ( lt bytes ) or greater than ( gt bytes ) a certain size.
    
    The interface keyword, along with an interface type and number, can also be used to mark frames coming from that interface as discard-eligible.
  - Apply the DE list to an interface and DLCI:
```
 (interface)  frame-relay de-group   list-number dlci  
```
    On the Frame Relay interface, the DE list numbered list-number is used to flag packets eligible for discarding only on the dlci virtual circuit.
8. Integrate priority queuing with multiple DLCIs.
  - Define a priority list:
```
 (global)  priority-list   list-number   protocol   protocol  {  high   medium   low   default  } 
```
    A priority list numbered list-number is created, grouping multiple queue definitions. A specific protocol is assigned to a priority queue level: high, medium, low, or default.
  - Assign DLCIs to carry traffic from priority queues:
```
 (interface)  frame-relay priority-dlci-group   list-number high-dlci  med-dlci normal-dlci low-dlci 
```
    The priority queues can be applied to individual DLCIs that are carried over a single Frame Relay interface. The list-number given is the same number as the priority list. The priority queues are defined to DLCIs high-dlci, med-dlci, normal-dlci, and low-dlci. In this fashion, the queues can be carried over DLCIs with the appropriate CIR and quality of service characteristics.
(Optional) Configure Frame Relay traffic shaping.

For certain Quality of Service (QoS) needs, Frame Relay traffic can be shaped prior to transmission. See Section 10-4 for complete details.

Example

A Frame Relay connection to a remote site is configured on major interface serial 0. The interface is given an IP address and is also configured to flag all outgoing HTTP traffic (TCP port 80) as discard-eligible. Two other PVCs are defined on subinterfaces of serial 1. Each subinterface has an IP address and is configured to use map class "branches" to enable end-to-end keepalives. In addition, Frame Relay fragmentation is used to transmit data frames as 100-byte fragments. Figure 2-4 shows a network diagram.

Figure 2-4. Network Diagram for the Frame Relay Interface Example

graphics/02fig04.gif

  map-class frame-relay branches   frame-relay end-to-end keepalive mode bidirectional   frame-relay fragment 100   frame-relay de-list 1 protocol ip tcp 80   interface serial 0   encapsulation frame-relay cisco   ip address 120.17.3.45 255.255.255.0   frame-relay de-group 1 5   interface serial 1   encapsulation frame-relay cisco   no ip address   interface serial 1.1 point-to-point   frame-relay interface-dlci 18   frame-relay class branches   ip address 192.168.254.17 255.255.255.252   interface serial 1.2 point-to-point   frame-relay interface-dlci 23   frame-relay class branches   ip address 192.168.254.21 255.255.255.252