tlv协议格式应用，企业如何搭建一个能满足自己需求的分布式检测系统

关于【tlv协议格式应用】，今天小编给您分享一下，如果对您有所帮助别忘了关注本站哦。

• 内容导航：
• 1、tlv协议格式应用：好文预警：企业如何搭建一个能满足自己需求的分布式检测系统？
• 2、tlv协议格式应用，tlv格式数据解析案例

1、tlv协议格式应用：好文预警：企业如何搭建一个能满足自己需求的分布式检测系统？

一、概述

入侵检测系统（intrusion detection system，简称IDS），它通过实时监视系统和网络等，一旦发现异常情况就发出警告。根据信息来源可分为基于主机的IDS和基于网络的IDS。

本文主要是简单介绍基于主机型入侵检测系统(Host-based Intrusion Detection System，简称HIDS)，提供一种快速实现的分布式HIDS的整体解决方案，对其中关键模块的关键技术进行探讨，提供了多种实现方案，并分析不同方案的优劣，为企业实现满足自己需求的HIDS系统提供参考。

当前，有许多开源的入侵检测系统，如OSSEC、WaZuh、Yulong-hids、AgentSmith-Hids等等，但是这些通用的HIDS不一定能满足企业自身需求。尤其是对于复杂的网络环境和个性化的功能定制需求，设计一套灵活可控的HIDS尤为重要。

入侵检测系统，按照功能主要有日志监控、文件完整性检测、Rootkit、安全基线、进程监控等。对于特征不明显的攻击行为，可以通过行为关联、机器学习等技术手段加强检测。

二、快速实现灵活的分布式入侵检测系统

为保证入侵检测系统的灵活性和稳定性，我们设计整体系统上时尽量保持KISS原则，各模块间尽量避免过于耦合，并且要满足以下几个特性：

• 易扩展、稳定性好
• 功能插件模块化，可以充分利用现有的开源项目
• 个性化规则下发（配置可以精细化单个服务器级别）
• 灾备容错能力
• 升级与回滚

2.1 系统总体架构

在很多时候，网络环境是非常复杂的，不同环境的网络是是无法直接连通的。这些完全或者不完全相互隔离的网络，我们定义为域。一个域可以是一个机房，也可以是多个机房，也可以是同一个机房不同的VLAN。因此，我们在设计系统的时候有必要考虑到整体系统的横向扩展能力。

为解决域的网络连通问题，有两种解决方案：一种是在域中边界部署单独的接入层集群，另外一种是在域上层部署接入层，然后打通各个域到接入层集群的网络。第一种方案，即在不同域中边界处单独部署接入集群，然后打通接入层集群到上层应用的网络。这种解决方案实现不难，但是会带来以下几个较大问题：

• 每个域都需要部署单独接入层集群，考虑到高可靠，至少得部署2台服务器，随着域的增加部署成本会急剧增加。
• 不同域的服务器数量不同的，有的多有的少，会导致接入集群的服务器资源浪费，无法充分有效利用起来。
• 后期开发维护成本很高，每次迭代升级时间成本都很高，极容易出问题。

因此，建议采用第二种方案，在域上层部署统一的接入层集群，然后直接打通各域到接入层网络，该方案可以有效降低部署成本和开发成本。

经过反复的设计推敲，去繁就简，分布式入侵检测系统的总体设计框架如下图1所示：

图1：分布式入侵检测系统总体框架结构图

从上我们可以看出，整体系统架构从下到上主要分为客户端、接入层集群、分析集群、定时任务、WEB管控、离线分析六大模块。客户端是部署运行在业务服务器上，它会收集服务器上的信息上报到接入层，同时也接收执行从接入层下发的命令。接入层主要为客户端提供认证、授权、配置下发、上报数据预处理并推送到KAFKA队列等功能。而分析集群则是从KAFKA队列中消费客户端上报后预处理完之后的数据，利用预设的报警规则对数据进行模式识别，从而发现其中的异常入侵行为。定时任务应用主要是执行一些定时化的功能脚本，比如升级、告警推送、日志审计等等。离线分析模块主要是对数据进行离线分析，找出其中的攻击行为，提取攻击特征，以便更新收集规则和告警规则。

