You can gather Frame Relay performance information either through MIBs or through the command-line interface (CLI) via Telnet or RSH. We will look at both methods, including what the highlighted variables indicate, why they are useful, and how to manage the resulting factors. Where appropriate, we also will identify some starting point thresholds to set and watch for when monitoring performance. But please note that the threshold settings defined in this section reflect only a starting point and nothing more. You must understand your network traffic flows and network characteristics before making the appropriate threshold setting. Thresholds constantly need re-evaluation and adjustment to meet the needs of your environment.
We will consider the following performance issues for Frame Relay:
Measuring Utilization On Frame Relay Virtual Circuits
To accomplish this task, you must be able to associate the collected data with the appropriate DLCI and interface. The data in Table 16-1 will be used in this section for example purposes. The standard ifTable variables are important to gather as well (refer to Chapter 12 for more information).
MIBs to Monitor for Utilization
As in any circuit, the variables that you want to monitor are the packets (frames, in this case) and octets transmitted and received. The relevant variables from RFC 1315 are as follows:
The preceding variables provide you with the base utilization statistics for the specified virtual circuit. The variable frCircuitThroughput appears to be useful, but the variables that are used in the calculation frCircuitCommittedBurst and frCircuitExcessBurst are set to 0 unless Frame Relay traffic shaping is configured. Even then, the variables are manually configured by you (see "Traffic Shaping for Frame Relay" later in this chapter).
There is no threshold recommended. The CLI command show frame-relay pvc is covered in subsequent sections for each of the performance variables. Also, an example of an SNMP collection that extends the earlier table of virtual circuits and interfaces will be covered.
CLI Commands for Utilization
The show frame-relay pvc command (or show frame pvc, for short) displays the number of frames sent, octets sent, frames received, and octets received; as well as frames from the network indicating forward or backward congestion since the virtual circuit counters were cleared. It also provides the local DLCI number, creation time, and discard eligible packets.
The show frame pvc command is useful when you are troubleshooting the Frame Relay circuit. It contains several valuable data points in the display output that can help you identify possible problem areas with the router or in your network. Example 16-1 shows output from the show frame pvc command.
Example 16-1 Using the show frame pvc command to obtain utilization information.
router#sh frame pvc PVC Statistics for interface Serial2/0 (Frame Relay DTE) CI = 460, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0 input pkts 183521960A output pkts 186990758B in bytes 3108846619C out bytes 3787418196D dropped pkts 4 in FECNE pkts 49912 in BECN pkts 227072 out FECNF pkts 0 out BECN pkts 0 in DEG pkts 7488798 out DEH pkts 0 pvc create time 33w0d, last time pvc status changed 00:15:48
Here are the meanings of the annotated features in Example 16-1:
SNMP Example for Utilization
Using the frCircuitTable and the ifIndex information you already gathered, you can loop through all the PVCs in the frCircuitTable to gather the following information:
KEY=2.101 frCircuitIfIndex=7 frCircuitDlci=101 frCircuitState=active frCircuitReceivedFECNs=14 frCircuitReceivedBECNs=23 frCircuitSentFrames=576 frCircuitSentOctets=345987 frCircuitReceivedFrames=464 frCircuitReceivedOctets=238971 frCircuitCreationTime=42:30:07.48 frCircuitLastTimeChange=8:00:10.11 frCircuitCommittedBurst=0 frCircuitExcessBurst=0 frCircuitThroughput=0
After this information has been collected for each ifIndex and DLCI, you can extend Table 16-1, as shown in Table 16-2.
Congestion management in Frame Relay networks is a challenge for network managers. Although Frame Relay technology has congestion-notification mechanisms built into the specifications and switch vendors have implemented them, the notifications primarily have been intended for end systems, which are usually the source of the congestion.
MIBs to Monitor for Forward/Backward Explicit Congestion Notification
Congestion is a network problem that can result in severe degradation of the network in both response time and throughput. One of the essential elements in preventing congestion is through flow control. The two mechanisms that Frame Relay uses to notify users, routers, and Frame Relay switches about congestion are the BECN and FECN bits.
Two relevant variables, from RFC 1315, are the following:
These are good MIB variables to collect because they indicate that the Frame Relay circuit is receiving congestion. The variables are valuable for trending and capacity planning of the network. When a Frame Relay switch begins to experience congestion due to its queues becoming full or a problem with memory management, the switch usually will inform its upstream and downstream nodes through the setting of the FECN, BECN, and DE bits. Therefore, this data provides you and your circuit provider with information to use when making decisions on circuit sizing. Cisco routers currently record only the congestion variable numbers. Unless Frame Relay traffic shaping is configured for the Frame Relay interface, the router does not support any congestion control using the FECN, BECN, or DE bits.
The recommended baseline values to watch for are delta values greater than 100.
The show frame-relay pvc command (refer to Example 16-1) displays the number of frames received from the network, indicating forward or backward congestion since the virtual circuit counters were cleared. Looking at the packets that are marked for DE and the number of FECN and BECN packets received can provide an insight into the level of congestion on the Frame Relay circuit.
MIBs to Monitor for Discard Eligible Packets
The following variables, from CISCO-FRAME-RELAY-MIB, indicate the number of discard eligible packets that have been received or transmitted since the PVC was established:
cfrCircuitDEins is an important variable because it indicates that the committed information rate (CIR) for the VC is being exceeded. This variable indicates that the DE bit in the Frame Relay header has been set. The setting of this bit indicates that the frame is eligible for discard in the event of network congestion. The bit is set when a frame entering the switch is determined to be in excess of the Committed Information Rate (CIR), but less than the excess burst limit. If the Be (excess burst) limit is exceeded, the frame should be dropped during normal operation.
The option to not enforce the use of the DE bit is available in some Frame Relay switches and may be useful where Ingress and Egress access speeds are equal and where full bandwidth could be used when available. All access being equal would allow full bandwidth to be used if needed. This type of scenario would usually apply to private Frame Relay networks, such as an internal stratacom network.
The cfrCircuitDEouts indicate that the DE bit has been set before entering the Frame Relay switch cloud by DTE equipment, such as a router. Cisco IOS allows the setting of DE bit for packets classified through standard access lists.
The recommended baseline threshold values are delta greater than 100.
As shown in Example 16-1, the CLI command show frame-relay pvc also provides information on the number of DE-marked packets, both incoming and outgoing.
MIBs to Monitor for Packet Discards
Actively monitoring the Frame Relay dropped packets provides you with an immediate insight into the circuit congestion. The relevant variable, from CISCO-FRAME-RELAY-MIB, is cfrCircuitDropPktsOuts, which indicates the number of drops on a virtual circuit.
The recommended baseline threshold is a delta value greater than 100.
Related MIB objects from OLD-CISCO-INTERFACE are as follows:
Related MIB objects from RFC-1213-MIB/IF-MIB are as follows:
The show frame-relay pvc command (refer to Example 16-1) also provides packet discard information. In this case, you would look specifically at the amount of output drops, input drops, and no buffer values.
Committed Burst and Excess Burst Rates
The routers that connect the end stations to the Frame Relay network have largely played a passive role in Frame Relay congestion management. Many protocols do not have a mechanism to provide for congestion notification; that is, the protocol header contains no congestion indication bit. This has driven the need for more control and led to the development of a Frame Relay traffic shaping congestion-management feature that can also prioritize the data going into a Frame Relay network.
Traffic Shaping for Frame Relay
Before looking at MIBs and CLI commands for committed burst and excess burst information, you need to understand more about traffic shaping for Frame Relay. This feature, available in IOS release 11.2, allows the router to regulate and prioritize the transmission of frames on a per-VC basis to the network as well as react to congestion notification from the Frame Relay network. Traffic shaping for Frame Relay can be broken down into three main components:
The functions just described apply to both PVCs and SVCs. Additional overall feedback is provided to the traffic shaping algorithm by monitoring the queue depth of the physical interface. This means that you can populate the variables. Based on the accuracy of your input, this capability can assist you in managing your Frame Relay network.
The rate enforcement algorithm used incorporates a two-stage queuing process. The first stage is where the queuing on a VC basis is implemented, using Custom, Priority, or the default First Come, First Served mechanism. These first-stage queues output into a single interface-level queue. Traffic is then metered at the output of the per-VC queues, based on the traffic-shaping configuration parameters specified for each of these queues. It is important to note that Weighted Fair Queuing and Traffic Shaping over Frame Relay are mutually exclusive.
For each Frame Relay virtual circuit, the user may configure the following router parameters:
These variables are used to ensure that the router paces traffic to match the service level agreement with the service provider. They pace traffic going out, but do not alter the settings on the connected FR switch.
Facilities are provided so that a user may configure a default profile for all VCs at the interface or sub-interface level that can be overridden at the individual VC level, if required. See the configuration Example 16-2 of Frame Relay traffic shaping.
End User Interface
The end user interface on the router is configured using the following command:
The following interface level command turns on traffic shaping and per-VC queuing:
frame-relay traffic-rate average [peak]
where average is the average rate equivalent to CIR in bps and peak is the peak rate equivalent to CIR + Be/t = CIR(1+Be/Bc). If peak is omitted, the default value used is derived from the BW (interface bandwidth) parameter.
The following command marks the section where the traffic shaping parameters are defined:
Some other related Frame Relay traffic shaping commands are as follows:
Example 16-2 shows output from the sample traffic-shaping configuration for Frame Relay. Note that comment lines are provided to highlight the purpose of specific command lines. The routers used in Example 16-2 are named FR-Hub and FR-spoke router.
Example 16-2 Sample traffic-shaping configuration for Frame Relay.
FR-Hub router configuration Current configuration: ! version 11.2 ! hostname FR-Hub ! ! interface Ethernet0 ip address 10.100.1.1 255.255.255.0 media-type 10BaseT ! ! interface Serial0 no ip address encapsulation frame-relay no fair-queue ! !Enable Traffic Shaping on physical interface ! frame-relay traffic-shaping ! interface Serial0.1 point-to-point ip address 10.20.1.113 255.255.255.240 ipx network AB449D80 ! !the map-class defined below is assigned to this subinterface frame-relay class 32cir frame-relay interface-dlci 101 broadcast ! interface Serial0.2 point-to-point ip address 10.20.1.129 255.255.255.240 ! !the map-class defined below is assigned to this subinterface frame-relay class 16cir frame-relay interface-dlci 102 broadcast ! interface Serial0.3 point-to-point ip address 10.20.1.145 255.255.255.240 ! !the map-class defined below is assigned to subinterface frame-relay class bc64 frame-relay interface-dlci 103 broadcast ! ! router eigrp 100 network 10.20.0.0 ! map-class frame-relay 32cir ! !the average & peak rates are set to the VC's CIR, and Excess Burst frame-relay traffic-rate 32000 64000 ! !a custom queue list is also assigned to this map class frame-relay custom-queue-list 1 ! map-class frame-relay 16cir ! !the average & peak rates are set to the VC's CIR, and Excess Burst frame-relay traffic-rate 16000 64000 ! map-class frame-relay bc64 frame-relay cir in 32000 ! !Here, specific control of parameters is possible on a bi-directional basis frame-relay cir out 32000 frame-relay bc in 32000 frame-relay bc out 64000 frame-relay be in 64000 frame-relay be out 64000 ! queue-list 1 protocol ip 1 queue-list 1 protocol ipx 2 queue-list 1 queue 1 byte-count 4200 queue-list 1 queue 2 byte-count 1400 ! ! end FR-Spoke Configuration Current configuration: ! version 11.2 ! hostname FR-Spoke ! enable password cisco ! ipx routing 0000.0c18.d70c ! interface Ethernet0 ip address 10.21.1.1 255.255.255.0 ipx network ABC001 ! ! interface Serial0 ip address 10.20.1.146 255.255.255.240 encapsulation frame-relay ipx network ABC010 frame-relay traffic-shaping ! !the map-class defined below is assigned to interface frame-relay class 32cir ! router eigrp 100 network 10.20.0.0 ! ! no ip classless ! map-class frame-relay 32cir ! !the average & peak rates match those in the Hub router frame-relay traffic-rate 32000 64000 frame-relay custom-queue-list 1 !the custom queue list matches that in the Hub router ! queue-list 1 protocol ip 1 queue-list 1 protocol ipx 2 queue-list 1 queue 1 byte-count 4200 queue-list 1 queue 2 byte-count 1400 ! ! end
Benefits of Frame Relay Traffic Shaping
Traffic shaping allows you to prioritize packets on a per-VC basis, which is important when multiple protocols are configured on the same DLCI.
Frame Relay traffic entering a Frame Relay network does so at the link access rate, regardless of any parameters set on the switch such as CIR, Excess Burst, or Committed Burst. Of course, the rate and volume of traffic entering the switch will be monitored at the input, and decisions will be made on what to do with the traffic based on these parameters. The Frame Relay traffic shaping provides control over how much data is sent into the network. It enables you to ensure, for example, that packets enter the Frame Relay network within CIR and thus have a guarantee of being propagated through. You can further ensure that traffic enters the network within the Excess Burst limit so that immediate drops do not occur.
By working with your service provider, understanding your network traffic patterns, and experimenting with the different levels, you can find the correct rate-enforcement parameters for your particular environment. Finding these parameters can result in maximizing the available resources while minimizing the amount of dropped frames.
In the event of congestion within the Frame Relay network where Backward Explicit Congestion Notification (BECN) is provided to the source (in this case, the router), a further throttling of data that is network-bound will occur. The congestion in the Frame Relay network then has a much better chance of dissipating quickly, with the result that fewer DE packets are dropped.
The throttling occurs if a router receives any BECNs during the current time interval (Interval = Bc/CIR, with the maximum size being 125ms). Whether the router receives 1 or 1000 BECNs in this time interval, it decreases the transmit rate by 25 percent. The rate will continue to drop with each BECN (the limit is one drop per time interval) until the traffic rate gets to mincir, where it stops. The mincir is the minimum amount of data to be sent during periods of congestion. By default, this is half of CIR.
After the traffic rate has decreased, it takes 16 time intervals of receiving no BECNs to start to increase traffic again. The amount that traffic increases by is (Be+Bc)/16, or (more accurately) the byte limit that shows up in show traffic and sh frame pvc x divided by 16. Therefore, it takes much longer to get back to CIR than it does to drop to mincir. This is similar to the slow start in TCP/IP. One way of making this length of time much shorter would be to set Be to 7 times the value of Bc, which would ensure that the traffic rate gets back to CIR immediately after going through 16 time intervals without a BECN.
It is important to note two issues. First, this throttling occurs only when traffic shaping is configured. If traffic shaping is not configured, the transmit increment will stay the same whether BECNs are being received or not. Second, traffic shaping of your circuits within the presence of congestion from other customers who are not traffic shaping can lead to limiting the traffic on your circuits while another's traffic saturates the trunk.
MIBs to Monitor for Committed Burst and Excess Burst Information
From RFC 1315-MIB, the variables to monitor for Bc and Be are as follows:
Neither of these MIB variables means anything without the configuration of Frame Relay traffic shaping.
Again, you can use the CLI command show frame-relay pvc to obtain similar information to these MIB variables (refer to Example 16-1).
Correlating Performance Variables
The MIB variables for FECN, BECN, DE, and dropped packets all are correlated statistically with respect to performance management. Also, much of what you gather in performance management can be applied to fault/error management.
Specifically, you should look for a high number of FECNs or BECNs, combined with a high number of received packets with DE bit set. This correlation is the only indication, other than calls from the users, that you are experiencing congestion on the Frame Relay circuit. When a Frame Relay switch begins to experience congestion due to its queues becoming full or problems with memory management, the switch sets the FECN, BECN, and DE bits to inform its upstream and downstream nodes. Therefore, you can use this data in conjunction with your Frame Relay provider to make decisions on circuit sizing or in the use of features such as Frame Relay traffic shaping.
Using the performance variables in the frCircuitTable, detailed previously, with the cfrExtCircuitTable variables detailed in the section "Identifying the Frame Relay Interface," you can build a table that correlates ifIndex, interface type, and virtual circuit with the utilization and congestion data. This is essential to both understanding and managing your Frame Relay network.