F1000-AI-90 IRF冗余口是否要为真实业务口

问题一：IRF主备模式下，是否一定要配置冗余口？

结论：是的，在F1000-AI-90上配置IRF主备模式，必须通过冗余口（Reth接口）或物理口冗余组（node-member）来确保业务流量“不跨框”。

• 核心原因：SSL VPN 流量不支持跨框处理。也就是说，用户拨入SSL VPN后，其流量进、出防火墙的物理接口必须在同一台物理设备上。IRF主备模式本身只是管理层面的角色，如果不使用冗余口将流量“钉”在主设备上，流量很可能被负载均衡或错误地分发到备设备，导致业务不通。

• 冗余组的作用：通过配置冗余组，将主设备的接口（物理口或聚合口）加入node 1并设置更高优先级，将备设备的对应接口加入node 2。这样，正常情况下只有主设备的接口处于活跃（Active）状态，备设备的接口处于待命（Standby）状态，彻底杜绝流量跨框的可能。

问题二：冗余口（Reth）里加三层聚合口导致网络不通的原因

结论：在IRF主备模式下，标准的配置方法是冗余口里不加聚合口，而是加“聚合口的成员物理口”，并为聚合口本身配置link-aggregation selected-port maximum 1。

你遇到“添加十几业务三层聚合口后不通”的问题，根源在于配置逻辑错误，而非网络架构本身有问题。

正确的配置逻辑是这样的：

1. 定义聚合口，并强制主备：创建一个三层聚合口（例如 Route-Aggregation 1），并配置 link-aggregation selected-port maximum 1。这条命令强制该聚合口在任何时候最多只选中一个成员端口，从而实现该聚合口内部的主备。同时，通过调整成员端口的 port-priority 来决定谁是主（优先级值越小越优）。

   text

   interface Route-Aggregation1 ip address 10.1.1.1 24 link-aggregation selected-port maximum 1 # 关键：强制聚合口主备 quit # 在主设备上的物理口（例如1/0/1），设置更高优先级（数值小） interface GigabitEthernet1/0/1 port link-aggregation group 1 link-aggregation port-priority 10 quit # 在备设备上的物理口（例如2/0/1），设置更低优先级（数值大） interface GigabitEthernet2/0/1 port link-aggregation group 1 link-aggregation port-priority 100 quit

2. 冗余组里加物理口，而非聚合口：在冗余组的 node 1 里，添加主设备上的物理成员口（如 GigabitEthernet1/0/1），而不是添加 Route-Aggregation 1。同样地，在 node 2 里添加备设备上的物理成员口（如 GigabitEthernet2/0/1）。

   text

   redundancy group 1 node 1 bind slot 1 priority 100 node-member interface gigabitethernet 1/0/1 # 加物理口 ... node 2 bind slot 2 priority 50 node-member interface gigabitethernet 2/0/1 # 加物理口 ...

你当前的配置错误在于：直接将三层聚合口加入冗余组，这违反了冗余口（Reth）的定义规则。冗余口本身就是一种虚拟接口，其成员必须是物理口或子接口，不能再包含一个聚合口。这种错误叠加导致了网络协议计算混乱，从而不通。

总结与建议

1. 修复方案：请按照上述“正确配置逻辑”，重新梳理并修改你的配置。核心就是两条命令：在聚合口下配置 link-aggregation selected-port maximum 1，在冗余组里添加对应的物理成员口。

2. 版本与兼容性：值得注意的是，有官方文档明确指出 F1000-AI-90 不支持 IRF 功能。这与你的实际组网（客户正在使用）存在直接矛盾。这是一个非常严重的关键信息冲突。

3. 关键行动项：

   • 立即与H3C官方400技术支持确认：告知他们你的设备型号（F1000-AI-90）和当前运行的软件版本（R9960），确认该型号在此版本上是否正式支持IRF功能，以及是否存在特殊限制。

   • 考虑备选方案：如果官方确认不支持或存在严重限制（特别是对SSL VPN的影响），你需要和客户、售前团队紧急沟通，评估是否弃用IRF，改用更成熟、功能无限制的RBM（Remote Backup，远程备份）双机热备方案。

你提供的故障现象和配置方式，完美印证了SSL VPN流量“跨框”导致业务不通的判断。上面的配置逻辑如果能理解，修复起来就没问题。另外，关于 F1000-AI-90 不支持 IRF 这个信息与你的现网组网矛盾

结合你遇到的“SSL VPN访问异常”和“添加三层聚合口后网络不通”的现象来看，问题的根本原因在于网络架构和业务要求的错配：当前的IRF组网是为“双主”模式设计的，但SSL VPN业务强制要求“主备”模式，从而引发了这一系列故障。

 SSL VPN 跨框问题的本质

SSL VPN这类应用，不仅要求所有流量从主墙进出，更要求防火墙上的业务会话也绑定在主设备上，不支持跨设备处理。一旦流量偶然跑到备墙，会话就会中断，这正是你遇到的故障原因。

因此，必须为这台防火墙配置冗余组和专用的冗余口，以“锚定”业务流量并可靠触发主备切换。

 两种解决方案

根据你的环境，有两种可行的解决方案，整体建议采用方案一。

方案配置思路如下：

 方案一：架构整改为“标准主备” (推荐)

步骤1: 准备专用冗余口
冗余口必须是独占的二层物理接口，绝对不能是聚合口或逻辑口。你需要拿出两台防火墙各一个空闲物理口直连，专用于冗余口。

步骤2: 修改业务聚合为单框模式

1. 定义聚合口并强制主备：在现有的三层聚合口（Route-Aggregation）上配置 link-aggregation selected-port maximum 1，使其在任何时候仅选中一个成员端口。

2. 调整成员端口优先级：通过配置端口的 link-aggregation port-priority 来决定哪个成员端口是主用。确保同属一台防火墙的所有端口优先级相同，并高于对端防火墙的端口。

3. 分别加入成员物理口：确保每个聚合组的成员端口都来自同一台防火墙。这样，业务聚合口就变成了“单框”内部的主备，主用端口随设备优先级切换，避免了跨框转发。

步骤3: 配置冗余组和冗余口

1. 创建冗余口（Reth）：创建一个 Reth 口，并配置IP地址。将步骤1中准备好的专用物理口作为其成员接口。注意：这里加入 Reth 的是物理口，不是聚合口。

2. 配置冗余组：创建 redundancy group，将上一步创建的 Reth 口加入其中。同时将业务聚合口（如 Route-Aggregation1）配置为 track 对象，以便系统感知链路故障。

3. 配置节点优先级：在冗余组内，通过 node 命令绑定设备成员号（slot 1/slot 2），并配置优先级，确保主设备优先级高于备设备。

4. 开启会话同步：执行 session synchronization enable 命令，确保主备切换时已有业务不中断。

 方案二：升级软件（备选/临时方案）

若业务无法中断，可尝试将设备软件升级至最新版本（如R9960P系列），看是否支持“SSL VPN跨框会话同步”特性。此方案不能从根本上解决所有跨框流量问题。

 补充：为何网络不通？

你提及“冗余口添加了十几业务三层聚合口后不通”，原因正是配置逻辑冲突：已经加入冗余组的端口，不能再加入链路聚合组。强行操作会导致系统配置混乱。