2.2 模块化的Agent

由于Agent是部署在业务的服务器上，因此有必要对其稳定性和资源占用进行严格的控制，并提供一种优雅的升级和回滚方式，避免对业务造成太大的侵扰。Agent的功能模块设计结构如下图2所示：

图2：模块化的Agent结构图

在上图中，Agent采用了模块化的设计，主要分成守护模块、核心插件和普通插件。其中守护进程主要是监控守护常驻核心插件进程和常驻普通插件进程，对于不是常驻进程则不需要守护监控，比如升级回滚插件和脚本库。守护进程和接入层保持一个长TCP连接，主要是发送心跳保持在线状态。

• 核心插件：它是系统必须有的基本插件，主要包含通信交互和升级回滚两个插件。通信交互插件和接入层保持一个TCP长连接，实现发送收集数据和接收执行命令的功能。
• 普通插件：它是常规插件，可启用关闭，它可以和核心插件交互，主要是和通信交互插件通信。

如果从头到尾，重写一个Agent的所有功能，那么开发工作量势必会很高，所以有必要借鉴集成一些开源的数据收集模块或者入侵检测模块。经过慎重的对比分析，我们决定采用OSQuery作为数据采集的基础模块，并将其作为普通插件集成到Agent中，考虑到以后能够顺利升级，尽量少变更OSQuery原生代码，那么个性化的功能需求应该通过新的普通插件模块来实现。

插件化的模块设计，使得的Agent的升级和扩展都非常容易，尤其是插件的替换升级。比如，当OSQuery无法满足现有需求时，需要替换成另外一个组件易盾安全模块时，我们只需要将OSQuery这个普通插件卸载掉，开启易盾安全模块插件即可。

2.3 接入层

接入层是所有的Agent接入的入口，配有内网和外网地址。所有的Agent优先从内网接口接入，如果网络不通则使用外网接口接入，它主要功能如下：

• 提供注册、密钥更新功能。
• 配置信息下发更新配置。
• 提供接受用户指令等功能，并下发到对应的机器中执行，异步返回结果。
• 将收集上报的数据预处理后等推送到KAFKA队列中。
• 处理上传可疑文件，并保存到存储桶中
• 处理心跳、状态报告、处理结果等交互命令

2.4 分析集群

该集群主要是消费由Agent上报的信息，并基于Flink流式计算实现更为复杂的行为分析功能，检测潜在的异常攻击行为，其主要的功能如下：

• 聚合分析上报数据，应用告警规则检测潜在的入侵行为，产生不同级别的警告。
• 安全基线、合规规范
• 将Agent收集的信息（简单处理）推送到HBase中

2.5 通信协议

Agent和接入层的通信协议建议采用TLV格式：T表示数据类型，L表示数据的长度，V表示具体的数据。数据类型可以简单分成对象数据和文件数据两大类。

2.5.1 协议格式

其中数据分成以下对象数据和文件数据两大类：

• 对象数据：

对象数据主要包括控制命令、上报信息、下发配置等等，其格式定义如下：

• 文件数据

文件数据主要是上传可疑的恶意文件，其格式定义如下：

报文头部4个字节用于存放字符#^?#，用于数据错乱后的重新对齐，可以根据结合企业实际情况自定义字节数和魔法字符。

2.5.2 数据压缩

对交互数据的压缩能节省大量的网络带宽，尤其对于文本类的数据，压缩比很高。下图是各种库的压缩比对比图，可以看出snappy算法压缩和解压速率较好，可优先作为数据通信的压缩算法。

2.6 收集规则

一般来说，若Agent收集的信息越多，那么检测出攻击的概率就越大。但是，对于部署了海量服务器的分布式入侵检测系统来说，收集上报太多信息，会消耗大量的网络资源和服务端计算资源；若告警检测全部在Agent来执行，势必会占用业务服务器的资源，严重可能引起业务中断。因此作为折中方案，有必要在Agent端对收集数据进行过滤，只上传比较重要或比较可疑的数据，主要的分析工作放在后端分析集群中。

2.6.1 收集方式

