路由交换技术基础这四个字，很多刚入行的朋友一听就觉得抽象，觉得是考试大纲里的名词。但真到了机房里，你面对的就是几台设备、一捆网线、一个 console 口，以及一堆必须跑通的业务。H3C 网络设备原理与操作这套东西，本质上就是教你把“数据从 A 点送到 B 点”这件事拆成可配置、可验证、可回滚的步骤。我见过太多人背得出一堆协议名，却卡在“为什么我配了 VLAN 还是不通”这种问题上。这篇文章不打算复述教材，我想从一个实际动手者的角度，把设备原理、命令行逻辑、二层三层的落地配置、以及那些文档里不会写的坑，按我自己的理解完整摊开。不管你是刚接触网络设备的学生，还是从其他品牌转过来的运维，只要能照着敲一遍、看着现象想明白一遍，基本就能独立撑起一个中小型网络的开局配置和日常排障。

1. 先想清楚：路由交换到底在解决什么问题

1.1 从“一个网段”到“多个网段”的必然分裂

所有网络设备的配置逻辑，都源于一个很朴素的矛盾：大家想互通，但又不希望互相干扰。早期一个小办公室，十几台电脑接一台交换机，全在 192.168.1.0/24 里，谁都能访问谁，简单直接。可一旦人数上去、部门分开、出现打印机、监控、无线、服务器这些不同角色，单一的广播域就会变成灾难——某台机器的网卡故障狂发广播帧，整层楼跟着卡；某个部门要做访问控制，发现根本无处下手。

于是就有了 VLAN。VLAN 的本质不是“把网络切开”，而是“把广播域切开，同时用逻辑手段重新组织成员关系”。一台 24 口交换机，物理上是一个盒子，逻辑上可以变成四五个互不相干的广播域，每个广播域内部二层直达，跨广播域必须经过三层转发。这一步理解透了，后面所有配置都是它的延伸。

路由则是解决“切开之后怎么再连起来”。三层转发做的事情是：收到一个包，看目的 IP，查路由表，找到出接口和下一跳，重新封装二层头，发出去。整个过程没有任何神秘的地方，关键在于路由表里的条目是怎么来的——直连、静态、动态协议，来源不同，优先级不同，最终生效的只有一条。

我个人的经验是：初学阶段不要急着上动态路由协议。把直连路由和静态路由吃透，能把一个总部加两个分支的网段规划清楚，已经能解决八成以上的实际需求。动态协议是规模上去之后的效率工具，不是入门门槛。

1.2 为什么坚持从命令行入手

现在很多设备都有 Web 管理页面，点几下就能配好 VLAN，看起来省事。但我依然建议先把命令行啃下来，理由很实在。

第一，Web 页面是命令行的封装，它能做的永远是命令行能力的子集。遇到页面没覆盖的功能，或者页面配置出错需要定位，你还是得回到命令行看配置文本。第二，排障时你需要的是“设备当前到底是什么状态”，图形界面给你的往往是经过加工的摘要，而display系列命令给你的是原始事实。第三，也是最重要的一点，命令行的操作是有肌肉记忆和逻辑顺序的，视图层级强制你先进入全局、再进入接口、再配置具体参数，这个流程本身就在训练你对设备结构的认知。

命令行还有个隐性好处：可复制、可比对。两台设备的配置差异，用文本一对比就出来了；Web 界面点出来的东西，你很难快速说清楚两边的区别在哪。我在做设备替换和配置迁移时，基本都是导出配置文件做文本比对，效率比翻页面高一个数量级。

1.3 实验环境怎么搭才不浪费时间

真正的设备当然最好，但不是每个人都有条件。我的建议是分层准备：

我自己的做法是：先用手边一台旧交换机练熟 console 登录、视图切换、VLAN 和端口配置，把“手不抖”这件事解决掉；然后在模拟器里搭三台设备的小拓扑，练跨设备 trunk、STP、静态路由。真机练手感和物理层，模拟器练逻辑和规模，两者不冲突。

