Remote Packet Capture Using RMON

Mustapa Wangsaatmadja
Australian Telecommunications Research Institute,
Curtin University of Technology
Email: mustapa@atri.curtin.edu.au

Windiaprana Ramelan
Australian Telecommunications Research Institute,
Curtin University of Technology
Email: windia@atri.curtin.edu.au

Bradley Williamson
Department of Computer Science,
Curtin University of Technology
Email: brad@cs.curtin.edu.au

Craig Farrell
Department of Computer Science,
Curtin University of Technology
Email: craig@cs.curtin.edu.au

Abstract

This project studied the effectiveness of the Remote Monitoring Management Information Base (RMON MIB) at performing remote packet capture. A remote monitoring (RMON) application was constructed which sent SNMP requests to RMON probes to capture, retrieve and store packets in a file. The captured packets were converted into a dump format (Sniffer format) which is meaningful to the packet analyser Packetman: The Next Generation (TNG). Packetman TNG was used to decode and display the captured packets for further analysis. Using this technique, a number of limitations with the use of the RMON packet capture group were identified.

1 Introduction

Maintaining communication infrastructures to maximise efficiency and productivity requires effective network management techniques (Leinwand and Fang 1993). Research into network management protocols has produced two standards:

Open Systems Interconnection (OSI) system management. Defined by the International Telecommunication Union - Telecommunications Sector (ITU-T), the OSI system management standards define a set of general purpose network management applications, services and protocols (CCITT 1991, 1992). Furthermore, OSI defines a database structure specification and a set of data objects (Rose 1990).
Simple Network Management Protocol (SNMP): Like the OSI model, the SNMP (Case et al. 1990) family also refers to a set of standards for network management. However, unlike the OSI model, SNMP is based around a TCP/IP-based network (Rose 1994) (Case et al. 1990).

The Internet Activities Board (IAB) eventually standardised two versions of the network management protocols. SNMP was standardised to accommodate the short-term needs of the Internet community. Common Management Information Protocol over TCP/IP (CMOT) (Warrier and Besaw 1989), which is based upon CMIP, was standardised to meet the long-term needs of the Internet community. Based on the OSI management framework, CMOT provides a 'smooth' transition from SNMP to CMIP. The SNMP family has become a de facto standard due to market domination.

1.2 Simple Network Management Protocol (SNMP)

The Internet-standard Network Management Framework consists of three components:

The Structure and Identification of Management Information (SMI).
Defined in Request for Comment (RFC) 1155, the SMI describes how managed objects contained in the MIB are defined, constructed and encoded for the purpose of management (Stallings 1993). The encoding rules are a subset of Abstract Syntax Notation One (ASN.1) (CCITT 1994).
The Management Information Base (MIB).
Defined in RFC 1156 (McCloghrie and Rose 1990), the MIB describes the managed objects used in the management of TCP/IP-based internets. An enhanced version of the MIB (MIB-II) (McCloghrie and Rose 1991), defined in RFC 1213, refines the MIB based on implementation experience and new operational requirements.
The Simple Network Management Protocol (SNMP).
Defined in RFC 1157 (Case et al. 1990), SNMP is used to manipulate and transfer managed objects between end points (Stallings 1993).

In relation to the architectural model for the Internet Suite of protocols, SNMP is in the application layer and uses User Datagram Protocol (UDP) (Postel 1980) for the underlying transport substrate (Rose 1994).

SNMP version 1 is made up of four operations (PDUs are described in Figure 1) allowing the network management station to manipulate managed objects on an agent. These are:

Get: retrieves an MIB variable from the agent.
Set: sets a value on an MIB variable on the agent.
Trap: notifies the network management station of an event that has occured.
Get Next: retrieves the next MIB variable.

Figure 1. SNMP PDU definition

2 Remote Monitoring Management Information Base (RMON MIB)

The Remote Monitoring Management Information Base (RMON MIB) (Waldbusser 1995), defined in RFC 1757 is an extension to the SNMP framework which provides a mechanism for proactive remote monitoring at the data link layer. Remote monitoring refers to a probe which autonomously collects network segment statistics. Data captured by RMON probes is retrieved using SNMP. The data collected allows the Network Manager to analyse activity in a sub-network.

The RMON MIB is incorporated into MIB-II. Identified as subgroup 16, the RMON MIB itself is further divided into nine functional groups, shown in Figure 2. One of these groups is packet capture which will be discussed in more detail. Using SNMP, network management applications can remotely configure, activate and deactivate probe entities.

Figure 2. RMON MIB

2.1 Packetman: The next generation

