1.3 现有网络管理实践和相关限制
管理网络并不新鲜。本节着眼于“传统”网络管理实践。传统上网络针对不同的FCAPS管理方面使用不同的管理协议，具有不同的管理模型和不同的实践（通常是CLI和“抓屏”、SNMP、NetFlow和IPFIX以及syslog）。从那里你可以观察到各自的协议限制，下一节将重点介绍协议限制引起的不同数据模型的问题。
这些协议描述了当今世界上大多数网络操作的现状。各个部分看起来都有些不同并包含许多小细节，本章末的摘要中汇总了图片。一旦你看到每个环境如何工作的快照并了解其中一些细节，全景图就会更加清晰。
1.3.1 CLI：这是API吗
大多数设备具有内置命令行界面（CLI），用于配置和故障排除。传统上通过Telnet协议对CLI进行网络访问，并添加SSH协议来解决与Telnet相关的安全问题。在某个时间点，CLI是访问设备进行配置和故障排除的唯一方式。随着新功能的增加，CLI将成为一个庞大的配置和show命令列表。
CLI：解释
CLI通常是面向任务的，这使得它们易于被运维人员使用。由于目标是让人使用，设计原则是使CLI更具可读性。举个例子，旧的IOS命令已从show mac-address-table更改为show mac address-table，这可能是因为开发人员认为从接口角度来看更好，或者可能与新的“show mac”功能一致。对于多数时间与设备交互时使用命令自动实现功能的用户，此更改不是问题。实际上，大多数命令行界面都提供了上下文相关的帮助以减少学习难度。但是，由于此CLI更改，现在将命令发送到设备的脚本将会失败。
另一方面，保存的文本命令序列很容易被重放。通常以CLI片段形式出现的相同访问列表可以应用于多个设备。通过简单的替换和任意的文本处理工具，操作工程师可以将相似的CLI片段应用于网元。通常访问列表代码段包含几个要替换的参数，具体情况取决于被管理设备的特征。
CLI：限制
“CLI不再是标准”部分已涵盖大部分CLI限制，本小节添加一些实际配置示例，例如以下片段：
Conf t router ospf x vrf xxx
以下是另一个示例：
Conf t vrf xxx router ospf x
换句话说，即使来自同一供应商不同设备上的命令也很可能表现不同。这些差异背后的根本原因是什么？是因为CLI通常缺乏通用的数据模型。
这些VRF示例导致第二个CLI限制：CLI是上下文相关且有特定顺序的。问号有助于列出所有可用的选项，但输入一个命令可能会提供命令的子菜单。添加命令会引发问题，删除命令也会带来一些挑战。回到VRF示例，删除VRF可能会删除整组与VRF相关的命令，这同样取决于设备。由于CLI是专有的，因此在语法和语义上无法有效地在一组异构设备的环境中自动执行进程。
命令行界面主要面向用户，他们可以轻松适应较小的语法和格式更改。由于解析的复杂性，使用CLI作为编程接口很麻烦。例如，CLI在发生故障时不会报告错误代码，这是一个必要的自动化属性。最重要的是它无法发现新的CLI更改：CLI通常缺乏对语法和语义的有效版本控制。因此，维护不同版本的命令行界面接口程序或脚本既费时又容易出错。
此外，随着更多特性的引入CLI也在不断发展。当然，版本说明中记录了这些更改，至少记录了配置命令更改，但自动化不能使用版本说明。
CLI是否是API？它曾经作为API使用，但是非常脆弱。
作为一个测验，示例1-1显示了运维工程师在处理CLI时可能遇到的四种潜在情况。你能找到错误吗？这些输出有什么问题？
示例1-1 CLI测验
Router1的show命令看起来像AAA（授权、身份验证、计费）问题，而它可能指向Router2的非易失性随机存取存储器（NVRAM）问题。除非配置为空，否则Router3的输出看似有误。最后，Router4的输出像是一个错误，而实际上并非如此！在这种特定情况下，运维工程师将接口说明配置为“%Error with interface”，以标记此特定接口的问题。同样，对于用户而言，此说明有所帮助；但是对于基于CLI的脚本可能有意外的后果。在这种特殊情况下，这会导致Expect[3]脚本在自动配置存档时出现错误。当脚本尝试上载配置时，一旦遇到特定的描述行便停止工作，并认为脚本本身是错误的。实际上该脚本是基于“Error”的正则表达式（regex）。该示例充分说明了使用CLI进行自动化的困难。让我们直面它——CLI不适合自动化。它不是人机友好的，它缺乏明确规范的格式。作为配置和收集设备信息的唯一方法，CLI已使用多年，但它非常脆弱。
1.3.2 SNMP：用于监控但不用于配置
简单网络管理协议（SNMP）是IETF指定的协议。已经有多个协议版本。以下是不同SNMP版本的简要历史记录：
- SNMPv1（historic）：协议的第一个版本，由RFC 1157指定。本文档取代之前发布的RFC 1067和RFC 1098版本。安全性基于SNMP社区字符串。
- SNMPsec（historic）：此版本的协议在SNMPv1的协议操作上增加了强大的安全性，由RFC 1351，RFC 1352和RFC 1353指定。考虑了各方面的安全性。很少有供应商实施此版本的协议，该版本现已被搁置。
- SNMPv2p（historic）：对于此版本，已做了大量工作来更新SNMPv1协议和管理信息结构版本1，不仅仅是安全性。结果是更新了协议操作、新协议操作和数据类型，以及基于参与方的SNMPsec安全性。此版本的协议（现在称为基于参与方的SNMPv2）由RFC 1441、RFC 1445、RFC 1446、RFC 1448和RFC 1449定义。（注意此协议曾称为经典SNMPv2，但该名称与基于社区的SNMPv2混淆。因此术语SNMPv2p更可取。）
- SNMPv2c（experimental）：此版本的协议称为基于社区字符串的SNMPv2。由RFC 1901、RFC 1905和RFC 1906指定，是SNMPv2p协议操作和数据类型的更新，使用来自SNMPv1的基于社区的安全性。
- SNMPv2u（experimental）：此版本的协议使用基于用户的SNMPv2c协议操作和数据类型以及安全性。由RFC 1905、RFC 1906、RFC 1909和RFC 1910规定。
- SNMPv3（standard）：此版本的协议是基于用户的安全和协议操作以及来自SNMPv2p的数据类型的组合，并为代理提供支持。安全性基于SNMPv2u和SNMPv2*，经过大量审查后更新。定义此协议的文档有多个部分：
- 3410：互联网标准管理框架简介和适用性说明。
- 3411：描述SNMP管理框架的架构。通过RFC 5343简单网络管理协议（SNMP）上下文引擎ID发现和RFC 5590更新了的简单网络管理协议（SNMP）的传输子系统。
- 3412：SNMP的消息处理和调度。
- 3413：SNMPv3应用。
- 3414：SNMPv3版本3的基于用户的安全模型（USM）。
- 3415：基于视图的SNMP访问控制模型（VACM）。
- 3584：第1版、第2版和第3版共存的互联网标准网络管理框架。
本书的目的不是深入探讨SNMP的细节。对于SNMP、管理信息结构（SMI）和管理信息库（MIB）的相关技术有很多有价值的参考资料、书籍和教材，这里涵盖所有内容没有意义，尤其是你将很快意识到本书中的关键信息之一就是远离SNMP。但是，让我们看一下本书中必要的一些概念。
SNMP：说明
如图1-4所示，嵌入在要管理的设备（通常是网络环境中的路由器或交换机）中的SNMP代理，响应位于网络管理系统中的SNMP管理器的信息和操作请求（NMS）：典型信息包括接口计数器、系统正常运行时间、路由表等。这些数据集存储在设备内存中，并通过SNMP轮询的方式从网络管理应用程序中检索。MIB是驻留在SNMP代理虚拟信息存储中的管理对象的集合。在特定的MIB模块中定义了相关管理对象的集合。例如，在“Interfaces Group MIB”文档中指定了与接口相关的对象，由RFC 2863中的IETF详细说明。SMI定义了描述管理信息的规则，使用抽象语法符号ASN.1作为接口描述语言。换句话说，SMI是一种数据建模语言，用于描述要通过SNMP协议管理的对象。
图1-4 SNMP基本模型
SNMP管理器和SNMP代理之间发生以下类型的交互：
- Read：从SNMP代理读取托管对象的能力，其特征在于MIB模块中的“只读”对象。典型示例是接口计数器统计信息的轮询，由ifInOctets和ifOutOctets托管对象（RFC 2863）描述。
- Write：如果托管对象在MIB模块中指定为“读写”状态（例如，使用ifAdmin-Status托管对象更改接口管理状态（RFC 2863）），则可以在SNMP代理中设置托管对象。
- Notification，也称为trap或inform：是一种从SNMP代理到SNMP管理器的基于推送的机制（与SNMP管理器从SNMP代理轮询信息时的拉取相反）。典型示例是当接口操作状态更改时，发送到SNMP管理器的linkUp或linkDown通知（RFC 2863）。
SNMP：限制
SNMP规范背后的思想是开发一个用于配置和监视设备与网络的通用协议，有效地涵盖FCAP的多个方面，而对安全性“S”则分开对待。SNMP通知涵盖“故障”，读写MIB对象的配置涵盖“配置”，而众多只读MIB对象则涵盖“计费”和“性能”的某些方面。
SNMPv1于1990年发布，SNMPv3于2002年完成。第三版中融入了多年的经验。虽然SNMPv3在增加安全性的情况下需要一段时间才能广泛实施，但几年后它得出了一个重要结论：SNMP在监控设备方面一直做得很好。但是在设备配置上是失败的。
2003年，RFC 3535“2002年IAB网络管理研讨会概述”记录了网络运维人员和协议开发人员开始对话的结果，以指导IETF关注未来的网络管理工作。本文报告了与SNMP协议相关的强（+）、弱（-）和中性（o）点列表。
SNMP分析
SNMP管理技术创建于20世纪80年代末，此后在互联网上广泛实施和部署。因为有很多实施和操作经验，其技术特点很容易理解。
+ SNMP在设备监控方面运行良好。SNMP的无状态性质对于统计和状态轮询非常有用。
+ SNMP广泛用于基础监控。在大多数网络设备上实现了一些核心MIB模块，如IF-MIB（RFC 2863）。
+ 网络设备供应商开发了许多有明确定义的专有MIB模块来支持其管理产品。
+ SNMP是进行事件关联、警报检测和根本原因分析系统的重要数据源。
○ SNMP要求应用程序是有用的。SNMP早期便被设计为管理应用程序和设备之间的编程接口。因此，在没有管理应用程序或智能工具的情况下使用SNMP似乎更复杂。
○ 标准化MIB模块通常缺少可用于配置的可写MIB对象，导致在专有MIB模块中存在有趣的可写对象的情况。
- 设备中的对象数量存在扩展性问题。虽然SNMP为从许多设备中检索少量数据提供了合理的性能，但在从一些设备检索大量数据（例如路由表）时，它变得相当缓慢。
- 可写MIB模块的部署太少。虽然在电缆调制解调器等重要的可写MIB模块中存在一些明显的例外，但路由器设备通常无法通过SNMP进行完整的配置。
- SNMP事务模型和协议约束使得实现MIB比实现命令行界面解释器的命令更加复杂。MIB上的逻辑操作可以转换为SNMP交互序列，在该序列中实施必须保持状态直到操作完成，或者确定出故障为止。如果出现故障，一个健壮的实现必须能够将设备回滚到一致的状态。
- SNMP不支持轻松检索和回放配置。部分因为识别配置对象并不容易。另外命名系统非常具体，物理设备的重新配置可能会破坏回放先前配置的功能。
- 运维人员首选的面向任务的视图与SNMP提供的以数据为中心的视图之间通常存在语义上的不匹配。从面向任务的视图映射到以数据为中心的视图通常需要管理应用程序端一些特殊的代码。
- 几个标准化的MIB模块缺乏对高级程序的描述。阅读MIB模块通常并不清楚如何完成某些高级任务，导致有几个不同的方法来实现相同的目标，增加成本并阻碍了互操作性。
有多种因素阻止SNMP取代设备CLI成为主要的配置方法。RFC 3535简要介绍了一些要点，在此补充一些经验之谈：
- 首先，是金钱问题：与CLI代码相比，SNMP代理代码开发、测试和维护成本过高。对于管理对象数量有限的小型设备以及供应商提供最终用户管理应用程序的小型设备，SNMP似乎运行得很好。对于更复杂的设备，SNMP过于昂贵，难以使用（SNMP Set: Can it be saved?）[24]。
- 由于用户数据报协议（UDP）的特性，批量数据传输性能较差。典型的例子是路由表，其中BGP表的轮询需要相当长的时间。SNMP与基于UDP的普通文件传输协议（TFTP）具有相同的数据传输行为，因此花费了大量的等待时间。特别是如果网络中存在任何延迟，这就成了问题。但是，SNMP基于UDP的优点是流量在拥塞时也可以顺利通过。请注意，从SNMP轮询到NETCONF后，有运维人员在实际生产网络中看到性能提高了10倍。用NETCONF更典型的数值是快两到三倍（NETCONF是基于TCP的，为FTP式传输）。
- MIB设计时没有预料到查询操作性能这样差。一个典型示例是以下查询：哪个外发接口用于特定的目标地址？
- 通常不可能通过SNMP检索所有的设备配置以便与以前的配置进行比较或检查设备之间的一致性。通过SNMP接口对设备功能部件的覆盖不完整，并且许多功能部件的配置数据和操作状态数据之间缺乏区分。例如，当SNMP管理器使用ifAdminStatus对象设置接口状态时，它必须轮询ifOperStatus对象以检查所应用的操作状态。该示例对任何网络运维人员都是显而易见的，却无法以编程方式发现这两个对象之间的链接。
- 无法及时提供可用的MIB模块及其实施（有时MIB模块滞后数年），这迫使用户使用CLI。如前所述，设备管理实际上一直是事后思考的事情。一旦运维人员被“强制”使用脚本来管理其CLI（例如，使用Expect脚本），便没有太多的动机使用不同的机制来获取不太多的附加值。
- 在内部数据结构方面，其排列顺序有时是人为的，这会造成大量运行时的开销或增加实施成本或实施延迟，或两者兼而有之。一个典型的例子是路由表，在应答SNMP请求之前需要重新排列其数据。
- 运维人员认为当前的SNMP编程/脚本接口太过低级耗时，使用不便。此外，设备制造商认为SNMP工具本身就很难实现，尤其是复杂的表索引方案和表之间的相互关系。举一个实际例子，RFC 5815指定了用于IPFIX（IP Flow Information eXport）（也称为NetFlow版本10）监控和配置的MIB模块。此MIB模块以非常灵活的方式创建，支持NetFlow CLI选项所许可的所有可能的配置选项。某些表条目最多需要四个索引，增加了复杂性，因此不建议实施这个MIB模块。为了进行记录使用YANG模块执行相同的练习并生成了RFC 6728：IPFIX和数据包采样（PSAMP）协议的配置数据模型。
- MIB模块面向数据的低级抽象级别与网络运维人员所需的面向任务的抽象级别之间存在语义上的不匹配。原则上可以用工具来弥补这一差距，但是总成本很昂贵，需要严肃的开发和编程工作。
- MIB模块通常没有描述如何使用各种对象来实现某些管理功能。MIB模块通常被描述为没有配方的成分列表。
- SNMP无法找到在设备上实施的SNMP MIB模块的版本，更无法找到获取副本的机制。必须访问供应商网站或致电客户支持。
- SMI语言处理困难，也不实用。
- SNMP陷阱用于跟踪状态更改，但通常认为syslog消息包含更多信息来描述问题，通常认为它们更有用。SNMP陷阱通常需要后续的SNMP GET操作才能找出陷阱的真正含义。
请注意，IETF修复SMI和SNMP、SMIng（SMI Next Generation）[25]的努力于2003年结束，没有确切结果。
个人体验
大约在2006年的一次CiscoLive展会上，我询问了SNMP的配置使用情况。查看了思科网络管理产品，并在我的演讲中询问了网络管理合作伙伴和客户之后，结论（再次）很清晰并完全与行业一致：SNMP被广泛用于监视（轮询和通知），但不用于配置。第一个例外是IP SLA，它是一种协议，监视IP流量的服务级别协议（SLA）参数，例如延迟、数据包丢失、抖动等。以下三个因素解释了这种特定的IP SLA情况：
作为管理协议，IP SLA自然由管理协议（SNMP）配置。
MIB模块始终与CLI配置保持一致，而实际上大多数MIB模块是事后考虑的。
最重要的是，IP SLA操作在称为影子路由器的专用设备上配置，避免管理站与转发流量设备交互，并且启用太多的IP SLA操作可能降低其性能。
第二个例外是CISCO-CONFIG-COPY-MIB，它是一个MIB模块，可以通过以下方式方便地写入运行CISCO IOS的SNMP代理配置文件：往返于网络、将运行配置复制到启动配置（反之亦然）以及将配置（运行或启动）复制到本地IOS文件系统。
——贝诺特·克莱斯（Benoît Claise）
2014年，互联网工程指导小组（IESG）[26]、负责IETF活动技术管理和互联网标准流程的IETF小组，发布了一份关于“可写MIB模块”[27]的声明。
IESG关于可写MIB模块的声明
“IESG已经意识到在OPS领域和一些工作组中就目前采用基于标准的配置方法的讨论。OPS领域对NETCONF/YANG的使用表示强有力的支持，而许多工作组却仍然制定MIB模块。IESG希望通过这一声明澄清这一情况：
鼓励IETF工作组使用NETCONF/YANG标准进行配置，特别是在新的章程中。
只有在使用SNMP写入操作进行配置并与OPSAD/MIB doctors协商一致的情况下，工作组才能创建SNMP MIB模块和修改配置状态。”
如果从以前的行业状况还看不清楚，那么这个声明明确禁止指定MIB模块进行配置并指明新的方向，即采用NETCONF/YANG的解决方案。
1.3.3 NetFlow和IPFIX：主要用于流记录
第一个与流量相关的BoF（Birds of a Feather）会议是2001年夏季在伦敦举行的IETF第51次会议。几个月后成立了IP流信息出口（IPFIX）工作组（WG）[28]，其章程是：“选择一个协议，通过该协议可将IP流信息从‘导出器’及时传输到一个或多个收集站，并定义使用该协议的架构。协议必须在IETF批准的拥塞感知传输协议（例如TCP或SCTP）上运行。”章程规划了三个可交付物：需求、架构和数据模型。目的是标准化NetFlow，NetFlow是一种思科专有的实施方式，已经部署在运营商网络中。工作就此展开。
工作组就未来IPFIX协议的选择以及就此产生的IPFIX架构进行了长时间的讨论。有五种具备不同能力的候选协议，每个候选提案者显然都在推销自己的协议。工作组主席在会上决定，工作组应将所有要求归类为“必须”“应该”“可以”和“不在乎”。RFC 3917的“IPFIX需求”记录了此结果。一个负责根据已记录的需求评估不同协议的独立的团队得出结论认为，服务IPFIX WG章程的目标最好从NetFlow v9开始，这部分内容同时记录在RFC 3954中。
此后几年致力于IPFIX协议的规范化。工作组在与传输相关的讨论中花费了一年左右：是否应该使用TCP或流控制传输协议（SCTP）作为拥塞感知传输协议？或者使用UDP，因为大多数运维人员仅在流导出集合完全在其管理域内时才关心UDP？最重要的是，转发ASIC的分布式功能使拥塞感知传输要求（例如TCP或SCTP）变得复杂。最终规范在以下方面达成妥协：
“使用（RFC 3758）中指定PR-SCTP扩展的SCTP（RFC 4960），必须通过所有符合规定的实施方式来实现。UDP还可以通过符合规定的实施方式来实现。TCP也可以通过符合规定的实施方式来实施。”
IPFIX协议（RFC 5101）和IPFIX信息模型（RFC 5102）最终在2008年1月作为拟议标准发布。IPFIX是一种改进的NetFlow v9协议，具有额外的功能和要求，例如传输、字符串可变长度编码、安全性和模板撤回消息等。
IPFIX WG于2015年关闭，成果如下：
- IPFIX协议和信息模型，分别为RFC 7011和RFC 7012，作为互联网标准发布
- 关于IPFIX调解功能的一系列RFC
- 总共近30个IPFIX RFCs[29]（架构、协议扩展、实施指南、适用性、MIB模块、YANG模块等）
其中，IPFIX社区在PSAMP（数据包采样Packet SAMPling）[30]上工作，另一个工作组选择IPFIX导出数据包采样信息，并生成了四个RFC[31]。注意：一系列采样数据包只是具有某些特定属性的流记录。
NetFlow和IPFIX：解释
与SNMP一样，有许多书籍、视频和参考资料详细解释NetFlow和IPFIX，下面简短的章节集中解释本书需要说明的内容。
简而言之，IPFIX导出器（通常是路由器）首先导出一个模板记录，其中包含流记录中定义的不同关键字段和非关键字段。IPFIX导出器内部的计量过程观察到一些带有关键字段和非关键字段的流量记录，并在一些流量过期后根据模板记录导出。key字段是使一个流量具有唯一性的字段。因此，如果在IPFIX缓存中还没有观察到数据包中的（一组）key字段值，就在该缓存中创建一个新的流量记录，如图1-5所示。
图1-5 IPFIX基本模型
图1-6显示了一个典型的流记录，由许多IPFIX信息元素组成，其中流key字段以灰色显示，non-key字段以浅色显示。
图1-6 NetFlow版本5流量格式
IPFIX信息元素由IETF在IANA（互联网号码分配机构）注册管理机构中指定，也可以由厂商指定。图1-6中Packet Count和Input ifIndex在示例1-2中分别指定。
示例1-2 NetFlow Packet Count和Input ifIndex规范
基于本章后面讨论的数据模型和信息模型之间的区别，IPFIX信息模型（RFC 7012）和IPFIX信息元素是否不应该分别被称为IPFIX数据模型和IPFIX数据模型元素？因为它们与实施的详细信息直接相关，此处尚有争议。
NetFlow和IPFIX：各种限制
IPFIX广泛部署在流量监控领域，用于容量规划、安全监控、应用发现或仅用于基于流量的计费。NetFlow计量流程具有灵活性，能够选择任何IPFIX信息元素作为key字段或non-key字段，从而创建多个用于部署IPFIX的使用案例。
IPFIX最大的限制是它只报告与流量有关的信息，实际上它已经成为一种通用的导出机制。我们了解一下IPFIX首字母缩写词。
IPFIX是为IP创建的，但不限于IP：它可以导出超过IP层的信息，例如MAC地址、MPLS、TCP/UDP端口、应用等。
留下FIX供我们使用，但从协议的角度来看，没有什么能够阻止我们转发非流式相关信息，例如CPU。
留下IX的“Information eXport”，作为这个通用导出机制的缩写。
IPFIX IETF WG的一次会议上讨论了这一建议，但从未正式地进行过名称更改。
还有两项建议是关于建立一个通用导出机制：
- RFC 6313指定IPFIX扩展协议，以支持分层结构化数据和数据记录中的信息元素列表（序列，sequences）。此扩展允许定义复杂的数据结构，例如可变长度列表和模板之间的分层包含关系规范。该规范背后的一个初步想法是导出完整的防火墙规则以及阻塞的流量记录。
- RFC 8038规范了使用管理信息库（MIB）对象补充IP流信息导出（IPFIX）数据记录的方法，避免为已完全规范的现有MIB对象定义新的IPFIX信息元素。此规范背后的初始思想之一是在流记录及其QoS类映射旁边导出MIB模块中可用的基于类的QoS计数器。
这两个提议是为了扩展IPFIX协议的作用域而创建的，IPFIX规范发布之后其兴趣仍然集中在与流相关的信息上，这两个提议来得太晚了。然而，最初在2009年和2010年提出的这两个提案表明该行业早期已有进行更多的自动化和数据模型整合的迹象。
1.3.4 syslog：无结构化数据
syslog是20世纪80年代开发的一种机制，用于生成日志，使软件子系统能够本地或远程报告和保存重要的错误消息，如示例1-3所示。
示例1-3 典型syslog消息
从类似Unix的操作系统开始（使用Unix手册页面中的文档）许多地方都在使用syslog，syslog成为事实上的标准。多年后，IETF[32]在信息RFC 3164“BSD syslog协议”中记录了这种常见的做法。
RFC 5424（“syslog协议”）于2009年标准化，目标是将消息内容与消息传输分离，同时轻松实现每层的可扩展性，并淘汰RFC 3164。它描述syslog消息的标准格式并概述传输映射的概念。它还描述了结构化数据元素用于传输易于解析的结构化信息并允许供应商扩展。然而这些实现没有遵循标准。到今天为止作者只知道一个商业实现案例。
syslog：解释
由于RFC 5424未被行业采用，本小节解释RFC 3164事实上所具有的标准特性。
syslog是一个非常基本的报告机制，由简单的英文文本组成：它不包含IPFIX中的信息元素或SNMP中的变量绑定。syslog消息从syslog代理（受监控的设备）通过UDP以未确认的方式传输到syslog守护进程。syslog标头格式提供了一个过滤字段、“facility”（设施）和一个“level”（级别）字段，标示紧急级别，从7到0（调试：7，信息：6，通知：5，警告：4，错误：3，关键：2，警报：1，紧急情况：0），如图1-7所示。
图1-7 syslog基本模型
syslog：限制
一方面，纯英文文本中的syslog消息内容对开发人员来说是一个优势，因为创建新的syslog消息就像打印US-ASCII字符串一样简单（例如C语言打印功能）。对于能够快速解释可读syslog消息的网络运维人员来说，这也是一个优势。另一方面，英语文本形式自由的内容也是最大的缺陷。除了一些基本的syslog消息（例如linkUp或linkDown）之外，syslog消息内容几乎没有一致性，无法进行自动处理。在某种程度上，如果信息过多，也会阻碍人员的处理。典型的用法是搜索关键词，及时读取围绕关键词的几个条目理解现状。
示例1-4显示了通过网络地址转换（NAT）过载配置，为ICMP ping记录的NAT信息格式。
示例1-4 通过NAT过载配置进行ICMP ping的NAT syslog消息
有四个IP地址/端口对列表，如何确定哪一对代表NAT前和NAT后的处理，或者说内部和外部的IP地址？syslog守护进程不能根据syslog消息内容做任何假设，如果不知道该设备类型的syslog消息惯例，或者仅知道设备厂商的syslog消息惯例，就不可能实现消息处理自动化。