这里有个容易被忽略的细节：console 线连接参数。绝大多数设备的 console 口是 9600 波特率、8 数据位、无校验、1 停止位、无流控。这个参数不对，终端就是一片乱码或者毫无反应。我第一次接设备时折腾了半小时，最后发现是终端软件默认的流控开着。

注意：设备上电前先接好 console 线再开机，能看到完整的启动过程。启动日志里的版本号、内存大小、端口数量，是判断设备状态最原始的依据，比事后查命令更直观。

2. 命令行基础：把设备“摸熟”比配通更重要

2.1 视图层级是命令行的骨架

网络设备的命令行不是平铺的，而是一棵树。最外层是用户视图，提示符是尖括号<>，这个层级只能做查看和少量操作，改不了配置。输入system-view进入系统视图，提示符变成方括号[]，这才是配置的起点。再往下，进入接口视图、VLAN 视图、协议视图，提示符会跟着变，比如[SW1-GigabitEthernet1/0/1]。

这个设计的用意是防止误操作：你必须明确告诉设备“我要改哪个对象”，才能改。反过来，如果你发现命令敲不进去，八成是视图不对。quit退回上一级，return或者快捷键直接回用户视图。这个逻辑看起来笨，但它保证了配置的确定性——同样的命令在不同视图下含义完全不同，比如ip address在接口视图下是配地址，在别的视图下可能压根不存在。

<SW1> system-view [SW1] sysname SW1 [SW1] interface GigabitEthernet 1/0/1 [SW1-GigabitEthernet1/0/1] quit [SW1] quit <SW1>

命名这件事别偷懒。设备默认名字都是一样的，一旦拓扑里超过两台，你display出来的东西根本分不清是谁。开局第一件事改sysname，改成能一眼看懂的，比如“一楼接入”“核心主”。

2.2 配置保存、备份与回滚的正确姿势

新手最容易犯的错，是配完就跑，设备一断电全没了。命令行的配置分两层：运行配置在内存里，掉电即失；启动配置在存储介质里，才是真正生效的。save这个动作就是把运行配置写进启动配置。

<SW1> save The current configuration will be written to the device. Are you sure? [Y/N]: y

看起来简单，但有几个坑。第一，save时如果提示配置文件已存在，会问你覆盖还是另存，选错就多出一份配置，下次启动加载哪份要看启动项设置。第二，改配置的过程中不要随手save，尤其是远程操作时，一个错误的save可能让你下次连不上设备。稳妥的做法是：改完一批配置先验证业务通不通，通了再存。

备份我一般做两层。一层是把配置文件导出来存到本地，不同日期各存一份，出问题能对比；另一层是在设备上保留一份“已知可用”的配置副本，作为回滚基线。真出事了，把基线配置导回去重启，比现场一条条命令往回改快得多。

<SW1> display current-configuration <SW1> display saved-configuration <SW1> display startup

这三条命令分别看运行配置、启动配置、本次启动加载的文件。三者不一致的时候，就是你要警惕的时候。

2.3 远程管理：方便与风险并存的一步

设备放机房，天天跑过去插 console 线不现实，所以要开远程管理。开启之前先想清楚三件事：谁能登录、通过什么协议登录、登录后能干什么。

账号权限靠角色控制。管理级角色能改所有配置，监控级只能看。给运维同事开监控级账号，给自己开管理级，这是基本的分权。密码策略上，我倾向于强制一定长度和复杂度，并且定期更换，原因很简单：弱口令的设备一旦暴露在内网，就是整个网络的入口。

[SW1] local-user netadmin class manage [SW1-luser-manage-netadmin] password simple YourStrongPass@2024 [SW1-luser-manage-netadmin] service-type ssh telnet [SW1-luser-manage-netadmin] authorization-attribute user-role network-admin [SW1-luser-manage-netadmin] quit [SW1] line vty 0 4 [SW1-line-vty0-4] authentication-mode scheme [SW1-line-vty0-4] user-role network-admin

line vty 0 4表示允许 5 个并发远程会话。这个数字别开太大，一来没必要，二来会话数多意味着攻击面大。协议上优先 SSH，Telnet 是明文传输，密码在链路上裸奔，能用 SSH 就别用 Telnet。