Packetman (Benko 1992) (Barron 1993) (Williamson 1995) is a protocol analyser that was developed as part of the Netman (Schulze 1993) project at Curtin's School of Computing. Packetman: The Next Generation (TNG) (Tantiprasut 1995) is an extension of the original Packetman capable of capturing and decoding PDUs based on an ASN.1 specification.

2.2 Remote packet capture using RMON

The RMON MIB provides the filter and capture groups (identified by subtrees 7 and 8 of the RMON MIB) which allow packets to be captured remotely.

To capture packets, RMON provides a packet capture group which is dependent upon the implementation of the filter group (Stallings 1993). Filter and capture groups have associated control tables containing variables, most of which can be modified by network management applications using a network management transport protocol such as SNMP.

The filter group provides a means by which a management station can instruct a probe to observe selected packets on a particular interface. By using either the data filter or the status filter, a selection of packets can be stored in a capture buffer.

In order to capture selected packets, the packet capture probe must be initialised. The steps that are required are described below.

2.2.1 Initialise data channel

The PDUs will be captured in promiscuous mode from a sepcified network interface and filtered by the data channel. The PDUs that pass the filter test are then forwarded to the capturebuffertable.

To set up the data channel, a vacant index must first be determined (Stallings 1994) then:

Set the channelstatus attribute to createrequest (2) then to undercreation (3). This will allow the network management application to modify the configuration before the probe commences execution.
Set the channelowner and channeldescription attributes to a (defined) arbitrary string. The purpose of this field is for identification by other network management stations (Stallings 1993).
Set channelindex to an integer which represents the interface used for promiscuous capture mode.
Set channelaccepttype to acceptmatched (1); this will accept packets if they pass the associated filters, or set to acceptfailed (2) (Stallings 1993).
Set channeldatacontrol to (1), thus allowing packets to flow through the channel (Stallings 1993).
Set channelstatus to valid (4); this will activate the probe and therefore packet capture will commence.

2.2.2 Initialise capture buffer

The packet capture group can be used to set up a buffering scheme for capturing packets from one of the channels in the filter group. It consists of two tables: bufferControlTable, which specifies the details of the buffering function, and captureBufferTable, which buffers the packets passing through the channel.

Each row in the bufferControlTable defines one buffer that is used to capture and store packets from one channel. To set up the capture buffer, the following steps are needed (Waldbusser 1995; Stallings 1994):

Set the bufferstatus attribute to createrequest (2) then to undercreation (3). This will allow the network management application to modify the configuration before the capture commences.
Set the ownerstring to an arbitrarily defined string.
Set the channelindex attribute to the index number of the packet channel used.
Set bufferControlFullAction to lockwhenfull (1), the buffer will accept no more packets after it becomes full. If the value is wrapWhenFull (2), the buffer will acts as a circular buffer after it becomes full, deleting enough of the oldest packets to make room for new ones as the arrive (Stallings 1993).
Set the bufferControlCaptureSliceSize to an integer value which indicates the maximum number of octets that are saved from each PDU.
Set the buffercontroldownloadslicesize attribute to an integer value which indicates the number of octets to return when querying the variable. This is to take into account the minimum-maximum size (defined in section 'Captured PDU size') of the network management transport protocol. For example, the minimum-maximum size of SNMP PDU is 484 bytes. Taking into account the size of Internet Protocol (IP) header and the SNMP header, the maximum size is significantly reduced.
Set the buffercontroldownloadoffset attribute to the offset of the first octet of the PDU. As mentioned previously, SNMP PDUs have an effective size of 484 bytes. Therefore, to capture and transport an Ethernet PDU which is equal to the MTU, multiple buffers need to be defined which grab the PDUs from the same channel. The only difference between each buffer is the value of this field.
Set the bufferControlMaxOctetsRequested attribute to the maximum number of octets the application requires to capture. The value set depends on the RAM available in the probe. If all the available RAM is required then this field is set to -1.
Set the bufferstatus attribute to valid (4). When this variable is set, packet buffering will commence. When the buffer is full and bufferfullaction is set to lockwhenfull, then the probe will remain IDLE.

If multiple buffers are to be set up using one channel, then the bufferstatus variable must be set when all the buffers have been configured. Setting this variable after each configuration will cause the packets captured to be misaligned. This problem will always exist due to the finite time difference between initialisation; however, this sequence will reduce the problem.

2.2.3 Download captured packets

Transferring PDUs between the RMON probe and the network management application depends upon the transport protocol. To transfer PDUs using SNMP, a getnext request is issued which, in effect, commences an 'MIB walk' which traverses the tree.

