/mcpPVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 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 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end−to−end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303 Refer to the show frame−relay pvc description for a complete explanation of all fields. What to Look For What you should be concerned with in the command output are the values that show if there has been congestion in the frame network. These values are the forward explicit congestion notification (FECN), backward explicit congestion notification (BECN) and discard eligible (DE) parameters. You should be concerned with only input packets since Cisco does not send any of these. You may see one or more of these values incrementing. This depends on the type and configuration of the frame switches that the provider uses. In general terms, if you have Frame Relay traffic shaping, and are configured for the same CIR as the circuit, you should never see these values increment. If you do see these values increment, and you match the true CIR of the circuit, something in the frame provider's network is not configured properly. One good example of this is if you purchase a zero CIR circuit, but have a burst value. Some providers sell the zero CIR permanent virtual circuit (PVC). This is fine for data, but causes problems with voice quality. If you look at the command output from a zero CIR circuit, the number of DE or FECN packets equals the number of input packets. To take this a step further, if you have a PVC that is provisioned by the carrier to be 128 kbs and the CIR of the router is set to 512 kbs, you see these counters increment (at a slower rate). Remember that you are only looking at packets that come into the router interface and that this rate is controlled by the traffic−shaping parameters configured on the router at the opposite end of the PVC. Conversely, you control what is input to the other router by which traffic−shaping parameters are configured on the local end. It is very important that you not exceed the CIR for the PVC that is provisioned by the carrier. You can be below this CIR without having problems. However, if you exceed it, you will see congestion. The reason you are able to see the congestion in this fashion is because the CIR that is configured for a specific PVC on a frame switch dictates the rate that traffic is passed by that switch (for that PVC). When the configured CIR on the frame switch is exceeded by the actual data rate it receives, it must buffer the frames that exceed the CIR until the capacity is available to forward the buffered packets. Any packet that is buffered gets either the DE bit set or the FECN bit set by the frame switch. As always, you also want to closely examine the interface statistics, and look for drops or errors to be sure that everything functions correctly at the physical layer. To do this, use the show interface command.