收集规则是在HIDS Agent端执行的规则集合，主要是用来指明收集信息的规则。依赖不同的实现方式，定义和执行方式会存在差异。根据信息收集的方式不同，分为以下四大类：

• 集成第三方模块收集

该收集方式是通过集成第三方模块收集获得的结果，比如OSQuery、OSSEC等。规则的形式依赖于第三方模块，比如OSQuery是SQL为主的json形式，OSSEC是为正则为主的xml形式。

• 脚本收集

该收集方式是通过周期性地执行脚本获得采集信息结果，主要形式为Shell脚本，python脚本、二进制类执行文件等。

• 预定义收集

该收集方式是指Agent自己内置的一些收集插件，不需要在上层配置具体的收集策略，比如Webshell检测等。我们在上层需要开关、或者配置简单的一些参数即可达到收集的目的，比如自动收集web目录，可以预内置代码逻辑，上层不需要配置具体的参数，只需要开启即可；而Webshell检测可能需要配置一些关键词或特征向量等简单的参数即可。

• 被动推送

该收集方式是第三方程序主动地收集数据，接入层被动接收数据的推送，它主要是满足当前的通用收集方式中无法满足特定业务个性化的信息采集需求。为此，业务需要自定义开发（通常需要提供HIDS SDK）相应的功能，然后将收集的信息推送到上层。该种接入方式的特点，是需要业务方接入SDK，或者按照数据的格式要求，自己收集数据，然后HIDS上层被动地接收业务数据的推送。

2.6.2 收集数据

收集的数据格式，是严重依赖于收集方式和收集规则。尤其是收集规则，自由度太大，会导致数据的非结构化以及嵌套化，这对于告警规则和告警规则解析引擎都会带来很大的复杂度，稳定性也将会受到影响，因此有必要对数据的字段做如下的规范限制：

• 字段具有原子性

每条记录的字段是一个原子的基本类型，是不可分解的，不能是一个复合的对象，比如Map，List等。

• 显式指明字段的类型

在收集规则中需要显式指明该规则收集的字段及其类型。接入层对于上报的数据，如果不符合要求的脏数据则直接扔掉。目前支持的字段类型限定为：INT,FLOAT, DOUBLE, STRING, DATE_TIME, CLOG, BLOG。

• 数据项（数据蔟)

由于限定字段都是原子性类型，不可再次拆解。为应对复杂的数据，保证其能降解为简单数据，必须要引入数据项的概念。数据项是同属一类的结构化数据集合，包含了多个不同基本类型字段。在mysql中可以简单理解为表，在HBase可以简单地理解为Family Column。

举个简单的例子：如果一个学校有2个班，一个班有10个人，一个班有20个人，那么如何将班级信息和班级人员收集上来，如果没有前面条件限定，我们可以直接用一个大的json上报所有的信息，那现在的做法将收集信息拆分两个数据项，分别是：

2.6.3 采集数据类别

采集数据的大致分为基线相关数据、日志相关数据、攻击相关数据以及可疑文件四大类。有些分类信息是有交叉的，边界不一定非常棱角分明，比如用户命令和nc反弹shell本身就有交叉的关系，但是由于OSQuery本身就有这些检测功能的sql，所以可以单独拎出来，增加分析数据源。

其中，基线相关数据是指与主机合规加固相关的，主要包含（但不限于）以下数据：

日志相关数据是指与用户或敏感程序的执行结果日志数据的，主要包含（但不限于）以下数据：

攻击相关数据是指用户或敏感程序的执行结果日志数据的，主要包含（但不限于）以下数据：

可疑文件是指可疑黑客攻击所使用文件或者被植入木马病毒的文件，用于确认文件是否恶意，主要包含（但不限于）以下数据：

2.7 告警规则

告警规则，是指针对收集上来的信息进行分析的触发条件，并指明触发规则后的告警信息。

2.7.1 分析数据对象

一个告警的信息，可能需要分析一个或者多个数据对象，才能得到有效的信息，更加规则应用的数据对象可分为如下三类。

• 单数据项

告警的触发规则应用到单数据项，编写容易，解释引擎也比较容易实现。

• 相同收集规则的多个数据项

告警的触发规则，由于空间维度不同，有一定的编写难度，且解释引擎实现有一定的难度。