还有个细节：远程管理用的源地址范围最好用 ACL 限制。只允许管理网段登录，其他网段一律拒绝。这一步多花五分钟，能挡掉大量扫描和试探。

2.4 时间、日志与版本：三个容易被跳过的地基

设备时间不准，日志时间戳就是废的，排障时你根本没法把两条日志对应到同一起事件上。所以开局配 NTP，把设备和内网时间源对齐，这是性价比极高的一步。

日志要往外送。设备本地日志容量有限，滚一圈就覆盖了。配一个日志主机，把 info 级别的日志发出去，出事时能回溯。display logbuffer看本地缓冲，display trapbuffer看告警，两个都要会用。

版本信息也别忽略。display version能看到软件版本、硬件型号、运行时长、上次重启原因。设备无故重启，先看这条，能直接告诉你是不是掉电、看门狗、还是异常。升级固件前一定先记录当前版本，升级后对比，出问题好回退。

提示：把display version、display current-configuration、display interface brief三条命令的输出在开局时各存一份，作为设备“健康基线”。以后任何异常，拿现状和基线比，差异就是线索。

3. 二层交换：VLAN、Trunk 与防环的完整落地

3.1 VLAN 规划：先画表再动手

VLAN 配置本身只有几行命令，难的是规划。我见过太多网络，VLAN 是随手加的，10、20、30 用完发现 100 被占了、200 被别的设备用了，最后谁也说不清哪个 ID 对应哪个部门。

正确的做法是先出一张规划表，把 ID、用途、网段、网关、DHCP 范围一次定死，之后所有配置都照表来。

为什么网关取 .254 而不是 .1？纯粹是习惯问题，两种都行。取 .254 的好处是把低位地址留给服务器和网络设备，人工分配时不容易和网关撞车。关键是全网络统一，别这台设备用 .1 那台用 .254，后面查问题能把人逼疯。

网段大小的计算也要说清楚。192.168.20.0/24 有 256 个地址，去掉网络号和广播地址，可用 254 个。如果无线终端预计超过 200 台，就得考虑扩到 /23，也就是 192.168.20.0/23，覆盖 192.168.20.0 到 192.168.21.255，可用 510 个地址。掩码从 255.255.255.0 变成 255.255.254.0。这个换算必须熟练，不然地址不够用时临时改网段，整个部门的配置全要跟着动。

3.2 Access 与 Trunk：两种端口角色的本质区别

交换机端口对 VLAN 的处理方式，只有两种角色。Access 口属于某一个 VLAN，收到无标签帧就打上该 VLAN 的标签，发出时把标签剥掉。它面向的是终端设备，终端不懂 VLAN，也不需要懂。Trunk 口承载多个 VLAN，帧在链路上带着标签传输，用于交换机之间的互联。

[SW1] vlan 10 [SW1-vlan10] quit [SW1] vlan 20 [SW1-vlan20] quit [SW1] interface GigabitEthernet 1/0/1 [SW1-GigabitEthernet1/0/1] port link-type access [SW1-GigabitEthernet1/0/1] port access vlan 10 [SW1-GigabitEthernet1/0/1] quit [SW1] interface GigabitEthernet 1/0/24 [SW1-GigabitEthernet1/0/24] port link-type trunk [SW1-GigabitEthernet1/0/24] port trunk permit vlan 10 20

配置本身没难度，难点在验证。配完 Access 口，用display vlan 10看端口有没有加进去；配完 Trunk，用display port trunk看允许通过的 VLAN 列表对不对。很多“不通”的问题，根源就是 Trunk 上漏了一个 VLAN。

trunk 有个默认行为要注意：某些版本下 trunk 口默认只允许 VLAN 1 通过，你新加的 VLAN 必须显式 permit。还有的配置里会出现port trunk pvid vlan这个参数，它决定无标签帧进来时归到哪个 VLAN。这个参数在级联场景下配错，会导致莫名其妙的跨 VLAN 串流，我一般建议除非明确需要，否则保持默认。

3.3 链路聚合：把两根线变成一根的逻辑

