|
|
So far, this chapter has discussed MIB objects for generic performance monitoring, which can be applied across any network. For a detailed analysis or for troubleshooting help, you should also consider technology-specific monitoring variables. A classic example is Spanning Tree Protocol (STP) in a LAN environment. A misconfigured spanning-tree environment can result in drastically reduced performance even though all basic monitoring parameters (such as CPU and link utilization) indicate a normal situation. In contrast to the preceding section, this section offers pointers on how to retrieve accounting and performance management information associated with technology-specific environments, such as Frame Relay, MPLS, QoS, IPv6, VLAN, and others.
Because most data networks are based on Frame Relay or MPLS, only these two transport technologies are discussed in detail. To focus on accounting and performance management, the MIB selection criteria were based on the question "Does the MIB contain relevant counters?" For example, at least four MPLS MIBs exist. The MPLS LSR MIB (RFC 3813) and MPLS Traffic Engineering MIB (RFC 3812) offer the most details.
Frame Relay is a mature technology. Adequate monitoring functionality is provided by the IETF Frame Relay MIB (RFC 2115), which is supplemented by the CISCO-FRAME-RELAY-MIB. To gain the most benefit from using these MIBs, an understanding of Frame Relay concepts is helpful.
Relevant objects from the FRAME-RELAY-DTE-MIB (RFC 2115) are as follows:
frCircuitReceivedFrames is the number of frames received over this Frame Relay virtual circuit since it was created.
frCircuitReceivedOctets is the number of octets received over this Frame Relay virtual circuit since it was created.
frCircuitSentFrames is the number of frames sent from this Frame Relay virtual circuit since it was created.
frCircuitSentOctets is the number of octets sent from this frame-relay virtual circuit since it was created.
frCircuitThroughput is the average number of 'Frame Relay Information Field' bits transferred per second across a user network interface in one direction.
frCircuitReceivedFECNs is the number of frames received from the network indicating forward congestion since the virtual circuit was created. The FECN mechanism, Forward Explicit Congestion Notification, is a means to notify network congestion to the destination station (receiver).
frCircuitReceivedBECNs is the number of frames received from the network indicating backward congestion since the virtual circuit was created. Backward Explicit Congestion Notification (BECN) is a means to notify the sending station about network congestion. Closely monitoring these two variables is advisable, because it helps identify link overload situations early on.
frCircuitCommittedBurst is a read/write variable that describes the maximum amount of data, in bits, that the network agrees to transfer under normal conditions.
Note
The variables frCircuitCommittedBurst and frCircuitThroughput are configurable operational parameters related to outgoing traffic. They cannot be used to monitor the incoming burst and throughput traffic rate. The CISCO-FRAME-RELAY-MIB provides additional monitoring parameters.
Relevant objects from the CISCO-FRAME-RELAY-MIB (read-only) are as follows:
cfrCircuitTable is a table of descriptive and statistics information that are generic to Frame Relay virtual circuits:
- cfrCircuitDEins is the number of packets received with the Discard Eligibility indicator (the DE bit) set. This indicates that the committed interface rate (the maximum transmission rate in bits per second per virtual circuit) for a specific virtual circuit is being exceeded.
- cfrCircuitDEouts is the number of packets transmitted with the DE bit set.
- cfrCircuitDropPktsOuts is the number of discarded packets.
cfrSvcTable is a table of Frame Relay switched virtual circuits (SVC) of specific statistics:
- cfrSvcThroughputIn is the circuit's incoming throughput. This is the ingress monitoring_variable that is related to the egress configuration parameter frCircuitThroughput from RFC 2115.
- cfrSvcCommitBurstIn is the circuit's incoming Committed Burst Rate. This is the ingress monitoring variable that is related to the egress configuration parameter frCircuitCommittedBurst from RFC 2115.
MPLS is a standardized and widely deployed technology today, for both service provider networks and large enterprises. Several MIBs are available, standardized by the IETF, with extensions for Operation, Administration, and Maintenance (OAM) capabilities. From an accounting and performance perspective, these MIBs help an operator increase the availability of the MPLS network, carry out traffic engineering and network redesign, build the core traffic matrix, and feed the data into a billing system.
The following sections detail the MIBs that are relevant to an MPLS environment.
This MIB can be used for configuration and monitoring purposes. Ingress and egress MPLS statistics are available for accounting and performance management. A global table for each interface gathers the total amount of traffic, and two tables per segment collect LSR-specific information. RFC 3813 contains 32- and 64-bit counters. Three tables are of main interest:
mplsInterfacePerfTable provides MPLS performance information on a per-interface basis. This table aggregates details across different MPLS labels on the physical interface:
- mplsInterfaceInPackets is the number of labeled packets received on this interface (ingress traffic).
- mplsInterfaceInDiscards is the number of inbound labeled packets that were discarded even though no errors were detected.
- mplsInterfaceOutPackets is the number of labeled packets transmitted on this interface (egress traffic).
- mplsInterfaceOutDiscards is the number of outbound labeled packets that were chosen to be discarded even though no errors were detected.
mplsInSegmentPerfTable contains statistical information for incoming MPLS segments to an LSR:
- mplsInSegmentPerfOctets, mplsInSegmentPerfHCOctets is the total number of octets received by this segment (32- and 64-bit).
- mplsInSegmentPerfPackets is the total number of packets received by this segment.
- mplsInSegmentPerfErrors is the number of erroneous packets received on this segment.
- mplsInSegmentPerfDiscards is the number of labeled packets received on this segment that were chosen to be discarded even though no errors have been detected.
mplsOutSegmentPerfTable is a similar table for outgoing segments from an LSR.
These MIB modules include managed object definitions for MPLS Traffic Engineering (TE). Traffic engineering is the process of identifying and selecting paths through the MPLS network. This enables load balancing on parallel links and choosing paths based on performance metrics such as delay, bandwidth, and utilization. The ultimate goal is to increase availability and reliability while optimizing utilization and traffic performance. TE is a complex task, and the details are outside the scope of this book. However, remarkable accounting and performance statistics can be polled from the MPLS-TE-MIB. The mplsTunnelTable is the configuration part, which creates and modifies MPLS tunnels between an originating LSR and a remote endpoint, the terminating LSR:
mplsTunnelPerfTable provides per-tunnel MPLS performance information:
- mplsTunnelPerfPackets, mplsTunnelPerfHCPackets is the number of packets forwarded by the tunnel (32- and 64-bit counters).
- mplsTunnelPerfErrors is the number of erroneous packets.
- mplsTunnelPerfBytes, mplsTunnelPerfHCBytes are the number of bytes forwarded by the tunnel (32- and 64-bit counters).
mplsTunnelTrapEnable is a read-write object that enables the generation of mplsTunnelUp and mplsTunnelDown traps, which are very important from a fault and performance standpoint.
Note
More details can be found in MPLS Network Management: MIBs, Tools, and Techniques by Thomas Nadeau (Morgan Kaufmann, 2002).
IP version 6 is a the IP protocol designed to become the successor of IP version 4, the Internet protocol that is predominantly deployed and extensively used throughout the world. In 1990, the IETF identified the potential issue of a lack of IPv4 addresses and started the IPNG working group. In 1995, RFC 1883 defined the IPv6 specification. RFC 2460 obsoletes RFC 1883 and is the present standard for IPv6. The first MIBs for IPv6 were standardized in 1998 as RFC 2465 and RFC 2466. At that time, the approach was to have separate tables for IPv4 and IPv6 addresses. However, this approach turned out to be unsuccessful, with only a limited number of implementations. Starting in 2001, the new approach was to extend the existing MIBs to manage IPv4 and IPv6 in combined tables. This applies particularly for RFC 2011 (SNMPv2 MIB for IP using SMIv2), RFC 2012 (SNMPv2 MIB for TCP using SMIv2), RFC 2013 (SNMPv2 MIB for UDP using SMIv2), and RFC 2096 (IP Forwarding Table MIB).
RFC 4293 is the IETF's proposed standard and defines the MIB for IP, unified for IPv4 and IPv6. RFC 4022 is the MIB counterpart for TCP, and RFC 4113 is the MIB for UDP. The new MIBs obsolete RFCs 2011, 2012, 2013, 2465, and 2466. Implementations at the obsolete MIB are no longer suggested by the IETF.
From an accounting and performance perspective, these MIBs offer basic interface counters, which are useful to distinguish between IPv4 and IPv6 traffic. From an operator's perspective, this is one of the most relevant monitoring tasks during the network's IPv4-to-IPv6 transition, because it answers the question "How much traffic has already been migrated to IPv6 and which percentage remains on IPv4?"
The following extract from RFC 4293 is a representative example of the other MIBs:
"The IP statistics tables (ipSystemStatsTable and ipIfStatsTable) contain objects to count the number of datagrams and octets that a given entity has processed. Unlike the previous attempt, this document uses a single table for multiple address types. Typically, the only two types of interest are IPv4 and IPv6; however, the table can support other types if necessary. The first table, ipSystemStatsTable, conveys system-wide information. (That is, the various counters are for all interfaces and not a specific set of interfaces.) Its index is formed from a single sub-id that represents the address type for which the statistics were counted. The second table, ipIfStatsTable, conveys interface-specific information. Its index is formed from two sub-ids. The first represents the address type (IPv4 and IPv6), and the interface within that address type is represented by the second sub-id."
Cisco never implemented the deprecated IPv6 MIBs (RFC 2465 and RFC 2466). Instead, the early drafts of the updated MIBs are partly supported; however, the interface statistics to differentiate IPv4 and IPv6 traffic at the interface level are not implemented:
CISCO-IETF-IP-MIB— This MIB is based on draft-ietf-ipngwg-rfc2011-update-00.txt.
CISCO-IETF-IP-FORWARD-MIB— This MIB was extracted from draft-ietf-ipngwg-rfc2096-update-00.txt.
IPv6-MIB— This MIB was extracted from RFC 2465.
You can find the latest status updates for Cisco IPv6 MIB implementation at http://www.cisco.com/go/ipv6.
SNMP can be configured over IPv6 transport so that an IPv6 host can perform SNMP queries and receive SNMP notifications from a device running Cisco IOS with IPv6 enabled. The following MIBs can be configured with SNMP over IPv6:
CISCO-DATA-COLLECTION-MIB
CISCO-CONFIG-COPY-MIB
CISCO-FLASH-MIB
ENTITY-MIB
NOTIFICATION-LOG-MIB
SNMP-TARGET-MIB
Note
CISCO-CONFIG-COPY-MIB and CISCO-FLASH-MIB support IPv6 addressing if FTP, TFTP, or Remote Copy Protocol (RCP) is used.
SNMP over IPv6 transport is initially supported in IOS 12.0(27)S; more features are added to IOS 12.0(30)S and 12.3(14)T.
NetFlow also supports the collection of IPv6-related flows since IOS 12.3(7)T; however, the flow export is still based on IPv4.
In general, network conversations can be distinguished as one-to-one traffic (unicast), one-to-many conversations (multicast), or one-to-all transmissions (broadcast). This separation is relevant for the network design as well as accounting and performance monitoring, because it is relevant to have accounting and performance statistics per unicast, multicast, and broadcast traffic. Historically, monitoring of multicast traffic was an issue, because there was no separation between multicast and broadcast traffic. The ifTable from RFC 1213 gathers only unicast (ifInUcastPkts) and nonunicast (ifInNUcastPkts) traffic.
Today, at least three different measurement approaches exist for monitoring multicast traffic: the interface group MIB (RFC 2863), the RMON-MIB (RFC 1757), and the Multicast Routing MIB for IPv4 (RFC 2932):
The interface group MIB IF-MIB distinguishes between unicast, multicast, and broadcast packets and adds 64-bit high-capacity counters:
ifHCInUcastPkts, ifHCOutUcastPkts
ifHCInMulticastPkts, ifHCOutMulticastPkts
ifHCInBroadcastPkts, ifHCOutBroadcastPkts
The RMON-MIB also separates multicast and broadcast packets (etherStatsBroadcastPkts, etherStatsMulticastPkts). Implementations of RFC 1757 can gather multicast packets per interface; however, no statement about the packets belonging to a specific multicast group can be made. This might be sufficient from a performance perspective; however, a billing application would require identifying the multicast group details.
This MIB assigns packets to the related multicast groups (ipMRouteGroup). It gathers multicast routing status information plus traffic statistics. A table (ipMRouterInterfaceTable) offers per-interface octet counters for ingress and egress multicast traffic. The MIB contains high-capacity (64-bit) counters and has three performance and accounting MIB tables:
The IP Multicast Route Table holds multicast routing information for IP datagrams sent by particular sources to the IP multicast groups known to a router.
The IP Multicast Routing Next Hop Table includes information on the next hops for the routing IP multicast datagrams. The list contains entries of next hops on outgoing interfaces for sources sending to a multicast group address.
The IP Multicast Routing Interface Table has multicast routing information specific to interfaces.
No specific VLAN performance MIB exists, so you need to leverage the existing MIBs (such as MIB-II RFC 1213, interfaces group MIB RFC 2863, TCP-MIB RFC 2012) to collect performance details in a VLAN environment. For example, STP can become an issue if it is configured incorrectly or if link-up/link-down causes time-consuming STP operations. Therefore, it is suggested that you poll MIB objects from the CISCO-STACK-MIB and the BRIDGE-MIB (RFC 1493). For example, if a 10-Mbps link and a 1-Gbps link are parallel connections between two switches, under normal circumstances the 1-Gbps link should be in forwarding mode, and the 10-Mbps link should be in blocking mode. From a monitoring perspective, monitor the LAN. For each VLAN, identify which ports of a network element are in forwarding or blocking spanning tree mode. Afterwards, ensure that backup links with less capacity (10 Mbps in the preceding example) are not used during normal operations. The cvbStpForwardingMap object from the CISCO-VLAN-BRIDGING-MIB returns this information (1 = forwarding; 0 = disabled, blocking, listening, learning, broken, or nonexistent). Network management tools such as CiscoWorks can draw a nice map that illustrates the spanning tree in the LAN.
Retrieving the content of the BRIDGE-MIB returns the MAC addresses associated with all VLANs, because there is no notion of the VLANS indexing in the MIB specification. However, a special feature called community string indexing lets you retrieve a particular instance of the MIB. In these cases, community string indexing is provided to access each instance of the MIB. The syntax is community string@instance number. For example, the Catalyst switch includes one instance of the BRIDGE-MIB for each VLAN. If the read-only community string is public and the read-write community string is private, you could use public@25 to read the BRIDGE-MIB for VLAN 25 and use private@33 to read and write the BRIDGE-MIB for VLAN 33.
Note
Community string indexing does not affect access to MIBs that have only one instance. Thus, public@25 can be used to access RFC1213-MIB at the same time that the BRIDGE-MIB for VLAN 25 is accessed.
Community string indexing was created before the introduction of SNMPv3. SNMPv3 offers the notion of context instead of the community string index. The VLAN number is replaced by the VLAN name (vlan-25, vlan-33); the names are displayed with the show snmp context CLI command.
The following checklist helps you identify configuration errors in a VLAN environment:
Check for link configuration mismatch (full- or half-duplex, different interface speed, trunking or nontrunking).
Check if the uplink fast parameter is enabled on connection ports between switches.
Check if the port fast parameter is enabled on ports toward end devices.
Check if Cisco Discovery Protocol (CDP) is enabled only between Cisco devices and disabled toward end-user ports (this is a potential security issue) and is also disabled on WAN interfaces (for performance and security reasons, because knowing device details can be attractive for hackers). CDP does not supply accounting and performance details; however, it offers relevant indirect information about network connectivity, which relates to performance monitoring.
More details on VLAN monitoring can be found in Chapter 5.
Two different approaches for traffic management and control are briefly described in this section: rate limiting and service classes. Even though both methods use different technologies, related parts from an accounting and performance perspective are the traffic counters. Statistics such as the number of forwarded and dropped packets are collected, optionally per class of service.
Cisco weighted rate limit, also known as Committed Access Rate (CAR), is a method for traffic control. It lets you regulate traffic at the network element level by configuring sets of rate limits to packets flowing into and out of an interface. Each rate limit has a configurable action associated with specific traffic conditions. The CISCO-CAR-MIB provides weighted rate-limit packet-filtering information. Rate-limit actions are defined per interface and traffic direction (ingress or egress) separately. Whereas the MIB also provides a set of read-write objects for configuration purposes, the described MIB objects gather traffic statistics related to accounting and performance management. The CISCO-CAR-MIB has 32-bit counters and 64-bit (high-capacity [HC]) counters.
Relevant MIB objects (read-only) are as follows:
ccarStatHCSwitchedPkts, ccarStatHCSwitchedBytes are the counters of packets or bytes permitted by the rate limit.
ccarStatHCFilteredPkts, ccarStatHCFilteredBytes are the counters of packets or bytes that exceeded the rate limit.
ccarStatCurBurst is the current received burst size.
These objects are specifically defined in a table (ccarStatTable) with separate entries (ccarStatEntry) for each interface (ifIndex) and for each direction (ingress/egress).
This MIB supplies QoS information for Cisco network elements that support the modular quality of service command-line interface (MQC). It provides configuration capabilities as well as monitoring statistics, including summary counts and rates by traffic class before and after the enforcement of QoS policies. In addition, detailed feature-specific statistics are available for select PolicyMap features. Policy actions are defined per interface and traffic direction (ingress or egress). The CISCO-CLASS-BASED-QOS-MIB supports 32-bit counters as well as 64-bit (HC) counters. From an accounting and performance management perspective, the following tables are significant. This MIB is structurally very similar to the IETF DIFFSERV-MIB (RFC 3289).
The following relevant MIB tables for QoS contain statistical information only; no configuration information is associated with them. They are indexed by the instance indexes, such as cbQosPolicyIndex and cbQosObjectsIndex:
cbQosClassMapStats— Each entry in this table describes statistical information about class maps, such as pre/post-policy packet/byte counts, bit rates, drop packet/bytes, and no-buffer drops.
cbQosMatchStmtStats— Each entry in this table describes statistical information about match statement-specific information, such as prepolicy packet/byte counters and bit rates.
cbQosPoliceStats— Each entry in this table describes statistical information about police actions, such as conformed or exceeded packet/byte counters and bit rates.
cbQosQueueingStats— Each entry in this table describes statistical information about queuing actions, such as various queue depth and discard packet/byte counters.
cbQosTSStats— Each entry in this table describes statistical information about traffic-shaping actions, such as various delay and drop packet/byte counters, state of feature, and queue size.
cbQosREDClassStats— Each entry in this table describes statistical information about per-precedence Weighted Random Early Detection (WRED) actions, such as random packet/byte counters and tail drop packet/byte counters.
cbQosPoliceActionCfg— Required objects to display class-based QoS objects' configuration information.
This MIB is quite comprehensive and complex; a good understanding of the QoS mechanisms is a suggested prerequisite before you get started. Reading this MIB is recommended, because it is well structured and presents additional details and examples.
Note
Cisco DQOS Exam Certification Guide by Wendell Odom and Michael Cavanaugh (Cisco Press, 2003) is an excellent resource for information on QoS. Although this book is geared toward the Cisco DQOS exam #9E0-601 and QOS exam #642-641, it is considered the definitive Cisco Press book on QoS, going far beyond what is covered on the specific QOS and DQOS exams.
Telephony is a term that covers a wide range of topics, including legacy telephony networks with dedicated infrastructure over dial-in connections, ISDN links, and legacy voice encapsulated in IP-to-IP telephony. This section covers MIB-related telephony details. Chapter 17, "Billing Scenarios," discusses how to gather telephony statistics from multiple sources.
Performance and accounting statistics can be retrieved from the various Cisco voice gateways that are implemented in Cisco IOS. The following terminology provides guidance for understanding accounting and performance collection in a VoIP environment. The ITU-T H.323 standard specifies four VoIP components:
Gateway— An H.323 gateway is an endpoint on a LAN that provides real-time, two-way communication between H.323 terminals on the LAN and other International Telecommunication Union Telecommunication Standardization Sector (ITU-T) terminals in the WAN. Gateways are the translation mechanism for call signaling, data transmission, and audio and video transcoding. An H.323 gateway can also communicate with another H.323 gateway. Gateways allow H.323 terminals to communicate with non-H.323 terminals by converting protocols. The gateway is the point at which a circuit-switched call is encoded and repackaged into IP packets. Because gateways function as H.323 endpoints, they provide admission control, address lookup and translation, and accounting services.
Gatekeeper— A gatekeeper is an H.323 entity that provides services such as address translation and network access control for H.323 terminals, gateways, and Multipoint Control Units (MCU). Gatekeepers are used to group H.323 gateways into logical zones and perform call routing between them. They are also responsible for edge routing decisions between the Public Switched Telephone Network (PSTN) and the H.323 network. In addition, they can provide other services, such as bandwidth management, accounting, and dial plans, that can be centralized to provide scalability. Gatekeepers are logically separated from H.323 endpoints such as terminals and gateways. They are optional in an H.323 network, but if a gatekeeper is present, endpoints have to use the services provided. In an environment in which both gatekeepers and gateways are used, only gateways are configured to send VoIP data. Cisco offers a VoIP gatekeeper called the Multimedia Conference Manager, which is an H.323-compliant program implemented as part of Cisco IOS Software. It is supported by the Cisco 2500, 2600, 3600, 3700, 7200, and MC3810 Multiservice Access Concentrators.
Multipoint Control Unit (MCU)— An MCU is an endpoint on the LAN that enables three or more terminals and gateways to participate in a multipoint conference. It controls and mixes video, audio, and data from terminals to create a robust videoconference. An MCU can also connect two terminals in a point-to-point conference that can later develop into a multipoint conference.
Terminal— This is a LAN client endpoint that provides real-time two-way communication. According to H.323, terminals must support voice communications, whereas video and data support is optional.
Table 4-5 compares the different relevant MIBs and assigns them to the related voice technology.
| Dial | ISDN | VoIP | |
|---|---|---|---|
| CISCO-CALL-HISTORY-MIB |  | ||
| DIAL-CONTROL-MIB (RFC 2128) | | | |
| CISCO-DIAL-CONTROL-MIB | | | |
| CISCO-VOICE-DIAL-CONTROL-MIB | | | |
| CISCO-VOICE-COMMON-DIAL-CONTROL-MIB | | | |
| CISCO-CAS-IF-MIB | | ||
| CISCO-CALL-APPLICATION-MIB | | ||
| CISCO-DSP-MGMT-MIB | | ||
| CISCO-VOICE-ANALOG-IF-MIB | | ||
| CISCO-VOICE-IF-MIB | | | |
| CISCO-GATEKEEPER-MIB | | ||
| CISCO-POP-MGMT-MIB | | |
The following MIBs supply general information on the gateways or gatekeepers:
Cisco Channel Associated Signal Interface MIB (CISCO-CAS-IF-MIB)— Configures and monitors the generic Channel Associated Signaling (CAS) or DS0 clear-channel interfaces in the router.
CISCO-VOICE-DIAL-CONTROL-MIB and the CISCO-DIAL-CONTROL-MIB— Enhances the IETF Dial Control MIB (RFC 2128) by providing configuration and monitoring of voice telephony peers on both a circuit-switched telephony network and an IP data network.
CISCO-VOICE-COMMON-DIAL-CONTROL-MIB— Contains voice-related parameters that are common across more than one network encapsulation—voice over IP (VoIP), voice over Asynchronous Transfer Mode (VoATM), and voice over Frame Relay (VoFR).
CISCO-CALL-APPLICATION-MIB— Allows configuration and monitoring of call applications on a network device. A call application is a software module that processes calls, such as data, voice, video, or fax calls.
Digital Signal Processing MIB (CISCO-DSP-MGMT-MIB)— Monitors the DSP resource and status.
CISCO-VOICE-ANALOG-IF-MIB— Supports multiple different voice interfaces in a gateway, such as the analog interface general group, the E&M (receive and transmit) interface group, the Foreign Exchange Office (FXO) interface group, and the Foreign Exchange Station (FXS) interface group.
CISCO-VOICE-IF-MIB— Manages the common voice-related parameters for both voice analog and ISDN interfaces.
CISCO-GATEKEEPER-MIB— Supports the functions of an H.323 gatekeeper. The gatekeeper is a function of the H.323 Packet-Based Multimedia Communications Systems, a standard of ITU-T. The gatekeeper provides address translation and controls access to the network for H.323 terminals.
The following MIBs grant reporting explicitly for performance and accounting details, for both completed calls and calls in progress:
Dial Control Management MIB (RFC 2128) provides configuration details as well as statistics about active calls and call history in a circuit-switched telephony network.
CISCO-VOICE-DIAL-CONTROL-MIB manages voice telephony peers on both a circuit-switched telephony network and an IP data network.
CISCO-CALL-HISTORY-MIB reports accounting statistics on completed calls. Note that this MIB monitors only a dial environment!
Point of Presence (PoP) Management MIB (CISCO-POP-MGMT-MIB) reports on DSX0 and DSX1 facilities management and call summaries for analog and ISDN.
The following sections offer more details on the CISCO-CALL-HISTORY-MIB and CISCO-VOICE-DIAL-CONTROL-MIB, because these are the two main MIBs for accounting and performance management.
RFC 2128 provides statistics for circuit-switched telephony networks (ISDN) and dial-in networks. For accounting purposes, these two groups should be monitored:
The callActive group is used to store active call information.
The callHistory group is used to store call history information. The calls could be circuit-switched, or they could be virtual circuits. Call history is stored for successful and unsuccessful or rejected calls. An entry is created when a call is cleared.
The CISCO-VOICE-DIAL-CONTROL-MIB and CISCO-VOICE-COMMON-DIAL-CONTROL-MIB are extensions to RFC 2128.
This MIB consists of four groups and a trap definition:
cvGatewayCallActive— This group contains two tables—one for the telephony interfaces and one for the VoIP interfaces:
cvGatewayCallHistory— This group also has one table for the telephony interface and one for the VoIP interface:
cvPeer— The objects in this group are responsible for voice-related peer configuration, which controls the dial string and the interface or session target for the call establishment to a peer on the telephony network or on the IP backbone.
cvGeneralConfiguration— This group contains one object (cvGeneralPoorQoVNotificationEnable), which indicates whether a trap (cvdcPoorQoVNotification) should be generated for poor-quality-of-voice calls.
This MIB also extends RFC 2128 by offering voice-related objects that are common across more than one network encapsulation (such as VoIP, VoATM, and VoFR). These objects are structured into two MIB groups:
cvCommonDcCallActive— This group has one table (cvCommonDcCallActiveTable) with an instance of cvCommonDcCallActiveEntry for each call in progress. Information such as the global call identifier (cvCommonDcCallActiveConnectionId) and call-specific details are stored.
cvCommonDcCallHistory— This group also has one table (cvCommonDcCallHistoryTable) that stores the details from the active table (cvCommonDcCallActiveTable) after call completion.
The Call History MIB includes ciscoCallHistoryTable, which contains information about specific calls. Here is a selection of relevant table elements:
ciscoCallHistoryEntry— Information on a single connection. The following MIB objects are instantiated for each call. They are indexed by ciscoCallHistoryStartTime and ciscoCallHistoryIndex:
ciscoCallHistoryStartTime is the value of sysUpTime when this call history entry was created. This is useful for an NMS to retrieve all calls after a specific time.
ciscoCallHistoryCallingNumber is the calling number for this call. This variable is instantiated if this is an incoming call.
ciscoCallHistoryCalledNumber is the number this call is connected to. This variable is instantiated if this is an outgoing call.
ciscoCallHistoryCallConnectionTime is the value of sysUpTime when the call was connected.
ciscoCallHistoryCallDisconnectTime is the value of sysUpTime when the call was last disconnected.
ciscoCallHistoryConnectTimeOfDay is the time of day at the time of call connect.
ciscoCallHistoryDisonnectTimeOfDay is the time of day when the call disconnected.
ciscoCallHistoryTransmitPackets is the number of packets transmitted when this call was up.
ciscoCallHistoryTransmitBytes is the number of bytes transmitted when this call was up.
ciscoCallHistoryReceiveBytes is the number of packets received when this call was up.
ciscoCallHistoryReceivePackets is the number of bytes received when this call was up.
ciscoCallHistoryCurrency, ciscoCallHistoryCurrencyAmount, ciscoCallHistoryMultiplier are call billing details.
The MIBs just described were created for legacy telephony services. Currently the IT industry is strongly moving toward Session Initiation Protocol (SIP)-based services, such as IP Multimedia Subsystem (IMS). SIP is an application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, such as Internet telephone calls and multimedia conferences. SIP is defined in RFC 3261. Whereas the earlier voice architectures were built on central voice control, SIP is designed as a peer-to-peer protocol. The MIB for SIP is in a late draft status (draft-ietf-sip-mib-12.txt), close to completion, but it has not been implemented yet.
The SIP MIB describes a set of managed objects that are used to manage SIP entities, which include User Agents, Proxy, Redirect, and Registrar servers. The goal is to provide a basic set of management functions for SIP devices. (Managing SIP applications and services is out of the scope of this discussion.) These include basic device configuration operations, which also means that the MIB has both read-only and read-write objects. Although this book is not a SIP reference, the major SIP entities are as follows:
User Agent Client (UAC) is a logical entity that creates new requests, such as a phone call. The UAC role lasts for only the duration of that transaction, which means that a SIP-based application that initiates a request acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a User Agent Server (UAS) for the processing of that transaction.
User Agent Server (UAS) is the counterpart to the UAC because it responds to SIP requests. The request can be accepted, rejected, or redirected. The UAS role lasts for only the duration of a transaction. From a voice application perspective, both the UAC and UAS should be implemented for calls to be initiated and received.
Proxy server is an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing by ensuring that a request is sent to an entity that is "closer" to the targeted user. Proxies are also useful for enforcing policy, because they can rewrite specific parts of a request message before forwarding it.
Proxy servers can have three different flavors: stateless, transaction stateful, or call stateful:
- A stateless proxy does not maintain the client or server transaction state machines. It forwards every request it receives downstream and every response it receives upstream.
- A transaction stateful proxy, also called a stateful proxy, maintains the client and server transaction state during the processing of a request.
- A call stateful proxy retains the state for a dialog from the initiating message to the terminating request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.
Redirect server is a user agent server that accepts requests from clients and directs the client to contact an alternative set of Uniform Resource Identifiers (URI).
Registrar is a server that accepts register requests and places the request information into the location service for the domain it handles.
Figure 4-2 illustrates the different SIP components.
Four modules are specified in the SIP MIB:
SIP-TC-MIB defines the textual conventions used throughout MIB modules.
SIP-COMMON-MIB defines management objects common to all SIP entities, as just described. Different groups and tables exist for configuration, monitoring, and notifications.
The sipCommonCfgBase object includes the SIP protocol version, the type of SIP entity (UA, Proxy, Redirect, or Registrar server), the operational and administrative status, the SIP organization name, the maximum number of SIP transactions an entity can manage, etc. The sipCommonCfgTimer object group defines timer configuration objects applicable to SIP user agent and stateful SIP proxy entities.
Various statistics tables are defined for monitoring purposes, such as the summary of all requests and responses (sipCommonSummaryStats), the number of in and out SIP responses on a per-method basis (sipCommonStatusCode), a gauge reflecting the number of transactions currently awaiting definitive responses (sipCommonStatsTrans), a counter for retransmissions (sipCommonStatsRetry), and other statistics (sipCommonOtherStats).
SNMP notification objects are defined by the sipCommonNotifObjects object group. The monitoring indicator sipCommonStatusCodeNotif shows that a specific status code was sent or received. Threshold notifications can be configured. sipCommonStatusCodeThreshExceededNotif indicates that a threshold was breached.
Status-related notifications are sipCommonServiceColdStart, sipCommonServiceWarmStart, and sipCommonCfgServiceLastChange.
SIP-SERVER-MIB contains objects specific to Proxy, Redirect, and Registrar servers.
The server (sipServerCfg) and proxy (sipServerProxyCfg) configuration object groups define basic server configurations, including the SIP server host address. For Proxy servers, the mode of operation (stateless, stateful, call stateful) as well as the proxy authentication methods and realm, can be modified.
SIP Registrar servers are configured via the sipServerRegCfg object group. Statistics can be obtained from the sipServerRegStats object group.
SIP-UA-MIB includes objects specific to user agents (UA), which can act as both a UAC and a UAS.
The sipUACfgServer object group specifies SIP server configuration objects applicable to SIP user agents, including the IP address of the SIP server to register, proxy, or redirect calls.
|
|