上个月接手了一批预装 KeyarchOS（浪潮信息云峦操作系统，简称 KOS）的服务器，业务方要求当天晚上完成网络初始化：两块网卡做 bond、按机房拓扑划两个 VLAN、配好默认路由和 DNS。说实话，第一次独自动这套系统时我心里是有点打鼓的——毕竟之前主要碰 CentOS，而 KOS 在服务器圈里虽然不算冷门，但网上针对网络配置的实操记录确实比较零散。
跑完几个机柜、踩过几个坑之后，我把整个网络配置过程整理成了这篇操作笔记。它适合刚接手 KOS 的运维同学，也适合从 CentOS/RHEL 或 openEuler 切换过来、想直接照着做的人。里面没有太多理论包装，全是能直接敲进终端的命令和配置。
1. 先搞清楚KOS里的网络栈由谁接管：NetworkManager、ifcfg文件和它们的分工
1.1 为什么第一步要先看“谁在管网络”
KOS 面向数据中心和云场景，默认的网络管理方式是 NetworkManager（以下简称 NM），同时对传统的 ifcfg 文件体系做了很好的兼容。这意味着你在/etc/sysconfig/network-scripts/下看到的ifcfg-*文件依然有效，但真正决定网卡状态的是 NetworkManager。
我见过不少从 CentOS 6/7 过来的人，上来就直接vim /etc/sysconfig/network-scripts/ifcfg-eth0，改完 IP 之后执行systemctl restart network，结果系统提示找不到服务，或者配置确实生效了、但一重启机器 IP 又没了。根因就是对这套“NM 接管 ifcfg 文件”的机制不熟。
KOS 里NetworkManager服务默认是开着的，你可以用下面几条命令确认当前系统的网络管理栈：
systemctl status NetworkManager nmcli general status ls /etc/sysconfig/network-scripts/如果看到NetworkManager处于active (running)，那后面所有操作都以 NM 为中心。
1.2 ifcfg文件与NetworkManager的配合关系
KOS 中 ifcfg 文件并不是“废弃”的，NM 会动态读取ifcfg-*文件并把它转化为内部连接（connection）。所以改完 ifcfg 文件后，你需要让 NM 重新加载，而不是傻等：
nmcli connection reload nmcli connection up ens3我个人的理解是：ifcfg 文件是“持久化存储”，NM 是“运行时管家”，两者通过nmcli connection这条线同步。你在命令行用nmcli connection add/modify做的修改，最终也会写回 ifcfg 文件。
反过来也一样：手动改了 ifcfg 文件但没执行reload，nmcli看到的连接信息还是旧的，这往往就是“文件里明明改了，但就是不生效”的原因。
1.3 上手前的四板斧
在动任何配置之前，我建议先把当前网络现状完整看一遍，免得后面改完找不到原始状态：
ip addr show ip route show nmcli connection show hostnamectl这四条命令分别告诉你：IP 地址和网卡状态、路由表、NM 认识的连接配置、主机名。我每次接手一台新 KOS 机器都会先把这四样输出存到一个临时文件里，作为配置前的“基线”。出问题的时候翻回来对比，效率高很多。
2. 第一台KOS入网：主机名、静态IP和DNS的配置链路
2.1 设置主机名：别只敲 hostnamectl
每台服务器都应该有明确的身份标识。KOS 上修改主机名非常简单：
hostnamectl set-hostname kos-node-01但这里有个容易被忽略的细节：hostnamectl只改了系统层的主机名，/etc/hosts里如果还写着旧主机名，很多依赖本地解析的程序（比如部分集群软件、sudo、邮件服务）会取到不一致的结果。
所以我的习惯是改完hostnamectl之后，顺手把/etc/hosts里的对应行更新一遍：
cat /etc/hosts # 将 127.0.1.1 后面的旧主机名改为 kos-node-01如果你不确定当前生效的主机名，用hostname和hostnamectl都看一眼，两个输出一致才算改完。
2.2 静态IP配置：先用nmcli，再用ifcfg理解原理
服务器场景下基本都要配静态 IP，而不是 DHCP 自动获取。在 KOS 上我推荐先掌握nmcli命令行方式，因为它是最不容易出错、也最适合批量操作的路径。
假设我的业务网卡是ens3，要配 IP10.10.100.11/24，网关10.10.100.1，DNS 用10.10.100.2和114.114.114.114：
nmcli connection add \ con-name prod-data \ type ethernet \ ifname ens3 \ ipv4.method manual \ ipv4.addresses 10.10.100.11/24 \ ipv4.gateway 10.10.100.1 \ ipv4.dns "10.10.100.2 114.114.114.114"这里我给连接取了一个自定义名字prod-data，而不是默认的ens3。这个习惯很重要：连接名是一个逻辑标识，你可以随时把连接从ens3换绑到别的物理网卡上，业务配置不用重写。
随后激活这条连接：
nmcli connection up prod-data2.3 直接编辑ifcfg文件：适用批量脚本和版本管理
如果你需要批量生成几十台机器的网络配置，或者想把配置纳入 Git 管理，直接写 ifcfg 文件反而更直观。KOS 上对应的文件是/etc/sysconfig/network-scripts/ifcfg-ens3，一个完整的静态 IP 配置长这样：
TYPE=Ethernet BOOTPROTO=none NAME=ens3 DEVICE=ens3 ONBOOT=yes IPADDR=10.10.100.11 PREFIX=24 GATEWAY=10.10.100.1 DNS1=10.10.100.2 DNS2=114.114.114.114 DEFROUTE=yes写完之后按前面说的执行nmcli connection reload，再nmcli connection up ens3。
有几个字段我想额外解释一下：
BOOTPROTO=none：明确关闭 DHCP，改成静态配置。如果是dhcp，IPADDR会被忽略。ONBOOT=yes：开机自动激活该网卡。我踩过最蠢的坑就是这里漏写yes，重启后机器完全失联，只能带外管理口进去改。PREFIX=24：等价于NETMASK=255.255.255.0，但 KOS 上我更推荐PREFIX，简洁不易错。DEFROUTE=yes：允许这条连接写入默认路由。如果你有多条连接，只有一条可以设yes，否则默认路由会互相“打架”。
2.4 两种方式怎么选：我的判断标准
| 对比项 | nmcli 命令 | 直接编辑 ifcfg |
|---|---|---|
| 适合场景 | 单台调试、交互式配置、动态修改 | 批量生成、配置入库、版本管理 |
| 学习成本 | 中等，命令多但可补全 | 低，字段死记即可 |
| 出错概率 | 低，NM 会做校验 | 中等，字段拼写或引号容易错 |
| 是否立即生效 | 需要up激活 | 需要reload+up |
给新人的建议：先学nmcli，把命令跑通之后再回头看 ifcfg 文件里被自动写入了什么，这样理解最扎实。给老手的建议：批量场景直接用脚本写 ifcfg，但写完一定要校验一遍ONBOOT和BOOTPROTO。
3. 多网卡bond实践：从物理口到bond0的完整步骤与验证
3.1 为什么服务器上一定要做bond
数据中心里的服务器通常至少有两块物理网卡。做 bond 的核心目的有两个：一是链路冗余，一块网卡或一根网线挂了，业务流量自动切换到另一块，不中断；二是提升吞吐，把两块网卡的带宽汇聚起来，比如两块 25G 网卡 bond 后逻辑上变成一条 50G 的管道。
KOS 对 Linux 内核标准的 bonding 驱动支持得很好，不需要额外装包，确认模块加载即可：
modprobe bonding lsmod | grep bonding如果lsmod没有输出，说明模块没加载，但一般不会，因为内核默认就编译进去了。
3.2 用nmcli完成bond0的完整配置流程
这里我用两块网卡ens3和ens4做例子，bond 模式选active-backup（主备模式），逻辑 bond 口叫bond0。
先创建 bond 连接：
nmcli connection add \ type bond \ con-name bond0 \ ifname bond0 \ mode active-backup \ bond.options "miimon=100,use_carrier=1"解释一下两个参数：
miimon=100：每 100 毫秒检测一次链路状态。这个值太短会误判抖动，太长则故障切换慢，我这边生产环境基本都用 100。use_carrier=1：以网卡物理载波状态作为判断依据，比单纯发探测包更可靠。
接下来把两块物理网卡“挂”到 bond0 上：
nmcli connection add type ethernet con-name bond0-slave-1 ifname ens3 master bond0 nmcli connection add type ethernet con-name bond0-slave-2 ifname ens4 master bond0最后给 bond0 配置 IP：
nmcli connection modify bond0 \ ipv4.method manual \ ipv4.addresses 10.10.200.10/24 \ ipv4.gateway 10.10.200.1 \ ipv4.dns "10.10.100.2"全部执行完后把 bond0 拉起来：
nmcli connection up bond03.3 验证bond是否正常工作：别只盯ifconfig输出
很多人配完 bond 只看ip addr里有没有bond0，这远远不够。我每次都要进到内核 bonding 的虚拟文件里看真实状态：
cat /proc/net/bonding/bond0这个文件会明确告诉你：
Bonding Mode：当前运行模式，比如IEEE 802.3ad Dynamic link aggregation（对应 mode 4）或active-backup。MII Status：每个 slave 是up还是down。Active Slave：当前实际承载流量的物理口是谁。
如果看到某一个 slave 的MII Status是down，先别急着换网线，可能是对端交换机端口没配好，或者miimon检测策略太严格。另外可以用ethtool ens3查看网卡速率和自协商状态，确保物理链路本身是正常的。
3.4 bond模式怎么选：看你的交换机支持什么
| 模式 | 名称 | 特点 | 适用场景 |
|---|---|---|---|
| mode 0 | balance-rr | 轮询负载均衡，需要交换机支持 | 很少用，跨交换机场景有乱序风险 |
| mode 1 | active-backup | 主备冗余，同一时刻只有一块网卡工作 | 最稳妥，不挑交换机，强烈推荐 |
| mode 4 | 802.3ad | 动态链路聚合，两块网卡同时收发 | 交换机需开启 LACP，吞吐最高 |
如果你暂时无法确认交换机配置，我建议先选mode 1，它不需要交换机做任何特殊处理，只要两根网线都通就行。等网络侧把 LACP 配好，再改mode 4也不迟：
nmcli connection modify bond0 bond.options "mode=802.3ad,miimon=100,use_carrier=1" nmcli connection reload nmcli connection up bond0改模式之后一定再看一眼/proc/net/bonding/bond0，确认协商成了802.3ad，而不是嘴上说了算。
4. VLAN子接口和路由：把一张物理网卡拆成多个逻辑网络
4.1 在KOS上创建VLAN子接口的两种方式
服务器经常要“一卡多用”：同一块物理网卡，既要跑管理网段，又要跑业务网段，甚至还要跟存储网络通信。这时候 VLAN 就派上用场——交换机的 trunk 口把带 VLAN tag 的帧送进来，服务器侧拆出多个逻辑子接口。
假设物理网卡是enp3s0，要创建 VLAN 100 和 VLAN 200 两个子接口：
nmcli connection add \ type vlan \ con-name vlan100 \ ifname enp3s0.100 \ vlan.id 100 \ dev enp3s0 \ ipv4.method manual \ ipv4.addresses 10.10.100.11/24ifname写成enp3s0.100是 Linux 下 VLAN 子接口的命名惯例，点号后面的数字对应 VLAN ID，光看名字就能知道是哪个网络，排障时非常方便。
如果你习惯用 ifcfg 文件，创建/etc/sysconfig/network-scripts/ifcfg-enp3s0.100：
DEVICE=enp3s0.100 NAME=enp3s0.100 TYPE=Vlan PHYSDEV=enp3s0 VLAN_ID=100 BOOTPROTO=none IPADDR=10.10.100.11 PREFIX=24 ONBOOT=yes创建完子接口后，用ip link show能看到类似这样的输出：
enp3s0.100@enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP@enp3s0表示这个 VLAN 子接口依附于哪块物理网卡。如果状态不是UP，检查一下物理网卡状态和交换机 trunk 配置。
4.2 默认路由和静态路由：让数据包按预期走
VLAN 配好之后，最关键的是路由。KOS 默认会根据网卡配置生成一条默认路由，但真实生产环境里经常需要一些“特殊路径”，比如访问某个测试网段要走另一条链路。
先看当前路由表：
ip route show默认路由一般长这样：
default via 10.10.100.1 dev enp3s0.100如果要加一条静态路由，比如访问10.20.0.0/16网段要走10.10.200.1，且从enp3s0.200出去，可以临时敲：
ip route add 10.20.0.0/16 via 10.10.200.1 dev enp3s0.200但这只是临时的，重启即失效。要持久化，我习惯在 ifcfg 目录下新建一个路由文件/etc/sysconfig/network-scripts/route-enp3s0.200：
10.20.0.0/16 via 10.10.200.1 dev enp3s0.200写完后nmcli connection reload。下次开机，KOS 会自动加载这个文件里的静态路由。
4.3 策略路由：当一台服务器需要多张路由表时
有一种场景静态路由解决不了：服务器有两条线，业务流量希望默认走10.10.100.1，但来自某个特定网段的流量必须走10.10.200.1。普通路由表只有一个，数据包无法区分“来源”。
这时候要用策略路由，也就是多路由表。先创建一个新路由表，比如编号 100：
ip rule add from 10.10.200.0/24 table 100 ip route add default via 10.10.200.1 dev enp3s0.200 table 100ip rule的意思是：凡是源地址属于10.10.200.0/24的数据包，去查询table 100里的路由规则，而默认路由表只处理其他流量。
KOS 上持久化策略路由的话，依然写在/etc/sysconfig/network-scripts/route-enp3s0.200里：
default via 10.10.200.1 dev enp3s0.200 table 100同时在/etc/iproute2/rt_tables里给 100 起个名字也行，但大多数人直接用数字，简单不额外维护。
4.4 验证连通性：ping、traceroute、ip route get 组合使用
配置全做完之后，不要只敲ping 网关就完事。我推荐按这个顺序验证：
ping -c 3 10.10.100.1 ip route get 10.20.0.1 traceroute -n 10.20.0.1ip route get特别有用：它会把内核实际计算出来的出接口和下一跳直接告诉你，比如：
10.20.0.1 via 10.10.200.1 dev enp3s0.200 src 10.10.200.10如果这条输出和你预期不一样，那就说明前面某个环节配错了。traceroute则负责定位是哪个跳数丢包，把问题范围缩小到交换机还是服务器。
5. 配置完不等于配完：重启失效、网卡命名和排障三板斧
5.1 这里有一份我攒下来的KOS网络踩坑清单
| 现象 | 根本原因 | 解决办法 |
|---|---|---|
| 重启后 IP 丢失 | ONBOOT=no或 NM 未托管该连接 | 改成ONBOOT=yes，nmcli con up |
| 改了 ifcfg 不生效 | 没执行nmcli connection reload | 改完马上reload，再up |
| 网卡名变了导致脚本失联 | 命名规则从eth0变成enp3s0 | 用ifcfg里的DEVICE和NAME固定匹配 |
手动改了/etc/resolv.conf被覆盖 | NM 接管 DNS 管理 | 在 ifcfg 或nmcli里改 DNS |
| bond 主备切换不生效 | miimon没配或交换机不支持 | 确认内核参数和交换机端口为 trunk |
| 多个连接争抢默认路由 | 多条连接的DEFROUTE=yes | 只保留一条默认路由 |
这张表是我在实际维护 KOS 机器时真金白银踩出来的，每一个都可以对应到一个具体的深夜排障场景。
5.2 网卡命名规则：别再写死 eth0
KOS 沿用了现代 Linux 的可预测命名规则，常见的有ens3、enp3s0、eno1。这些名字不是随便生成的，而是根据网卡的 PCI 物理位置、板载信息等规则固化下来的，好处是同一个网口在每次开机后名称稳定。
但也带来一个小问题：很多人习惯在脚本里写死eth0，到 KOS 上一跑就报错。我的建议是，脚本里尽量通过nmcli connection show拿连接名，或者用ip link先确认实际网卡名再操作，不要拍脑袋猜。
如果非要用传统的eth0命名，可以加内核启动参数net.ifnames=0，但我不推荐，因为会丢失可预测命名的排障优势，而且和集群里其他机器不一致时特别难受。
5.3 排障三板斧：从现象到根因的思路
网络不通的时候，先不要急着反复重启网卡。我总结了一个固定的排查链路：
第一步，确认网卡和连接状态：
nmcli device status ip addr show如果看到网卡state unmanaged，说明 NM 没有托管这块网卡，这时无论你怎么配 IP 都不会生效。原因一般是 ifcfg 文件里缺少NAME和DEVICE，或者连接没有正确导入。解决办法是先nmcli dev set ens3 managed yes，再reload。
第二步，确认路由决策：
ip route get <目标IP>这一步能把问题聚焦到“路由没走对”还是“下一跳不通”。如果ip route get出来的接口不是你以为的那个，那就是路由表配置有误。
第三步，抓包验证：
tcpdump -i enp3s0.100 icmp -c 5看到 ICMP 请求发了出去、但没有回应，说明是物理链路上二层/三层的问题；如果 tcpdump 根本看不到包，那就是本地路由或网卡状态问题。抓包一上，问题归属立刻清晰。
5.4 我的备份与回滚习惯
最后给各位一个实用建议：动 KOS 网络配置之前，先把整目录备份一份：
cp -a /etc/sysconfig/network-scripts /root/network-scripts.bak.$(date +%Y%m%d%H%M)以后任何一次改完发现不对劲，直接把备份目录整体拷回去，再执行：
nmcli connection reload systemctl restart NetworkManager就能回到改动前的状态。这个习惯我坚持了很多年，救过我不止一次。KOS 的网络配置方式和 RHEL/openEuler 高度一致，一旦把 NetworkManager 这套托管关系摸透了，你完全可以把这套操作流程复制到整个机房的几百台机器上，后续再用脚本批量生成 ifcfg 文件，运维效率会高很多。