两台交换机之间单线连接，带宽和可靠性都是单点。链路聚合把多条物理链路捆成一条逻辑链路，带宽叠加，一条断了另一条顶上。听起来美好，但配置有硬性前提：两端的聚合组号不要求一致，但成员口的速率、双工、VLAN 允许列表必须一致，而且必须都是 trunk 或者都是 access。

[SW1] interface Bridge-Aggregation 1 [SW1-Bridge-Aggregation1] port link-type trunk [SW1-Bridge-Aggregation1] port trunk permit vlan 10 20 [SW1-Bridge-Aggregation1] quit [SW1] interface GigabitEthernet 1/0/23 [SW1-GigabitEthernet1/0/23] port link-aggregation group 1 [SW1] interface GigabitEthernet 1/0/24 [SW1-GigabitEthernet1/0/24] port link-aggregation group 1

聚合之后，流量怎么分配到各条物理链路上，取决于负载分担模式。二层转发常用源 MAC 加目的 MAC 的哈希，三层转发常用源 IP 加目的 IP。这里有个很多人踩过的坑：如果只有一对主机在通信，哈希结果永远是同一条链路，带宽根本叠不上去，你看到的现象是“聚合配了但还是一条线在跑”。解决办法是调整分担模式，或者在多主机、多会话场景下才真正能看出效果。别拿单机测带宽来判断聚合有没有成功，那是测不出来的。

验证聚合状态用display link-aggregation summary，看 Selected 状态的成员口有几个。如果某个口是 Unselected，说明参数不一致或者对端没配，先查这个。

3.4 STP：让环路自己断掉的保命机制

网络里最怕的就是二层环路。一根线接错，广播帧在环里无限循环，几秒钟内整网瘫痪，交换机 CPU 打满。STP 就是自动检测环路并阻塞冗余端口的机制。

现在主流用 RSTP，收敛快。核心交换机配低优先级，让它成为根桥。优先级必须是 4096 的倍数，数值越小越优先。

[SW1] stp mode rstp [SW1] stp priority 4096 [SW1] interface GigabitEthernet 1/0/1 [SW1-GigabitEthernet1/0/1] stp edged-port

stp edged-port是接终端的端口必须配的。配了之后端口直接进入转发状态，不参与 STP 计算，终端插上就能用，不用等 30 秒。但这个参数千万别配在交换机互联口上，否则环路检测失效，直接炸网。

验证用display stp brief，看每个端口的角色和状态。根桥的端口是 Designated，非根桥通往根桥的口是 Root，被阻塞的口是 Alternate。如果你发现根桥不是你预期的核心设备，说明优先级没配或者配错了，用display stp root确认。

注意：临时接线调试时，如果不确定会不会成环，宁可先把一端 shutdown，确认拓扑清楚再放开。一次环路的代价可能是整层楼断网加一堆投诉，比多花五分钟确认贵得多。

4. 三层路由：从能通到可控

4.1 VLAN 间路由：SVI 是最常用的解法

VLAN 切开之后，跨 VLAN 通信必须经过三层。最常用的方式是给每个 VLAN 配一个三层接口，也就是 SVI（VLAN 接口）。三层交换机上，这个接口的地址就是该 VLAN 所有终端的网关。

[SW1] interface Vlan-interface 10 [SW1-Vlan-interface10] ip address 192.168.10.254 24 [SW1-Vlan-interface10] quit [SW1] interface Vlan-interface 20 [SW1-Vlan-interface20] ip address 192.168.20.254 24

配完之后，display ip routing-table里应该能看到两条直连路由，比如 192.168.10.0/24 指向 Vlan-interface10。有这两条，VLAN 10 和 VLAN 20 之间就能互访了。

但这里有个前提：三层交换功能得开着。有些低端设备默认是二层模式，需要手动切到三层，或者用undo portswitch把某个物理口变成三层口。这个坑在混用不同型号设备时特别容易遇到——命令敲下去了，路由表里什么都没有，排查半天发现功能没开。

还有一点要提醒：SVI 接口的状态跟着 VLAN 走。如果某个 VLAN 里一个 up 的成员口都没有，SVI 就是 down 的，路由也不会生效。所以配完 VLAN 接口发现不通，先看这个 VLAN 里有没有活着的端口。

