• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

某局点 MSR3640-X1-HI BFD震荡导致BGP不稳定

2024-05-30 发表
  • 0关注
  • 0收藏 144浏览
付军 五段
粉丝:1人 关注:47人

组网及说明

版本:Version 7.1.064, Release 6749P2102

问题描述

现场反馈MSR路由器 BFD检测超时,导致BGP状态变化,影响MSR和友商设备的邻居建立,需要分析BFD检测超时的原因

过程分析

查看接口无错包,故障时间点左右没有异常日志,从本端的日志看到Diag为1,说明是本端超时导致故障,需要重点排查本端设备运行情况。

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired)

BGP/5/BGP_STATE_CHANGED: 

 BGP.: 10.xxx.xxx.xxx state has changed from ESTABLISHED to IDLE for session down event received from BFD.

BFD/5/BFD_CHANGE_SESS: Sess[XXXX, Interface:XGE0/XXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: Deleted, Diag: 1 (Control Detection Time Expired)

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired)

BGP/5/BGP_STATE_CHANGED: 

 BGP.: 10.xxx.xxx.xxx state has changed from ESTABLISHED to IDLE for session down event received from BFD.

BFD/5/BFD_CHANGE_SESS: Sess[XXXX, Interface:XGE0/XXXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: Deleted, Diag: 1 (Control Detection Time Expired)

BGP/5/BGP_STATE_CHANGED: 

 BGP.: 10.xxx.xxx.xxx state has changed from OPENCONFIRM to ESTABLISHED.

BGP/5/BGP_STATE_CHANGED: 

 BGP.: 10.xxx.xxx.xxx state has changed from OPENCONFIRM to ESTABLISHED.

 

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: DOWN->INIT, Diag: 0 (No Diagnostic)

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: INIT->UP, Diag: 0 (No Diagnostic)

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: DOWN->UP, Diag: 0 (No Diagnostic)

BFD/5/BFD_CHANGE_FSM: Sess[XXXX, Interface:XGE0/XXXX, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired)

 

-------------------------------------------------------------------------------------------------------

 

从诊断信息里看到,两个设备都有后端接收丢包,并且在BFD震荡的时间段也是流量高峰,BFD诊断可能是丢包导致的

MSR1

  ===============inner-port 5 statistics=============== 

PKI_STAT4_STAT0 = 0x000000d1d4476736

PKI_STAT4_STAT1 = 0x00000223c69bd284

PKI_STAT4_STAT2 = 0x0000000000000000

PKI_STAT4_STAT3 = 0x00000000009a9ffb

PKI_STAT4_STAT4 = 0x000000007f2bbc13

 

Ten-GigabitEthernet0/XX

Peak input rate: 72567759 bytes/sec, at 2024-05-27 23:31:36

 Peak output rate: 397379844 bytes/sec, at 2024-04-25 20:06:11

 

Top 10 peak input bit rates: 580542072 bits/sec at 2024-05-27 23:31:36

                              580540152 bits/sec at 2024-05-27 23:31:36

                              580538224 bits/sec at 2024-05-27 23:31:26

                              580536304 bits/sec at 2024-05-27 23:31:26

                              580534376 bits/sec at 2024-05-27 23:31:16

 

MSR2

  ===============inner-port 5 statistics===============  ~

PKI_STAT4_STAT0 = 0x000000c8fd1b90cd

PKI_STAT4_STAT1 = 0x0000cc48e4bdd6b4

PKI_STAT4_STAT2 = 0x0000000000000000

PKI_STAT4_STAT3 = 0x00000000028b12f3

PKI_STAT4_STAT4 = 0x000000021d521de4

 

 

Ten-GigabitEthernet0/XX

Peak input rate: 490599 bytes/sec, at 2024-05-27 23:30:26

 Peak output rate: 630080262 bytes/sec, at 2024-04-17 10:03:48

 

 Top 10 peak input bit rates: 3924792 bits/sec at 2024-05-27 23:30:26

                              3924776 bits/sec at 2024-05-27 23:30:16

                              3924768 bits/sec at 2024-05-27 23:29:56

                              3924760 bits/sec at 2024-05-27 23:29:46

                              3924752 bits/sec at 2024-05-27 23:29:31

                              3806152 bits/sec at 2024-05-27 23:29:31

                              3806144 bits/sec at 2024-05-27 23:29:16

 

设备的接口都是一个CPU后端,所有接口的报文都通过这个通道上送,加起来可能超过单核的接收性能,导致其他接口上送CPU报文丢掉,包括BFD

解决方法

BFD震荡的时间段也是流量高峰,BFD震荡是丢包导致的。

前方如果频繁出现或者不能接受震荡的话,可以配上forwarding policy per-flow enhance看有没有改善。

 

命令手册链接:1.1.1       forwarding policy

1.1.1  forwarding policy

forwarding policy命令用来配置报文负载分担策略。

undo forwarding policy命令用来恢复缺省情况。

【命令】

forwarding policy { per-flow enhance ] | per-packet }

undo forwarding policy

【缺省情况】

采用基于流处理的报文负载分担策略。

【视图】

系统视图

【缺省用户角色】

network-admin

【参数】

per-flow:基于流处理,处理过程保证先进先出。

enhance:增强模式的流处理。配置本参数后,同一条流的入方向、转发和出方向分担到不同的CPU进行处理,从而提升单条流的处理性能。

本参数的支持情况与设备型号有关,请以实际情况为准。

该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作