企业官网建设流程全解析

简介：针对现网环境核心交换机堆叠改造需求，提供H3C S6520交换机IRF2（智能弹性架构2）堆叠配置的实战经验总结。面向需要在不中断业务前提下完成设备扩容与高可用改造的网络工程师、运维人员，解决同型号设备下堆叠口规划、Master竞选、配置同步等常见问题。资料为单份PDF文档，大小395KB，已有1265人学习。

主体内容从设备型号与软件版本核对、堆叠线缆与端口速率匹配、IRF-port编号规则、优先级设置，到命令行创建IRF口、绑定物理端口、BFD分裂检测等关键步骤均有清晰说明，并给出了配置前备份、业务中断预案等实操建议。针对“不断网”目标，重点讲解通过提高Device A优先级确保Device B重启并同步配置，以及配置BFD避免堆叠分裂引发业务故障的方法。读者可依据文档中的命令示例与操作顺序，在现网中降低变更风险，快速完成两台S6520交换机虚拟化为单一逻辑设备的部署，提升网络带宽、简化运维管理。 前两周刚帮客户完成了一次H3C S6520的现网堆叠改造，两台汇聚交换机要做成IRF，业务不能断。这种需求在项目里越来越常见了，设备单点跑了好几年，领导终于批了预算做高可用，结果一查维护窗口，深夜两三点，业务还不能中断。

很多朋友一听“S6520堆叠”就说简单，无非是配个成员编号、绑个IRF端口、重启一下。可放到现网环境里，每一步都可能踩雷。我见过太多案例，实验环境里跑得飞起，一上真机就翻车，还不是命令敲错，而是对整个“不断网”的流程没有想清楚。这篇文章我就把自己在这个项目里实际操作的完整过程、踩过的坑、以及为什么这样做的原因全部写出来，给正在做类似改造的运维和集成工程师一个参考。

1. 现网堆叠的选型与整体思路

1.1 先想清楚：堆叠到底解决什么问题

S6520是H3C在园区网和中小型企业网里非常常见的汇聚/接入层设备，盒式机身、接口密度高、支持Comware V7。两台S6520要做高可用，方案其实不止一种：IRF堆叠、M-LAG、VRRP+双活链路都能做。为什么要选IRF？因为在这个项目里客户的核心诉求，一是把两台设备逻辑成一台，配置统一管理，不用再一台台登录维护；二是下面接的服务器和接入交换机要做跨设备链路聚合，带宽可以翻倍，出故障能自动切换；三是IRF这个技术本身在H3C设备上非常成熟，实施成本低，不需要额外增加复杂的控制协议。

但IRF有一个绕不开的特性：设备要组成堆叠，成员设备必须加载IRF配置并重启。这一点决定了施工过程和M-LAG完全不同。M-LAG可以做到两台设备独立运行、通过控制平面协商，成员设备不需要重启；IRF则是两台设备“合并”成一台逻辑设备，这个过程必须重新初始化堆叠成员。所以如果谁跟你保证“配IRF全程零重启”，那基本是在画饼。

1.2 “不断网”的真实含义：不是零中断，而是业务无感知

很多项目在前期交流时，客户把“不断网”理解成“一条命令都不能丢包”。实际干过运维的都知道，这个目标在IRF场景下不太现实。两台设备重启合并的过程中，必然会出现毫秒级甚至秒级的控制面切换窗口。真正要做的，是把这个窗口对上层业务的影响降到最低，让服务器、终端用户感知不到。

我这次给客户定的标准是：整个改造期间，除了设备重启瞬间可能出现的TCP重传，业务应用无感知，SSH登录不断，监控系统不告警。要达到这个效果，核心手段就是一句话：在重启任何一台设备之前，先把它的业务流量完整地、可验证地切换到另一台设备上。流量能平滑切走，剩下的堆叠配置就是纯粹的技术动作了。

这里还想多说一句，很多人以为环境越复杂越容易断网，其实恰恰相反。单机单链路的场景反而最危险，因为没有任何冗余可以依靠；真正能扛住“不断网”改造的，往往是已经有双链路、双上联基础的拓扑。所以如果你手头的网络还是单链路裸奔，建议不要硬搬我这套流程，先解决物理冗余再谈堆叠。

1.3 现网拓扑与设备选型背景

简单交代一下现场情况：两台S6520作为汇聚设备，下联多台接入交换机和服务器，上联核心交换机。A设备目前承载全部业务，B设备是这次新增的，已经完成了基础配置，但没有跑业务流量。抓包测试、版本核对都完成后，我制定了先配B、再合并A的整体策略——B没有业务，随便重启不心疼；A放到最后动，给它留出充分的观察窗口。

