A frame relay DTE device can terminate a large number of virtual circuits on each physical interface. Any MIB hoping to be useful to frame relay network administrators must report on the physical interfaces, the associated logical connections, and the mapping between the two.
Tables in the frame relay MIB report on the LMI configuration, the status of each virtual circuit, and errors observed on each interface. The MIB is shown in Figure D-6.
RFC 2115 also defines the DLCI textual convention (data type) as an integer ranging from 0 to 8,388,607. In practice, most networks use DLCIs ranging from 0 to 1,023.
The first
table contains data about the Data Link Connection Management
Interface (DLCMI). For each frame relay physical interface, it
reports on LMI parameters. Objects in this table begin with
frameRelayDTE.frDlcmiTable.frDlcmiEntry
(32.1.1). Here is a list:
-
frDlcmiMaxSupportedVCs(DLCI) This object reports the maximum number of virtual circuits allowed on the interface. Network management stations may attempt to set the value of this object, but the frame relay network usually imposes a cap. If the attempted new value exceeds the old value, an error is returned.
Frame relay physical interfaces may
carry several logical connections. Each virtual circuit has an entry
in the circuit table. LMI connections are circuits on DLCI 0 and thus
have entries in the circuit table. All entries in this section begin
with the prefix
frameRelayDTE.frCircuitTable.frCircuitEntry
(32.2.1) and are as follows:
-
frCircuitSentFrames,frCircuitReceivedFrames,frCircuitSentOctets, andfrCircuitReceivedOctets(Counter32) These objects may be used to monitor the traffic on a per-virtual circuit basis. Monitoring traffic patterns may assist in selecting appropriate committed information rates from the service providers.
-
frCircuitReceivedDEsandfrCircuitSentDEs(Counter32) These objects monitor the number of frames sent and received on the circuit that have the discard eligible bit set. In conjunction with the previous objects, they can assist in evaluating whether or not the purchased set of services is appropriate.
Errors are placed into a table so
that network managers may analyze them. Each interface occupies one
row in the table, with the row describing the last error seen on the
interface. Errors are timestamped so they can be correlated to clock
time. Each error results in up to 1,600 bytes of the offending packet
that is being stored in the table as frErrData
for further analysis.
-
frErrType(RFC-defined enumerated type) Nine different specific errors are enumerated with a tenth “catch-all” code. The list of error types is shown in Table D-3.
Table D-3. frErrType enumeration
|
Error |
Code |
Description |
|---|---|---|
|
|
1 |
Error not described by other codes |
|
|
2 |
Similar to a runt frame on an Ethernet, a
|
|
|
3 |
Incoming frame exceeded maximum frame length for the interface |
|
|
4 |
Received frame did not match the address format configured on the interface |
|
|
5 |
Inbound frame received on inactive or disabled DLCI |
|
|
6 |
Unintelligible LMI frame |
|
|
7 |
LMI frame with an invalid information element |
|
|
8 |
Unexpected sequence number in LMI frame |
|
|
9 |
LMI frame with an invalid report type IE |
|
|
10 |
No errors since interface was initialized |
To prevent traps from overwhelming network capacity or the network
management station, the frame relay MIB includes the rate-limiting
mechanism,
frameRelayDTE.frameRelayTrapControl.frTrapMaxRate
(32.4.2), which specifies the number of milliseconds that must elapse
between sending traps. It ranges up to one hour; setting it to zero
disables rate control. By default, rate control is disabled.
Only one trap is defined. When the
status of a frame relay virtual circuit changes, a
frDLCIStatusChange trap may be sent to the
network management station. Virtual circuits may change status by
being switched between the inactive and active states or they may be
created and destroyed by other mechanisms.