ErrorFault Data for Frame Relay

Error/Fault Data for Frame Relay

The means to monitor errors and faults for Frame Relay are essentially the same as those covered in Chapter 12. The problem is being able to manage virtual circuit utilization and end-to-end delay measurements, which is mandatory for assessing the impact of network queuing. Beyond the statistics that we have covered under the performance section, decodes and traces of Layer 3 protocols are required for the complete isolation of virtual path problems. Packet capture and decodes are used to verify the integrity of application traffic.

This section covers the following:

• Monitoring Frame Relay Circuit Flapping

• Monitoring Frame Relay Errored Frames

Monitoring Frame Relay Circuit Flapping

From RFC 1315-MIB, several MIB variables are useful for monitoring circuit flapping:

• frCircuitState: Indicates whether the particular virtual circuit is operational.

• frCircuitCreationTime: Indicates the value of sysUpTime when the virtual circuit was created, whether by the Data Link Connection Management Interface or by a SetRequest.

• frCircuitLastTimeChange: Indicates the value of sysUpTime when last there was a change in the state of the virtual circuit.

• frTrapState: Indicates whether the system produces the frDLCIStatusChange trap.

In the absence of a Data Link Connection Management Interface, virtual circuit entries (rows) may be created by setting the virtual circuit state to active (frCircuitState in the previous performance SNMP example) or deleted by changing circuit state to invalid. Whether or not the row actually disappears is an implementation issue, so the frCircuitState object may actually read as invalid for some arbitrary length of time. It is also legal to set the state of a virtual circuit to inactive to temporarily disable a given circuit.

Changes in the circuit state and the creation time of the circuit can provide you with indications of circuit problems with your Frame Relay provider. They also provide a way to check the frDLCIStatusChange trap on your network management station. If the FrCircuitCreationTime is not changing, but you are receiving the frDLCIStatusChange trap, then your circuit may not be fluctuating. Therefore, looking at the FrCircuitCreationTime caching, comparing to the last value, and reporting if there is a change will help to correlate with the frDLCIStatusChange traps that are received.

The recommended baseline threshold values are related to each other. If frCircuitState changes, other variables should experience a corresponding change.

See the output from show frame-relay pvc in the performance section (refer to Example 16-1) for CLI command information that corresponds to these MIBs.

From CISCO-FRAME-RELAY-TRAP, a related SNMP trap message is frDLCIStatusChange. This reload trap indicates that the Frame Relay PVC specified by the DLCI has changed.

A number of syslog messages are useful for Frame Relay circuit fault management and apply directly to the MIB objects and CLI commands previously discussed.

Specifically, %FR-5-DLCICHANGE indicates that the state of the Frame Relay PVC specified by the DLCI has changed.

Monitoring Frame-Relay Errored Frames

From RFC 1315-MIB, the following MIB variables can provide data on the number and types of Frame Relay-specific errors that the circuits are receiving:

• frErrType: Indicates the type of error that was last seen on this interface. This variable does not contain a printable octet string, but contains a numerical value that indicates the reason for the error. This would include the following: unknownError(1), receiveShort(2), receiveLong(3), illegalDLCI(4), unknownDLCI(5), dlcmiProtoErr(6), dlcmiUnknownIE(7), dlcmiSequenceErr(8), dlcmiUnknownRpt(9), noErrorSinceReset(10).

• frErrData: An octet string containing as much of the error packet as possible. At a minimum, it must contain the Q.922 address or as much as was delivered. It is desirable to include all information up to the PDU.

• frErrTime: The value of sysUpTime at which the error was detected.

These variables are valuable because they can assist you in identifying errors and help you in working with your Frame Relay service provider.

There are no corresponding CLI show commands to get the Frame Relay error types.