• 不同收集规则多个数据项

由于不同收集规则的周期不同，时间和空间维度均不同，会导致规则异常复杂，实现解释引擎门槛要求较高。

2.7.2 触发规则

触发规则是指触发条件的表达式、或者一段具有判断分类的脚本。形式上来看，该规则可以是一个boolean型结果的表达式，也可以是一个具有判定分类的复杂脚本。

• 布尔表达式

通常的形式是一个简单表达式语句，执行之后得到一个确定的boolean值。比如，检测可疑文件名的布尔报警表达式语句如下。

比如，可疑文件名检测:

string.contains(filename,"muma") || string.contains(filename,"mimikatz")

表达式的语句形式，是取决于我们所使用的表达式解析库，目前可参考使用有Drools, IKExpression, Aviator和Groovy等。根据使用经验，JAVA推荐使用Aviator，性能最佳。

注意事项：在选择规则解释引擎原型时，必须考虑是否支持自定义函数。有些功能和业务联系比较紧密，不是常规函数所能解决的，比如黑白名单，业务逻辑等。

• 判定分类脚本

判定分类脚本，是指输出结果类型数量大于两种的情况，代码相对比较复杂。比如，我有个判定脚本，判定的结果有三种整数：0表示正常，1表示警告，2表示错误。该脚本编写有一定的难度，需要一定的经验，必须确保所有结果需投影在预设的结果集合中。

• 直接聚合产生告警信息

直接聚合产生告警信息的脚本比较复杂，是直接将规则匹配，告警信息产生全部糅合在一起的复杂脚本。编写较为复杂，不需要额外重量的引擎，全部的业务执行逻辑代码全部有业务方编写的代码完成，对业务方要求一定的编码能力。

• 频次阈值

对于一些可能会存在短暂异常信息，但是很快自动调整回来，并且不会造成业务影响的告警，我们可以启用频次阈值，尽量减少海量告警或误报。比如，网络上有大量的盲扫盲爆破，如果持续时间不超过10分钟，而且没有被爆破入侵成功的话，那么可以就可以忽略掉，因为每天发生这样的攻击次数实在是太多了。

• 告警信息

阈值规则触发条件满足时，则意味着一个异常事件被检测到了。告警信息，则是为了描述该异常事件，并通知给相应的运维和研发人员。

2.8 升级回滚

独立的更新回滚插件是核心插件，在需要升级是才启动，并不是常驻内存插件，主要完成对客户端可执行文件的更新，包括可能的失败回滚。

2.9 离线分析，规则调优

离线分析是安全运维人员通过对离线数据，采用各种辅助工具和过程方法挖掘潜在的攻击行为，尤其是对于蜜罐中的攻击行为所收集的数据分析。通过数据分析，提炼出攻击特征，然后通过离线数据重放统计出召回率和正确率，并将最后总结出的收集规则和相对应的报警规则逐步应用到实践中。

三、戴明环式地安全运维开发

PDCA循环是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及，所以又称戴明环。全面质量管理的思想基础和方法依据就是PDCA循环。PDCA循环的含义是将质量管理分为四个阶段，即计划（Plan）、执行（Do）、检查（Check）、处理（Act）。在质量管理活动中，要求把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，不成功的留待下一循环去解决。这一工作方法是质量管理的基本方法，同样是也适用于入侵检测系统的安全运维工作中。

3.1 计划(PLAN)

我们目标是通过搜集侵者者留下的蛛丝马迹，从而发现黑客的攻击行为，以便安全人员后续响应处理，重点是发现。那么就可以通过以下的方式来发现攻击并提取特征：

• 部署蜜罐，引诱黑客进行攻击，然后提取入侵者的攻击特征
• 通过之前发现的某一阶段的攻击，如下载恶意文件，然后提取出入侵者所有的攻击链路，分析所有的阶段特征。
• 用扫描爆破等入侵辅助工具，去扫描靶机，提取攻击特征
• 开源社区、线上线下沙龙交流等获得攻击特征

3.2 执行（Do）

