End-to-end PVC Management With Frame Relay to ATM Service Interworking (FRF.8)

Available Languages

Download Options

  • PDF     (39.3 KB)
    View with Adobe Reader on a variety of devices
Updated:November 15, 2007
Document ID:10440

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

In the FRF.8 implementation agreement, the Broadband Forum leavingcisco.com (formerly the Frame Relay Forum) defines communication between a Frame Relay endpoint and an ATM endpoint through a router or switch that interworks or connects the two layer-2 protocols. This document describes permanent virtual circuit (PVC) management procedures over a FRF.8 service interworking (IWF) connection and provides a sample configuration using a router and a switch.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

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

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Configure

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) .

FRF.8 PVC Management Procedures

Section 5.2 of FRF.8 describes ATM and Frame Relay PVC management procedures. On the ATM side, these procedures use F5 operations, administration, and maintenance (OAM) cells and Interim Local Management Interface (ILMI) Management Information Base (MIB) variables. The ATM status information is then mapped to the corresponding Frame Relay status indicators by the interworking device.

The Frame Relay side uses the local management interface (LMI) protocol to communicate status information. The standard 2-byte Frame Relay header does not include any fields that indicate the status of a virtual circuit (VC) to the endpoint. The LMI protocol thus augments Frame Relay with a mechanism that notifies the endpoint when a permanent virtual circuit (PVC) has been added, deleted or changed state. It also provides a polling mechanism which verifies the link remains operational. It sends LMI frames on a data link connection identifier (DLCI) that is different from the DLCI used for data traffic.

The message type field in the LMI frame is eight bits and consists of Status Enquiry and Status messages. Every few seconds, the Frame Relay endpoint (user) sends a Status Enquiry message to the network; this message verifies link integrity. The network responds with a Status message containing the requested information. After a defined number of status enquiries, the Frame Relay endpoint requests a so-called full status response. The network responds with a status message that contains an information element (IE) for every PVC configured on that link.

The PVC status IE is five bytes. In addition to the DLCI of the reported PVC, the IE contains two important status bits:

  • New bit - Set by the network when a PVC is added on a switch. The network continues to set the new bit to one in the full status message until it receives a status enquiry message from the Frame Relay endpoint (user) which contains a receive sequence number equal to the network's current send sequence number.

  • Active bit - Set when the network is satisfied that a complete path to a destination exists and that the PVC is fully established end to end.

One caveat with the Frame Relay status mechanism is that it is not a real-time process and must wait for scheduled status messages to be sent. In some cases, timing issues may arise if, after the PVC becomes available in the network, the two Frame Relay endpoints receive a full status message with the active bit set to one at different times. One endpoint will be sending data frames across the PVC before the other endpoint (the destination) has received an active status message.

The LMI protocol overcomes this weakness with the asynchronous status report type IE. An asynchronous message consists of status and status enquiry messages sent immediately after a change in PVC status and without waiting for the message timers to expire. Procedures for the asynchronous status message are not supported on Cisco routers doing the interworking.

Based on the status bits, a PVC is assigned one of four status values on the Frame Relay side. The switch or Cisco router performing the IWF uses a set of criteria to determine which status to assign to the VC.

Status Indications and Matching Criteria
Added Frame Relay network sets the new bit in a full status report to the IWF.
Deleted IWF reports this status to the Frame Relay network in a full status report.
Inactive IWF uses the following criteria to determine inactive status:
  • An alarm indication signal (AIS) or remote defect indicator (RDI) OAM F5 cell indicates explicitly that the ATM PVC is down somewhere along the end-to-end path.
  • The ILMI MIB reports localDown or end2EndDown in the variable atmfVccOperStatus.
IWF sends a full Status report with the Active bit set to zero.
Active IWF uses the following criteria to determine active status:
  • There is no AIS OAM cell and no RDI OAM cell from the ATM network for a time interval as defined in the OAM specification, ITU-I.610
  • The ILMI MIB does not report localDown or end2EndDown in the variable atmfVccOperStatus.
IWF places the VC in active status on the Frame Relay side when both criteria are met (if both are used) and where there are no physical alarms detected by the IWF on the ATM side. The IWF sends a full status report with the Active bit set to one to the Frame Relay network.

Example Using a Catalyst 8540 MSR as the IWF Switch

The example below shows a Catalyst 8540 MSR as the IWF switch.

Network Diagram

The topology appears as follows:

frf8_pvc_manage1.gif

Note: The ATM-router is a 7500 router using a PA-A3-OC3MM in a VIP2-50 and runnning 12.1(13)E. The FR-router is a 7200 router running 12.1(17). The ATM/FR-IWF-switch is an catalyst 8540MSR running 12.1(12c)EY.

Configurations

FR-router 
controller E1 4/0
 channel-group 0 timeslots 1-31
!         
interface Serial4/0:0
 ip address 12.12.12.2 255.255.255.0
 encapsulation frame-relay IETF
 no fair-queue
 frame-relay map ip 12.12.12.1 123 broadcast

ATM-FR/IWF-switch 
controller E1 10/0/0
 channel-group 1  timeslots 1-31
!
interface Serial10/0/0:1
 no ip address
 encapsulation frame-relay IETF
 no arp frame-relay
 frame-relay intf-type dce
 frame-relay pvc 123 service translation  interface  ATM9/1/2 0 123 
 atm oam interface  ATM9/1/2 0 123

ATM-router 
interface ATM2/1/0.1 point-to-point
 ip address 12.12.12.1 255.255.255.0
 pvc 0/123 
  oam-pvc manage
  encapsulation aal5snap

Show Commands 

ATM-router#show atm pvc 0/123
ATM2/1/0.1: VCD: 2, VPI: 0, VCI: 123
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 10 second(s), OAM retry frequency: 1 second(s), OAM retry frequen
cy: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Received
OAM VC state: Verified
ILMI VC state: Not Managed
VC is managed by OAM.
InARP frequency: 15 minutes(s)
Transmit priority 4
InPkts: 5, OutPkts: 8, InBytes: 540, OutBytes: 624
InPRoc: 5, OutPRoc: 5
InFast: 0, OutFast: 0, InAS: 0, OutAS: 3
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 124713
F5 InEndloop: 74872, F5 InSegloop: 49841, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 124756
F5 OutEndloop: 74915, F5 OutSegloop: 49841, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP

FR-router#show frame-relay pvc

PVC Statistics for interface Serial4/0:0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 123, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0:0

  input pkts 8             output pkts 5            in bytes 1633      
  out bytes 520            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 0          out bcast bytes 0         
  pvc create time 00:02:44, last time pvc status changed 00:02:44

ATM-FR/IWF-switch#show frame-relay pvc 

PVC Statistics for interface Serial10/0/0:1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 123, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial10/0/0:1

  input pkts 5             output pkts 6            in bytes 520       
  out bytes 550            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 4151       out bcast bytes 1494481      Num Pkts Switched 0         
  pvc create time 2d21h, last time pvc status changed 2d21h

ATM-FR/IWF-switch#show atm vc interface atm 9/1/2 0 123

Interface: ATM9/1/2, Type: oc3suni 
VPI = 0  VCI = 123
Status: UP
Time-since-last-status-change: 2d21h
Connection-type: PVC 
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 32
OAM-configuration: Seg-loopback-on End-to-end-loopback-on Ais-on Rdi-on
OAM-states:  OAM-Up
OAM-Loopback-Tx-Interval: 5
Cross-connect-interface: ATM-P10/0/0, Type: ATM-PSEUDO 
Cross-connect-VPI = 1 
Cross-connect-VCI = 155
Cross-connect-UPC: pass
Cross-connect OAM-configuration: Ais-on
Cross-connect OAM-state:  OAM-Up
OAM-Loopback-Tx-Interval: 5
Threshold Group: 3, Cells queued: 0
Rx cells: 16, Tx cells: 15
Tx Clp0:15,  Tx Clp1: 0
Rx Clp0:16,  Rx Clp1: 0
Rx Upc Violations:9, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 100
Rx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Rx pcr-clp01: 81
Rx scr-clp0 : 81
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: 50
Tx connection-traffic-table-index: 100
Tx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Tx pcr-clp01: 81
Tx scr-clp0 : 81
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: 50

Scenario One

Using the configuration described above, let's see know how both routers react to failures within the network. In this first scenario, we will shut down the ATM-router ATM interface and see what the impact of this failure on the FR-router PVC is.

  1. Shutdown the ATM sub-interface on the ATM-router:

       ATM-router#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   ATM-router(config)#interface atm 2/1/0.1
   ATM-router(config-subif)#shut

  2. Check the status of the PVC on the ATM-FR/IWF-switch:

    ATM-FR/IWF-switch#show atm vc interface atm 9/1/2 0 123

