LACP几点问答

当前以太产品支持哪几种类型的lag

• Active-standby
• Load-Sharing

---

如何强制将某端口从LAG的selection logic选择中移除

• 通过设置该端口的force out of sync标志，使该端口从select logic逻辑中移除
• 端口处于disable状态
• 端口处于故障状态（SFP-REMOVED，etc.）

---

单条链路是否可以创建lag？为什么

• 可以

---

带内和带外区别

inband和outband

下面中中的解释是针对于通信领域的带内和带外

• 通信中的带内（in-band）一般是指数据和业务报文所走的通道。带内管理也就是指管理通道走的路径其实是和业务报文走的路径是一样
• 带外（out of band）：和业务与数据报文走的不一样的通道，带外管理也就是值管理通道走的路径其实是和业务报文走的路径不一样

---

在负载均衡模式下的lag，能保证OAM报文和业务报文走的是同样的通道么？

• 不能
• 因为在实现负载均衡（load sharing）的时候，我们是通过MAC地址做hash算法来计算所需走的链路的，这样即使是属于同一条flow的报文所走的通道也极有可能是不一样的

---

CFM的哪些告警可以作为LAG的端口故障输入

下面这两种告警可以作为lag的端口故障输入

• loss-of-continuity
• ETH-RDI

一旦检测到了故障，那么故障端口就会从lag的选择逻辑中移除，并且会立即开始重新进行active端口的选择流程

---

使用CFM来触发lag时，对于lag 50ms倒换时间的要求

