Synchronous Optical NETwork (SONET)

Configuring Frame Relay Encapsulation on Cisco 12000 Series POS Interfaces

Document ID: 19180

Updated: Jun 01, 2005



This document provides a sample configuration for Frame Relay encapsulation on packet over SONET (POS) interfaces on the Cisco 12000 Series Internet Router.



There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.


For more information on document conventions, refer to Cisco Technical Tips Conventions.

Background Information

Cisco POS interfaces support three layer-2 encapsulation types: point to point protocol (PPP), high-level data link control (HDLC), and Frame Relay. The Frame Relay encapsulation adheres to Internet Engineering Task Force (IETF) Request for Comments (RFC) 1490. Both IP over Frame Relay and Frame Relay switching are supported on the Cisco 12000 Series' POS line cards.

Note: Other POS interfaces and line cards from Cisco Systems also support Frame Relay encapsulation on POS interfaces. For example, the OC-12 POS line card and the six-port OC-3 POS line card for the Cisco 10000 Series also support Frame Relay encapsulation. Frame Relay encapsulation for such interfaces is supported in the Parallel Express Forwarding (PXF) path. See the Release Notes for Cisco IOS Release 12.0 ST. In addition, Cisco IOS Software Release 12.1(11b)E introduced Frame Relay encapsulation on the WAN ports of the POS Optical Services Modules (OSMs) in the Cisco 7600 Series Internet Router. See Release Notes for Cisco IOS Release 12.1E on the Catalyst 6000 and Cisco 7600 Supervisor Engine and MSFC.

IP Over Frame Relay

The POS line cards for the Cisco 12000 Series support IP over Frame Relay permanent virtual circuits (PVCs). They also support the following features:

  • Up to 300 subinterfaces.

  • Frame Relay User-Network Interface (UNI) data terminal equipment (DTE) or data communications equipment (DCE) and Network-to-Network Interface (NNI) interface capabilities (LMI DCE, NNI and LMI DTE).

  • Frame Relay Management Information Base (MIB) (RFC 1315) and the Cisco Frame Relay MIB for network management. The Cisco Frame Relay MIB complements the standard Frame Relay MIB by providing additional link-level and virtual circuit (VC)-level information and statistics that are covered by the show frame-relay commands such as, show frame-relay lmi, show frame-relay pvc, and show frame-relay map.

  • Inverse ARP (RFC1490/2427) or Static Frame Relay Address Resolution.


In this section, you are presented with the information to configure the features described in this document.

Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .

Network Diagram

This document uses this network setup:



This document uses these configurations:

interface pos 8/0  
  no ip address  
  encapsulation frame-relay  
  no keepalive  

 !--- This command disables LMI processing.  

 interface pos 8/0.1 point-to-point  

 !--- A point-to-point subinterface has been created.  

 ip address  
 frame-relay interface-dlci 101  

 !--- DLCI 101 has been assigned to this interface

 interface pos 1/0 
  no ip address  
  encapsulation frame-relay  
  no keepalive  

 !--- This command disables LMI processing.  

 interface pos1/0.1 point-to-point  

 !--- A point-to-point subinterface has been created. 
  ip address  
  frame-relay interface-dlci 101  

 !--- DLCI 101 has been assigned to this interface

Point-to-Point and Multipoint Interfaces

Frame Relay supports two types of interfaces: point-to-point and multipoint. The one you choose determines whether you need to use the configuration commands that ensure IP address to data-link connection identifier (DLCI) mappings. After configuring the PVC itself, you must tell the router which PVC to use in order to reach a specific destination. Let's look at these options:

  • Point-to-point subinterface - With point-to-point subinterfaces, each pair of routers has its own subnet. If you put the PVC on a point-to-point subinterface, the router assumes that there is only one point-to-point PVC configured on the subinterface. Therefore, any IP packets with a destination IP address in the same subnet are forwarded on this VC. This is the simplest way to configure the mapping and is therefore the recommended method. Use the frame-relay interface-dlci command to assign a DLCI to a specified Frame Relay subinterface.

  • Multipoint networks - Multipoint networks have three or more routers in the same subnet. If you put the PVC in a point-to-multipoint subinterface or in the main interface (which is multipoint by default), you need to either configure a static mapping or enable inverse Address Resolution Protocol (ARP) for dynamic mapping.


This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

  • show frame-relay map—Displays map entries and information about connections. A point-to-point interface does not need a static map statement and displays output similar to the following on Router12008:

    Router12008#show frame-relay map 
    POS1/0.1 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast
  • show frame-relay pvc—Displays statistics about PVCs for Frame Relay interfaces. The above configurations in this document disabled Local Management Interface (LMI) processing on both routers when the no keepalive command is issued. Without the exchange of LMI messages, the PVC status changes to "static", and the interfaces remain up/up unless clocking is lost on the DTE cable side or data terminal ready (DTR), and Request To Send (RTS) is lost on the DCE cable side. The following sample output of the show frame pvc command was captured on Router12008.

    Router12008#show frame-relay pvc 
    PVC Statistics for interface POS1/0 (Frame Relay DTE) 
                  Active     Inactive      Deleted       Static 
      Local          0            0            0            1 
      Switched       0            0            0            0 
      Unused         0            0            0            0 
      input pkts 3             output pkts 6            in bytes 1152 
      out bytes 2061           dropped pkts 0           in FECN pkts 0 
      in BECN pkts 0           out FECN pkts 0          out BECN pkts 0 
      in DE pkts 0             out DE pkts 0 
      out bcast pkts 6         out bcast bytes 2061 
      pvc create time 00:05:30, last time pvc status changed 00:03:30

