Performance Data for Frame Relay


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 virtual circuits

  • Congestion monitoring

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:

  • frCircuitSentFrames: The number of frames sent from this virtual circuit since it was created

  • frCircuitSentOctets: The number of octets sent from this virtual circuit since it was created

  • frCircuitReceivedFrames: The number of frames received over this virtual circuit since it was created

  • frCircuitReceivedOctets: The number of octets received over this virtual circuit since it was created

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:

A The input packets(related to SNMP variable frCircuitReceivedFrames)

B The output packets (related to SNMP variable frCircuitSentFrames)

C The input bytes (related to SNMP variable frCircuitReceiveOctets)

D The output bytes (related to SNMP variable frCircuitSentOctets)

E The input FECN packets (related to SNMP variable frCircuitReceivedFECNs see "MIBs to Monitor for Forward/Backward Explicit Congestion Notification")

F The output FECN packets that will remain at 0 unless Frame Relay traffic shaping has been configured (see "MIBs to Monitor for Forward/Backward Explicit Congestion Notification")

G The number of incoming DE (Discard Eligible) marked packets (see "MIBs to Monitor for Discard Eligible Packets")

H The number of output DE marked packets normally 0 unless configured on the router (see "MIBs to Monitor for Discard Eligible Packets")

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.

Table 16-2. Frame Relay Utilization and Performance Information
if Index Name String SubIf Type DLCI Sent Frames Sent Octets Rcvd Frames Rcvd Octets FECN BECN
7 Serial0.1 PointTo Point 101 342 105467 258 100568 0 0
8 Serial0.2 Multipoint 201 576 345987 464 238971 14 23
9 Serial0.3 Multipoint 301 322 193416 288 172993 0 0
10 Serial0.4 Multipoint 401 221 100396 204 94044 0 0

Congestion Monitoring

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:

  • frCircuitReceivedFECNs: Reports the number of frames received from the network, indicating forward congestion since the virtual circuit was created

  • frCircuitReceivedBECNs: Reports the number of frames received from the network, indicating backward congestion since the virtual circuit was created

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

  • cfrCircuitDEouts

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:

  • locIfInputQueueDrops: Indicates the number of packets dropped because the input queue was full

  • locIfOutputQueueDrops: Indicates the number of packets dropped because the output queue was full

Related MIB objects from RFC-1213-MIB/IF-MIB are as follows:

  • ifInDiscards: Indicates the number of inbound packets that were discarded even though no errors had been detected to prevent their being deliverable to a higher-layer

  • ifOutDiscards: Indicates the number of outbound packets that were chosen to be discarded even though no errors had been detected to prevent their being transmitted

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:

  1. Rate Enforcement on a per-VC basis: Define and enforce a rate on the VC at which the router will send traffic into the network.

  2. Generalized BECN support on a per-VC basis: Enable router to dynamically fluctuate the rate at which it sends packets, depending on the BECNs it receives. For example, if the router begins receiving numerous BECNs, it will reduce the frame transmission rate. As BECNs become more intermittent, the router will increase the frame transmission rate.

  3. Virtual Circuit Queuing (Custom, Priority, and FIFO): For circuits carrying more than one protocol, queuing can now be applied on a per-VC basis. This can be accomplished by configuring queuing as in earlier releases and then applying either the keywords queue-list (for custom queuing) or priority-group (for priority queuing) to the map-class command used in traffic shaping. (See Example 16-2 for a sample traffic shaping configuration for Frame Relay.) It is essential for performance that queuing be defined the same when sending and receiving routers for proper operation.

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.

Configurable Parameters

For each Frame Relay virtual circuit, the user may configure the following router parameters:

  • CIR Committed information rate

  • Bc Committed burst size

  • Be Excess burst size

  • Q Queuing algorithm to be used within the VC

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:

 frame-relay traffic-shaping 

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:

 map-class frame-relay 

Some other related Frame Relay traffic shaping commands are as follows:

  • frame-relay custom-queue-list list-number Uses custom queuing to apply against the map-class command.

  • frame-relay priority-group list-number Uses priority queuing to apply against the map-class command.

  • frame-relay becn-response-enable Enables the use of congestion reduction when BECN bits are received.

  • frame-relay class map-class-name Enables the use of setting up the map-class name.

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:

  • frCircuitCommittedBurst: This variable indicates the maximum amount of data, in bits, that the network agrees to transfer under normal conditions, during the measurement interval.

  • frCircuitExcessBurst: This variable indicates the maximum amount of uncommitted data bits that the network will attempt to deliver over the measurement interval. By default, if not configured when creating the entry, the Excess Information Burst Size is set to the value of ifSpeed.

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.



Performance and Fault Management
Performance and Fault Management: A Practical Guide to Effectively Managing Cisco Network Devices (Cisco Press Core Series)
ISBN: 1578701805
EAN: 2147483647
Year: 2005
Pages: 200

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net