In this case, the captured packets that will be retrieved are located at rmon(16) capture(8).captureBufferTable(2).captureBufferEntry(1).captureBufferPacketData(4) on the MIB tree. We will retrieve the value on that entry, and convert them into sniffer format which is a meaningful representation to Packetman TNG.

2.2.4 Deactivate probe

The RMON probe has to be deactivated to avoid overloading the monitor. If Internet is moderately busy, this could put quite a stress on one or more of the affected sub-networks. In addition, the monitor may not have the speed to capture all of these packets producing summary information and monitoring alarms. If this is not done, the monitor may drop packets or fail to perform other duties adequately.

2.2.5 Decoding and displaying captured packets using Packetman TNG

The captured packets are retrieved using SNMP and stored in a file. The file is converted into a dump in a format which is meaningful to Packetman TNG (Sniffer format). Packetman TNG was then used to decode and display the dump packets for further analysis.

Figure 3. Experiment Results.

3 Discussion

Remote packet capture using RMON gives the network manager the ability to proactively monitor the network. The network manager can remotely configure RMON probes which are then used to capture traffic. The collected packets are retrieved using SNMP messages and then saved to a file which can then be read by Packetman TNG.

The RMON MIB is designed to allow offline operation, enabling the network manager to retrieve the collected data at any time. This eliminates the need for routine polling and, as a result, network traffic and, consequently, the misdiagnosis of network faults is reduced.

Theoretically, the RMON MIB capture group provides an efficient solution to remote packet capturing. However, our experiments showed that the following problems exist:

dropped packets
captured PDU size
coordination of multiple buffers
limits on the number of captured PDUs

3.1 Dropped packets

One of the problems in performing packet capture is PDU loss. very often, the network manager does not receive a response from the probe or the response is dropped before the transfer is completed. This occurs as a combination of having a busy RMON probe and using an unreliable transport protocol (for example, SNMP/UDP). When the network is heavily loaded, the cabling hub running the RMON probe may decide that it is too busy processing packets to relinquish processing resources to the RMON probe. Thus, the RMON probe appears to simply ignore (or drop) the SNMP requests for packet capture. Paradoxically, when the network is heavily loaded, this is often the time when packet capture (and network management) is most required.

In our experiments, we attempted to perform remote packet capture using RMON many times, often without any response from the probe. This was a serious problem that must be taken into consideration by the network manager before using RMON to perform remote packet capture.

3.2 Captured PDU size

Another problem that exists in practice is the size of the PDU. If the network management application conforms to the SNMP (Case 1990) standard, captured PDUs with a length greater than 484 bytes may need to be fragmented to accommodate SNMP's minimum-maximum PDU size of 484 bytes.

The minimum-maximum size is a limit on the smallest possible maximum size for an SNMP PDU. An implementation of SNMP may have a maximum SNMP PDU size larger than 484 bytes, but its minimum size must be at least 484 bytes. In practice, most SNMP implementations simply implement this as the maximum size; they are still standards compliant.

In order to remain compatible with any SNMP implementation, we decided to fragment all PDUs into this size. Thus, no matter what size maximum PDU the underlying SNMP substrate used, it would always be able to carry the 484 byte captured PDU fragments.

3.3 Coordination of multiple buffers

The decision to fragment all captured PDUs into 484 byte fragments required the use of multiple buffers. These buffers exist as individual RMON probe entities. Each buffer has a different buffercontroldownloadoffset value set. It is sometimes difficult to set up these buffers simultaneously (using one SNMP set) to start the capture of packets. In the case of an error, setting these buffers up simultaneously will only return a single SNMP error packet which later must be resolved before capturing packets.

If multiple buffers are to be set up using one channel, then the bufferstatus variable will be set when all the buffers have been configured. Even though the standard says that if there are multiple variables in a varbind list they are to be set simultaneously, it was found that the variables were actually set sequentially. Unfortunately, there was a finite time difference between the setting of each variable which was enough for PDUs to become misaligned. This problem is exaggerated when the RMON probe is busy. In this case, there is often a large delay between initialisation of the first probe, the second probe and so on. The delay can be so large that by the time the second and subsequent probes start capturing packets, the previous probes have already finished capturing. Therefore we cannot reassemble the packets from all of the probes.

3.4 Inability to capture many packets

In our experiments, remote packet capture using RMON could only capture a few packets. This was due to resource limitations in the RMON probe. The number of captured packets depends upon the availability of resources such as memory and CPU as well as network load, and other external factors.