2. 动手前把检查项做足再做足

2.1 设备体检和版本核对清单

这次踩过的第一个坑就出在版本上。两台S6520一台跑了R63xx版本，另一台是R65xx，刚开始还想赌一把直接配堆叠，结果IRF邻居半天协商不上，一查display version才发现问题。H3C的IRF要求成员设备软件版本一致，至少要保证大版本一致，否则合并过程会出现各种莫名其妙的问题，比如成员状态Inconsistent、配置同步失败。

现场实施前，我习惯先把以下命令跑一遍，把输出全部留存：

display version display device display license display irf configuration display transceiver interface

版本不一致就先升级，S6520升级时要特别注意启动文件路径，典型的操作是用boot-loader指定新的软件包，确认当前和下次启动文件都正确后再重启设备。电源、风扇状态也要看，堆叠形成后整个IRF系统是一个整体，任何一个成员硬件异常都会影响全局。光模块兼容性同样不能忽视，IRF链路的光模块不兼容，物理层起不来，后面所有配置都是白搭。

2.2 IRF物理链路规划才是重头戏

设备配置前，先把IRF物理链路规划清楚，包括成员编号、优先级、IRF端口对应关系、物理连线方式。这个环节如果出错，后面设备一重启就会陷入“接口全变、配置全乱”的泥潭。

我的规划是：A设备作为主设备，成员编号保持默认的1，优先级设32；B设备作为从设备，成员编号改成2，优先级设1。IRF端口方面，每台设备都有IRF-Port1和IRF-Port2，用后面两个万兆光口做堆叠链路，双链路冗余，避免一根线断了就分裂。

连线规则是交叉连接：A的IRF-Port1/1连B的IRF-Port2/2，A的IRF-Port1/2连B的IRF-Port2/1。这个交叉关系很多人容易记混，一旦接成直连，IRF报文协商不了，堆叠永远起不来。连线完成后，先用display transceiver interface检查光功率，确认物理链路正常再进配置阶段。

2.3 配置备份与回滚预案不是走过场

我给客户做任何改动之前，一定先做全量配置备份。命令很简单，把display current-configuration的输出保存下来，同时也把startup配置文件导出一份。虽然IRF配置本身不算高风险操作，但谁也不能保证过程中不会出意外，特别是在A设备重启前的关键时刻。

现场还要准备好Console线，管理地址的SSH通道在堆叠切换时可能会短暂中断，万一网络配置有问题，只能靠console口救命。这次项目里我特意多带了一根Console线，最后果然用上了——这个后面讲踩坑的时候细说。

3. 不断网堆叠配置的实战步骤

3.1 把业务冗余做扎实，再谈堆叠配置

这一步是整个“不断网”方案的核心，直接决定最终效果。我的做法是在配置IRF之前，先把B设备的所有业务配置同步完整，包括VLAN、接口、路由、ACL，一条不落。同时在网络拓扑上做好冗余准备：下联服务器和接入交换机双上联，分别接到A和B；上联核心侧也采用双链路，让A和B都能独立承担流量转发。

具体到流量切换，老式的做法是配VRRP双网关，一组VRRP跑在A上，B作为备用，A重启时VRRP自动切换到B。但如果是二层接入环境，依赖STP冗余链路，收敛速度会慢一些，需要根据业务容忍度来评估。这次现场因为已经有了动态路由协议，我直接用OSPF等价路由实现了故障切换，效果比较理想。

验证冗余是否生效的方法其实很简单：在不配置任何堆叠功能的情况下，手动把A的上联口shutdown，观察业务是否平滑切换到B，观察监控是否告警。如果这一步都能通过，后续重启带来的风险就会小很多。这个验证不能跳过，因为你永远不知道实际流量路径里还有哪些意想不到的依赖。

3.2 从设备B：成员编号变更和IRF端口配置

B是新增设备，没有业务负担，流程可以从容一些。S6520默认成员编号就是1，直接配置会和A冲突，所以第一步把B的成员编号改成2。这里有个非常容易踩坑的细节：成员编号改完后，设备接口的命名会从Ten-GigabitEthernet1/0/x变成Ten-GigabitEthernet2/0/x，接口名一变，原来绑定在接口上的所有配置会全部失效。

所以我在配置脚本里先把B上的业务配置全部导出备份，改完编号重启后，再按新的接口名重新核对配置。