Interface: ATM9/1/2, Type: oc3suni 
VPI = 0  VCI = 123
Status: UP
Time-since-last-status-change: 00:00:44
Connection-type: PVC 
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 32
OAM-configuration: Seg-loopback-on End-to-end-loopback-on Ais-on Rdi-on
OAM-states:  OAM-Up Segment-loopback-failed End-to-end-loopback-failed
OAM-Loopback-Tx-Interval: 5
Cross-connect-interface: ATM-P10/0/0, Type: ATM-PSEUDO 
Cross-connect-VPI = 1 
Cross-connect-VCI = 155
Cross-connect-UPC: pass
Cross-connect OAM-configuration: Ais-on
Cross-connect OAM-state:  OAM-Up
OAM-Loopback-Tx-Interval: 5
Threshold Group: 3, Cells queued: 0
Rx cells: 1, Tx cells: 0
Tx Clp0:0,  Tx Clp1: 0
Rx Clp0:1,  Rx Clp1: 0
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 100
Rx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Rx pcr-clp01: 81
Rx scr-clp0 : 81
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: 50
Tx connection-traffic-table-index: 100
Tx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Tx pcr-clp01: 81
Tx scr-clp0 : 81
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: 50

  3. Check the PVC status on the FR-router:

    FR-router#show frame-relay pvc

PVC Statistics for interface Serial4/0:0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            1            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 123, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial4/0:0

  input pkts 18            output pkts 5            in bytes 4320      
  out bytes 520            dropped pkts 5           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 0          out bcast bytes 0         
  pvc create time 00:15:21, last time pvc status changed 00:03:50

As you can see in the outputs above, a failure on the ATM side is reflected on the FR side. Indeed, the FR PVC goes into INACTIVE state.

Scenario Two

Now, let's see what happens on the ATM side when a failure occurs within the FR cloud. To simulate that type of failure, let's shut down the serial interface on the FR-router and see how the ATM-router reacts.

  1. Shut down the serial interface on the FR-router and see how the ATM-router reacts:

       FR-router#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   FR-router(config)#int serial 4/0:0
   FR-router(config-if)#shut

  2. debug atm oam is enabled on the ATM-router. We can see that, upon detection of the failure, the ATM-FR/IWF-switch is sending an AIS signal to the ATM router:

       3d12h: atm_oam_ais(ATM2/1/0): AIS signal, failure=0x6A, VC 0/123
   3d12h: atm_oam_setstate - VCD#3, VC 0/123: newstate = AIS/RDI
   3d12h: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM2/1/0.1, changed state    to down
   3d12h: atm_oam_ais_inline(ATM2/1/0): AIS signal, failure=0x6A, VC 0/123

    If we check the PVC status on the ATM-router, we can see that the PVC is down:

    ATM-router#show atm pvc 0/123
ATM2/1/0.1: VCD: 3, VPI: 0, VCI: 123
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 10 second(s), OAM retry frequency: 1 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Received
OAM VC state: AIS/RDI
ILMI VC state: Not Managed
VC is managed by OAM.
InARP frequency: 15 minutes(s)
Transmit priority 4
InPkts: 0, OutPkts: 4, InBytes: 0, OutBytes: 112
InPRoc: 0, OutPRoc: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 4
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 304
F5 InEndloop: 114, F5 InSegloop: 69, F5 InAIS: 121, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 310
F5 OutEndloop: 120, F5 OutSegloop: 69, F5 OutRDI: 121
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: DOWN, State: NOT_VERIFIED

  3. Check the status on the ATM-FR/IWF-switch:

    ATM-FR/IWF-switch#show atm vc interface atm 9/1/2 0 123

Interface: ATM9/1/2, Type: oc3suni 
VPI = 0  VCI = 123
Status: DOWN
Time-since-last-status-change: 00:03:04
Connection-type: PVC 
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 32
OAM-configuration: Seg-loopback-on End-to-end-loopback-on Ais-on Rdi-on
OAM-states:  OAM-Up
OAM-Loopback-Tx-Interval: 5
Cross-connect-interface: ATM-P10/0/0, Type: ATM-PSEUDO 
Cross-connect-VPI = 1 
Cross-connect-VCI = 155
Cross-connect-UPC: pass
Cross-connect OAM-configuration: Ais-on
Cross-connect OAM-state:  OAM-Down
OAM-Loopback-Tx-Interval: 5
Threshold Group: 3, Cells queued: 0
Rx cells: 3, Tx cells: 0
Tx Clp0:0,  Tx Clp1: 0
Rx Clp0:3,  Rx Clp1: 0
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 100
Rx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Rx pcr-clp01: 81
Rx scr-clp0 : 81
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: 50
Tx connection-traffic-table-index: 100
Tx service-category: VBR-NRT (Non-Realtime Variable Bit Rate)
Tx pcr-clp01: 81
Tx scr-clp0 : 81
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: 50

