当前位置: 首页 > article >正文

M-LAG 技术笔记

M-LAG 简介

M-LAG(Multichassis link aggregation,跨设备链路聚合)将两台物理设备在聚合层面虚拟成一台设备来实现跨设备链路聚合,从而提供设备级冗余保护和流量负载分担。

M-LAG 基础概念

如 图1-1 所示,Device A 与 Device B 形成负载分担,共同进行流量转发,当其中一台设备发生故障时,流量可以快速切换到另一台设备,保证业务的正常运行。
图1-1 M-LAG网络模型示意图

  • M-LAG 接口:与外部设备相连的二层聚合接口。与外部设备上相同聚合组相连的 M-LAG 接口属于同一 M-LAG 组。如图1-1所示,Device A上的二层聚合接口 1 和 Device B 上的二层聚合接口 2 属于同一 M-LAG 组。M-LAG 组中的 M-LAG 接口由多条链路聚合组成,且具有相同的 M-LAG 组编号。

  • peer-link 接口:连接对端 M-LAG 邻居设备用于内部控制的接口。每台 M-LAG 设备只有一个 peer-link 接口。peer-link 接口间的链路为 peer-link 链路,M-LAG 设备通过 peer-link 链路交互协议报文及传输数据流量。一个 M-LAG 系统只有一条 peer-link 链路,peer-link 链路通过运行 DRCP协议 来交互信息。

  • Keepalive 链路:检测 M-LAG 邻居状态。关于 Keepalive 机制的详细描述,请参见 Keepalive 机制。

DRCP 协议

M-LAG 通过在 peer-link 链路上运行 DRCP(Distributed Relay Control Protocol,分布式聚合控制协议)来交互分布式聚合的相关信息,以确定两台设备是否可以组成 M-LAG 系统。运行该协议的设备之间通过互发 DRCPDU(Distributed Relay Control Protocol Data Unit,分布式聚合控制协议数据单元)来交互 M-LAG 的相关信息。

DRCPDU的交互

两端 M-LAG 设备通过 peer-link 链路定期交互 DRCP 报文。当本端 M-LAG 设备收到对端 M-LAG 设备的 DRCP 协商报文后,会判断 DRCP 协商报文中的 M-LAG 系统配置是否和本端相同。如果两端的 M-LAG 系统配置相同,则这两台设备可以组成 M-LAG 系统。

DRCP 超时时间

DRCP 超时时间是指 peer-link 接口或者 M-LAG 接口等待接收 DRCPDU 的超时时间。在 DRCP 超时时间之前,如果本端 peer-link 接口或者 M-LAG 接口未收到来自对端 M-LAG 设备的 DRCPDU,则认为对端 M-LAG 设备 peer-link 接口或者 M-LAG 接口已经失效。

DRCP 超时时间同时也决定了对端 M-LAG 设备发送 DRCPDU 的速率。DRCP 超时有短超时(3秒)和长超时(90秒)两种:

  • 若本端 DRCP 超时时间为短超时,则对端 M-LAG 设备将快速发送 DRCPDU(每1秒发送1个DRCPDU)。

  • 若本端 DRCP 超时时间为长超时,则对端 M-LAG 设备将慢速发送 DRCPDU(每30秒发送1个DRCPDU)

Keepalive 机制

M-LAG 设备间通过 Keepalive 链路检测邻居状态,即通过交互 Keepalive 报文来进行 peer-link 链路故障时的双主检测。

如果在指定时间内,本端 M-LAG 设备收到对端 M-LAG 设备发送的 Keepalive 报文:

  • 如果 peer-link 链路状态为 down,则本端和对端 M-LAG 设备根据收到的 Keepalive 报文选举主从设备,保证 M-LAG 系统中仅一台 M-LAG 设备转发流量,避免两台 M-LAG 设备均升级为主设备。

  • 如果 peer-link 链路状态为 up,则 M-LAG 系统正常工作。