# B设备：先改成员编号，保存重启 system-view irf member 1 renumber 2 # 提示重启生效，保存配置后重启 save force reboot

B重启完成后，成员编号已经是2，接口名变成Ten-GigabitEthernet2/0/x。接下来配置IRF端口，把两个万兆口分别绑定到IRF-Port2/1和IRF-Port2/2：

# B设备：配置IRF端口 system-view irf member 2 priority 1 interface Ten-GigabitEthernet2/0/49 irf-port 2/2 quit interface Ten-GigabitEthernet2/0/50 irf-port 2/1 quit irf-port 2/1 port group interface Ten-GigabitEthernet2/0/50 quit irf-port 2/2 port group interface Ten-GigabitEthernet2/0/49 quit irf-port-configuration active save force

这里我要强调一下，irf-port视图下用port group interface命令把物理口加入IRF端口，是Comware V7比较通用的做法。单独使用物理口下的irf-port命令也可以，但如果有多个物理口聚合到一个IRF端口的需求，就必须用port group interface方式。

配置完成后执行display irf configuration确认IRF配置已经生效，然后重启B，让设备以IRF成员身份启动：

reboot

B重启后已经是一个单成员的IRF系统，成员编号2。这时候它的业务配置如果之前同步完整，就已经具备接管A流量的能力了。

3.3 主设备A：优先级提高，合并重启

A是现网主设备，承载业务最重，所以所有准备工作都要在它重启前完成。确认B已经正常启动、IRF成员状态正常后，再配置A。A不需要改成员编号，保持1，只需要设置优先级，保证合并后A仍然胜出成为主设备：

# A设备：配置优先级和IRF端口 system-view irf member 1 priority 32 interface Ten-GigabitEthernet1/0/49 irf-port 1/1 quit interface Ten-GigabitEthernet1/0/50 irf-port 1/2 quit irf-port 1/1 port group interface Ten-GigabitEthernet1/0/49 quit irf-port 1/2 port group interface Ten-GigabitEthernet1/0/50 quit irf-port-configuration active save force

在重启A之前，我再次确认了一遍B上的业务状态，确保B已经能转发流量。然后选择业务最低谷的时间点，执行reboot。

A重启过程中，原本经过A的流量开始切换到B，这个环节我对监控盯得很紧，好在整个切换过程业务无感知。A重新启动后，通过IRF链路与B自动完成合并协商，H3C IRF机制会根据优先级选出主设备，A优先级高，成为新IRF系统的主设备。整个合并过程有两三次丢包，但对上层业务影响可以忽略。

合并完成后，执行display irf确认两个成员都处于Stable状态，这是堆叠建立成功的标志：

display irf display irf topology

3.4 跨设备链路聚合和MAD检测，一个都不能少

堆叠合并成功后，最直观的好处就是可以做跨设备链路聚合了。原来A和B各自上联核心，只能靠路由协议切换，现在可以把两个成员的口子放进同一个聚合组，形成真正的跨设备Eth-Trunk，带宽翻倍、故障自动切换。配置示例：

# IRF系统视图下配置跨设备聚合口 system-view interface Bridge-Aggregation1 link-aggregation mode dynamic quit interface Ten-GigabitEthernet1/0/1 port link-aggregation group 1 quit interface Ten-GigabitEthernet2/0/1 port link-aggregation group 1 quit

看到Ten-GigabitEthernet1/0/1和Ten-GigabitEthernet2/0/1同时出现在一个聚合组里，就能直观感受到“两台设备变成一台”的意义了。

接下来必须做的一件事是MAD检测。IRF最怕的不是配置失败，而是堆叠链路断裂后两台设备都认为自己是主设备，导致双主冲突、MAC漂移、整个网络瘫痪。S6520上常用BFD MAD检测，原理是让两个IRF成员通过一条独立的物理链路跑BFD心跳，一旦检测到对端失联，从设备会自动关闭自己的业务接口，避免双主。

我的做法是规划一个专用VLAN给MAD，比如VLAN 4092，再在IRF成员之间拉一根独立的万兆线用于BFD检测：

# IRF系统视图下配置BFD MAD system-view vlan 4092 quit interface Vlan-interface4092 ip address 192.168.200.1 24 bfd mad ip-address 192.168.200.2 24 quit interface Ten-GigabitEthernet1/0/52 port link-type trunk port trunk permit vlan 4092 quit interface Ten-GigabitEthernet2/0/52 port link-type trunk port trunk permit vlan 4092 quit

