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

S6800 M-LAG问题

2026-06-04提问
  • 0关注
  • 0收藏,179浏览
席宸 三段
粉丝:2人 关注:10人

问题描述:

mmexport1780565547699.png
如图所示
核心用采用mlag(双活网关配置),既两台设备的互联地址和MAC一模一样。
核心交换机之间有peerlink,有keep a alive,有互联三层ospf
向下采用二层聚合口互联(透传vlan)
加入核心上配置vlan11:1.1.1.1/30
接入配置vlan11 1.1.1.2/30
接入到核心采用链路聚合(动态lacp),且配置OSPF路由
现象:邻居full以后,在核心1上显示full,核心2上显示init
(我认为这是合理状态),当断开核心1下联的链路,接入上的邻居消失,此时核心1上依然显示full,需要等10s左右日志显示down邻居才会消失,核心2依然是init 
.此状态应该不合适吧,不应该是full状态吗?

组网及组网描述:

最佳答案

粉丝:16人 关注:2人

S6800 M-LAG + 接入 LACP 聚合 + OSPF 故障根因 + 整改配置

先结论:当前现象不正常,故障根源:M-LAG 双机同网关 IP + 下联二层透传,OSPF 单邻居卡在一台 Full、一台 Init;断主设备下联后 OSPF 老化 10s 才断邻居

组网梳理

  1. 两台 S6800 做 M-LAG,Peer-link+Keepalive,M-LAG 双设备 Vlanif11 共用 IP:1.1.1.1/30(M-LAG 虚网关)
  2. 接入交换机 LACP 静态聚合→M-LAG 聚合组(二层口、透传 VLAN11,无三层子接口)
  3. 接入 Vlanif11:1.1.1.2/30,OSPF 基于 VLAN11 三层网段建立邻居
  4. 异常:
    • SW-M1:OSPF 邻居 FULL;SW-M2:OSPF 邻居永远 INIT
    • 断开 M1 下联聚合:接入 OSPF 邻居直接消失,M1 邻居 10s 后 Dead 超时 Down,M2 仍 INIT

根因详解

  1. M-LAG 是二层多活,三层网关虚拟化在 M1 主设备
    M-LAG 同 IP 网关实际流量收发主控在 M-LAG 主设备,接入 OSPF 报文所有收发全部送到 M1,M2 收不到 OSPF Hello 报文 → M2 无法完成邻居协商,永久 INIT。
OSPF 邻居建立必需双向收发 Hello,M2 收不到接入 Hello,停留在 Init。
  1. 断 M1 下联链路,接入断网、OSPF 邻居消失,但 M1OSPF 进程无直连链路 Down 事件
    OSPF 靠 Dead 计时器(默认 10s/40s)老化邻居,不是接口物理 Down 立即删除,所以 M1 等 40s(默认 dead=4*hello)才 DOWN 邻居。
接入端下联断,接入 Vlanif11 协议 Down→接入 OSPF 删邻居;但 M 侧 M-LAG 是二层链路,M1 的 Vlanif11 物理 / 协议 UP 不变,只能等待 OSPF dead 超时。
  1. 错误点:OSPF 不能跑在 M-LAG 共用三层 VLANIF 网段
    M-LAG 虚 IP 只做终端网关,不能跨 M-LAG 双机和下联设备建立 OSPF 邻居,这是 M-LAG 经典误区。

两套标准整改方案(二选一,现场常用方案 1)

方案 1(推荐:下联改成三层互联,放弃 M-LAG 二层透传,接入分两条三层链路分别连两台核心)

  1. 核心侧:取消 M-LAG 聚合,拆成两个独立三层口,分别配置不同网段
plaintext
#M-LAG主SW1 interface Gigabit 1/0/1 port link-mode route ip address 10.0.1.1 255.255.255.252 #M-LAG备SW2 interface Gigabit 2/0/1 port link-mode route ip address 10.0.1.5 255.255.255.252
  1. 接入交换机两条上联分别对接两台核心三层口,分别配置对端 IP,OSPF 建立两条邻居
效果:两台核心 OSPF 都是 FULL,单条链路 Down 立刻接口 Down,OSPF 邻居瞬间删除,不依赖 dead 计时器。

