ADDC 6.0控制器未向leaf设备下联服务器聚合组下发以太网服务实例

⚠️ 一句话翻译：不是控制器"下了但没下发成功"，而是控制器压根没打算下——因为你的聚合组在控制器模型里"不存在"。

一、为什么审计发现不了差异（这是 6.0 的机制局限）

• 控制器比设备多的配置（红灯）：控制器有、设备没有 → 点同步会下发下去
• 控制器比设备少的配置（黄灯）：设备有、控制器没有 → 通常是设备侧手动加的
• 控制器与设备不一致的配置：两边都有但参数不同

• 你说的"配置审计控制器没有比设备多的配置" → 说明控制器基线里压根没有这两个聚合口的以太网服务实例
• 设备侧两个聚合口的 service-instance 配置不同，且都未加入 MLAG 接口 → 这些配置不是控制器下发的（否则应该是相同的），大概率是：
  1. 设备底层手动配的，或
  2. 早期某次下发残留下来的，或
  3. 控制器压根没把它们纳入管理模型

二、为什么控制器不下发以太网服务实例

1. 控制器不认为这两个口是"双归接入的统一逻辑口"
   • MLAG 的核心目的是让两台 Leaf 对下联服务器呈现为"一台逻辑设备"
   • 只有加入 MLAG 接口后，控制器才会对跨设备聚合组生成统一的以太网服务实例
   • 你这两个聚合组是独立的、未加入 MLAG，控制器没有触发 service-instance 下发 logic
2. 两个聚合组的 service-instance 配置不同是必然结果
   • 因为没有统一的 MLAG 模型驱动，两台 Leaf 各自的聚合口只能拿到各自本地生成的、或不完整的 service-instance
   • 表现出来就是"配置不同"
3. ADDC 6.0 对 MLAG 下联口的自动化程度有限
   • 据 H3C 知了社区确认："一般需要手动创建 M-LAG 然后通过 ADDC 纳管配置其他功能"​
   • 也就是说，MLAG 基础配置本身就需要先手动建好，控制器才能在其上叠加业务配置
   • 如果你的 MLAG 没建好/没建对，控制器上层的 service-instance 自然不会下发

三、根因总结（按概率排序）

四、排查与解决步骤

🎯 第一步：确认 MLAG 接口状态

🎯 第二步：在控制器上检查跨设备聚合组模型

• 资源 → 设备管理 → 设备列表 → 找到对应 Leaf
• 检查跨设备聚合组是否已创建
• 如果未创建 → 按 H3C 建议手动创建 MLAG 基础配置，再由控制器纳管​

1. 两台 Leaf 上手动建立 MLAG 域、Peer-link、Keepalive
2. 将下联服务器的两个聚合组加入 MLAG 接口
3. 在控制器上创建跨设备聚合组，关联到这两台 Leaf 的聚合口
4. 触发控制器重新下发业务配置

🎯 第三步：将聚合口加入"Leaf 下行口接口组"

• 控制组件页面 → 自动化 → 园区网络（或数据中心网络）→ 网络设备 → 通用策略组
• 找到 Leaf 下行口接口组
• 将两个下联聚合口加入接口组
• 如果已在接口组里 → 先移除、再重新添加，触发配置重新下发

🎯 第四步：检查控制器南向下发历史

🎯 第五步：版本配套核查

• ADDC E7303 控制器对应 S9850 推荐 Release 6715 之后版本（如 6715P01/P02）
• 早期 6715 版本存在 service-instance 下发失败的已知问题

🎯 第六步：应急 workaround（不推荐长期使用）

1. 设备侧配置控制器不知道，审计会继续显示差异或黄灯
2. 后续控制器做任何平滑同步，可能 undo 掉这些手动配置

⚠️ 所以手动补配置只是应急，根治必须回到控制器模型修正。

五、给你的行动建议

1. display m-lag summary 确认两个下联聚合组是否在 MLAG 接口里
2. display configuration delivery history 确认控制器是否曾对这两个口下发过 service-instance
3. 在控制器上检查"跨设备聚合组"是否已创建

1. 如果 MLAG 没建 → 按标准流程手动创建 MLAG 基础配置
2. 在控制器上创建跨设备聚合组，关联两台 Leaf 的下联口
3. 将聚合口加入 Leaf 下行口接口组，移除重加触发重新下发​
4. 验证：两台 Leaf 的 service-instance 配置一致，且 display configuration delivery history 能看到下发记录

• 如果你们是 ADDC 6.0 早期版本，强烈建议升级到 6.3 或以上——6.3 以后支持"设备比控制器多的配置加入审计白名单" ，能避免这类审计盲区
• 版本升级前务必查官方配套表，确认 Leaf 交换机版本匹配

📌 核心认知：ADDC 是"控制器单向下发"架构 ，控制器只下发它"知道"的配置。你的两个下联聚合组未加入 MLAG 接口 → 控制器模型里没有这两个口的完整业务模型 → 不会生成 service-instance → 不下发 → 审计无差异（因为控制器基线里本来就没有）。这不是 Bug，是模型缺失导致的"沉默"。

解决的关键是：先把 MLAG 基础架构搭对，让控制器"看见"这两个口是一个双归逻辑口，service-instance 自然会下发，且两台 Leaf 配置会保持一致。

建议联系400排查。
可能的问题排查方向如下：
在聚合口没有加入MLAG接口的情况下，控制器只根据vport上线的聚合接口下发配置，不会在一组m-lag接入交换机的两个聚合口都下发配置。