The probe has a limited memory; the main function of the hub is to perform the switching functions. Management functions such as network monitoring are secondary considerations. It is not efficient (that is, costly in terms of hardware) to use a large number of resources for RMON.

Capturing packets generates large amounts of data. When packet capturing is performed, another problem related to the bulk transfer of data to the management station may become an issue. Stallings (1993) indicates that SNMP is not well-suited to retrieving large volumes of data. To transfer PDUs using SNMP, a getnext request is issued which, in effect, commences an MIB walk. Executing an MIB walk is inefficient. After each PDU is downloaded, a snmpgetnext request PDU needs to be resent requesting the next set of variable bindings.

This problem can be eliminated if a transport protocol, implemented using TCP, is used for bulk data transfer between the RMON probe and the network manager. As TCP is connection oriented, a continuous stream of data can be sent, hence removing the requirement of the request after each PDU. This results in improved bulk data transfer of captured PDUs. The FTP or TFTP protocol may be suitable for this purpose.

4 Conclusion

The Remote Monitoring Management Information Base (RMON MIB) (Waldbusser 1995; Waldbusser 1996) provides a mechanism for efficient remote packet capture. Our research has shown that remote packet capture using RMON can sometimes be inefficient and cumbersome. Our results highlight a number of problems which occur in practice that must be overcome for RMON to be truly effective for remote packet capture.

Bibliography

1

Barron, G. (1993) Packetman v1.1. Technical Report, Department of Computer Science, Curtin University of Technology.

2

Benko, G. (1992) LAN-Based Packet Analysis of a TCP/IP network on X-Windows. Technical Report, Department of Computer Science, Curtin University of Technology.

3

Case, J., Fedor, M., Schoffstall, M. & Davin, J. (1990) A Simple Network Management Protocol (SNMP). Request for Comments 1157, Internet Engineering Task Force.

4

CCITT (1991) Data Communication Networks: Open Systems Interconnection (OSI); Management: Common Management Information Protocol for CCITT applications. Recommendation X.711, International Telecommunication Union.

5

CCITT (1992) Data Communication Networks: Management Framework for Open Systems Interconnection (OSI) for CCITT applications. Recommendation X.700, International Telecommunication Union.

6

CCITT (1994) Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. Recommendation X.680, International Telecommunication Union.

7

Leinwand, A. & Fang, K. (1993) Network Management: A Practical Perspective, Addison-Wesley.

8

McCloghrie, K. & Rose M. (1990) Management Information Base for Network Management of TCP/IP-based Internets. Request for Comments 1156, Internet Engineering Task Force.

9

McCloghrie, K. & Rose, M. (1990) Management Information Base for Network Management of TCP/IP-based Internets (MIB-II). Request for Comments 1157, Internet Engineering Task Force.

10

Postel, J. (1980) User Datagram Protocol. Request for Comments 768, Internet Engineering Task Force.

11

Rose, M. (1990) The Open Book: A Practical Perspective on OSI, Prentice-Hall.

12

Rose, M. (1994) The Simple Book: An Introduction to Internet Management, 2^nd edition, Prentice-Hall.

13

Rose, M. & McCloghrie, K. (1990) Structure and Identification of Management Information for TCP/IP-based Internets. Request for Comments 1155, Internet Engineering Task Force.

14

Schulze, M., Benko, G., & Farrell, C. (1993) Homebrew Network Monitoring: A Prelude to Network Management. Technical Report, Department of Computer Science, Curtin University of Technology.

15

Stallings, W. (1993) SNMP, SNMPv2 and CMIP: The Practical Guide to Network Management Standards, Addison-Wesley.

16

Stallings, W. (1994) Packet Filtering in the SNMP Remote Monitor. Dr Dobb's Journal 19(11).

17

Tantiprasut, D. (1995) Protocol Analysis via ASN.1 Specification: Compilation of ASN.1 Specification into Packetman. Honours Thesis, Department of Computer Science, Curtin University of Technology.

18

Williamson, B. (1995) Packetman v1.2. Technical Report, Department of Computer Science, Curtin University of Technology.

19

Waldbusser, S. (1995) Remote Network Monitoring Management Information Base. Request for Comments 1757, Internet Engineering Task Force.

20

Waldbusser, S. (1996) Remote Network Monitoring Management Information Base. Internet Draft. Work in Progress. Internet Engineering Task Force.

21

Warrier, U. & Besaw, L. (1989) The Common Management Information Services and Protocol over TCP/IP. Request for Comments 1095, Internet Engineering Task Force.

Return to Conference Proceedings