企业官网建设流程全解析

入行做网络这一行，几乎人手一份“H3C常用命令笔记”，但真正遇到问题的时候，你会发现零散的命令根本救不了场。尤其是看到后台这些搜索词——设备启动不了、忘记Console密码、IPv6 ACL配置实验、VXLAN命令、GRE over IPsec野蛮模式、last-hop hold……这些场景我基本都亲手趟过一遍，有的坑在模拟器里，有的坑在真机现场。这篇不打算做成一本干巴巴的命令字典，而是把高频场景拆开来，把命令背后的逻辑和实测中容易踩的点一起讲清楚，希望能帮你省下一些查文档和试错的时间。

1. 模拟器起不来、设备不启动？先把实验环境救活

不少人拿到H3C Cloud Lab（老版本叫HCL）之后，第一关就卡住了：设备启动不了，双击路由器或交换机半天没反应，或者直接报错。其实这个问题我在不同电脑上遇到过不下十次，根因大概率不是设备镜像坏了，而是模拟器的底层虚拟化环境不对。

H3C Cloud Lab默认依赖的虚拟化组件是老版本VirtualBox。它和VMware Workstation、Hyper-V、Windows内核隔离之间都存在冲突。最常见的两个冲突源：

• Hyper-V开启时，VirtualBox启动虚拟机大概率失败，报错通常是“VT-x is not available”或内核模块加载异常。
• VirtualBox版本过新（比如7.x），H3C Cloud Lab的内置兼容脚本还没适配，设备同样起不来。

排查顺序建议这样来：

1. 查Windows功能里Hyper-V是否开启。如果开着，要么关掉重启，要么换用支持Hyper-V的模拟器版本。
2. 查“内核隔离-内存完整性”是否打开。这个功能和VirtualBox的硬件虚拟化穿透是互斥的，在Windows安全中心里关掉后重启。
3. 确认VirtualBox版本。HCL历史版本适配较好的VirtualBox是5.2.x到6.0.x，理论上越新越好的想法在这里不成立。
4. 以上都排除后，如果设备还是停在“Starting……”或控制台黑屏，删除该设备实例，重新导入安装目录下的镜像文件（通常是H3C Cloud Lab安装目录\devices下的.ova或.vmdk），手动挂载一次。

控制台卡死还有一种很隐蔽的情况：内存分配不足。默认MSR路由器是2GB内存的规格，如果宿主机总内存只有8GB还开了其他软件，设备轮到CPU和内存资源时会非常慢甚至假死。这时候别急着删设备，打开设备设置把内存降到1GB或1.5GB，大部分实验依然能跑。

模拟器能正常启动后，再顺手把实验习惯养成：每次改完配置执行save force，每次关模拟器之前先quit到用户视图再保存拓扑。这一步主要是防崩，HCL在异常断电或宿主机关机时，配置丢失的概率比真机高不少。

2. 登录密码相关操作：取消串口密码、恢复遗忘的Console密码

“华三交换机怎么取消串口密码”这个搜索词背后，通常是两种情况：一是新设备到手后console口有默认密码，需要取消；二是接手别人设备时不知道Console密码，想恢复出厂级别的操作权限。

先说取消串口密码，这个很简单。只要能正常登录，取消密码的本质是把用户界面（User-Interface）的认证方式改为none：

system-view user-interface console 0 authentication-mode none return save force

改完之后再连Console口就直接进用户视图了，不用再输密码。如果只是想换一个自己记得住的密码，不取消，那么认证方式改为password，再设置密码：

system-view user-interface console 0 authentication-mode password set authentication password simple YourPassword return save force

注意，set authentication password后面可以跟simple或cipher两个关键字。simple是明文显示在配置里，cipher是加密显示。从运维管理的角度，建议用cipher，避免巡检或者导出配置时密码直接暴露在文本里。

再说恢复遗忘的Console密码，这个要复杂得多，操作不当会丢配置。以S7506E这类Comware V7框式交换机为例，过程大致是：

1. 重启设备，启动阶段按Ctrl+B进入BootROM菜单。
2. 在BootROM菜单里，选择跳过配置文件启动，或者清除超级密码。不同版本菜单名称略有差异，核心思路就是不让设备加载当前配置文件。
3. 设备进入空配置状态后，重新登录并恢复配置。

这里有两个关键细节必须说清楚。一是Comware默认开启了password-recovery enable，只有在这个状态下BootROM菜单才会提供“跳过配置文件”或“恢复密码”的完整选项；如果设备上执行过undo password-recovery enable，那密码恢复就只能重置用户权限，不能跳过配置文件，配置大概率会被清掉。二是跳过配置文件启动后，设备里还保留着startup.cfg等启动配置文件，重新登录后可以执行：