• 当lag protocol使能且ccm也使能的时候，必须保证50ms的倒换时间
• 当lag protocol没有使能，但是ccm使能的时候，可以不用要求50ms的倒换时间，当然倒换的时间还是越短越好
  

  Marker protocol主要功能是什么

  • 在真正发送业务报文之前通过发送Marker协议报文以验证链路的可靠性，如果发送一个Marker pdu之后收到了Marker response pdu，那么就证明这条链路是可靠的，可以进行业务报文的发送

  ---

  Marker pdu和普通业务报文有什么区别

  • 没有什么区别
  • marker protocol的目的本来就是要验证链路是否可以正常发送业务报文，所以marker报文既没有高的优先级，也没有别的什么特殊字段，它的作用本身就是为了验证链路的可用性

  ---

  Marker protocol是如何触发的

  • Actor的link aggregation 的distribution function向marker protrocol申请在指定链路上发送marker pdu（用于验证链路的可用性）。
  • marker pdu被partner的collecting模块收到，然后partner会响应一个marker response PDU
  • 在底层模块，marker pdu和marker response pdu其实都被当做普通的业务报文

  ---

  Marker协议是否受lag port状态的影响？

  • 不受影响
  • 无论lag port的collecting 和distributing状态是enable还是disable，marker pdu都可以发送出去，也可以被collecting状态是disable的端口收上来

  ---

  Marker protocol是否是lag必选的一个功能

  • marker protocol对于lag来说是一个可选的功能
  • 但是响应marker pdu的marker responder功能是必选的

  • Select logic的主要功能是什么？

    • 使用端口的LAGID（这点是什么意思呢）为端口选择一个合适的Aggregator（注意：不同的Aggregator不会有相同的LAG ID）
    • 一旦LAGID发生变化，端口会马上从对应的Aggregator上detach，即使之后又选择了同样的Aggregator，也必须这样，不这样做的话就很有可能将报文发送到错误的地方

    ---

    aggregation表示什么？

    aggregation有两个意思

    • 为端口选定一个合适的aggregator
    • 将端口attach到该aggregator上

    ---

    端口如何确认是否属于同一个LAG（聚合组）

    当端口的下面几个属性相同时，他们就属于同一个聚合组

    • Actor System ID
    • Actor key
    • Partner System ID
    • Partner key

    ---

    协议规定的选择逻辑正确的行为是怎样的

    • 系统必须支持至少一个Aggregator
    • 每个端口必须被分配一个operational key，如果多个端口需要支持被聚合到一个Aggregator，那么这些端口需要被分配相同的operational key，如果一个端口不支持与别的端口聚合到一起，那么这个端口需要被分配一个unique的operational key
    • 每个Aggregator必须被分配一个operational key
    • 系统中每个Aggregator都必须被分配一个operational key
    • 端口只能选择operational key 相同的Aggregator attach
    • 如果端口属于同一个聚合组（如何判断端口是否属于同一个聚合组，请参见上面的的描述）
    • 设备上直连的（环回的）两个端口不能选择到同一个Aggregator
    • 一旦一个端口选定了相应的Aggregator，那么该端口的selected变量就要被设置为selected或者standby
    • 如果是selected状态，那么mux状态机就开始将这个端口attach到Aggregator
    • 如果是standby状态，那么mux状态机就会将这个端口保持在waiting状态（waiting状态表示该端口已经ready，一旦状态变化为selected，就可以马上attach到Aggregator）
    • selection logic负责计算READY变量的值（根据一系列ready_N变量的值）
    • 当需要重新选择Aggregator的时候，总是先将selected的值修改为unselected，然后再开始重新选择的流程
    • 只有当端口状态变为selected，并且已经成功attach到一个Aggregator后才能够将该端口给mac client使用

    LACP协议有几种报文

    • 只有一种，就是LACPPDU报文

    ---

    LACP协议中哪些角色会发送LACPPDU

    • Actor会主动发送
    • Passive会发送响应报文，但是不会主动发送（slave端在收到actor端的lacp报文后，会根据报文内容决定自己下一步该怎么做）

    ---

    LACP中的Active和Passive

    • LACP协议中的每个端口都有一个LACP_Activity属性，根据这个端口可以确定端口是active端还是passive端
    • Actor会主动发送LACPPDU报文
    • Passive端只有在收到Active端发过来的报文之后才会进行响应，它不会主动发送协议报文（slave端在收到actor端的lacp报文后，会根据报文内容决定自己下一步该怎么做）
    • 周期性的LACP报文发送只有当Actor和Partner的LACP_Activity属性都是Active_LACP的时候才会发生
    • 除了周期性的发送，还有一种情况就是当NTT被置位的时候，需要发送LACPPDU（NTT被置位一般是在Active端的配置发生了变化，或者Active通过收到的Passive端过来的报文的数据发现Passive端关于自己的信息没有更新，也就是发现Active端发现和partner的信息不一致了，那么Active就会置为NTT，让两端再重新进行一次信息交互）

    ---

    LACP协议是否需要重传机制

    • 802.3ad假设LACP协议报文的丢失概率非常低，所以是没有设计其相应的重传机制

    ---

    LACPPDU的各个字段含义

    • 在802.3ad中的43.4.2.2节中已经解释得比较清楚了，不需要在此处过多解释
      

      选择一个LAG

      每个端口都会被LAG上的membership选择，每个membership是由设备上唯一的LAG ID进行标识的

      43.3.7 Selecting a Link Aggregation Group

      Each port is selected for membership in the Link Aggregation Group uniquely identified by the LAG ID (composed of operational information, both derived from local administrative parameters and received through the Link Aggregation Control Protocol). Initial determination of the LAG ID is delayed to allow receipt of such information from a peer Link Aggregation Control entity; in the event such information is not received, locally configured administrative defaults are assumed for the remote port’s operational parameters. Where a particular link is known to be Individual, the complete LAG ID is not required to select the Link Aggregation Group since the link will not be aggregated with any other.

      • 每个端口会被LAG选作其中的一个成员，每个端口只能够属于一个LAG组
      • 一般都要等收到对方的LACP消息获取到对方的一点信息后才能够确认自己的LAGID，为什么？因为LAGID的组成中需要对端的一些信息（系统优先级，系统标示符，关键参数等）
      • 如果没有收到对方的信息，那么就会使用本地的一些默认配置信息进行配置

      ---

      在一个LAG上的协商

      43.3.8 Agreeing on a Link Aggregation Group（协商些什么玩意？）

      Before frames are distributed and collected from a link, both the local Link Aggregation Control entity and its remote peer (if present) need to agree on the Link Aggregation Group. The Link Aggregation Control Protocol allows each of the communicating entities to check their peer’s current understanding of the LAG ID, and facilitates rapid exchange of operational parameters while that understanding differs from their own. The protocol entities monitor their operation and, if agreement is not reached (perhaps due to an implementation failure), management is alerted. The ability of LACP to signal that a particular link is Individual can accelerate the use of the link since, if both Link Aggregation Control entities know that the link is Individual, full agreement on the LAG ID is not necessary.i

      • LAG上的链路在发送和接收数据帧之前，必须将链路上的参数协商一致，本地链路汇聚控制实例和它的远端peer都需要在LAG层面协商一致
      • 链路控制协议允许两个通信实例检查它们双方对LAG ID的理解是否一致（两个通信的实体它们的LAGid应该是需要是一致的）
      • 协议实例监控它们的操作，如果协商没有达成一致（也许是由于实现失败）管理模块需要告警
      • lacp的能力是发现一条特定的链路是独立的能加速链路的使用
      • 如果两个链路控制实例都知道某条链路是独立的，那么完全的LAGID协商就是没有必要的