在制定完计划之后，就按照上述计划实施策略。比如可以在外网不同区域部署多个蜜罐，收集入侵者所有的攻击行为数据，然后对数据进行分析，提取攻击特征。然后，再根据这些攻击特征编写数据收集规则和报警规则，下图是一个条收集规则和一条告警规则的示例：

图3. 收集规则

图4. 报警规则

图5. 报警规则逻辑示例

在完成规则编写后，如果已相应的历史收集数据，则可通过离线分析模块，针对历史数据统计出规则的召回率和正确率，如果出现较大偏差，则继续调整规则。

3.3 检查（Check）

在规则确定之后，则逐步灰度发布到线上，然后把规则触发的报警信息标记哪些是正确的，哪些是误报的，明确效果。对应误报的告警，则需要分析找出原因所在。

图6. 告警信息

图7. 告警邮件

3.4 处理（Act）

对于告警效果较好的规则则保留下来，正式发布到所有服务器上。对于存在较多误报的，则下线，然后进入下一个循环周期，不断地持续改进检测效果。

四、总结

入侵检测系统在实际的运维过程中，会碰到很多稀奇古怪的坑，但随着戴明环式地安全运维，稳定性和检测性能会持续改进。根据目前的运维经验，有以下两个坑需要稍微注意下：

• 文件完整性检测性能瓶颈

当启用了文件完整性检测的功能之后，如果监控的文件较多或者当系统正在更新的时候引起大量文件变化时，会占用很大的资源，如存储服务器（文件多），缓存用户可变化信息（Cookie等），系统更新（文件变化较多）等场景。

• 端口检测瓶颈

当启用了端口检测之后，就会实时检测端口的变化情况。但是当连接数较多时，每次枚举SOCKET时都会比较耗时，影响业务，如Web前端代理服务器，高并发的后端服务器等场景。

安全从来就不是一蹴而就的事情，需要充分地准备+长期的坚持+专业的安全技能+不断地精进，让入侵者无处遁形，切实保证企业的主机安全（文/易盾实验室）。

参考文献

[1]. 入侵检测系统: https://baike.baidu.com/item/入侵检测系统/404710

[2]. 祝亚楠：《入侵检测系统面临的主要问题及其未来发展方向》

[3]. 戴明环:https://baike.baidu.com/item/PDCA循环/5091521

[4]. 企业安全建设之HIDS: https://www.freebuf.com/articles/es/194510.html

[5]. 周健祥：《基于神经网络入侵检测系统的研究与实现》

[6]. 使用osqueryd监控系统:https://blog.spoock.com/2018/11/27/usage-of-osqueryd/

[7]. Phoenix(SQL On HBase):https://www.cnblogs.com/funyoung/p/10249115.html

2、tlv协议格式应用，tlv格式数据解析案例

说明

之前介绍过EIGRP建立邻居的过程，并且介绍了一些特性，这次主要看的是EIGRP的数据包格式，包括TLV，和EIGRP的三张表的内容。

EIGRP的包头字段

1、版本：从EIGRP发布以来，一直为版本22、操作码：指出EIGRP数据包的类型，1为更新 3为查询 4为答复 5为hello和ACK3、标记：包括两个标记，一个为init位，表示新的邻居开始，第二位为接收位，使用一个私有可靠组播算法4、序列号：RTP中使用的32位序列号5、确认序列号（ACK）：本地路由器从邻居路由器那收到最新的序列号，单播传送的6、自主系统号（AS）：指定EIGRP协议所处的标示号，所以，两端都必须一致7、TLV：（1）一般TLV：携带K值和hold time时间，包括序列、软件版本和下一个组播序列（一般用Hello包进行发送）

TLV的类型

在EIGRP中引用TLV的字段，TLV称为 Type/Length/Value ，这个TLV在路由选择协议中有非常好的扩展性，特别是ISIS中，它就是利用TLV字段来扩展支持更多的特性，当一个新的协议或者特性出现，路由协议需要去支持它，像OSPF的话，IPV6的支持就必须开发新的版本了，而ISIS对IPV6的支持，直接用TLV字段就能实现，EIGRP也是如此。

（1）一般TLV：携带K值和hold time时间，包括序列、软件版本和下一个组播序列（一般用Hello包进行发送）

（2）IP内部路由TLV：从同一个AS内学习到的路由参数

