Network Working Group J. Schoenwaelder
Request for Comments: 5345 Jacobs University Bremen
Category: Informational October 2008
Network Working Group J. Schoenwaelder
Request for Comments: 5345 Jacobs University Bremen
Category: Informational October 2008
Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
简单网络管理协议（SNMP）流量测量和跟踪交换格式
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from the IETF Last Call on the allocation of a URI by IANA and the IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
IESG认为这项工作与IETF在与SNMP相关的操作和管理领域所做的工作有关，但这并不妨碍发布。本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IETF关于IANA分配URI的最后一次调用和IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已自行决定发布本文件。有关更多信息，请参阅RFC 3932。
Abstract
摘要
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
简单网络管理协议（SNMP）广泛用于监视、控制和（有时也）配置网络元素。尽管SNMP技术有很好的文档记录，但在实践中如何使用SNMP以及典型的SNMP使用模式仍然相对不清楚。
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
本文档描述了一种执行大规模SNMP流量测量的方法，以便更好地了解SNMP在实际生产网络中的使用方式。它描述了开展此类研究所需的动机、测量方法、工具和数据格式。
This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
本文件由IRTF的网络管理研究小组（NMRG）编制，代表了该小组所有积极参与者的共识。
Table of Contents
目录
1. Introduction ....................................................3
2. Measurement Approach ............................................4
2.1. Capturing Traffic Traces ...................................5
2.2. Converting Traffic Traces ..................................6
2.3. Filtering Traffic Traces ...................................7
2.4. Storing Traffic Traces .....................................7
2.5. Analyzing Traffic Traces ...................................8
3. Analysis of Traffic Traces ......................................9
3.1. Basic Statistics ...........................................9
3.2. Periodic versus Aperiodic Traffic ..........................9
3.3. Message Size and Latency Distributions .....................9
3.4. Concurrency Levels ........................................10
3.5. Table Retrieval Approaches ................................10
3.6. Trap-Directed Polling - Myths or Reality? .................10
3.7. Popular MIB Definitions ...................................11
3.8. Usage of Obsolete Objects .................................11
3.9. Encoding Length Distributions .............................11
3.10. Counters and Discontinuities .............................11
3.11. Spin Locks ...............................................12
3.12. Row Creation .............................................12
4. Trace Exchange Formats .........................................12
4.1. XML Representation ........................................12
4.2. CSV Representation ........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
1. Introduction ....................................................3
2. Measurement Approach ............................................4
2.1. Capturing Traffic Traces ...................................5
2.2. Converting Traffic Traces ..................................6
2.3. Filtering Traffic Traces ...................................7
2.4. Storing Traffic Traces .....................................7
2.5. Analyzing Traffic Traces ...................................8
3. Analysis of Traffic Traces ......................................9
3.1. Basic Statistics ...........................................9
3.2. Periodic versus Aperiodic Traffic ..........................9
3.3. Message Size and Latency Distributions .....................9
3.4. Concurrency Levels ........................................10
3.5. Table Retrieval Approaches ................................10
3.6. Trap-Directed Polling - Myths or Reality? .................10
3.7. Popular MIB Definitions ...................................11
3.8. Usage of Obsolete Objects .................................11
3.9. Encoding Length Distributions .............................11
3.10. Counters and Discontinuities .............................11
3.11. Spin Locks ...............................................12
3.12. Row Creation .............................................12
4. Trace Exchange Formats .........................................12
4.1. XML Representation ........................................12
4.2. CSV Representation ........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
The Simple Network Management Protocol (SNMP) was introduced in the late 1980s [RFC1052] and has since then evolved to what is known today as the SNMP version 3 Framework (SNMPv3) [RFC3410]. While SNMP is widely deployed, it is not clear what protocol versions are being used, which protocol features are being used, how SNMP usage differs in different types of networks or organizations, which information is frequently queried, and what typical SNMP interaction patterns occur in real-world production networks.
简单网络管理协议（SNMP）于20世纪80年代末引入[RFC1052]，并从那时起发展到今天所称的SNMP版本3框架（SNMPv3）[RFC3410]。虽然SNMP已广泛部署，但尚不清楚正在使用哪些协议版本、使用哪些协议功能、SNMP在不同类型的网络或组织中的使用情况如何不同、经常查询哪些信息以及在实际生产网络中出现了哪些典型的SNMP交互模式。
There have been several publications in the recent past dealing with the performance of SNMP in general [SM99][Mal02][Pat01], the impact of SNMPv3 security [DSR01][CT04], or the relative performance of SNMP compared to Web Services [PDMQ04][PFGL04]. While these papers are generally useful to better understand the impact of various design decisions and technologies, some of these papers lack a strong foundation because authors typically assume certain SNMP interaction patterns without having experimental evidence that the assumptions are correct. In fact, there are many speculations on how SNMP is being used in real-world production networks, and performance comparisons are based on limited test cases, but no systematic measurements have been performed and published so far.
最近有几份出版物涉及SNMP的总体性能[SM99][Mal02][Pat01]，SNMPv3安全性[DSR01][CT04]的影响，或SNMP与Web服务[PDMQ04][PFGL04]相比的相对性能。虽然这些论文通常有助于更好地理解各种设计决策和技术的影响，但这些论文缺乏一些坚实的基础，因为作者通常假设某些SNMP交互模式而没有实验证据表明假设是正确的。事实上，人们对SNMP在现实生产网络中的使用方式有很多猜测，性能比较是基于有限的测试用例，但迄今为止还没有进行过系统的测量和发布。
Many authors use the ifTable of the IF-MIB [RFC2863] or the tcpConnTable of the TCP-MIB [RFC4022] as a starting point for their analysis and comparison. Despite the fact that there is no evidence that operations on these tables dominate SNMP traffic, it is even more unclear how these tables are read and which optimizations are done (or not done) by real-world applications. It is also unclear what the actual traffic trade-off between periodic polling and more aperiodic bulk data retrieval is. Furthermore, we do not generally understand how much traffic is devoted to standardized MIB objects and how much traffic deals with proprietary MIB objects and whether the operation mix between these object classes differs between different operational environments (e.g., backbone networks, access networks, enterprise networks).
许多作者使用IF-MIB[RFC2863]的ifTable或TCP-MIB[RFC4022]的TCPCONTABLE作为分析和比较的起点。尽管没有证据表明这些表上的操作控制着SNMP流量，但更不清楚的是，这些表是如何读取的，以及哪些优化是由实际应用程序完成的（或未完成的）。还不清楚定期轮询和更不定期的批量数据检索之间的实际流量权衡是什么。此外，我们通常不了解有多少流量用于标准化MIB对象，有多少流量用于专有MIB对象，以及这些对象类之间的操作组合在不同的操作环境（例如主干网络、接入网络、企业网络）之间是否不同。
This document recommends an approach to collecting, codifying, and handling SNMP traffic traces in order to find answers to some of these questions. It describes the tools that have been developed to allow network operators to collect traffic traces and to share them with research groups interested in analyzing and modeling network management interactions.
本文档推荐一种收集、编码和处理SNMP流量跟踪的方法，以便找到其中一些问题的答案。它描述了为允许网络运营商收集流量跟踪并与对分析和建模网络管理交互感兴趣的研究小组共享而开发的工具。
While the SNMP trace collection and analysis effort was initiated by the research community, network operators can benefit from the SNMP measurements too. Several new tools are being developed as part of
虽然SNMP跟踪收集和分析工作是由研究团体发起的，但网络运营商也可以从SNMP测量中受益。一些新的工具正在开发中，作为项目的一部分
this effort that can be used to capture and analyze the traffic generated by management stations. This resulting information can then be used to improve the efficiency and scalability of management systems.
这项工作可用于捕获和分析管理站生成的流量。由此产生的信息可用于提高管理系统的效率和可伸缩性。
The measurement approach described in this document is by design limited to the study of SNMP traffic. Studies of other management protocols or the impact of management protocols such as SNMP on other traffic sharing the same network resources is left to future efforts.
本文档中描述的测量方法在设计上仅限于SNMP流量的研究。其他管理协议的研究或管理协议（如SNMP）对共享相同网络资源的其他通信量的影响将留给未来的工作。
This is an Informational document, produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
这是一份信息性文件，由IRTF的网络管理研究小组（NMRG）编制，代表了该小组所有积极参与者的共识。
This section outlines the process of doing SNMP traffic measurements and analysis. The process consists of the following five basic steps:
本节概述了进行SNMP流量测量和分析的过程。该过程包括以下五个基本步骤：
1. Capture raw SNMP traffic traces in pcap packet capture files [1].
1. 在pcap数据包捕获文件[1]中捕获原始SNMP流量跟踪。
2. Convert the raw traffic traces into a structured machine and human-readable format. A suitable XML schema has been developed for this purpose that captures all SNMP message details. Another more compact comma-separated values (CSV) format has been developed that only keeps key information about SNMP messages.
2. 将原始流量跟踪转换为结构化机器和人类可读的格式。为此，已经开发了一个合适的XML模式，它捕获所有SNMP消息细节。另一种更紧凑的逗号分隔值（CSV）格式已经开发出来，它只保存有关SNMP消息的关键信息。
3. Filter the converted traffic traces to hide or anonymize sensitive information. While the filtering is conceptually a separate step, filtering may actually be implemented as part of the previous data conversion step for efficiency reasons.
3. 过滤转换的流量跟踪以隐藏或匿名敏感信息。虽然过滤在概念上是一个单独的步骤，但出于效率原因，过滤实际上可以作为前一个数据转换步骤的一部分来实现。
4. Submit the filtered traffic traces to a repository from which they can be retrieved and analyzed. Such a repository may be public, under the control of a research group, or under the control of a network operator who commits to run analysis scripts on the repository on behalf of researchers.
4. 将过滤后的流量跟踪提交到存储库，从中可以检索和分析这些流量跟踪。这样的存储库可能是公共的，在研究小组的控制下，或者在网络运营商的控制下，网络运营商承诺代表研究人员在存储库上运行分析脚本。
5. Analyze the traces by creating and executing analysis scripts that extract and aggregate information.
5. 通过创建和执行提取和聚合信息的分析脚本来分析跟踪。
Several of the steps listed above require the involvement of network operators supporting the SNMP measurement projects. In many cases, the filtered XML and CSV representation of the SNMP traces will be the interface between the researchers writing analysis scripts and the operators involved in the measurement activity. It is therefore important to have a well-defined specification of these interfaces.
上面列出的几个步骤需要支持SNMP测量项目的网络运营商参与。在许多情况下，SNMP跟踪的过滤XML和CSV表示将是编写分析脚本的研究人员与参与测量活动的操作员之间的接口。因此，对这些接口有一个定义良好的规范是很重要的。
This section provides some advice and concrete hints on how the steps listed above can be carried out efficiently. Some special tools have been developed to assist network operators and researchers so that the time spent on supporting SNMP traffic measurement projects is limited. The following sections describe the five steps and some tools in more detail.
本节就如何有效执行上述步骤提供了一些建议和具体提示。已经开发了一些专用工具来帮助网络运营商和研究人员，因此用于支持SNMP流量测量项目的时间是有限的。以下各节将更详细地描述这五个步骤和一些工具。
Capturing SNMP traffic traces can be done using packet sniffers such as tcpdump [2], wireshark [3], or similar applications. Some care must be taken to specify pcap filter expressions that match the SNMP transport endpoints used to carry SNMP traffic (typically 'udp and (port 161 or port 162)'). Furthermore, it is necessary to ensure that full packets are captured, that is packets are not truncated (tcpdump option -s 0). Finally, it is necessary to carefully select the placement of the capturing probe within the network. Especially on bridged LANs, it is important to ensure that all management traffic is captured and that the probe has access to all virtual LANs carrying management traffic. This usually requires placing the probe(s) close to the management system(s) and configuring dedicated monitoring ports on bridged networks. Some bridges have restrictions concerning their monitoring capabilities, and this should be investigated and documented where necessary.
可以使用数据包嗅探器（如tcpdump[2]、wireshark[3]或类似应用程序）捕获SNMP流量跟踪。必须注意指定与用于承载SNMP流量的SNMP传输端点相匹配的pcap筛选器表达式（通常为“udp和（端口161或端口162）”。此外，必须确保捕获完整的数据包，即数据包不会被截断（tcpdump选项-s 0）。最后，有必要在网络中仔细选择捕获探头的位置。特别是在桥接LAN上，确保捕获所有管理流量以及探测器能够访问承载管理流量的所有虚拟LAN非常重要。这通常需要将探测器靠近管理系统，并在桥接网络上配置专用监控端口。一些桥梁对其监控能力有限制，必要时应进行调查和记录。
It is recommended to capture at least a full week of data to capture diurnal patterns and one cycle of weekly behavior. Operators are strongly encouraged to capture traces over even longer periods of time. Tools such as tcpdump and tcpslice [2] or mergecap and editcap [3] can be used to split or merge pcap trace files as needed.
建议至少捕获一整周的数据，以捕获日变化模式和一周行为周期。强烈鼓励操作员在更长的时间内捕获跟踪。可以根据需要使用诸如tcpdump和tcpslice[2]或mergecap和editcap[3]之类的工具来拆分或合并pcap跟踪文件。
Several operating systems can offload some of the TCP/IP processing such as the calculation of transport layer checksum to network interface cards. Traces that include traffic to/from a capturing interface that supports TCP/IP offloading can include incorrect transport layer checksums. The simplest solution is of course to turn checksum offloading off while capturing traces (if that is feasible without losing too many packets). The other solution is to correct or ignore checksums during the subsequent conversion of the raw pcap files.
一些操作系统可以卸载一些TCP/IP处理，例如计算网络接口卡的传输层校验和。包含到/来自支持TCP/IP卸载的捕获接口的流量的跟踪可能包含不正确的传输层校验和。当然，最简单的解决方案是在捕获跟踪时关闭校验和卸载（如果这在不丢失太多数据包的情况下是可行的）。另一种解决方案是在原始pcap文件的后续转换过程中更正或忽略校验和。
It is important to note that the raw pcap files should ideally be kept in permanent storage (e.g., compressed and encrypted on a CD ROM or DVD). To verify measurements, it might be necessary to go back to the original pcap files if, for example, bugs in the tools described below have been detected and fixed.
需要注意的是，原始pcap文件最好保存在永久存储中（例如，压缩并加密在CD-ROM或DVD上）。为了验证测量结果，可能需要返回原始pcap文件，例如，如果检测到并修复了下面描述的工具中的错误。
For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the trace was collected (name of the network and name of the organization owning the network, description of the measurement point in the network topology where the trace was collected), when it was collected, contact information, the size of the trace, any known special events, equipment failures, or major infrastructure changes during the data collection period and so on. It is also extremely useful to provide a unique identification. There are special online services such as DatCat [4] where meta data can be stored and which provide unique identifiers.
对于每个捕获的跟踪，应记录并提供一些元数据。元数据应包括以下信息：收集跟踪的位置（网络名称和拥有网络的组织名称、收集跟踪的网络拓扑中测量点的描述）、收集时间、联系信息、跟踪的大小、任何已知的特殊事件、，设备故障，或数据收集期间的重大基础设施变更等。提供唯一标识也非常有用。有一些特殊的在线服务，如DatCat[4]，其中可以存储元数据，并提供唯一的标识符。
Raw traces in pcap format must be converted into a format that is human readable while also remaining machine readable for efficient post-processing. Human readability makes it easy for an operator to verify that no sensitive data is left in a trace while machine readability is needed to efficiently extract relevant information.
pcap格式的原始记录道必须转换为人类可读的格式，同时保持机器可读，以实现高效的后处理。人工可读性使操作员能够轻松验证跟踪中是否没有留下任何敏感数据，同时需要机器可读性来有效提取相关信息。
The natural choice here is to use an XML format since XML is human as well as machine readable and there are many tools and high-level scripting language application programming interfaces (APIs) that can be used to process XML documents and to extract meaningful information. However, XML is also pretty verbose, which increases processing overhead. In particular, the usage of XML streaming APIs is strongly suggested since APIs that require an in-memory representation of XML documents do not handle large traces well.
这里的自然选择是使用XML格式，因为XML是人类和机器可读的，并且有许多工具和高级脚本语言应用程序编程接口（API）可用于处理XML文档和提取有意义的信息。然而，XML也非常冗长，这增加了处理开销。特别是，强烈建议使用XML流API，因为需要XML文档内存表示的API不能很好地处理大型跟踪。
Section 4.1 of this document defines a RELAX NG schema [OASISRNG] for representing SNMP traffic traces in XML. The schema captures all relevant details of an SNMP message in the XML format. Note that the XML format retains some information about the original ASN.1/BER encoding to support message size analysis.
本文档第4.1节定义了一个RELAX NG模式[OAISRNG]，用于以XML表示SNMP流量跟踪。模式以XML格式捕获SNMP消息的所有相关详细信息。注意，XML格式保留了一些关于原始ASN.1/BER编码的信息，以支持消息大小分析。
A lightweight alternative to the full-blown XML representation based on comma-separated values (CSV) is defined in Section 4.2. The CSV format only captures selected parts of SNMP messages and is thus more compact and faster to process.
第4.2节定义了基于逗号分隔值（CSV）的完整XML表示的轻量级替代方案。CSV格式仅捕获SNMP消息的选定部分，因此更紧凑，处理速度更快。
As explained in the previous sections, analysis programs that process raw pcap files should have an option to ignore incorrect checksums caused by TCP/IP offloading. In addition, analysis programs that process raw pcap files should be able to perform IP reassembly for SNMP messages that were fragmented at the IP layer.
如前几节所述，处理原始pcap文件的分析程序应具有忽略TCP/IP卸载导致的错误校验和的选项。此外，处理原始pcap文件的分析程序应该能够对在IP层分段的SNMP消息执行IP重组。
The snmpdump [5] package has been developed to convert raw pcap files into XML and CSV format. The snmpdump program reads pcap, XML, or CSV files as input and produces XML files or CSV files as output.
snmpdump[5]包已开发用于将原始pcap文件转换为XML和CSV格式。snmpdump程序读取pcap、XML或CSV文件作为输入，并生成XML文件或CSV文件作为输出。
Specific elements can be filtered as required to protect sensitive data.
可以根据需要过滤特定元素以保护敏感数据。
Filtering sensitive data (e.g., access control lists or community strings) can be achieved by manipulating the XML representation of an SNMP trace. Standard XSLT processors (e.g., xsltproc [6]) can be used for this purpose. People familiar with the scripting language Perl might be interested in choosing a suitable Perl module to manipulate XML documents [7].
过滤敏感数据（例如，访问控制列表或社区字符串）可以通过操纵SNMP跟踪的XML表示来实现。标准XSLT处理器（例如xsltproc[6]）可用于此目的。熟悉脚本语言Perl的人可能对选择合适的Perl模块来操作XML文档感兴趣[7]。
The snmpdump program, for example, can filter out sensitive information, e.g., by deleting or clearing all XML elements whose name matches a regular expression. Data type specific anonymization transformations that maintain lexicographic ordering for values that appear in instance identifiers [HS06] can be applied. Note that anonymization transformations are often bound to an initialization key and depend on the data being anonymized in an anonymization run. As a consequence, users must be careful when they merge data from independently anonymized traces. More information about network traffic trace anonymization techniques can be found in [XFA02], [FXAM04], [PAPL06], and [RW07].
例如，snmpdump程序可以过滤出敏感信息，例如，通过删除或清除名称与正则表达式匹配的所有XML元素。可以应用特定于数据类型的匿名化转换，该转换维护实例标识符[HS06]中出现的值的字典顺序。请注意，匿名化转换通常绑定到初始化密钥，并且依赖于在匿名化运行中被匿名化的数据。因此，用户在合并来自独立匿名跟踪的数据时必须小心。有关网络流量跟踪匿名化技术的更多信息，请参见[XFA02]、[FXAM04]、[PAPL06]和[RW07]。
The raw pcap traces as well as the XML / CSV formatted traces should be stored in a stable archive or repository. Such an archive or repository might be maintained by research groups (e.g., the NMRG), network operators, or both. It is of key importance that captured traces are not lost or modified as they may form the basis of future research projects and may also be needed to verify published research results. Access to the archive might be restricted to those who have signed some sort of a non-disclosure agreement.
原始pcap跟踪以及XML/CSV格式的跟踪应存储在稳定的存档或存储库中。此类档案或存储库可能由研究小组（如NMRG）、网络运营商或两者共同维护。捕获的痕迹不丢失或修改至关重要，因为它们可能构成未来研究项目的基础，也可能需要验证已发表的研究结果。对档案的访问可能仅限于那些签署了某种保密协议的人。
While this document recommends that raw traces should be kept, it must be noted that there are situations where this may not be feasible. The recommendation to keep raw traces may be ignored, for example, to comply with data-protection laws or to protect a network operator from being forced to provide the data to other organizations.
虽然本文件建议应保留原始痕迹，但必须注意，在某些情况下，这可能不可行。保留原始跟踪的建议可能会被忽略，例如，为了遵守数据保护法律或保护网络运营商不被强迫向其他组织提供数据。
Lossless compression algorithms embodied in programs such as gzip or bzip2 can be used to compress even large trace files down to a size where they can be burned on DVDs for cheap long-term storage.
gzip或bzip2等程序中包含的无损压缩算法可用于将大型跟踪文件压缩到可以刻录在DVD上的大小，以实现廉价的长期存储。
It must be stressed again that it is important to keep the original pcap traces in addition to the XML/CSV formatted traces since the pcap traces are the most authentic source of information. Improvements in the tool chain may require going back to the original pcap traces and rebuilding all intermediate formats from them.
必须再次强调，除了XML/CSV格式的跟踪之外，保留原始pcap跟踪非常重要，因为pcap跟踪是最真实的信息源。工具链的改进可能需要返回原始pcap跟踪，并从中重建所有中间格式。
Scripts that analyze traffic traces must be verified for correctness. Ideally, all scripts used to analyze traffic traces will be publically accessible so that third parties can verify them. Furthermore, sharing scripts will enable other parties to repeat an analysis on other traffic traces and to extend such analysis scripts. It might be useful to establish a common, versioning repository for analysis scripts.
必须验证分析流量跟踪的脚本的正确性。理想情况下，用于分析流量跟踪的所有脚本都可以公开访问，以便第三方可以对其进行验证。此外，共享脚本将使其他各方能够对其他流量跟踪重复分析，并扩展此类分析脚本。为分析脚本建立一个通用的版本控制存储库可能很有用。
Due to the availability of XML parsers and the simplicity of the CSV format, trace files can be processed with tools written in almost any programming language. However, in order to facilitate a common vocabulary and to allow operators to easily read scripts they execute on trace files, it is suggested that analysis scripts be written in scripting languages such as Perl using suitable Perl modules to manipulate XML documents <http://perl-xml.sourceforge.net/faq/>. Using a scripting language such as Perl instead of system programming languages such as C or C++ has the advantage of reducing development time and making scripts more accessible to operators who may want to verify scripts before running them on trace files that may contain sensitive data.
由于XML解析器的可用性和CSV格式的简单性，跟踪文件可以使用几乎任何编程语言编写的工具进行处理。但是，为了方便使用通用词汇表，并允许操作员轻松读取他们在跟踪文件上执行的脚本，建议使用脚本语言（如Perl）编写分析脚本，使用合适的Perl模块操作XML文档<http://perl-xml.sourceforge.net/faq/>. 使用诸如Perl之类的脚本语言代替系统编程语言（如C或C++）具有减少开发时间和使脚本更容易访问的可能性，这些操作符可能希望在对包含敏感数据的跟踪文件上运行脚本之前验证脚本。
The snmpdump tool provides an API to process SNMP messages in C/C++. While the coding of trace analysis programs in C/C++ should in general be avoided for code readability, verifiability, and portability reasons, using C/C++ might be the only option in dealing with very large traces efficiently.
snmpdump工具提供了一个API来处理C/C++中的SNMP消息。虽然出于代码可读性、可验证性和可移植性的原因，通常应避免使用C/C++编写跟踪分析程序，但使用C/C++可能是有效处理超大跟踪的唯一选择。
Any results produced by analyzing a trace must be interpreted in the context of the trace. The nature of the network, the attachment point used to collect the trace, the nature of the applications generating SNMP traffic, or the events that happened while the trace was collected clearly influence the result. It is therefore important to be careful when drawing general conclusions based on a potentially (too) limited data set.
分析跟踪产生的任何结果都必须在跟踪的上下文中进行解释。网络的性质、用于收集跟踪的连接点、生成SNMP通信的应用程序的性质，或者收集跟踪时发生的事件都会明显影响结果。因此，在根据可能（过于）有限的数据集得出一般结论时，务必小心。
This section discusses several questions that can be answered by analyzing SNMP traffic traces. The questions raised in the following subsections are meant to be illustrative and no attempt has been made to provide a complete list.
本节讨论通过分析SNMP流量跟踪可以回答的几个问题。以下小节中提出的问题旨在说明问题，未试图提供完整的清单。
Basic statistics cover things such as:
基本统计数据包括：
o protocol version used,
o 使用的协议版本，
o protocol operations used,
o 使用的协议操作，
o message size distribution,
o 消息大小分布，
o error message type frequency, or
o 错误消息类型频率，或
o usage of authentication and encryption mechanisms.
o 身份验证和加密机制的使用。
The Object Identifier (OID) names of the objects manipulated can be categorized into OID subtrees, for example, to identify 'standardized', 'proprietary', and 'experimental' objects.
被操纵对象的对象标识符（OID）名称可以分为OID子树，例如，用于识别“标准化”、“专有”和“实验”对象。
SNMP is used to periodically poll devices as well as to retrieve information at the request of an operator or application. The periodic polling leads to periodic traffic patterns while on-demand information retrieval causes more aperiodic traffic patterns. It is worthwhile to understand what the relationship is between the amount of periodic and aperiodic traffic. It will be interesting to understand whether there are multiple levels of periodicity at different time scales.
SNMP用于定期轮询设备，以及在操作员或应用程序请求时检索信息。周期轮询导致周期性的流量模式，而按需信息检索导致更多的非周期性流量模式。有必要了解周期性和非周期性流量之间的关系。了解在不同的时间尺度上是否存在多个层次的周期性将是一件有趣的事情。
Periodic polling behavior may be dependent on the application and polling engine it uses. For example, some management platforms allow applications to specify how long polled values may be kept in a cache before they are polled again. Such optimizations need to be considered when analyzing traces for periodic and aperiodic traffic.
定期轮询行为可能取决于应用程序及其使用的轮询引擎。例如，一些管理平台允许应用程序指定轮询值在再次轮询之前可以在缓存中保留多长时间。在分析周期性和非周期性流量的跟踪时，需要考虑此类优化。
SNMP messages are size constrained by the transport mappings used and the buffers provided by the SNMP engines. For the further evolution of the SNMP framework, it would be useful to know what the actual message size distributions are. It would be useful to understand the
SNMP消息的大小受使用的传输映射和SNMP引擎提供的缓冲区的限制。对于SNMP框架的进一步发展，了解实际的消息大小分布是非常有用的。了解这一点将是有益的
latency distributions, especially the distribution of the processing times by SNMP command responders. Some SNMP implementations approximate networking delays by measuring request-response times, and it would be useful to understand to what extent this is a viable approach.
延迟分布，特别是SNMP命令响应程序的处理时间分布。一些SNMP实现通过测量请求响应时间来近似网络延迟，了解这在多大程度上是一种可行的方法将非常有用。
Some SNMP implementations update their counters from the underlying instrumentation following adaptive algorithms, not necessarily periodically, and not necessarily on-demand. The granularity of internal counter updates may impact latency measurements and should be taken into account.
一些SNMP实现按照自适应算法从底层检测更新其计数器，不一定是定期更新，也不一定是按需更新。内部计数器更新的粒度可能会影响延迟测量，应予以考虑。
SNMP allows management stations to retrieve information from multiple agents concurrently. It will be interesting to identify what the typical concurrency level is that can be observed on production networks or whether management applications prefer more sequential ways of retrieving data.
SNMP允许管理站同时从多个代理检索信息。确定在生产网络上可以观察到的典型并发级别是什么，或者管理应用程序是否更喜欢以顺序方式检索数据，这将是一件有趣的事情。
Furthermore, it will be interesting to analyze how many redundant requests coming from applications are processed almost simultaneously by a device. The concurrency level and the amount of redundant requests has implications on caching strategies employed by SNMP agents.
此外，分析一台设备几乎同时处理来自应用程序的多少冗余请求将是一件有趣的事情。并发级别和冗余请求的数量对SNMP代理使用的缓存策略有影响。
Tables can be read in several different ways. The simplest and most inefficient approach is to retrieve tables object-by-object in column-by-column order. More advanced approaches try to read tables row-by-row or even multiple-rows-by-multiple-rows. The retrieval of index elements can be suppressed in most cases or only a subset of columns of a table are retrieved. It will be useful to know which of these approaches are used on production networks since this has a direct implication on agent implementation techniques and caching strategies.
表格可以用几种不同的方式读取。最简单也是最低效的方法是按逐列顺序逐对象检索表。更高级的方法尝试逐行或甚至多行多行地读取表。在大多数情况下，可以禁止检索索引元素，或者只检索表的一部分列。了解这些方法中的哪一种用于生产网络是很有用的，因为这对代理实现技术和缓存策略有直接影响。
SNMP is built around a concept called trap-directed polling. Management applications are responsible to periodically poll SNMP agents to determine their status. In addition, SNMP agents can send traps to notify SNMP managers about events so that SNMP managers can adapt their polling strategy and basically react faster than normal polling would allow.
SNMP是围绕一个称为陷阱定向轮询的概念构建的。管理应用程序负责定期轮询SNMP代理以确定其状态。此外，SNMP代理可以发送陷阱，将事件通知SNMP管理器，以便SNMP管理器可以调整其轮询策略，并且基本上比正常轮询允许的反应速度更快。
Analysis of SNMP traffic traces can identify whether trap-directed polling is actually deployed. In particular, the question that should be addressed is whether SNMP notifications lead to changes in the short-term polling behavior of management stations. In particular, it should be investigated to what extent SNMP managers use automated procedures to track down the meaning of the event conveyed by an SNMP notification.
对SNMP流量跟踪的分析可以确定是否实际部署了陷阱定向轮询。特别是，应该解决的问题是SNMP通知是否会导致管理站的短期轮询行为发生变化。特别是，应调查SNMP管理器在多大程度上使用自动化过程来跟踪SNMP通知所传达事件的含义。
An analysis of object identifier prefixes can identify the most popular MIB modules and the most important object types or notification types defined by these modules. Such information would be very valuable for the further maintenance and development of these and related MIB modules.
对对象标识符前缀的分析可以识别最流行的MIB模块以及这些模块定义的最重要的对象类型或通知类型。这些信息对于这些和相关MIB模块的进一步维护和开发非常有价值。
Several objects from the early days have been obsoleted because they cannot properly represent today's networks. A typical example is the ipRouteTable that was obsoleted because it was not able to represent classless routing, introduced and deployed on the Internet in 1993. Some of these obsolete objects are still mentioned in popular publications as well as research papers. It will be interesting to find out whether they are also still used by management applications or whether management applications have been updated to use the replacement objects.
早期的一些对象已经过时，因为它们不能正确地表示今天的网络。一个典型的例子是ipRouteTable，它因无法表示1993年在Internet上引入和部署的无类路由而被淘汰。流行出版物和研究论文中仍然提到其中一些过时的物体。了解管理应用程序是否仍在使用这些对象，或者管理应用程序是否已更新以使用替换对象，这将是一件有趣的事情。
Depending on the data recorded in a trace, it might be possible to determine the age of devices by looking at the values of objects such as sysObjectID and sysDecr [RFC3418]. The age of a device can then be taken into consideration when analyzing the use of obsolete and deprecated objects.
根据记录在跟踪中的数据，可以通过查看诸如sysObjectID和sysDecr[RFC3418]等对象的值来确定设备的使用年限。然后，在分析过时和不推荐对象的使用时，可以考虑设备的使用年限。
It will be useful to understand the encoding length distributions for various data types. Assumptions about encoding length distributions are sometimes used to estimate SNMP message sizes in order to meet transport and buffer size constraints.
了解各种数据类型的编码长度分布将非常有用。关于编码长度分布的假设有时用于估计SNMP消息大小，以满足传输和缓冲区大小限制。
Counters can experience discontinuities [RFC2578]. A widely used discontinuity indicator is the sysUpTime scalar of the SNMPv2-MIB [RFC3418], which can be reset through a warm start to indicate counter discontinuities. Some MIB modules introduce more specific discontinuity indicators, e.g., the ifCounterDiscontinuityTime of the
计数器可能会出现不连续性[RFC2578]。广泛使用的不连续性指示器是SNMPv2 MIB[RFC3418]的系统正常运行时间标量，可通过热启动重置该标量以指示计数器不连续性。一些MIB模块引入了更具体的不连续性指示器，例如
IF-MIB [RFC2863]. It will be interesting to study to what extent these objects are actually used by management applications to handle discontinuity events.
IF-MIB[RFC2863]。研究管理应用程序在多大程度上实际使用这些对象来处理不连续事件将是一件有趣的事情。
Cooperating command generators can use advisory locks to coordinate their usage of SNMP write operations. The snmpSetSerialNo scalar of the SNMPv2-MIB [RFC3418] is the default coarse-grain coordination object. It will be interesting to find out whether there are command generators that coordinate themselves using these spin locks.
协作命令生成器可以使用建议锁来协调它们对SNMP写入操作的使用。SNMPv2 MIB[RFC3418]的snmpSetSerialNo标量是默认的粗粒度协调对象。了解是否有命令生成器使用这些自旋锁来协调它们自己将是一件有趣的事情。
Row creation is an operation not natively supported by the protocol operations. Instead, conceptual tables supporting row creation typically provide a control column that uses the RowStatus textual convention defined in the SNMPv2-TC [RFC2579] module. The RowStatus itself supports different row creation modes, namely createAndWait (dribble-mode) and createAndGo (one-shot mode). Different approaches can be used to derive the instance identifier if it does not have special semantics associated with it. It will be useful to study which of the various row creation approaches are actually used by management applications on production networks.
行创建是协议操作本机不支持的操作。相反，支持行创建的概念表通常提供一个使用SNMPv2 TC[RFC2579]模块中定义的RowStatus文本约定的控制列。RowStatus本身支持不同的行创建模式，即createAndWait（运球模式）和createAndGo（单发模式）。如果实例标识符没有与之关联的特殊语义，则可以使用不同的方法来派生实例标识符。研究生产网络上的管理应用程序实际使用的各种行创建方法中的哪一种是有用的。
The XML format has been designed to keep all information associated with SNMP messages. The format is specified in RELAX NG compact notation [OASISRNC]. Freely available tools such as trang [8] can be used to convert RELAX NG compact syntax to other XML schema notations.
XML格式旨在保留与SNMP消息相关的所有信息。格式在RELAX NG紧凑表示法[OAISRNC]中指定。可以使用trang[8]等免费提供的工具将RELAXNG紧凑语法转换为其他XML模式符号。
The XML format can represent SNMPv1, SNMPv2c, and SNMPv3 messages. In case a new version of SNMP is introduced in the future or existing SNMP versions are extended in ways that require changes to the XML format, a new XML format with a different namespace needs to be defined (e.g., by incrementing the version number included in the namespace URI).
XML格式可以表示SNMPv1、SNMPv2c和SNMPv3消息。如果将来引入新版本的SNMP，或者现有的SNMP版本以需要更改XML格式的方式进行扩展，则需要定义具有不同名称空间的新XML格式（例如，通过增加名称空间URI中包含的版本号）。
# Relax NG grammar for the XML SNMP trace format. # # Published as part of RFC 5345.
#放松XML SNMP跟踪格式的NG语法作为RFC 5345的一部分发布。
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
start =
element snmptrace {
packet.elem*
}
start =
element snmptrace {
packet.elem*
}
packet.elem =
element packet {
element time-sec { xsd:unsignedInt },
element time-usec { xsd:unsignedInt },
element src-ip { ipaddress.type },
element src-port { xsd:unsignedInt },
element dst-ip { ipaddress.type },
element dst-port { xsd:unsignedInt },
snmp.elem
}
packet.elem =
element packet {
element time-sec { xsd:unsignedInt },
element time-usec { xsd:unsignedInt },
element src-ip { ipaddress.type },
element src-port { xsd:unsignedInt },
element dst-ip { ipaddress.type },
element dst-port { xsd:unsignedInt },
snmp.elem
}
snmp.elem =
element snmp {
length.attrs?,
message.elem
}
snmp.elem =
element snmp {
length.attrs?,
message.elem
}
message.elem =
element version { length.attrs, xsd:int },
element community { length.attrs, xsd:hexBinary },
pdu.elem
message.elem =
element version { length.attrs, xsd:int },
element community { length.attrs, xsd:hexBinary },
pdu.elem
message.elem |=
element version { length.attrs, xsd:int },
element message {
length.attrs,
element msg-id { length.attrs, xsd:unsignedInt },
element max-size { length.attrs, xsd:unsignedInt },
element flags { length.attrs, xsd:hexBinary },
element security-model { length.attrs, xsd:unsignedInt }
},
usm.elem?,
element scoped-pdu {
length.attrs,
element context-engine-id { length.attrs, xsd:hexBinary },
element context-name { length.attrs, xsd:string },
pdu.elem
}
message.elem |=
element version { length.attrs, xsd:int },
element message {
length.attrs,
element msg-id { length.attrs, xsd:unsignedInt },
element max-size { length.attrs, xsd:unsignedInt },
element flags { length.attrs, xsd:hexBinary },
element security-model { length.attrs, xsd:unsignedInt }
},
usm.elem?,
element scoped-pdu {
length.attrs,
element context-engine-id { length.attrs, xsd:hexBinary },
element context-name { length.attrs, xsd:string },
pdu.elem
}
usm.elem = element usm {
usm.elem=元素usm{
length.attrs,
element auth-engine-id { length.attrs, xsd:hexBinary },
element auth-engine-boots { length.attrs, xsd:unsignedInt },
element auth-engine-time { length.attrs, xsd:unsignedInt },
element user { length.attrs, xsd:hexBinary },
element auth-params { length.attrs, xsd:hexBinary },
element priv-params { length.attrs, xsd:hexBinary }
}
length.attrs,
element auth-engine-id { length.attrs, xsd:hexBinary },
element auth-engine-boots { length.attrs, xsd:unsignedInt },
element auth-engine-time { length.attrs, xsd:unsignedInt },
element user { length.attrs, xsd:hexBinary },
element auth-params { length.attrs, xsd:hexBinary },
element priv-params { length.attrs, xsd:hexBinary }
}
pdu.elem =
element trap {
length.attrs,
element enterprise { length.attrs, oid.type },
element agent-addr { length.attrs, ipv4address.type },
element generic-trap { length.attrs, xsd:int },
element specific-trap { length.attrs, xsd:int },
element time-stamp { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
pdu.elem =
element trap {
length.attrs,
element enterprise { length.attrs, oid.type },
element agent-addr { length.attrs, ipv4address.type },
element generic-trap { length.attrs, xsd:int },
element specific-trap { length.attrs, xsd:int },
element time-stamp { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
pdu.elem |=
element (get-request | get-next-request | get-bulk-request |
set-request | inform-request | snmpV2-trap |
response | report) {
length.attrs,
element request-id { length.attrs, xsd:int },
element error-status { length.attrs, xsd:int },
element error-index { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
pdu.elem |=
element (get-request | get-next-request | get-bulk-request |
set-request | inform-request | snmpV2-trap |
response | report) {
length.attrs,
element request-id { length.attrs, xsd:int },
element error-status { length.attrs, xsd:int },
element error-index { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
varbind.elem = element varbind { length.attrs, name.elem, value.elem }
varbind.elem=元素varbind{length.attrs，name.elem，value.elem}
name.elem = element name { length.attrs, oid.type }
name.elem=元素名{length.attrs，oid.type}
value.elem =
element null { length.attrs, empty } |
element integer32 { length.attrs, xsd:int } |
element unsigned32 { length.attrs, xsd:unsignedInt } |
element counter32 { length.attrs, xsd:unsignedInt } |
element counter64 { length.attrs, xsd:unsignedLong } |
element timeticks { length.attrs, xsd:unsignedInt } |
element ipaddress { length.attrs, ipv4address.type } |
element octet-string { length.attrs, xsd:hexBinary } |
element object-identifier { length.attrs, oid.type } |
element opaque { length.attrs, xsd:hexBinary } |
value.elem =
element null { length.attrs, empty } |
element integer32 { length.attrs, xsd:int } |
element unsigned32 { length.attrs, xsd:unsignedInt } |
element counter32 { length.attrs, xsd:unsignedInt } |
element counter64 { length.attrs, xsd:unsignedLong } |
element timeticks { length.attrs, xsd:unsignedInt } |
element ipaddress { length.attrs, ipv4address.type } |
element octet-string { length.attrs, xsd:hexBinary } |
element object-identifier { length.attrs, oid.type } |
element opaque { length.attrs, xsd:hexBinary } |
element no-such-object { length.attrs, empty } |
element no-such-instance { length.attrs, empty } |
element end-of-mib-view { length.attrs, empty }
element no-such-object { length.attrs, empty } |
element no-such-instance { length.attrs, empty } |
element end-of-mib-view { length.attrs, empty }
# The blen attribute indicates the number of octets used by the BER # encoded tag / length / value triple. The vlen attribute indicates # the number of octets used by the BER encoded value alone.
#blen属性表示BER编码的标记/长度/值三元组使用的八位字节数。vlen属性表示#仅BER编码值使用的八位字节数。
length.attrs =
( attribute blen { xsd:unsignedShort },
attribute vlen { xsd:unsignedShort } )?
length.attrs =
( attribute blen { xsd:unsignedShort },
attribute vlen { xsd:unsignedShort } )?
oid.type =
xsd:string {
pattern =
"(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))" ~
"(\.(0|([1-9]\d*))){0,126}"
}
oid.type =
xsd:string {
pattern =
"(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))" ~
"(\.(0|([1-9]\d*))){0,126}"
}
# The types below are for IP addresses. Note that SNMP's buildin # IpAddress type only supports IPv4 addresses; IPv6 addresses are only # introduced to cover SNMP over IPv6 endpoints.
#以下类型适用于IP地址。请注意，SNMP的buildin#IpAddress类型仅支持IPv4地址；IPv6地址的引入只是为了覆盖IPv6端点上的SNMP。
ipv4address.type =
xsd:string {
pattern =
"((0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))\.){3}" ~
"(0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))"
}
ipv4address.type =
xsd:string {
pattern =
"((0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))\.){3}" ~
"(0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))"
}
ipv6address.type =
xsd:string {
pattern =
"(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|" ~
"(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?"
}
ipv6address.type =
xsd:string {
pattern =
"(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|" ~
"(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?"
}
ipaddress.type = ipv4address.type | ipv6address.type
ipaddress.type=ipv4address.type | ipv6address.type
The following example shows an SNMP trace file in XML format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent.
以下示例显示XML格式的SNMP跟踪文件，其中包含OID 1.3.6.1.2.1.1.3（系统正常运行时间）的SNMPv1 get next请求消息和代理返回的响应消息。
<snmptrace xmlns="urn:ietf:params:xml:ns:snmp-trace-1.0">
<packet>
<time-sec>1147212206</time-sec>
<time-usec>739609</time-usec>
<src-ip>192.0.2.1</src-ip>
<src-port>60371</src-port>
<dst-ip>192.0.2.2</dst-ip>
<dst-port>12345</dst-port>
<snmp blen="42" vlen="40">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<get-next-request blen="29" vlen="27">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="15" vlen="13">
<varbind blen="13" vlen="11">
<name blen="9" vlen="7">1.3.6.1.2.1.1.3</name>
<null blen="2" vlen="0"/>
</varbind>
</variable-bindings>
</get-next-request>
</snmp>
</packet>
<packet>
<time-sec>1147212206</time-sec>
<time-usec>762891</time-usec>
<src-ip>192.0.2.2</src-ip>
<src-port>12345</src-port>
<dst-ip>192.0.2.1</dst-ip>
<dst-port>60371</dst-port>
<snmp blen="47" vlen="45">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<response blen="34" vlen="32">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="20" vlen="18">
<varbind blen="18" vlen="16">
<name blen="10" vlen="8">1.3.6.1.2.1.1.3.0</name>
<unsigned32 blen="6" vlen="4">26842224</unsigned32>
</varbind>
</variable-bindings>
</response>
</snmp>
</packet>
</snmptrace>
<snmptrace xmlns="urn:ietf:params:xml:ns:snmp-trace-1.0">
<packet>
<time-sec>1147212206</time-sec>
<time-usec>739609</time-usec>
<src-ip>192.0.2.1</src-ip>
<src-port>60371</src-port>
<dst-ip>192.0.2.2</dst-ip>
<dst-port>12345</dst-port>
<snmp blen="42" vlen="40">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<get-next-request blen="29" vlen="27">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="15" vlen="13">
<varbind blen="13" vlen="11">
<name blen="9" vlen="7">1.3.6.1.2.1.1.3</name>
<null blen="2" vlen="0"/>
</varbind>
</variable-bindings>
</get-next-request>
</snmp>
</packet>
<packet>
<time-sec>1147212206</time-sec>
<time-usec>762891</time-usec>
<src-ip>192.0.2.2</src-ip>
<src-port>12345</src-port>
<dst-ip>192.0.2.1</dst-ip>
<dst-port>60371</dst-port>
<snmp blen="47" vlen="45">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<response blen="34" vlen="32">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="20" vlen="18">
<varbind blen="18" vlen="16">
<name blen="10" vlen="8">1.3.6.1.2.1.1.3.0</name>
<unsigned32 blen="6" vlen="4">26842224</unsigned32>
</varbind>
</variable-bindings>
</response>
</snmp>
</packet>
</snmptrace>
The comma-separated values (CSV) format has been designed to capture only the most relevant information about an SNMP message. In situations where all information about an SNMP message must be captured, the XML format defined above must be used. The CSV format uses the following fields:
逗号分隔值（CSV）格式设计为仅捕获有关SNMP消息的最相关信息。在必须捕获有关SNMP消息的所有信息的情况下，必须使用上面定义的XML格式。CSV格式使用以下字段：
1. Timestamp in the format seconds.microseconds since 1970, for example, "1137764769.425484".
1. 自1970年以来，时间戳的格式为秒。微秒，例如，“1137764769.425484”。
2. Source IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
2. 源IP地址采用点四进制表示法（IPv4），例如“192.0.2.1”，或紧凑十六进制表示法（IPv6），例如“2001:DB8:：1”。
3. Source port number represented as a decimal number, for example, "4242".
3. 以十进制数表示的源端口号，例如“4242”。
4. Destination IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
4. 以点四元表示法（IPv4）表示的目标IP地址，例如“192.0.2.1”，或紧凑十六进制表示法（IPv6），例如“2001:DB8:：1”。
5. Destination port number represented as a decimal number, for example, "161".
5. 以十进制数字表示的目标端口号，例如“161”。
6. Size of the SNMP message (a decimal number) counted in octets, for example, "123". The size excludes all transport, network, and link-layer headers.
6. SNMP消息的大小（十进制数），以八位字节计，例如“123”。该大小不包括所有传输层、网络层和链路层标头。
7. SNMP message version represented as a decimal number. The version 0 stands for SNMPv1, 1 for SNMPv2c, and 3 for SNMPv3, for example, "3".
7. 以十进制数字表示的SNMP消息版本。版本0代表SNMPv1，1代表SNMPv2c，3代表SNMPv3，例如，“3”。
8. SNMP protocol operation indicated by one of the keywords get-request, get-next-request, get-bulk-request, set-request, trap, snmpV2-trap, inform-request, response, report.
8. SNMP协议操作由关键字get request、get next request、get bulk request、set request、陷阱、snmpV2陷阱、通知请求、响应、报告之一指示。
9. SNMP request-id in decimal notation, for example, "1511411010".
9. 以十进制表示的SNMP请求id，例如“1511411010”。
10. SNMP error-status in decimal notation, for example, "0".
10. 以十进制表示的SNMP错误状态，例如“0”。
11. SNMP error-index in decimal notation, for example, "0".
11. 以十进制表示的SNMP错误索引，例如“0”。
12. Number of variable-bindings contained in the varbind-list in decimal notation, for example, "5".
12. varbind列表中包含的变量绑定的数量，以十进制表示，例如“5”。
13. For each varbind in the varbind list, three output elements are generated:
13. 对于varbind列表中的每个varbind，将生成三个输出元素：
1. Object name given as object identifier in dotted decimal notation, for example, "1.3.6.1.2.1.1.3.0".
1. 以点十进制表示法作为对象标识符给出的对象名称，例如，“1.3.6.1.2.1.1.3.0”。
2. Object base type name or exception name, that is one of the following: null, integer32, unsigned32, counter32, counter64, timeticks, ipaddress, octet-string, object-identifier, opaque, no-such-object, no-such-instance, and end-of-mib-view.
2. 对象基类型名称或异常名称，即以下名称之一：null、integer32、unsigned32、counter32、counter64、timeticks、ipaddress、八位字节字符串、对象标识符、不透明、无此类对象、无此类实例和mib视图结尾。
3. Object value is printed as a number if the underlying base type is numeric. An IPv4 addresses is rendered in the dotted quad notation and an IPv6 address is rendered in the usual hexadecimal notation. An octet string value is printed in hexadecimal format while an object identifier value is printed in dotted decimal notation. In case of an exception, the object value is empty.
3. 如果基础基类型为数字，则对象值将打印为数字。IPv4地址以虚线四元表示法呈现，IPv6地址以通常的十六进制表示法呈现。八进制字符串值以十六进制格式打印，而对象标识符值以点十进制表示法打印。在异常情况下，对象值为空。
Note that the format does not preserve the information needed to understand SNMPv1 traps. It is therefore recommended that implementations be able to convert the SNMPv1 trap format into the trap format used by SNMPv2c and SNMPv3, according to the rules defined in [RFC3584]. The activation of trap format conversion should be the user's choice.
请注意，该格式不保留理解SNMPv1陷阱所需的信息。因此，建议实现能够根据[RFC3584]中定义的规则，将SNMPv1陷阱格式转换为SNMPv2c和SNMPv3使用的陷阱格式。陷阱格式转换的激活应由用户选择。
The following example shows an SNMP trace file in CSV format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent. (Note that the example uses backslash line continuation marks in order to fit the example into the RFC format. Backslash line continuations are not part of the CSV format.)
以下示例显示了CSV格式的SNMP跟踪文件，其中包含OID 1.3.6.1.2.1.1.3（系统正常运行时间）的SNMPv1 get next请求消息和代理返回的响应消息。（请注意，该示例使用反斜线延续标记，以便将示例适合RFC格式。反斜线延续不是CSV格式的一部分。）
1147212206.739609,192.0.2.1,60371,192.0.2.2,12345,42,1,\ get-next-request,1804289383,0,0,1,1.3.6.1.2.1.1.3,null, 1147212206.762891,192.0.2.2,12345,192.0.2.1,60371,47,1,\ response,1804289383,0,0,1,1.3.6.1.2.1.1.3.0,timeticks,26842224
1147212206.739609192.0.2.160371192.0.2.212345,42,1，\get next request，1804289383,0,0,1,1.3.6.1.2.1.1.3，null，1147212206.762891192.0.2.212345192.0.2.160371,47,1，\response，1804289383,0,0,0,1,1.3.6.1.2.1.1.3.0，timeticks，26842224
SNMP traffic traces usually contain sensitive information. It is therefore necessary to (a) remove unwanted information and (b) to anonymize the remaining necessary information before traces are made available for analysis. It is recommended to encrypt traces when they are archived.
SNMP流量跟踪通常包含敏感信息。因此，有必要（a）删除不需要的信息，以及（b）在跟踪可用于分析之前，将剩余的必要信息匿名化。建议在存档跟踪时对其进行加密。
Implementations that generate CSV or XML traces from raw pcap files should have an option to suppress or anonymize values. Note that instance identifiers of tables also include values, and it might therefore be necessary to suppress or anonymize (parts of) the
从原始pcap文件生成CSV或XML跟踪的实现应具有抑制或匿名化值的选项。请注意，表的实例标识符也包括值，因此可能需要抑制或匿名（部分）表
instance identifiers. Similarly, the packet and message headers typically contain sensitive information about the source and destination of SNMP messages as well as authentication information (community strings or user names).
实例标识符。类似地，数据包和消息头通常包含有关SNMP消息源和目标的敏感信息以及身份验证信息（社区字符串或用户名）。
Anonymization techniques can be applied to keep information in traces that could otherwise reveal sensitive information. When using anonymization, values should only be kept when the underlying data type is known and an appropriate anonymization transformation is available (filter-in principle). For values appearing in instance identifiers, it is usually desirable to maintain the lexicographic order. Special anonymization transformations that preserve this property have been developed, although their anonymization strength is usually reduced compared to transformations that do not preserve lexicographic ordering [HS06].
匿名化技术可用于将信息保存在可能泄露敏感信息的痕迹中。使用匿名化时，仅当基础数据类型已知且适当的匿名化转换可用时（原则上为过滤器），才应保留值。对于出现在实例标识符中的值，通常需要保持字典顺序。虽然与不保留字典顺序的转换相比，它们的匿名化强度通常会降低，但已经开发出保留此属性的特殊匿名化转换[HS06]。
The meta data associated with traces and in particular information about the organization owning a network and the description of the measurement point in the network topology where a trace was collected may be misused to decide/pinpoint where and how to attack a network. Meta data therefore needs to be properly protected.
与跟踪相关联的元数据，特别是关于拥有网络的组织的信息，以及收集跟踪的网络拓扑中测量点的描述，可能被误用以确定/精确定位攻击网络的位置和方式。因此，元数据需要得到适当的保护。
Per this document, IANA has registered a URI for the SNMP XML trace format namespace in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration has been made:
根据本文档，IANA已在IETF XML注册表[RFC3688]中注册了SNMP XML跟踪格式命名空间的URI。按照RFC 3688中的格式，进行了以下注册：
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
Registrant Contact: The NMRG of the IRTF.
注册人联系人：IRTF的NMRG。
XML: N/A, the URI is an XML namespace.
XML:N/A，URI是一个XML名称空间。
This document was influenced by discussions within the Network Management Research Group (NMRG). Special thanks to Remco van de Meent for writing the initial Perl script that lead to the development of the snmpdump software package and Matus Harvan for his work on lexicographic order preserving anonymization transformations. Aiko Pras contributed ideas to Section 3 while David Harrington helped to improve the readability of this document.
本文件受到网络管理研究组（NMRG）内部讨论的影响。特别感谢Remco van de Meent编写了导致snmpdump软件包开发的初始Perl脚本，以及Matus Harvan在词典顺序保护匿名化转换方面的工作。Aiko Pras为第3节提供了想法，而David Harrington则帮助提高了本文件的可读性。
Last call reviews have been received from Bert Wijnen, Aiko Pras, Frank Strauss, Remco van de Meent, Giorgio Nunzi, Wes Hardacker, Liam Fallon, Sharon Chisholm, David Perkins, Deep Medhi, Randy Bush, David Harrington, Dan Romascanu, Luca Deri, and Marc Burgess. Karen R.
最后一次通话的评论来自伯特·维宁、爱子·普拉斯、弗兰克·施特劳斯、伦科·范德梅恩、乔治·努齐、韦斯·哈达克、利亚姆·法伦、沙龙·奇肖姆、大卫·帕金斯、迪普·梅迪、兰迪·布什、大卫·哈灵顿、丹·罗马斯坎努、卢卡·德里和马克·伯吉斯。卡伦R。
Sollins reviewed the document for the Internet Research Steering Group (IRSG). Jari Arkko, Pasi Eronen, Chris Newman, and Tim Polk provided helpful comments during the Internet Engineering Steering Group (IESG) review.
Sollins审查了互联网研究指导小组（IRSG）的文件。Jari Arkko、Pasi Eronen、Chris Newman和Tim Polk在互联网工程指导小组（IESG）审查期间提供了有益的意见。
Part of this work was funded by the European Commission under grant FP6-2004-IST-4-EMANICS-026854-NOE.
这项工作的一部分由欧盟委员会资助，资助项目为FP6-2004-IST-4-EMANICS-026854-NOE。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[OASISRNG] Clark, J. and M. Makoto, "RELAX NG Specification", OASIS Committee Specification, December 2001.
[OASIRNG]Clark，J.和M.Makoto，“RELAX NG规范”，OASIS委员会规范，2001年12月。
[OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002.
[OASIRNC]Clark，J.，“RELAXNG紧凑语法”，OASIS委员会规范，2002年11月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC1052] Cerf, V., "IAB Recommendations for the development of Internet network management standards", RFC 1052, April 1998.
[RFC1052]Cerf，V.，“IAB关于制定互联网网络管理标准的建议”，RFC1052，1998年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，Ed.“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022]Raghunarayan，R.，“传输控制协议（TCP）的管理信息库”，RFC 40222，2005年3月。
[PDMQ04] Pras, A., Drevers, T., van de Meent, R., and D. Quartel, "Comparing the Performance of SNMP and Web Services based Management", IEEE Transactions on Network and Service Management 1(2), November 2004.
[PDMQ04]Pras，A.，Drevers，T.，van de Meent，R.，和D.Quartel，“比较SNMP和基于Web服务的管理的性能”，IEEE网络和服务管理交易1（2），2004年11月。
[Pat01] Pattinson, C., "A Study of the Behaviour of the Simple Network Management Protocol", Proc. 12th IFIP/IEEE Workshop on Distributed Systems: Operations and Management , October 2001.
[Pat01]Pattinson，C.，“简单网络管理协议行为的研究”，Proc。第12届IFIP/IEEE分布式系统：运营和管理研讨会，2001年10月。
[DSR01] Du, X., Shayman, M., and M. Rozenblit, "Implementation and Performance Analysis of SNMP on a TLS/TCP Base", Proc. 7th IFIP/IEEE International Symposium on Integrated Network Management , May 2001.
[DSR01]Du，X.，Shayman，M.，和M.Rozenblit，“基于TLS/TCP的SNMP实现和性能分析”，Proc。第七届IFIP/IEEE综合网络管理国际研讨会，2001年5月。
[CT04] Corrente, A. and L. Tura, "Security Performance Analysis of SNMPv3 with Respect to SNMPv2c", Proc. 2004 IEEE/IFIP Network Operations and Management Symposium , April 2004.
[CT04]Corrente，A.和L.Tura，“SNMPv3相对于SNMPv2c的安全性能分析”，Proc。2004年IEEE/IFIP网络运营和管理研讨会，2004年4月。
[PFGL04] Pavlou, G., Flegkas, P., Gouveris, S., and A. Liotta, "On Management Technologies and the Potential of Web Services", IEEE Communications Magazine 42(7), July 2004.
[PFGL04]Pavlou，G.，Flegkas，P.，Gouveris，S.，和A.Liotta，“关于管理技术和Web服务的潜力”，IEEE通信杂志42（7），2004年7月。
[SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB Data", Simple Times 7(1), March 1999.
[SM99]Sprenkels，R.和J.Martin Flatin，“MIB数据的批量传输”，《简单时代》第7（1）期，1999年3月。
[Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002.
[Mal02]Malowidzki，M.，“GetBulk Worth Fixing”，简单时报10（1），2002年12月。
[HS06] Harvan, M. and J. Schoenwaelder, "Prefix- and Lexicographical-order-preserving IP Address Anonymization", IEEE/IFIP Network Operations and Management Symposium NOMS 2006, April 2006.
[HS06]Harvan，M.和J.Schoenwaeld，“保留前缀和字典顺序的IP地址匿名化”，IEEE/IFIP网络运营和管理研讨会NOMS 2006，2006年4月。
[XFA02] Xu, J., Fan, J., and M. Ammar, "Prefix-Preserving IP Address Anonymization: Measurement-based Security Evaluation and a New Cryptography-based Scheme", 10th IEEE International Conference on Network Protocols ICNP'02, November 2002.
[XFA02]Xu，J.，Fan，J.，和M.Ammar，“保留前缀的IP地址匿名化：基于测量的安全评估和一种新的基于密码学的方案”，第十届IEEE网络协议国际会议ICNP'02，2002年11月。
[FXAM04] Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-Preserving IP Address Anonymization", Computer Networks 46(2), October 2004.
[FXAM04]Fan，J.，Xu，J.，Ammar，M.，和S.Moon，“保留前缀的IP地址匿名化”，计算机网络46（2），2004年10月。
[PAPL06] Pang, R., Allman, M., Paxson, V., and J. Lee, "The Devil and Packet Trace Anonymization", Computer Communication Review 36(1), January 2006.
[PAPL06]Pang，R.，Allman，M.，Paxson，V.，和J.Lee，“魔鬼和数据包追踪匿名化”，计算机通信评论36（1），2006年1月。
[RW07] Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving IP Address Anonymization for Passive Measurement Systems", IEEE Transactions on Networking 15(1), February 2007.
[RW07]Ramaswamy，R.和T.Wolf，“被动测量系统的高速前缀保留IP地址匿名化”，IEEE网络交易15（1），2007年2月。
URIs
URI
[1] <http://en.wikipedia.org/wiki/Pcap>
[1] <http://en.wikipedia.org/wiki/Pcap>
[2] <http://www.tcpdump.org/>
[2] <http://www.tcpdump.org/>
[3] <http://www.wireshark.org/>
[3] <http://www.wireshark.org/>
[4] <http://www.datcat.org/>
[4] <http://www.datcat.org/>
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>
[6] <http://xmlsoft.org/XSLT/>
[6] <http://xmlsoft.org/XSLT/>
[7] <http://perl-xml.sourceforge.net/faq/>
[7] <http://perl-xml.sourceforge.net/faq/>
[8] <http://www.relaxng.org/>
[8] <http://www.relaxng.org/>
Author's Address
作者地址
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
德国不来梅大学校园环128725
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.