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

S-MLAG+EVPN 组网 模拟故障测试

2天前提问
  • 0关注
  • 0收藏,57浏览
粉丝:0人 关注:0人

问题描述:

S-MLAG+EVPN 组网, 客户同一个ES组,客户得服务器双发ARP,模拟端口故障时候发现有如下集中情况正常吗?测试远端只打了一个流 五元组一样,只能哈希到其中一个交换机。ping测试

抓取服务器网卡数据包发现,一条流正常服务器只在其中一个网卡接口到比如eh0

1. 手动shutdown交换机接口,远端ping只有一个包延迟变大了一些没丢包,正常切到到eh1

2. 但是断开服务器eht0端口发现丢了6个包 大概6S切换时间,分析其中3S 因为lacp 短超时 聚合down原因,另外3S是什么原因哈,6S 故障正常吗?

2 个回答
已采纳
粉丝:8人 关注:0人

这是S-MLAG+EVPN组网中典型的故障切换过程。两个场景下的切换表现差异,根源在于故障检测机制不同:前者是设备主动通知,后者是协议超时等待。6秒的切换时间在EVPN场景下属于正常范围


为什么手动shutdown交换机接口几乎不丢包?

当你手动shutdown交换机接口时,这是一个主动通知的过程:

  1. 交换机立即停止转发,并通过LACP协议向服务器发送链路down通知

  2. EVPN控制平面快速反应,BGP立即撤销该VTEP相关的路由并通告新的可达信息

  3. 服务器网卡毫秒级感知,瞬间将流量切换到eth1

整个过程类似“主动让位”,没有等待超时,所以远端ping只看到单个包延迟变大(切换瞬间的缓存抖动),无丢包。



 为什么断开服务器eth0端口丢了6个包?

断开服务器端口时,交换机和服务器都处于“被动等待”状态,6秒由三个阶段构成:

阶段时长原因
LACP超时检测约3秒这是标准LACP短超时时间。服务器网卡停止发送LACPDU后,交换机需要连续3个周期(每个周期1秒)收不到才判定聚合口down
EVPN控制平面收敛约2秒MAC/IP路由撤销需要BGP重新通告,远端设备更新转发表项
远端ARP表项更新与ping探测超时约1秒远端设备需要刷新ARP缓存,同时ping探测本身有超时重传机制

合计约6秒,这正是你抓包观察到的时间。



 两组测试对比总结

对比项shutdown交换机接口断开服务器eth0端口
故障检测方式主动通告(毫秒级)协议超时(秒级)
切换时间< 1秒约6秒
丢包情况几乎无丢包丢6个包
原因设备主动通知,上游同时收敛被动等待LACP超时+控制平面收敛


 关于“另外3秒”的技术细节

你分析的3秒LACP短超时是正确的。另外3秒主要消耗在:

  1. EVPN控制平面收敛(约2秒):BGP需要撤销路由并重新通告,远端设备更新转发表

  2. 远端ARP表项刷新和ICMP超时(约1秒):ping探测本身有1秒超时重传机制,叠加后表现为额外丢包


在EVPN+M-LAG组网中,6秒切换时间属于正常范围,符合业界标准。如果需要进一步优化,可以参考以下方案。

优化建议

优化方向配置方法预期效果
缩短LACP超时已配置短超时(3秒),这是最优值已是最优
启用ARP双发服务器配置主动发送ARP请求,缩短远端感知时间可减少1-2秒
启用MAC/ARP联动刷新升级软件版本或配置联动刷新,避免ARP表项迁移延迟可减少1秒
调整BGP收敛参数调整BGP Hold Time和Keepalive间隔可减少1秒

如果对切换时间有更高要求(如1秒以内),建议采用两端同时检测的方案:

  • 服务器网卡配置链路聚合主备模式 + ARP探测

  • 交换机侧配置BFD联动,加快故障感知

这样可以将切换时间压缩到2-3秒以内。


暂无评论

粉丝:2人 关注:9人

在S-MLAG+EVPN组网中,同一个ES组的服务器双发ARP是正常行为,用于实现多活网关和流量负载分担。

针对您描述的故障切换时间差异,分析如下:

1. 手动shutdown交换机接口:切换快(仅一个ping延迟增大)是正常的。这是因为MLAG的Peer-Link能快速检测到对端接口故障,并通过DF选举和MAC/ARP同步机制,在控制平面快速完成收敛,业务流量几乎无感切换。

2. 断开服务器eth0端口:出现约6秒丢包,这个时间偏长,需要分解排查。

已知的3秒(LACP短超时):您分析正确。服务器网卡与交换机间使用LACP,`fast-period`模式下,链路故障后需要3个Hello报文(默认1秒间隔)未收到才认为超时,聚合口状态变为`Down`,这大约需要3秒。

另外3秒的可能原因(需要结合具体信息排查):
* EVPN Type-1路由收敛:物理口`Down`导致聚合口`Down`,进而触发ES(Ethernet Segment)状态变化。本端交换机需要生成新的EVPN Type-1路由(Ethernet A-D per ES路由,带DF选举属性)并通告给远端,远端PE需要重新计算DF和更新转发表。这个过程如果涉及BGP更新、路由计算和下发,可能产生额外延迟。
* 本地MAC/ARP表项刷新:交换机检测到聚合口`Down`后,需要清除通过该聚合口学习到的MAC和ARP表项,并可能通过Peer-Link从对端交换机重新学习或同步。如果表项数量大,操作可能耗时。
* 流量切换路径:流量需要从故障的交换机(原DF)切换到对端交换机(新DF)。如果对端交换机尚未完成ARP等表项同步,或转发芯片表项未及时更新,会导致流量中断。

排查建议与命令:

1. 确认LACP模式与超时时间:
display link-aggregation verbose interface Bridge-Aggregation X
查看`System Priority`、`Timeout`模式是否为`Fast`。

2. 检查EVPN路由收敛:
* 在Spine或远端PE上,抓取EVPN路由更新:
debugging bgp evpn update
terminal monitor
* 在故障切换时刻,观察Type-1路由的更新和撤回情况,计算时间间隔。

3. 检查DF选举与状态:
display evpn ethernet-segment verbose
查看故障前后,该ES的`DF`、`Candidate List`、`RD`、

暂无评论

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

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

确定

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

注册后可访问此模块

跳转hclhub

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

举报

×

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

侵犯我的权益

×

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

泄露了我的隐私

×

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

侵犯了我企业的权益

×

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

抄袭了我的内容

×

原文链接或出处

诽谤我

×

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

对根叔社区有害的内容

×

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

不规范转载

×

举报说明