如果在指定时间内,本端 M-LAG 设备未收到对端 M-LAG 设备发送的 Keepalive 报文时:

  • 如果 peer-link 链路状态为 down,则认为对端 M-LAG 设备状态为 down:

    • 本端设备为主设备时,如果本端设备上存在处于 up 状态的 M-LAG 接口,则本端仍为主设备;否则,本端设备角色变为 None 角色。

    • 本端设备为从设备时,则升级为主设备。此后,只要本端设备上存在处于 up 状态的 M-LAG 接口,则保持为主设备,否则本端设备角色变为 None 角色。

    • 当设备为 None 角色时,设备不能收发 Keepalive 报文,Keepalive 链路处于 down 状态。

  • 如果 peer-link 链路状态为 up,则认为 Keepalive 链路状态为 down。此时主从设备正常工作,同时设备打印日志信息,提醒用户检查 Keepalive 链路。

MAD 机制

peer-link 链路故障后,为了防止从设备继续转发流量,M-LAG 提供 MAD(Multi-Active Detection,多Active检测)机制,即在 M-LAG 系统分裂时将设备上部分接口置为 M-LAG MAD DOWN 状态,不允许此类接口转发流量,避免流量错误转发,尽量减少对业务影响。

当 peer-link 链路故障恢复后,为了防止丢包,从设备尽可能在延迟恢复时间内完成表项(MAC 地址表、ARP 表等)同步,其后该设备上处于 M-LAG MAD DOWN 状态的接口将恢复为 up 状态。

MAD DOWN 保持功能

当 peer-link 链路故障,Keepalive 链路正常工作时,主设备正常工作,从设备会自动关闭本设备上除 M-LAG 保留接口外的所有接口,将这些接口置为 M-LAG MAD DOWN 状态。如果此时 Keepalive 链路也发生故障,从设备上的接口会解除 M-LAG MAD DOWN 状态,并升级为主设备,使 M-LAG 系统中的两台设备都作为主设备转发流量,引起网络故障。为了避免以上情况,需要开启 M-LAG MAD DOWN 保持功能,使设备上的接口一直处于 M-LAG MAD DOWN 状态,不参与流量转发。

M-LAG 角色计算

图1-2 M-LAG 角色计算流程图

角色计算触发条件

角色计算触发条件包括:

  • M-LAG 设备在系统初始化时(包括新配置 M-LAG 或带 M-LAG 配置重启设备)。
  • peer-link 链路 UP 时,设备角色通过 peer-link 链路计算。
  • peer-link 链路故障,Keepalive 正常工作,设备角色通过 Keepalive 链路计算。
  • peer-link 链路和 Keepalive 链路均故障,根据本端 M-LAG 设备上 M-LAG 接口状态决定设备角色。
角色计算因素

当通过 peer-link 链路或 Keepalive 链路交互报文计算设备角色时,依次比较如下因素:

  • 比较设备所有M-LAG接口的状态,有可工作M-LAG接口的一端为优;

  • 比较计算前角色,若有一端为Primary,另一端为None,则Primary端优;

  • 比较 M-LAG MAD DOWN 状态,若一端存在处于 M-LAG MAD DOWN 状态的接口,另一端不存在处于 M-LAG MAD DOWN 状态的接口,则不存在处于 M-LAG MAD DOWN 状态的接口的一端优;

  • 比较设备健康状况,健康值越小越优,设备无故障运行时,健康值为0;

  • 比较设备角色优先级,越高越优;

  • 比较设备桥MAC,越小越优。

上述因素按顺序比较,结果为优的一端角色计算为Primary,另一端为Secondary。如果设备通过peer-link链路计算角色,则不比较设备所有M-LAG接口的状态。

M-LAG系统建立及工作过程

图1-3 M-LAG建立及工作过程示意图

如 图1-3 所示,Device A 和 Device B 之间 M-LAG 系统建立及工作过程如下:

  1. 当 M-LAG 设备完成 M-LAG 系统参数配置后,两端设备通过 peer-link 链路定期发送 DRCP 报文。当本端收到对端的 DRCP 协商报文后,会判断 DRCP 协商报文中的 M-LAG 接口编号是否和本端相同。如果两端的 M-LAG 接口编号相同,则这两台设备组成 M-LAG 系统。

  2. 配对成功后,两端设备会确定出主从状态。依次比较两端 M-LAG 设备的初始角色、M-LAG MAD DOWN 状态、设备的健康值、角色优先级、设备桥 MAC,比较结果更优的一端为主设备,具体比较原则请参见“M-LAG角色计算”。主从协商后,M-LAG设备间会进行配置一致性检查。有关一致性检查的详细介绍,请参见“配置一致性检查功能”。

  3. 当主从角色确定后,两端设备通过 Keepalive 链路周期性地发送 Keepalive 报文检测邻居状态。

  4. M-LAG 系统开始工作后,两端设备之间会实时同步对端的信息,例如 MAC 地址表项、ARP 表项等,这样任意一台设备故障都不会影响流量的转发,保证正常的业务不会中断。

