Document ID: 10440
Updated: Nov 15, 2007
Contents
Introduction
In the FRF.8 implementation agreement, the
Broadband
Forum
(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:
|
| Active |
IWF uses the following criteria to determine active status:
|
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:
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.
-
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
-
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
-
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.
-
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
-
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
-
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
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.
-
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
-
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
-
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 -
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
-
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.
-
-
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.
-
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 -
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
-
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
-
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
-
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
Open a Support Case 
(Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.