Frame Relay Switching

The Cisco 12000 Series' packet over SONET (POS) line cards also support Frame Relay switching. The following features complement Frame Relay switching:

  • Frame Relay switching diagnostics and troubleshooting

  • FRF2.1 Annex 1

  • Frame Relay Extended Addressing

  • Frame Relay Traffic Policing

  • 64-bit Simple Network Management Protocol (SNMP) counters

Frame Relay Switching Diagnostics and Troubleshooting

The Frame Relay Switching Diagnostics and Troubleshooting feature enhances Frame Relay switching functionality by providing tools to diagnose problems in switched Frame Relay networks. The show frame-relay pvc command has been enhanced to display detailed reasons why packets were dropped from switched PVCs. The command also displays the local PVC status, the NNI PVC status, and the overall PVC status. If a network problem is observed, the debug frame-relay switching command can be used to display the status of packets on switched PVCs at regular intervals. This debug command displays information such as the number of packets that were switched, why packets were dropped, and changes in status of physical links and PVCs.

FRF2.1 Annex 1

FRF2.1 Annex 1 for Event Driven Procedures provides a signaling protocol for PVC monitoring at the NNI for a frame relay switching network. FRF2.1 Annex 1 generates notification when an event occurs to change status and when an event occurs, it generates immediate notification. It allows for faster notification of PVC status, such as addition, deletion, or availability, in frame relay switching networks with multiple switching nodes. The faster notification results in better network management as well as increased PVC scalability per interface since LMI procedures are not needed at each NNI node for each PVC in the network.

FRF2.1 Annex 1 adds event driven procedures to the enterprise Frame Relay network. It enables fast convergence and provides quick responses to any changes within a Frame Relay network.

Frame Relay Extended Addressing

The Frame Relay Extended Addressing feature implements a 23-bit data-link connection identifier (DLCI) on NNIs. This 23-bit DLCI supports values between 16 and 8388607.

Frame Relay Traffic Policing

The Frame Relay Traffic Policing feature provides a mechanism to rate-limit packets on switched PVCs using a "leaky-bucket" implementation. When enabled, traffic policing prevents traffic congestion by discarding or setting the Discard Eligible (DE) bit on packets that exceed specified traffic parameters. Traffic policing .parameters can be specified per DCE interface or per switched PVC, using the map class mechanisms.

The Frame Relay Traffic Policing prevents traffic congestion by treating traffic as either committed or excess. Committed traffic is that which fits within the committed burst allowed within a given time interval. Excess traffic is traffic which does not fit within the committed burst allowed within a given time interval.

Note:  Some excess traffic can be configured to be allowed through.

64-Bit SNMP Counters

Cisco IOS® Software Release 12.0(17)S introduced support for 64-bit SNMP counters on Frame Relay interfaces. Use the show frame-relay pvc [interface] [dlci] [64-bit] command to view the counters.

The following table lists known issues with SNMP counters for Frame Relay over POS:

Cisco Bug ID Description
CSCdr43764 Extracting 64-bit SNMP counters for the Frame Relay subinterface on a POS interface might not work. This condition applies to both the relevant IF-MIB counters and the Cisco-specific 2 x 32-bit counters in CISCO-C12000-IF-HC-COUNTERS-MIB and relates only to the Frame Relay 64-bit PVC counts when a Frame Relay encapsulated interface is added to a POS interface. The main POS encapsulated subinterface counters are not affected and continue to function properly. Workaround: If the 32-bit equivalent SNMP counters from the IF-MIB are retrieved with a fast enough polling cycle that the counters can be guaranteed not to wrap between polls, the 64-bit SNMP counters are not necessary. Alternatively, upgrade to an image that contains a fix.
CSCds30986 Both 2x32-bit and 64-bit counters are incorrect when using Packet-over-SONET with Frame Relay encapsulation on subinterfaces.
CSCdt34120 On Engine 0 POS line cards, the input rate as displayed in the show interface output is higher than the interface line rate. This problem was introduced with support for 64-bit SNMP counters.
CSCdt49757 The 4xOC12 POS line card does not maintain input statistics per Frame Relay PVC to ensure maximum forwarding performance.
CSCdt51551 An Engine 0 POS line card may experience a line protocol status of down when configured with Multicast Broader Gateway Protocol (MBGP) and the neighbor peer-group command.


There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Jun 01, 2005
Document ID: 19180