So, we can see that, thanks to OAM, the ATM router will react to a failure within the FR cloud by bringing down the corresponding ATM PVC.

Known Caveats

  • CSCdu78168 (duplicate of CSCdt04356): OAM management does not work on MSR with FR to ATM IWF

Example Using a Cisco 7200 Router as the IWF

Network Diagram

frf8_pvc_manage2.gif

Configurations

3620 
interface Serial1/0 
 ip address 10.10.10.1 255.255.255.0 
 encapsulation frame-relay IETF 
 frame-relay interface-dlci 50 
 frame-relay lmi-type ansi

7206 
frame-relay switching 
! 
interface Serial4/3 
 no ip address 
 encapsulation frame-relay IETF 
 frame-relay interface-dlci 50 switched 
 frame-relay lmi-type ansi 
 frame-relay intf-type dce 
 clockrate 115200 
! 
interface ATM5/0 
 no ip address 
 atm clock INTERNAL 
 no atm ilmi-keepalive 
 pvc 5/50 
  vbr-nrt 100 75 
  oam-pvc manage 
  encapsulation aal5mux fr-atm-srv 
! 
connect SIVA Serial4/3 50 ATM5/0 5/50 service-interworking

7500 
interface atm 4/0/0.50 multi 
 ip address 10.10.10.2 255.255.255.0 
 pvc 5/50 
  vbr-nrt 100 75 30 
  protocol ip 10.10.10.1

Scenario One

The following scenario assumes that we have configured the ATM endpoint and the ATM interface on the IWF with the oam-pvc manage command. We will remove the PVC configuration statement from the ATM endpoint. When the ATM PVC comes down, the Frame Relay PVC changes to inactive status.

  1. Enable debug atm oam and clear the counters

    1d09h: ATM OAM(ATM4/0/0.50): Timer: VCD#5 VC 5/50 Status:2 CTag:8586 Tries:0 
1d09h: ATM OAM LOOP(ATM4/0/0.50) O: VCD#5 VC 5/50 CTag:218B 
1d09h: ATM OAM LOOP(ATM4/0/0) I: VCD#5 VC 5/50 LoopInd:0 CTag:218B    
1d09h: ATM OAM LOOP(ATM4/0/0) I: VCD#5 VC 5/50 LoopInd:1 CTag:4850    
1d09h: ATM OAM LOOP(ATM4/0/0.50) O: VCD#5 VC 5/50 CTag:4850

  2. Delete the PVC from the ATM endpoint with the "no" form of the new-style pvc command. 

    7500#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