ADDC6.0 层次化端口绑定故障：双归服务器两端聚合口以太网服务实例不一致，配置审计无差异
现象总结
Leaf 一对 M‑LAG 双归组网，服务器侧双链路聚合，两台 Leaf 各自创建独立 Bridge‑Aggregation，没有配置port m‑lag group X，聚合口没有加入 M‑LAG 组；
两台 Leaf 上对应聚合口下以太网服务实例（AC/vtep access port、VSI 绑定）配置不一致；
ADDC 控制器健康检查、配置审计均没有报差异，控制器上看不到配置缺失告警；控制器没有多余配置，审计对比无差异项。
关键点：ADDC 层次化端口绑定模型下，没有纳入 M‑LAG 组的聚合接口，控制器审计逻辑不会对两台 Leaf 上的对应聚合口做对等一致性校验。审计只校验：控制器存储模型 vs 单台设备本地配置，不会跨设备比对 M‑LAG 对端 Leaf 的业务实例配置，因此审计不输出差异，但是实际两台设备业务配置不一致。
根本原因
组网模型错误：服务器双归聚合口没有配置 M‑LAG 组
服务器双归接入 M‑LAG 一对 Leaf，服务器侧做 LACP 聚合；Leaf 侧两个 Bridge‑Aggregation 必须配置port m‑lag group X，把聚合接口纳入 M‑LAG 域。
当前环境：Leaf‑A、Leaf‑B 各自独立创建 Bridge‑Agg，没有 port m‑lag group，属于两台独立普通聚合，不是 M‑LAG 跨设备聚合。
ADDC 层次化端口绑定识别为两台设备上两个完全独立的普通聚合接口，控制器不会做跨设备的业务实例一致性校验；控制器审计只做 “控制器模型 ↔ 单台设备” 比对，不做 LeafA 聚合口 ↔ LeafB 聚合口的对等比对，所以审计看不到差异，但是实际转发配置不一致。
接口对象数据库状态不同步（控制器侧）
其中一台 Leaf 的聚合口，层次化端口绑定对象实例下发成功；另一台下发失败 / 部分下发；
但是 NEM 审计模块只分别对比每台设备自身，没有跨设备对等校验，不会生成审计差异记录；
控制器页面看端口绑定对象是正常绑定，但是实际一台设备完整下发以太网服务实例，另一台缺失 / 部分下发，形成两边配置不一致。
精细平滑依赖约束触发部分下发失败
存在接口依赖关系，其中一台 Leaf 聚合口下发以太网服务实例时触发Settings dependent on other settings cannot be synchronized separately，部分配置下发中止；该类内部平滑失败不一定会生成审计差异告警，只会在 SeerEngine‑DC 内部日志记录，界面健康检查不展示。
历史残留设备本地配置干扰
某台 Leaf 聚合口下存在设备本地手动残留的 vtep access port / 以太网服务实例配置；控制器审计白名单机制，将部分实例配置过滤，审计对比无差异，但实际两边实例配置不一样。
现场定位排查步骤
1、确认设备侧接口 M‑LAG 归属
bash
#两台leaf分别执行
display interface Bridge‑Aggregation X
#查看输出是否包含 port m‑lag group xx
display m‑lag summary
现象：聚合接口下没有port m‑lag group输出，就是问题点。
2、查看 SeerEngine‑DC 控制器日志（关键，界面看不到）
导出控制器 NEM 组件日志，检索关键字：
Settings dependent on other settings cannot be synchronized separately、NEM_VSIINFO_INCONSISTENT、Fine‑grained synchronization
会发现其中一台 leaf 聚合口以太网服务实例精细平滑没有完整下发，界面审计不体现。
3、设备侧比对两个聚合口完整业务配置
bash
display current‑configuration interface Bridge‑Agg X
#重点比对：vtep access port、ethernet‑service‑instance、vsi绑定
确认一边完整生成以太网服务实例，另一边缺失部分实例。
修复方案
方案 1：修正组网模型（根治，推荐）
在 ADDC 控制器层次化端口绑定，修改双归服务器接入模型：将两台 Leaf 的聚合接口加入同一个 M‑LAG 组；
控制器重新下发配置，控制器会对 M‑LAG 组内接口强制做对等校验，保证两台 Leaf 聚合口以太网服务实例完全一致；
重新执行设备同步，完成后再审计。
⚠️不要在设备 CLI 手动敲port m‑lag group，必须 ADDC 控制器层次化端口绑定页面完成，否则控制器数据库模型和设备配置不一致，后续会再次发生异常。
方案 2：临时恢复（不能根治，仅应急）
在控制器删除该层次化端口绑定对象；
两台 leaf 设备对应聚合口执行 default，清空接口下所有以太网服务实例、vtep access port 残留配置；
控制器重新创建层次化端口绑定，必须把两个聚合接口归属同一个 M‑LAG 组，再下发配置。
方案 3：如果不能修改 M‑LAG 模型（特殊约束）
不推荐，这是不标准的 ADDC VXLAN 接入模型。
因为是两个独立普通聚合，控制器不会做跨设备一致性校验；需要人工保障两边实例配置完全一致；每次变更业务 VLAN，两台 leaf 要分别校验接口下以太网服务实例是否全部生成。
版本提示
ADDC6.0 早期版本，非 M‑LAG 模式下双归接入，层次化端口绑定不会执行跨设备配置对等校验，审计不会上报该类跨设备差异，属于已知约束；建议升级到对应最新补丁版本。
避坑重点
服务器 LACP 双归接入 M‑LAG Leaf，Leaf 侧聚合接口必须纳入 M‑LAG 组，不能两边独立普通聚合；
配置审计只做【控制器模型 vs 单台设备】，不会自动比对 M‑LAG 对端 leaf 的接口配置；
精细平滑内部依赖报错，很多场景不会在 Web 界面告警，必须看控制器后台 NEM 日志。