所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

ME60 V800R010C10SPC500 特性描述 - 广域网接入 01

本文档是ME60 V800R010C10SPC500 特性描述 - 广域网接入
评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
IS-IS Purge溯源

IS-IS Purge溯源

产生原因

IS-IS链路状态报文全网删除导致网络不稳定时,需要尽快定位到问题源头,以便隔离问题源。但是,目前情况下,IS-IS协议本身没有溯源能力,无法快速定位,上述问题出现时通常采用分片隔离的方式,逐步逼近问题节点。问题定位过程复杂,耗时长,对用户网络业务也有影响,IS-IS Purge溯源用于解决上述问题。

IS-IS Purge溯源是华为私有协议。

相关概念

  • PS-PDU:IS-IS的LSP被Purge时,可以通过PS-PDU描述发起Purge节点相关信息。

  • CAP-PDU:IS-IS Purge溯源能力协商报文,用于在IS-IS协议邻居上协商溯源能力。

  • IS-IS Purge溯源协议端口:用于收发IS-IS Purge溯源协议报文的UDP端口号,支持用户配置。

实现原理

IS-IS的Purge LSP在网络中洪泛时,没有携带Purge源信息,当网络中设备故障,产生大量Purge LSP时,难以快速定位故障节点,通常需要逐节点隔离检查才能定位到故障节点,定位过程复杂,耗时长。在IS-IS网络发生LSP被Purge的情况下,网络中的路由存在震荡,甚至路由不可用。需要快速地找出发起Purge的故障设备,将该设备排除,然后恢复网络。

需要解决两个问题:

  • 问题1:在网络路由不可达的情况下,如何获取故障源信息,即谁发起了Purge LSP。

  • 问题2:获取故障源信息的方法要能兼容网络中老设备,能增量部署,且不影响路由功能。

针对问题1,IS-IS Purge溯源采用新的UDP端口,溯源协议报文采用UDP协议报文承载,协议报文中携带被当前设备Purge的IS-IS LSP信息,沿着IS-IS邻居拓扑逐跳洪泛。IS-IS Purge溯源的协议报文洪泛到网络中的其他设备后,在任何一台支持本特性的设备登录后,就可以查看到Purge LSP的设备信息,方便维护人员快速确定网络中的故障节点,并对故障节点进行隔离。

针对问题2,IS-IS Purge溯源依附于现有IS-IS协议沿着IS-IS邻居进行洪泛,但不依赖于现有IS-IS报文传输通道,独立建立新的UPD通道承载报文,因此,对于没有打开相关UDP端口的老设备,不产生任何影响。

能力协商

溯源信息使用UDP传输协议承载该私有协议报文,并侦听UDP端口,用于接收溯源协议报文。当设备和没有溯源能力的设备对接时,需要避免发送溯源报文给相关设备,以免被识别为攻击行为,因此,需要在设备间针对溯源能力进行协商,溯源报文只发送给有溯源能力的设备。同时,具有溯源能力的设备还需要帮助没有溯源能力的设备发送溯源信息,这个也需要根据协商获得的溯源能力来识别。

溯源协议依托于现有IS-IS协议,因此溯源协议的协商也依托于IS-IS邻居进行。当IS-IS邻居建立后,根据邻居中获取的对端接口IP地址,向邻居发起溯源能力协商。

PS-PDU生成

主动Purge一条LSP时,需要生成PS-PDU,并向全部溯源邻居洪泛。

收到不支持溯源能力的邻居Purge LSP时,需要生成PS-PDU,并向全部邻居洪泛;收到多个不支持溯源能力邻居Purge的同一条LSP(LSPID、Seq全相同),只生成一个PS-PDU。

PS-PDU的洪泛采用类似IS-IS协议的洪泛机制进行洪泛。

安全考虑

溯源协议使用UDP报文,需要打开私有端口收发协议报文,因此,需要考虑该端口的安全性问题。

溯源协议也会带来更多的主机收发压力和带宽压力,为了避免溯源协议影响原有协议正常工作,需要对溯源协议的报文收发做一定的控制,减少溯源报文流量,避免影响原油协议。

  • 认证

    溯源协议内嵌在已有的IGP协议中,可以继承已有协议配置参数,使用和原有协议相同的方式对协议报文进行加密认证。

  • GTSM

    GTSM是一种安全协议,通过配置IP报文发送时的TTL值,以及接收时,认为合法的TTL值,对报文进行检测。

    溯源协议报文设计中已经约束全部报文只能洪泛1跳,因此可以默认使用GTSM对报文进行检查。发送时,报文中的TTL设置为255,收到时,如果报文中的TTL不是254就丢弃报文。

  • CPU-CAR

    接口板的NP中可以对上送CPU处理的报文进行检测,控制上送流量,避免大量报文上送CPU,导致主控板超载。

    溯源协议需要申请独立的CAR通道,设置较小CAR值。