4.2 静态路由：简单但要写清楚下一跳

跨网段访问外部网络，靠静态路由或者默认路由。静态路由的写法是“目的网段 + 掩码 + 下一跳”。

[SW1] ip route-static 192.168.50.0 24 10.0.99.1 [SW1] ip route-static 0.0.0.0 0 10.0.99.1

第一条是去往 192.168.50.0/24，交给 10.0.99.1 处理。第二条是默认路由，所有路由表里找不到的目的地址，统统丢给 10.0.99.1。默认路由在出口设备上几乎是标配。

配静态路由最常见的错误是下一跳写成了自己的接口地址，或者写了一个不可达的地址。下一跳必须是直连网段里的对端地址，不能是任意地址。配完用display ip routing-table确认路由有没有生效，状态是不是 Active。再看display ip routing-table 192.168.50.0看具体这条的下一跳和出接口对不对。

路由有优先级的概念，数值越小越优先。直连路由优先级是 0，静态路由默认是 60。这意味着如果同一目的网段既有直连又有静态，直连生效。多條静态路由指向同一目的时，优先级低的生效。这个机制用来做备份：主链路一条低优先级，备链路一条高优先级，主链路断了备链路自动顶上。

4.3 DHCP：地址分配自动化与它的边界

几十台终端手动配 IP 不现实，DHCP 就是干这个的。三层交换机上开 DHCP 服务，按 VLAN 建地址池。

[SW1] dhcp enable [SW1] dhcp server ip-pool vlan10 [SW1-dhcp-pool-vlan10] network 192.168.10.0 mask 255.255.255.0 [SW1-dhcp-pool-vlan10] gateway-list 192.168.10.254 [SW1-dhcp-pool-vlan10] dns-list 223.5.5.5 [SW1-dhcp-pool-vlan10] expired day 3

几个参数值得说。network是地址池范围，跟 VLAN 网段一致。gateway-list是下发给终端的网关，就是 SVI 地址。dns-list下发 DNS 服务器。expired是租期，办公网三天足够，太短会导致频繁续租，太长会导致地址回收慢。

地址池要留出排除范围。网关、服务器、打印机、网络设备这些需要固定地址的，得在池子外面。如果不小心把网关地址也发出去，就会出现“某台电脑拿到了网关地址，然后全网访问异常”的诡异故障。查这种问题用display dhcp server ip-in-use，看地址分配情况，一眼就能发现冲突。

DHCP 还有一个隐蔽的坑：如果网络里存在多个 DHCP 服务器（比如有人私接路由器），终端可能拿到错误的地址和网关。防御手段是在接入端口上配 DHCP snooping，只信任上行口的 DHCP 应答，其他口的 DHCP 报文直接丢弃。这一步在办公网里非常有必要，能挡掉一大类“我上不了网”的报障。

4.4 出口与地址转换：把内网送出去

内网地址要访问外网，需要做地址转换。配置分两步：先定义哪些内网地址允许转换，再在出口接口上应用。

[SW1] acl basic 2000 [SW1-acl-ipv4-basic-2000] rule 0 permit source 192.168.0.0 0.0.255.255 [SW1-acl-ipv4-basic-2000] quit [SW1] interface GigabitEthernet 1/0/1 [SW1-GigabitEthernet1/0/1] nat outbound 2000

ACL 里的0.0.255.255是反掩码，表示前两段必须匹配，后两段任意。这个反掩码的概念让很多人卡住：它是 255.255.255.255 减去正常掩码的结果。255.255.0.0 的掩码，反掩码就是 0.0.255.255。理解了这个换算，ACL 就不难写了。

转换之后，内网终端出外网用的都是出口接口的公网地址。这时候如果内网有服务需要被外部访问，还要配端口映射，把特定端口转到特定内网地址。这块要注意安全边界，只映射必要的端口，映射完记得验证外部能不能通、内部访问是否正常。

5. 排障实录：不通、慢、断的排查路径

5.1 分层排查，别一上来就怀疑配置

网络不通，人的本能是去翻配置。但实际情况里，相当一部分问题出在物理层。我的排查顺序固定是：物理层、链路层、网络层、应用层。