这里要注意，MAD专用VLAN不能承载任何业务流量，否则BFD报文和业务流量混在一起，一旦触发MAD误判，后果不堪设想。配置完成后，我建议实际做一次“拔线演练”，把IRF主链路拔掉，观察从设备是否正常关闭业务口。这个演练虽然有点吓人，但真出了故障能救命。

4. 现网踩坑实录与排查方法

4.1 成员编号改完，接口名全变了

这个坑我在实验环境就吃过一次，这次现场又差点翻车。B设备改完成员编号后，接口从Ten-GigabitEthernet1/0/49变成了Ten-GigabitEthernet2/0/49，之前针对旧接口名写的批量下发脚本全部失效，如果不仔细核对，很容易出现“配置看着下了，其实没生效”的情况。

建议所有接口级配置都用新接口名重新梳理一遍，用display current-configuration interface逐个确认。大项目建议提前准备好接口名映射表，改编号前就把脚本生成好。

4.2 IRF端口配置了但没生效

有同事问过我，irf-port绑定都配了，物理链路也通了，为什么堆叠还是起不来？最常见的原因是漏了irf-port-configuration active这条激活命令。IRF端口配置必须激活后才会开始协商，光配置不激活，设备根本不会通过IRF链路发报文。激活后要保存配置再重启，顺序不能乱。

还有一种情况是绑定的物理口刚好被业务配置占用了，比如已经加进了某个聚合组。这会导致IRF配置冲突，激活时报错。所以在绑定IRF端口前，要把对应物理口的业务配置清干净，确保端口空闲。

4.3 两台设备版本不一致导致合并失败

前面说过，版本不一致是IRF合并失败的典型原因。现象就是两边都配好了IRF端口，物理链路也正常，但display irf里成员一直处于Inconsistent状态，二层/三层链路也建立不起来。排查思路很直接：先display version对比两台设备的软件版本，不一致就升级到相同版本，再重新配置IRF。

还有一点容易被忽略：License。如果设备上有依赖License的高级功能，IRF合并后License需要能在整个IRF系统内生效。建议在实施前联系设备供应商确认，避免合并完成才发现功能失效。

4.4 堆叠分裂，业务直接瘫痪

堆叠分裂是IRF最严重的事故，如果之前没配MAD，分裂后两台设备同时接管业务，MAC地址表震荡，广播风暴，整个网络秒瘫。所以我在第3.4节强调的MAD检测，真的不是“建议配置”，而是“必须配置”。

万一真遇到分裂，首先要做的是把人跑到机房，或者用带外管理通道登录设备，把其中一个成员的业务口全部shutdown，恢复网络稳定后再排查IRF链路。千万不要在设备还处于双主状态的时候尝试重新配置，这时候每一条写进设备的命令都可能加剧冲突。

4.5 模拟器验证的利与弊

HCL这类的H3C模拟器里可以练IRF配置流程，逻辑上大差不差。但模拟器毕竟不是真机，IRF端口编号、物理口支持情况、版本特性都可能和实际硬件有差异。我的建议是：用模拟器跑通整体思路和命令流程，但真机实施时必须用display命令逐项确认，别把模拟器里的配置无脑套进来。

5. 实际运维中的几个小建议

整个项目做下来，我最想分享的一条经验是：别把堆叠当成一次“配完就走”的操作，堆叠形成之后还有大量日常运维要注意。

比如升级版本，IRF系统虽然支持在整机或单成员上升级，但操作顺序、中断窗口控制都是有讲究的。我这次因为赶时间，没有等到后续版本发布，如果客户后续要升级系统软件，我会建议先在一台成员上升级，确认无误后再升级另一台，而不是两台一起重启。

另外，堆叠后的设备命名和配置管理也要更新。监控系统、网管平台里原来两台独立设备的记录，要改成一台IRF系统的记录，snmp团体名、trap服务器地址这些都要同步调整。如果监控还是按两台设备分开采集，IRF系统里出现大量重复数据不说，告警判断也可能误报。

这次现网改造，从前期检查到最终MAD验证，前后花了差不多一个完整维护窗口的时间。回头复盘，最危险的环节其实不是命令敲错，而是业务冗余没有验证充分就匆忙重启设备。如果你也在准备做类似的S6520现网堆叠，我的建议是：模拟器里先跑通，真机上把检查项逐条打勾，业务切换验证通过后再动设备，每一步都预留回退方案。堆叠本身不复杂，难的是把所有细节都想到位。

本文还有配套的精品资源，点击获取