典型场景

网络中的所有节点都支持溯源协议

假设网络中的全部节点都支持溯源协议,DeviceA是故障源。该场景下,故障源一定能精确查找到。如图8-25所示:

图8-25 网络中的所有节点都支持溯源协议场景

网络中的全部节点都支持溯源协议,上图中DeviceA是故障源。

当DeviceA purge IGP协议报文时,会同时发布溯源协议报文,溯源协议报文中携带DeviceA的节点信息和DeviceA purge掉的IGP协议报文的概要信息,并且溯源协议报文也会逐跳洪泛到整个网络。当网络出现故障时,维护人员登录网络中的任何一台设备都可以根据溯源协议看到当前DeviceA正在发起大量purge,是故障源。维护人员可以立刻采取措施,将DeviceA从网路中隔离出去,快速回复网络。

网络中有不支持溯源协议的节点,但支持溯源协议的节点不被隔离

假设网络中节点Device C不支持溯源协议,其他节点都支持溯源协议,DeviceA是故障源。该场景下,PS-LSA能够洪泛到整个网络,故障源能够精确查找到。如图8-26所示:

图8-26 网络中有不支持溯源协议的节点,但支持溯源协议的节点不被隔离场景

当DeviceA purge IGP协议报文时,会同时发布溯源协议报文,溯源协议报文中携带DeviceA的节点信息和DeviceA purge掉的IGP协议报文的概要信息,并且溯源协议报文也会逐跳洪泛到整个网络。但是,DeviceC不支持Purge溯源,DeviceB、DeviceE在同DeviceC进行溯源能力协商时,已经发现DeviceC不支持溯源能力。因此,当DeviceB收到DeviceA发来的溯源协议报文时,不会再发给DeviceC了,只会发给DeviceD。IGP协议的purge报文通过DeviceC洪泛到DeviceE时,DeviceE发现DeviceC不支持溯源协议,DeviceE会生成一条溯源协议报文,报文中携带发布源(DeviceE)信息、purge源(DeviceC)、被purge的IGP协议报文信息,也像整个网络进行洪泛。

当网络出现故障时,维护人员登录网络中的任何DeviceC以外的任何一台设备都会发现当前网络中有两个故障源,一个故障源时DeviceA发布的,宣称自己发起了大量的purge,另一个故障源是DeviceE发布的,宣称DeviceC可能发起了大量purge,并且DeviceA和DeviceC都purge了相同的协议报文。在这个情况下认为DeviceA宣称DeviceA purge的优先级比DeviceE宣称DeviceC purge更高,因此将DeviceA定位当前故障源第一优先嫌疑,采取措施,隔离DeviceA。隔离后,网路恢复正常,DeviceC的嫌疑排除。

网络中有不支持溯源协议的节点,但支持溯源协议的节点被隔离

假设网络中DeviceC和DeviceD不支持溯源协议,其他节点都支持溯源协议,DeviceA是故障源。该场景下,PS-LSA不能够洪泛到整个网络,故障源只能在一定范围内查找,不能精确找到。如图8-27所示:

图8-27 网络中有不支持溯源协议的节点,但支持溯源协议的节点被隔离场景

当DeviceA purge IGP协议报文时,会同时发布溯源协议报文,溯源协议报文中携带DeviceA的节点信息和DeviceA purge掉的IGP协议报文的概要信息,并且溯源协议报文也会逐跳洪泛到整个网络。但是,DeviceC、DeviceD不支持Purge溯源,DeviceA发布的溯源协议报文到DeviceB就终结了,无法继续洪泛到网络的其他部分。

DeviceE、DeviceF在同DeviceC、DeviceD进行溯源能力协商时,已经发现DeviceC、DeviceD不支持溯源能力。因此,当DeviceE、DeviceF收到DeviceC、DeviceD发来的溯源协议报文时,会协助DeviceC、DeviceD生成溯源协议报文,并在剩余的网络中进行洪泛。

当网络出现故障时,如果维护人员登录DeviceA、DeviceB,可以立刻发现DeviceA上存在故障,采取措施,隔离DeviceA;隔离后,发现网络已经恢复。如果维护人员登录的时DeviceE、DeviceF、DeviceG、DeviceH中的任何一个时,发现DeviceE、DeviceF同时针对同一个IGP协议报文宣称DeviceC、DeviceD是疑似故障源;维护人员登录DeviceC、DeviceD时,发现DeviceC、DeviceD并没有主动发起purge,DeviceC、DeviceD发给DeviceE、DeviceF的purge报文是从DeviceB来的;维护人员登录DeviceB时,发现DeviceA时故障源,采取措施隔离DeviceA后,网络故障恢复。

翻译
下载文档
更新时间:2019-01-04

文档编号:EDOC1100059511

浏览量:1232

下载量:20

平均得分:
本文档适用于这些产品
相关版本
相关文档
Share
上一页 下一页