方案 2(保留 M-LAG 二层聚合透传 VLAN,OSPF 剥离 M-LAG 网段,核心之间 OSPF、接入静态路由)

  1. Vlanif11 1.1.1.1/30 继续做 M-LAG 用户网关,此网段不再跑 OSPF
  2. 核心两台设备单独起三层互联口 / 单独 Loopback,核心之间 OSPF;接入配置静态默认路由 1.1.1.1指向 M-LAG 网关,取消接入侧 OSPF
适用:接入为接入层,不需要发布明细路由,仅默认路由上网。

如必须保留现有二层 M-LAG + 接入 OSPF(折中不推荐,临时过渡)

在两台核心额外新建独立 Loopback 互联网段,接入起 Loopback,OSPF 基于 Loopback 建邻居,M-LAG 业务网段只做网关,不参与 OSPF 组网。

补充优化:解决断链路后 OSPF 延时删邻居

  1. 三层互联场景:ospf timer dead 5 缩短 dead 时间;
  2. 二层 M-LAG 场景无解,只能改三层互联实现接口 UP/Down 联动 OSPF 邻居。

补充知识点

M-LAG 设计规范:

  1. 终端、接入二层设备:通过 M-LAG 接入,网关用 M-LAG 共享 IP(正确)
  2. 三层路由设备(需要 OSPF/BGP 建邻居):禁止接入 M-LAG 聚合组,必须分别独立上联两台核心三层口(强制规范)

豆包???

席宸 发表时间:2026-06-05 更多>>

豆包???

席宸 发表时间:2026-06-05
3 个回答
粉丝:5人 关注:14人

核心2显示INIT:这不是合理状态,确认Peer-Link允许传输OSPF协议报文所需的VLAN,。可以在核心看上debug ospf看下报文交互是否完成

M-LAG两台设备一边是OSPF 一边不可能建立OSPF邻居的,要么就是啥也没有

席宸 发表时间:2026-06-05 更多>>

M-LAG两台设备一边是OSPF 一边不可能建立OSPF邻居的,要么就是啥也没有

席宸 发表时间:2026-06-05
粉丝:22人 关注:1人

您好!您遇到的现象在 M-LAG 组网中非常典型,但这并不是一个合理的状态
在标准的 M-LAG(双活网关)设计中,两台核心交换机通过 Peer-Link 和 Keepalive 链路形成了一个逻辑上的“单台设备”。因此,下联接入交换机与这两台核心交换机建立的 OSPF 邻居关系,必须在两台核心设备上同时保持 Full 状态。如果核心2上一直显示 Init,说明 OSPF 控制面报文没有正常同步或交互。
针对您描述的故障现象,以下是深度的原因分析及排查建议:

一、 为什么会出现此异常?

  1. OSPF 网络类型配置不当:当核心侧采用 M-LAG 虚拟化网关时,两台核心共享同一个 IP 地址和 MAC 地址。如果互联接口使用的是默认的 Broadcast(广播)类型,OSPF 会进行 DR/BDR 选举,这在 M-LAG 切换或 LACP 负载分担时极易导致邻居状态震荡甚至无法建立 Full 状态。
  2. Keepalive 或 Peer-Link 状态异常:M-LAG 依赖这两条链路进行状态同步。如果它们存在隐患,可能导致双机之间无法正确协商角色或同步路由表项。
  3. MTU 不匹配:OSPF 邻居卡在 Init 或 Exstart 状态的一个经典原因是两端接口的 MTU 值不一致,导致 DD 报文无法正常交换。

二、 核心排查步骤

1. 检查并修改 OSPF 网络类型(关键)

强烈建议在 M-LAG 核心侧与接入侧的三层互联接口上,将 OSPF 网络类型强制指定为 P2P(点对点)。这可以避免 DR/BDR 选举带来的复杂性,简化邻居关系,加速收敛。
1[Core-Switch] interface Vlan-interface 11 2[Core-Switch-Vlan-interface11] ospf network-type p2p
注:接入交换机对应的物理接口或 VLANIF 接口也需做相同配置。

2. 验证 M-LAG 底层状态