物理层看什么？接口状态。display interface brief里，接口是 UP 还是 DOWN，速率和双工协商成什么。如果显示 DOWN，先查网线、光模块、对端口。如果显示 UP 但大量 CRC 错误，多半是网线质量或者接头问题，换一根线比改配置有用得多。

链路层看 MAC 和 VLAN。display mac-address能确认终端 MAC 有没有学到，学在哪个端口、哪个 VLAN。如果 MAC 学不到，说明二层没通；如果 MAC 学到了但 VLAN 不对，那就是端口配置问题。

网络层看地址和路由。终端 IP、掩码、网关对不对，设备上有没有对应的直连路由，跨网段的路由有没有。display arp看地址解析有没有成功，这一步失败往往是网段规划或者网关配错。

应用层才是端口、策略、DNS 这些。顺序错了，会在错误的方向上浪费大量时间。我见过有人为了一个网线没插好的问题，把整个 VLAN 配置推倒重来。

5.2 高频问题速查表

这张表是我这些年排障时最常翻的，实际用起来比背协议定义有效得多。遇到问题先对现象，再验原因，最后动手，别跳步。

5.3 我踩过的几个坑

第一个坑是 Trunk 口的 native VLAN 不一致。两台交换机互联，一端默认 VLAN 1，另一端被人改成了 VLAN 99，结果无标签帧在两端归属不同，出现间歇性丢包。这种问题排查起来极其费劲，因为 ping 大包丢、小包不丢，看着像 MTU 问题。后来用display port trunk两端对比才发现。教训是：互联两端的关键参数一定要逐项比对，别假设对方配得和你一样。

第二个坑是聚合口的成员口没清空原配置。我把两个口加进聚合组之前，其中一个口还残留着 access vlan 10 的配置，结果加进去之后聚合组状态一直不正常。后来先把成员口配置清干净再加组，问题消失。经验是：成员口加入聚合组之前，先default interface或者手动清掉无关配置。

第三个坑是 DHCP 地址池把网关地址发出去了。表现是某台电脑突然上不了网，查了半天发现它拿到的 IP 是网关地址，跟设备地址冲突。根因是地址池范围写成了全网段，没排除低位地址。从那以后，我配地址池一定先写排除范围，再写池子，顺序反过来容易忘。

第四个坑是save时机。有次远程改配置，改到一半网络断了，重连之后发现配置没保存，白干。后来养成习惯：远程操作前先确认带外管理或者本地 console 可用，改完立即验证，验证通过再save，而且save之前先display current-configuration扫一眼有没有多余的东西。

提示：所有配置变更，先在模拟器或者备用设备上跑一遍，确认命令没有语法问题、逻辑没有漏洞，再上生产设备。这个习惯能挡掉大部分低级事故。

6. 日常维护与配置管理的一点个人习惯

设备配通只是开始，真正麻烦的是后面的维护。我给自己定了几个固定动作。

每周导出一次配置文件，按日期命名存好，同时把display version和display interface brief一起存。这样设备出问题时，可以拿上周的基线跟现在比，差异就是这周发生的变化。这个习惯救过我两次，一次是发现有人偷偷改了 ACL 导致业务不通，一次是发现某个端口错误计数持续增长，提前换了模块。

配置变更走“改前备份、改后验证、验证通过再保存”的流程。改前备份是为了能回滚，改后验证是确认业务真的通了，不只是命令敲成功了。我见过太多“配置看着对但业务不通”的情况，命令返回成功不代表逻辑正确。

还有就是定期看日志。display logbuffer里如果反复出现某类告警，哪怕当前业务正常，也要当回事。接口频繁 up/down、MAC 漂移、CPU 占用告警，这些都是故障的前兆。等真断了再查，成本高得多。

最后一条是我自己的体会：文档比记忆可靠。每次配完一个稍微复杂的场景，比如双出口、跨设备聚合、多 VLAN 互联，我都会写几行记录，写清楚拓扑、地址规划、关键配置点和验证方法。过半年再回来看，这几行字能省下大量回忆时间。网络这东西，配的时候觉得都记住了，真出事的时候脑子里只剩一片空白。