display saved-configuration

查看之前设备的完整配置内容，再逐条手工恢复，或者把配置文件导出到TFTP服务器，修改后重新上传。但千万别在空配置状态下直接执行save force，那样会把原来的启动配置文件覆盖，老配置就再也找不回来了。

另外提醒一句，模拟器里练这个操作没什么成本，真机上操作前一定先确认设备当前是否有配置备份，没有备份就先想办法备份，哪怕用手机拍屏记录都比丢配置强。

3. 查看类命令与日常巡检：从接口MAC地址到整机状态

搜索词里有一条“华三路由器查看接口MAC地址命令”，这个问题其实特别基础，但确实很多人一上来就在命令门口打转。关键是搞清楚“设备接口的MAC地址”和“MAC地址表”是两个完全不同的东西。

查看接口物理属性，包括接口的MAC地址，用display interface：

display interface GigabitEthernet 0/0

输出的前面几行里会有MAC address: 00e0-fc00-xxxx之类的字段，这就是该三层接口的MAC地址。如果是查看所有接口的概要状态，用：

display interface brief

但这个命令只看得到链路状态、速率、双工、协议状态，看不到MAC地址，别指望它能直接告诉你接口MAC是多少。

查看设备MAC地址表（二层交换机的转发表），用的是：

display mac-address

这个命令输出的是交换机学到的MAC地址与接口/VLAN的对应关系，适合排查二层环路、定位终端在哪台设备哪个接口下挂，和“查看接口MAC地址”是两码事，写脚本或排查问题时候别混淆。

日常巡检时，我的习惯是固定执行一组命令，由浅入深看一遍整机状态：

一位老工程师总结过一句话：“不看display logbuffer的排查都是盲猜。”很多设备异常，日志里早就写了原因，只是大家习惯先看接口看路由，绕了一大圈回来才查日志。

4. 端口安全与IP-MAC绑定：ip verify source 和端口多MAC控制

搜索词“华三交换机端口启用ip verify source ip-address mac-address”对应的功能是IP Source Guard（IPSG），它是一项基于二层端口的源IP、源MAC合法性校验机制，适合用在接入层交换机上，防止终端私自改IP或伪造IP接入网络。

命令本身不复杂，核心就两步。第一步，在接口下启用校验：

system-view interface GigabitEthernet 1/0/1 ip verify source ip-address mac-address quit

第二步，配置合法的IP-MAC绑定表项。绑定表项有两种来源：一种是在系统视图下手工配置静态绑定，另一种是配合DHCP Snooping动态学习。静态绑定命令格式如下：

system-view ip source binding ip-address 192.168.1.10 mac-address 0001-0001-0001 interface GigabitEthernet 1/0/1

这里有个非常容易踩的坑：如果在接口下只执行了ip verify source ip-address mac-address，但没有配置任何绑定表项，也没开启DHCP Snooping，那么该接口下所有IP报文都会因为查不到绑定表而被丢弃，终端会直接断网。很多人在模拟器里测试这个命令，敲完接口就起不来，原因就在这里。

如果现场终端使用DHCP动态获取地址，正确做法是先开启DHCP Snooping：

system-view dhcp snooping enable interface GigabitEthernet 1/0/1 dhcp snooping binding record ip verify source ip-address mac-address quit

这样DHCP分配出去的IP-MAC对应关系会被记录成动态绑定表项，IPSG校验时才会放行。核心交换机的上联口或服务器口最好不要开IPSG，否则广播、组播或者特殊报文被过滤掉，排查起来很痛苦。

另一个搜索词“端口绑定可以同时绑”，我猜问的是“一个端口”或者“一个MAC”能不能绑定多个设备。先说结论：如果只是想给一个端口绑定多个MAC地址，用端口安全（Port Security）功能；如果只是想限制哪些MAC可以接入某个端口，也是端口安全更合适。配置示例：

system-view interface GigabitEthernet 1/0/1 port-security enable port-security max-mac-count 5 port-security mac-address security sticky port-security intrusion-mode disable quit

max-mac-count 5表示该端口最多学习5个MAC，超过不再学习；sticky表示动态学习到的MAC会变成粘性安全MAC，即使设备重启也能保存下来，适合Hub带多台终端的下行口。如果需要对特定MAC做限制，可以在端口安全视图下手工指定：

interface GigabitEthernet 1/0/1 port-security mac-address 0001-0001-0001 vlan 10

注意，端口安全和IPSG不要一上来同时叠加配置。IPSG查的是IP+MAC组合，端口安全只查MAC，两者同时开的时候，接口下数据报文要同时通过两层校验，一旦绑定表项不一致，业务直接中断。我遇到的故障案例里，十次有八次是业务方自己临时加了绑定，回头却把这笔账算在交换机头上。