1、下一跳：包括这个路由的更新源，如果为0.0.0.0，那么表示自身2、延迟（delay）：以10us为单位，沿途更新入向接口延迟总和3、带宽（bandwidth）：2560 000 000/沿途更新入向接口的最小带宽4、MTU：指路由器沿途抵达目的地路由器上所有链路中最小的MTU，一般不作为metric的参数计算5、跳数：表示到达目的地路由的跳数，最大为255。6、可靠性：用于反映到达目的的路由上接口的出站误码率的总和，取值0x01~0xFF7、负载：用于反映到达目的的路由上接口的出站负载的总和，取值0x01~0xFF8、保留字段：未使用的字段9、前缀长度：携带子网掩码10、目的地址：一个路由的目的地址

（3）IP外部路由TLV：从不同AS或不同路由协议重分布进本AS内的路由参数

1、下一跳：路由的下一跳地址。2、原路由器：一个IP地址，或者重分布外部路由到EIGRP的RID3、原自主系统号：始发路由的路由器所在的AS4、Arbitrary Tag：路由映射 Tag5、外部协议度量：标注外部路由的度量值6、保留字段：不被使用7、外部协议ID：用来标示外部路由从哪个协议学习到。8、标记：定义了两个值，如果为0x01的话，那么表示外部路由，如果是0x02表示缺省路由

EIGRP的五种类型数据包