M-LAG设备工作模式

M-LAG 设备工作模式分为以下两种:

  • M-LAG 系统工作模式:作为 M-LAG 系统成员设备参与报文转发。
  • 独立工作模式:脱离 M-LAG 系统独立工作,独自转发报文。

当 M-LAG 系统分裂时,为了避免 M-LAG 系统中的两台设备都作为主设备转发流量的情况,需要 M-LAG 设备独立工作。在 peer-link 链路和 Keepalive 链路均处于 DOWN 状态时,从设备会立即或经过一段时间切换到独立运行模式。

M-LAG 设备切换到独立运行模式后,聚合接口发送的 LACP 报文中携带的 M-LAG 系统参数还原为聚合接口的 LACP 系统 MAC 地址和 LACP 系统优先级,使同一 M-LAG 组中的两个聚合接口的 LACP 系统 MAC 地址和 LACP 系统优先级不一致。这样只有一边聚合接口的成员端口可以被选中,通过被选中的设备转发业务流量,避免流量转发异常。

配置一致性检查功能

M-LAG 系统建立过程中会进行配置一致性检查,以确保两端 M-LAG 设备配置匹配,不影响 M-LAG 设备转发报文。M-LAG 设备通过交换各自的配置信息,检查配置是否匹配。目前 M-LAG 支持对两种类型的配置一致性检查:

  • Type 1 类型配置:影响 M-LAG 系统转发的配置。如果 Type 1 类型配置不匹配,则将从设备上 M-LAG 接口置为 down 状态。

  • Type 2 类型配置:仅影响业务模块的配置。如果 Type 2 类型配置不匹配,从设备上 M-LAG 接口依然为 up 状态,不影响 M-LAG 系统正常工作。由 Type 2 类型配置对应的业务模块决定是否关闭该业务功能,其他业务模块不受影响。

为了避免设备 M-LAG 接口震荡,设备会在延迟恢复定时器(缺省为30s)一半时间之后进行配置一致性检查。


http://www.kler.cn/a/397989.html

相关文章:

  • 代码随想录第46期 单调栈
  • Amazon Web Services (AWS)
  • 【第三课】Rust变量与数据类型(二)
  • 移除元素(leetcode 27)
  • Spring Boot 启动时自动配置 RabbitMQ 交换机、队列和绑定关系
  • 黑马嵌入式开发入门模电基础学习笔记
  • linux使用scp和密钥在不同服务器传输文件
  • 校园导航系统
  • Ubuntu问题 -- 当安装使用dpkg命令安装deb包时, 安装失败, 提示缺少依赖 (一行命令搞定)
  • JMeter项目实战
  • 2024山西省网络建设运维第十八届职业院校技能大赛解析答案(7. mariadb 服务)
  • Mysql每日一题(if函数)
  • UE5材质篇 4 材质表面雨滴打落
  • 基于机器学习的虚拟传感器用于门开启检测和异常检测
  • Java基础夯实——1.7 序列化
  • Py之pymupdf:基于langchain框架结合pymupdf库实现输出每个PDF页面的文本内容、元数据等
  • 快速上手STL中list的使用
  • 新日撸java三百行` 新手小白java学习记录 `Day1
  • thinkphp 连表查询
  • 【大数据学习 | flume】flume之常见的sink组件
  • 解析 Android WebChromeClient:提升 WebView 用户体验的关键组件
  • RabbitMQ入门:“Hello World!“ 教程(一)
  • Uniapp踩坑input自动获取焦点ref动态获取实例不可用
  • docker启动训练容器教程
  • html数据类型
  • 【项目设计技巧】客户端SDK的开发