确保 M-LAG 系统层面的参数完全一致且链路正常:
  • 执行 display m-lag brief,确认两台核心的 M-LAG 状态是否为 Active/Standby,Peer-link 是否正常 UP。
  • 检查 Keepalive 链路是否独立于业务流量,且报文收发计数是否在持续增长。
  • 核对两端的 system-mac、域 ID 等核心参数是否绝对一致。

3. 排查 MTU 与连通性

  • 在核心1和核心2的 Vlan-interface 11 下分别测试到接入端 IP (1.1.1.2) 的大包 Ping 测试:ping -s 1500 1.1.1.2。如果不通,请检查沿途链路的 MTU 设置,或在 OSPF 接口下启用 MTU 检查功能(ospf mtu-enable)并确保两端 MTU 相等。

4. 开启 OSPF Debug 抓包分析

如果上述配置调整后依然卡在 Init,请在核心2上开启 Hello 报文调试开关,观察是否能收到来自接入交换机的 Hello 包:
1<HUAWEI> debugging ospf 1 packet hello interface Vlan-interface 11 2<HUAWEI> terminal monitor 3<HUAWEI> terminal debugging
如果没有 RECV Packet 打印,说明控制面报文被拦截或未到达;如果有接收但状态不变化,则重点排查 Router-ID 冲突或认证参数。


 架构优化建议(防坑指南)

在您当前的拓扑中,核心层使用 M-LAG 虚拟出一个网关,而向下透传 VLAN 并在接入层运行 OSPF。这种设计虽然可行,但在实际运维中容易引发复杂的选路和邻居问题。
更优的业界最佳实践是
让核心交换机直接作为三层网关(即在 M-LAG 核心侧创建相同的 VLANIF 接口并配置相同的 IP/MAC),核心与防火墙或上层路由器之间直接运行 OSPF。接入层仅作为二层转发节点(透传 VLAN),不在接入层运行 OSPF。这样可以利用 OSFP 自身的 Cost 机制和 M-LAG 的负载分担能力,彻底规避跨设备聚合带来的 OSPF 邻居状态不一致问题。

下联接入交换机与这两台核心交换机建立的 OSPF 邻居关系,必须在两台核心设备上同时保持 Full 状态 来个完整配置看看

席宸 发表时间:2026-06-05 更多>>

下联接入交换机与这两台核心交换机建立的 OSPF 邻居关系,必须在两台核心设备上同时保持 Full 状态 来个完整配置看看

席宸 发表时间:2026-06-05
粉丝:4人 关注:3人

缺少配置,在mlag 双活网关场景要运行ospf,需要配置mlag 虚IP。

#DeviceA

interface Vlan-interface102

 ip address 10.102.0.1 255.255.255.0

 ospf 1 area 0.0.0.0

 ospf peer sub-address enable 10.102.0.3

 ospfv3 1 area 0.0.0.0

 port m-lag virtual-ip 10.102.0.3 255.255.255.0 active

 port m-lag ipv6 virtual-ip FE80::2 link-local

 mac-address 0003-0003-0003

 ipv6 address 10:102::1/64

#

#Device B

interface Vlan-interface102

 ip address 10.102.0.1 255.255.255.0

 ospf 1 area 0.0.0.0

 ospf peer sub-address enable 10.102.0.4

 ospfv3 1 area 0.0.0.0

 port m-lag virtual-ip 10.102.0.4 255.255.255.0 active

 port m-lag ipv6 virtual-ip FE80::4 link-local

 mac-address 0003-0003-0003

 ipv6 address 10:102::1/64

#

参考:https://www.h3c.com/cn/d_202601/2739626_30005_0.htm

官配我知道 我要的是特殊情况下的

席宸 发表时间:2026-06-13 更多>>

这个是官方文档配置哈

席宸 发表时间:2026-06-05
回复席宸:

啥玩意,不是我答对的吗?

越ping越开心 发表时间:2026-06-11

官配我知道 我要的是特殊情况下的

席宸 发表时间:2026-06-13

编辑答案

你正在编辑答案

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

分享扩散:

提出建议

    +

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

确定

亲~检测到您登陆的账号未在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. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

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

不规范转载

×

举报说明