5. IPv6 ACL配置实验：从ACL定义到接口下发

IPv6 ACL在H3C设备上和IPv4 ACL的命令体系是分开的，虽然逻辑相似，但编号、匹配字段、应用命令都不一样。很多人上手时习惯性地敲acl number 3000，结果发现设备根本不识别，就是因为IPv6 ACL要用acl ipv6来定义。

基本IPv6 ACL的编号范围是2000到2999，匹配源地址；高级IPv6 ACL是3000到3999，可以同时匹配源、目的和协议类型。举个例子，一个典型实验需求：禁止2001:db8:2::0/64网段的终端访问2001:db8:3::0/64网段，其他流量放行。配置如下：

# 创建基本IPv6 ACL acl ipv6 number 2000 rule 5 deny source 2001:db8:2::0 64 rule 10 permit source 2001:db8:1::0 64 rule 15 deny quit

在IPv6中，source后面跟地址和前缀长度，不需要写通配符掩码，这一点和IPv4 ACL有本质区别。然后下发到接口：

interface GigabitEthernet 1/0/1 ipv6 packet-filter 2000 inbound quit

注意这里是ipv6 packet-filter，不是IPv4的packet-filter，少一个ipv6关键字，设备直接报错。

如果是高级IPv6 ACL，想匹配特定协议和特定目的地址，格式这样：

acl ipv6 number 3000 rule 5 deny tcp source 2001:db8:1::10 128 destination 2001:db8:3::10 128 destination-port eq 80 rule 10 permit ipv6 quit

这里permit ipv6表示允许其他所有IPv6报文，注意必须写ipv6关键字而不是只写permit。

模拟器上做IPv6 ACL实验，必须先给接口配IPv6地址并启用IPv6，否则ACL下发后接口可能处于“inactive”状态：

interface GigabitEthernet 1/0/1 ipv6 address 2001:db8:1::1/64 ipv6 enable

实验做完后，用display acl ipv6 2000查看命中次数，确认规则是否生效。如果数字一直是0，先看接口上的应用方向是不是搞反了，再查接口IPv6状态是否UP。

6. 进阶组网命令骨架：VXLAN、GRE over IPsec、AC本地转发

这三个搜索词都指向组网场景，命令量大，不可能一篇全部覆盖，这里给的是能快速上手的最小骨架和关键验证思路。

VXLAN命令骨架。H3C的VXLAN二层网关部署，核心是把业务VLAN接入VSI，再用VXLAN隧道跨物理设备打通。以Comware V7为例，最小化配置骨架如下：

# 第一步，底层IP网络（Underlay）打通 interface LoopBack0 ip address 1.1.1.1 32 quit interface GigabitEthernet1/0/1 ip address 10.0.12.1 24 quit ospf 1 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.0.12.0 0.0.0.255 # 第二步，创建VSI并绑定VXLAN vsi vpna vxlan 10 quit # 第三步，创建VXLAN隧道 interface Tunnel1 mode vxlan source 1.1.1.1 destination 2.2.2.2 quit # 第四步，把隧道关联到VSI vsi vpna tunnel 1 quit # 第五步，业务接口接入VSI interface GigabitEthernet1/0/2 xconnect vsi vpna quit

VXLAN最容易被忽略的是Underlay路由。很多人把注意力全放在VXLAN本身的命令上，结果两端LoopBack地址都不通，VXLAN隧道自然建立不起来，数据面的“VXLAN隧道状态”永远是Down。先验证Underlay，再查隧道，能省一半排错时间。

GRE over IPsec野蛮模式。这个场景常用于总部和分支之间，GRE负责承载私网路由协议或组播，IPsec负责加密。野蛮模式相比主模式的好处是，分支侧可以不依赖固定公网IP，只要能和总部互通就能建立IPsec隧道。

配置骨架如下：

# 第一步，配置GRE隧道 interface Tunnel0 mode gre ip address 10.0.0.1 255.255.255.0 source 1.1.1.1 destination 2.2.2.2 quit # 第二步，配置IPsec安全提议 ipsec transform-set tran1 esp encryption-algorithm aes-cbc-128 esp authentication-algorithm sha1 quit # 第三步，配置IKE keychain和profile，指定野蛮模式 ike keychain kc1 pre-shared-key address 2.2.2.2 0 key simple Test@123 quit ike profile prof1 keychain kc1 exchange-mode aggressive local-identity address 1.1.1.1 match remote identity address 2.2.2.2 proposal 1 quit # 第四步，配置IPsec策略并引用IKE Profile ipsec policy policy1 1 isakmp transform-set tran1 security acl 3000 remote-address 2.2.2.2 ike-profile prof1 quit # 第五步，定义进入IPsec的流量（GRE协议） acl number 3000 rule 5 permit gre source 1.1.1.1 0 destination 2.2.2.2 0 quit # 第六步，在GRE Tunnel接口下应用IPsec策略 interface Tunnel0 ipsec apply policy policy1 quit