7500(config)#interface atm 4/0/0.50
7500(config-subif)#no pvc 5/50

  3. Execute the show atm vc command and confirm the status of the VC is DOWN on the IWF 7200. 

    7200#show atm vc 
              VCD /                                Peak Avg/Min Burst 
   Interface  Name  VPI   VCI   Type  Encaps   SC  Kbps Kbps    Cells   Sts 
   5/0.200    test   2    20    PVC   SNAP     UBR 149760                UP 
   5/0.100     2     3    300   PVC   SNAP     UBR 149760                UP 
   5/0         1     5    50    PVC   FRATMSRV VBR 100     75     95    DOWN

  4. Execute the show atm pvc {vpi/vci} command and confirm OAM VC state: Not Verified. 

    7200#show atm pvc 5/50 
   ATM5/0: VCD: 1, VPI: 5, VCI: 50 
   VBR-NRT, PeakRate: 100, Average Rate: 75, Burst Cells: 95 
   AAL5-FRATMSRV, etype:0x15, Flags: 0x23, VCmode: 0x0 
   OAM frequency: 10 second(s), OAM retry frequency: 1 second(s),    OAM retry frequency: 1 second(s) 
   OAM up retry count: 3, OAM down retry count: 5 
   OAM Loopback status: OAM Sent 
   OAM VC state: Not Verified 
   ILMI VC state: Not Managed 
   VC is managed by OAM. 
   InARP DISABLED 
   Transmit priority 2 
   InPkts: 0, OutPkts: 0, InBytes: 0, OutBytes: 0 
   InPRoc: 0, OutPRoc: 0, Broadcasts: 0 
   InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 
   InPktDrops: 0, OutPktDrops: 0 
   CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0 
   Out CLP=1 Pkts: 0 
   OAM cells received: 19 
   F5 InEndloop: 19, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0    
   F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 
   OAM cells sent: 82 
   F5 OutEndloop: 82, F5 OutSegloop: 0, F5 OutRDI: 0 
   F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0 
   OAM cell drops: 0 
   Status: DOWN, State: NOT_VERIFIED

  5. Enable debug frame-relay packet on the Frame Relay endpoint. Observe the sequence of Status and Status Enquiry (StEnq) messages exchanged between the user and network ends of the Frame Relay connection. Confirm that the status of the VC changes from 0x2 (active) to 0x0 (inactive). 

    *Apr 7 01:53:18.407: Serial1/0(in): Status, myseq 69    
   *Apr 7 01:53:18.407: RT IE 1, length 1, type 0 
   *Apr 7 01:53:18.407: KA IE 3, length 2, yourseq 67, myseq 69    
   *Apr 7 01:53:18.407: PVC IE 0x7 , length 0x3 , dlci 50, status 0x2 
   
! -- A value of 0x2 indicates active status.
    
   *Apr 7 01:53:28.403: Serial1/0(out): StEnq, myseq 70, yourseen 67, DTE up 
   *Apr 7 01:53:28.403: datagramstart = 0x3D53954, datagramsize = 14    
   *Apr 7 01:53:28.403: FR encap = 0x00010308 
   *Apr 7 01:53:28.403: 00 75 95 01 01 01 03 02 46 43 
   *Apr 7 01:53:28.403: 
   *Apr 7 01:53:28.407: Serial1/0(in): Status, myseq 70 
   *Apr 7 01:53:28.407: RT IE 1, length 1, type 1 
   *Apr 7 01:53:28.407: KA IE 3, length 2, yourseq 68, myseq 70    
   *Apr 7 01:53:38.403: Serial1/0(out): StEnq, myseq 71, yourseen 68, DTE up 
   *Apr 7 01:53:38.403: datagramstart = 0x3D53954, datagramsize = 14    
   *Apr 7 01:53:38.403: FR encap = 0x00010308 
   *Apr 7 01:53:38.403: 00 75 95 01 01 01 03 02 47 44 
   *Apr 7 01:53:38.403: 
   *Apr 7 01:53:38.407: Serial1/0(in): Status, myseq 71 
   *Apr 7 01:53:38.407: RT IE 1, length 1, type 0 
   *Apr 7 01:53:38.407: KA IE 3, length 2, yourseq 69, myseq 71    
   *Apr 7 01:53:38.407: PVC IE 0x7 , length 0x3 , dlci 50, status 0x0 
   
! -- A value of 0x0 indicates inactive status.

    The possible values of the status field are explained below:

    • 0x0 - Added and inactive. The DLCI is programmed in the switch, but is not usable. One potential reason is that the other end of the PVC is down.

    • 0x2 - Added and active. The DLCI is programmed in the switch, and the PVC is operational.

    • 0x3 - Combines active status (0x2) and the receiver not ready (RNR) (or r-bit) that is set (0x1). A value of 0x03 means that the switch or a particular queue on the switch for this PVC is backed up, so the Frame Relay interface stops transmitting to avoid lost frames.

    • 0x4 - Deleted. The DLCI is not programmed in the switch, but was programmed previously. Alternately, a deleted status can be caused by the DLCIs being reversed on the router or by the PVC being deleted by the telco in the Frame Relay cloud. Configuring a DLCI on a Frame Relay endpoint without a matching value on the switch leads to a 0x4 status value for the VC.

  6. If you cannot run debug frame-relay packet on a production router, simply execute show frame pvc and confirm that the Frame Relay endpoint lists at least one inactive local PVC. 

    3620#show frame pvc    
PVC Statistics for interface Serial1/0 (Frame Relay DTE)    
                  Active     Inactive     Deleted     Static 
      Local         0           1            0           0      
      Switched      0           0            0           0 
      Unused        0           0            0           0    