1、hello ：目标地址为224.0.0.10，用于发现和维持邻居关系。邻居收到后不需要确认,Hello间隔由接口类型决定，低速链路–90s，高速链路–5s。(hello包中包含版本号、Opcode=5、seq、ACK、AS、EIGRP K值，seq和ACK永远为0，AS和EIGRP包括IP包的源地址是检查能否成为邻居的关键）

在Hello包中携带了K值、hold time时间，还包括软件的版本号，Opcode为5，如果两边邻居处于同一网段的话，邻居检查Hello包，还会看K值是否一致，如果不一致，则邻居建立不起来。

K值和软件版本是携带在TLV中传递的，也就是一般TLV字段

2、Update：发送给邻居路由表，通过单播或组播发送update数据包，邻居收到以后必须回复确认信息，如果没有收到来自邻居的确认信息，那么就会单播发送这个跟新包16次，在16次后还没有关于这个邻居的ACK信息，则认为邻居失效。会标明这路由信息属于外部还是内部的，内部的只携带了K值的参数，而外部标明了起源着是谁，还有tag信息。

在update包中，携带了路由信息，可以看到我ip interal route，它就是内部TLV字段，内部TLV的每个路由条目中包含的内容，在TLV字段中介绍了，可以查看数据包看看

可以看到Opcode为1，携带了子网掩码，和5个K值的参数，next hop为0.0.0.0，怎么是自己发送的。

3、Query：当路由信息丢失并没有备用路由时，使用Query数据包向邻居查询，邻居必须回复确认ACK和等待邻居的reply。

可以看到Opcode为3，当一条路由失效，并且没有FS的时候，就会对邻居进行插叙，可以看到192.168.4.0/24标记为目的不可达，这里序列号为46，看下回应的ACK内容

回应了ACK 46，并且是单播回应给10.0.0.2的

4、Reply：是对邻居Query数据包的回复，也需要邻居回复确认。

Opcode为4，reply，它回应的是关于192.168.4.0/24的不可达信息，另外，看下啊 Sequece：57，Acnowledge为48，这个48回应就是之前query，它的序列号为48，这是一种可靠性的表现查看关于回应ACK的信息，因为在收到一个reply后，也需要回应ACK

5、Ack：是对收到的数据包的确认，告诉邻居我已经收到数据包了，收到ACK，不需要对ACK做回复，这样导致死循环 （因为在IP中没有可靠的传输机制，必须依靠EIGRP来完成）

其中hello包中还携带了hold time时间，这个时间是给邻居使用的 ，告诉邻居如果在这个时间内还没收到关于我的任何hello信息的话，那么就认为邻居不存在了。

EIGRP的三张表探讨

地址信息如图，从R1上观看EIGRP的三张表情况，与在A与B之间还有个网段10.1.1.0/24

R1(config)#router eigrp 1R1(config-router)#network 10.1.1.1 0.0.0.0R1(config-router)#network 12.1.1.0 0.0.0.255

R2(config)#router eigrp 1R2(config-router)#network 12.1.1.2 0.0.0.0R2(config-router)#network 23.0.0.0R2(config-router)#network 10.1.1.2 0.0.0.0

R3(config)#router eigrp 1R3(config-router)#network 23.1.1.2 0.0.0.0

这里一定要注意IGP也就是内部协议network的含义匹配上network范围的网段都参路由协议，并且把这个网段宣告出去，也就是说12.1.1.2 0.0.0.0代表精确匹配，这里掩码为反掩码，0代表精确匹配，1代表忽略，就像12.1.1.0 0.0.0.255，它匹配的范围就是，12.1.1不变，因为0代表精确匹配，而255，则为忽略，也就是1~254， 另外不携带反掩码信息的话，那么就是以主类网络宣告

一、邻居表

通过 show ip eigrp neighbos查看邻居状态，包括可以加 detail参数，可以看到更加详细的内容

1、H：代表序列号，邻居的先后建立的顺序

2、address：显示邻居建立的地址信息，EIGRP对于同一个直连路由器建立的邻居，在有多条链路的情况下，会认为是多个邻居存在，就像B一样，同一台路由器，有多条链路，在A看来是不同的邻居存放的

3、interface：自己哪个接口参与建立的邻居关系

4、hold：在对方Hello包中携带的参数，在高速链路上，默认为15，也就是Hello包的3倍，当15s没有收到来自邻居的Hello包后，就认为对方失效 ，当然在正常情况下，每5s收到一个对方的Hello包，也就是hlod不低于10

5、uptime：与邻居建立的时间计时器。

6、SRTT（Smooth Round-Trip Timer）：平均往返时间，用来计算当一个路由器发送EIGRP数据包到邻居，从邻居接收到该数据包并且确认的平均时间。

7、multicast flow tmer：在说RTO之前，介绍个组播流计时器，当一个更新发送出去以后，邻居没有回应，那么这个等待的时间就由组播计时器决定，当计时器超时以后，就切换成单播来再次发送更新给邻居，等待邻居回应的ACK

8、RTO：决定单播传送之间的间隔时间

9、Q：当组播发送了更新后，而对方没有回应ACK的时候，会缓存在本地 ，那么会以单播的形式重新发送这个数据包给邻居，如果16次还没收到ACK，重置邻居

10、 Seq : 收到了邻居更新的次数，每次增加1

这里说下，关于SRTT和RTP是思科私有的算法，所以，没有公开的计算方法，在正常情况下，RTO是ST的6倍，但是，当邻居出现了故障以后，这个参数就会改变，RTO最大值为5000， 另外 在Cisco IOS中，没有可以定义这两个值的命令，卷一也没有提及过。

二、拓扑表

对于EIGRP来说，拓扑表中存在的内容是整个网络收敛的关键，对于EIGRP在网络中部署的关键，就是让每条路由都有可用的FS，关于FS和其他概念在DUAL算法总总结，这里拓扑表只做一个小小的介绍。

show ip eigrp topology来查看参数

可以看到，拓扑表中存放着去往每个目的地的路由信息，这里有FD和AD的概念，这个是DUAL的核心算法，在后面会再次介绍，当有多条路径去往同一个目的地的，当满足了特定的条件后，它也会出现在拓扑表中，这个条件就是FC，这个在DUAL算法的时候进行详细说明。

三、路由表

路由表是存放最优的下一跳的信息，可以看到在拓扑表中去往23.0.0.0/8，经过不同的下一跳到达，在路由表中出现的则只会是最优的，在拓扑表中为FD is 3087200，也就是最优的，下一跳为12.1.1.2。

总结：这次详细讲解了EIGRP的数据包格式，包括TLV中的作用，另外关于拓扑表的详细内容必须到DUAL算法中才好讲解，拓扑表的内容都是通过DUAL算法得来的。

这就是关于《tlv协议格式应用，企业如何搭建一个能满足自己需求的分布式检测系统》的所有内容，希望对您能有所帮助！