如果两端都是H3C设备，注意match remote identity address要和对端的local-identity address保持一致，否则IKE野蛮模式协商会一直卡在身份验证阶段。这个坑我踩过，总部侧local-identity address写的是LoopBack地址，分支侧match remote identity写成了物理接口地址，结果SA反复协商失败，排查到最后才发现是身份标识不匹配。

AC本地转发配置。本地转发（也叫本地桥接）模式下，AP通过CAPWAP管理隧道和AC通信，但终端的数据报文由AP直接转发到有线网络，不经过AC。命令上最核心的差别就是服务模板里那句client forwarding-location：

# 配置无线服务模板 wlan service-template 1 ssid H3C-WLAN client forwarding-location ap service-template enable quit # 配置AP的射频并关联服务模板 wlan ap ap1 model WA4320i-ACN serial-id 219801A0CNC1234567890 radio 1 service-template 1 vlan 100 radio enable quit quit

本地转发模式下，业务VLAN的网关不在AC上，而在AP上联交换机或汇聚交换机上。也就是说，数据流量从AP发出后直接带着VLAN 100的标签上送到有线网络，由有线侧的三层网关完成路由。所以，AP上联交换机Trunk口必须放行管理VLAN和数据VLAN，否则终端能连接但一直拿不到地址或无法上网。

模拟器里验证本地转发效果时，可以先拿一台PC接到AP上联交换机对应VLAN 100的接口，如果能正常和网关互通，说明本地转发路径已通，AC侧的CAPWAP隧道状态正常即可。

7. Last-hop hold 与几个容易搞混的隐藏坑

“华三last-hop hold”这个搜索词很冷门，但点名的场景是VXLAN/EVPN分布式网关部署里的回程流量路径优化。简单说，在多个VTEP同时承担同一VSI网关的时候，如果终端的入向流量从Leaf1进来，但网关选路时把回程流量从Leaf2转发出去，就会造成跨Leaf绕行，无谓消耗设备间链路带宽。last-hop hold的作用就是让网关记住报文的入设备信息，回程流量优先回到同一个Leaf，保证来回路径一致。

在Comware V7的VSI接口视图下，相关命令通常是：

interface Vsi-interface 10 last-hop hold quit

不同版本措辞可能略有差异，有的型号写作last-hop hold enable。这个特性在单网关场景下没有任何意义，一定要在分布式网关、多VTEP的VXLAN或EVPN组网里才需要关注。

除了last-hop hold，H3C设备上还有几个容易搞混的命令或特性，我每次培训或带人的时候都会专门提：

第一个是save和save force的区别。直接执行save会交互式询问“是否保存到文件”，如果远程维护时SSH窗口不太稳定，建议用save force一步到位。但保存前一定要确认配置正确，因为覆盖启动配置后想回退只能靠手工undo。

第二个是display current-configuration看不到默认配置。很多初学者用display current-configuration检查配置，发现没有自己想要的那条命令，就以为没配成功。实际上Comware默认配置和系统默认参数不会全部显示在当前配置里，比如vlan 1、某些接口的默认端口状态。要确认某条命令是否真实生效，用display this且在对应视图下查看，或者在display current-configuration后面加| include过滤关键字。

第三个是模拟器和真机之间的命令版本差异。HCL模拟器主要模拟的是Comware V7的某个子集，有些特性比如EVPN、VXLAN的进阶命令、部分框式设备板卡管理命令，模拟器里敲了不识别或直接报错是正常现象。遇到这种情况，先查设备版本和命令手册，别怀疑自己敲错。

第四个是display interface brief看到的Down不一定是物理故障。很多接口配置了shutdown后也显示Down，但不代表链路真实中断。排查时先看是否有Administratively down字样，有的话就是被人为shutdown了，undo shutdown就能恢复。

写在最后

说了这么多，其实H3C设备的命令体系很有规律，同一个意图在不同产品、不同版本上虽然写法有差异，但思路是共通的。如果你正在学或者正在用，我的建议是别背命令，先搭一个模拟器环境，把登录、密码恢复、接口查看这些最基本的操作练熟，再逐步尝试ACL、端口安全、VXLAN这类进阶特性。每做完一个实验，把配置导出，把自己踩过的坑用一两句话记录在注释里，时间长了这就是一份比任何命令手册都靠谱的私人排错手册。