DLCI = 50, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial1/0    
      input pkts 0             output pkts 0            in bytes 0 
      out bytes 0              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 0         out bcast bytes 0 
      pvc create time 3d04h, last time pvc status changed 00:05:04

Scenario Two

The following scenario assumes that we simply remove the oam-pvc manage command from the IWF 7200. The ATM VC remains in the UP status and in turn remains active on the Frame Relay side.

  1. Remove the oam-pvc manage command on the IWF 7200's ATM interface. 

       7200(config)#int atm 5/0 
   7200(config-if)#pvc 5/50 
   7200(config-if-atm-vc)#no oam-pvc manage 
   7200(config-if-atm-vc)#end 
   7200#show atm vc 
   *May 31 01:20:01.499: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM5/0,    changed state to up 
             VCD /                                    Peak   Avg/Min Burst 
   Interface Name   VPI   VCI   Type   Encaps   SC    Kbps   Kbps    Cells   Sts 
   5/0.100     2     3     300  PVC    SNAP      UBR  149760                  UP 
   5/0         1     5     50   PVC    FRATMSRV  VBR  100     75       95     UP

  2. Use the "no" form of the pvc command to delete the PVC on the ATM endpoint. 

    7500(config)#int atm 4/0/0.50 
   7500(config-subif)#no pvc 5/50 
   7500(config-subif)#end

  3. The show atm pvc vpi/vci command confirms that the status remains UP on the ATM side. 

    7200-2.4#show atm pvc 5/50 
   ATM5/0: VCD: 1, VPI: 5, VCI: 50 
   VBR-NRT, PeakRate: 100, Average Rate: 75, Burst Cells: 95 
   AAL5-FRATMSRV, etype:0x15, Flags: 0x23, VCmode: 0x0 
   OAM frequency: 0 second(s), OAM retry frequency: 1 second(s),    OAM retry frequency: 1 second(s) 
   OAM up retry count: 3, OAM down retry count: 5 
   OAM Loopback status: OAM Disabled 
   OAM VC state: Not Managed 
   ILMI VC state: Not Managed 
   InARP DISABLED 
   Transmit priority 2 
   InPkts: 15, OutPkts: 19, InBytes: 1680, OutBytes: 1332 
   InPRoc: 0, OutPRoc: 0, Broadcasts: 0 
   InFast: 15, OutFast: 19, InAS: 0, OutAS: 0 
   InPktDrops: 0, OutPktDrops: 0 
   CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0 
   Out CLP=1 Pkts: 0 
   OAM cells received: 157 
   F5 InEndloop: 157, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0 
   F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 
   OAM cells sent: 214 
   F5 OutEndloop: 214, F5 OutSegloop: 0, F5 OutRDI: 0 
   F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0 
   OAM cell drops: 0 
   Status: UP

  4. The status of the PVC on the Frame Relay side also remains active. 

     *Apr 7 02:25:08.407: Serial1/0(in): Status, myseq 5    
   *Apr 7 02:25:08.407: RT IE 1, length 1, type 0 
   *Apr 7 02:25:08.407: KA IE 3, length 2, yourseq 3 , myseq 5 
   *Apr 7 02:25:08.407: PVC IE 0x7 , length 0x3 , dlci 50, status 0x2 
   
! -- The Frame Relay PVC retains an active status (0x2). 

   *Apr 7 02:25:18.403: Serial1/0(out): StEnq, myseq 6, yourseen 3, DTE up 
   *Apr 7 02:25:18.403: datagramstart = 0x3D53094, datagramsize = 14    
   *Apr 7 02:25:18.403: FR encap = 0x00010308 
   *Apr 7 02:25:18.403: 00 75 95 01 01 00 03 02 06 03

  5. The show frame pvc command confirms the active status of the PVC on the Frame Relay endpoint. 

    3620#show frame pvc
PVC Statistics for interface Serial1/0 (Frame Relay DTE)    
               Active Inactive Deleted Static 
      Local      1      0       0        0      
      Switched   0      0       0        0 
      Unused     0      0       0        0    
DLCI = 50, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0    
      input pkts 0        output pkts 0         in bytes 0 
      out bytes 0         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 0    out bcast bytes 0 
      pvc create time 3d04h, last time pvc status changed 00:02:45

Troubleshoot

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

Related Information

Revision History

Revision Publish Date Comments
1.0
15-Nov-2007
Initial Release

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products