做运维这些年，CentOS双网卡配置优先级这个事，真是看着简单，翻车率极高。不少人装完系统，两块网卡都配好了IP，一测发现内网通的、外网不通，或者明明两个网卡都在线，流量死活不走你期望的那张卡。更邪门的是，上午还行，下午重启了一下服务器，网络又乱了。这些问题说到底就一个根源：Linux路由表的选路逻辑。这篇文章从路由表的底层机制讲起，把CentOS双网卡优先级从原理到实操拆开揉碎，帮你彻底告别“一配双网卡就翻车”的尴尬局面。无论你是刚入门的新手，还是被这个问题折腾过几次的老手，这篇文章都值得你花十分钟看完。

1. 双网卡场景拆解：先搞清楚你到底想要什么

1.1 三种最常见的双网卡业务场景

配置优先级之前，先想清楚你的业务场景。我碰到过很多案例，一上来就问我“metric怎么设”，问完发现他压根连自己需要什么优先级都没说清楚。CentOS双网卡场景基本分三类，每类的配置思路完全不一样。

第一类是内外网隔离，最常见的场景。一张网卡接内网，地址段通常是比较私密的网段，网关是核心交换机的地址；另一张网卡接办公外网或业务专线，网关是出口路由器的地址。这种场景下，你希望内网流量走内网卡，公网流量走外网卡，两者互不干扰。核心诉求是“按目标网段分流”，不是简单设个默认路由就能完事。

第二类是双出口或双链路冗余。比如服务器同时接了电信和联通两条线路，或者接了主备两台出口路由器。这种场景下，你希望默认情况下流量走主线路，线路故障时自动切到备用线路。核心诉求是“默认路由的优先级切换”，需要设置不同的metric值，配合路由追踪或健康检查。

第三类是管理网和业务网分离。管理卡（通常带外管理）负责SSH和监控系统访问，业务卡负责真正的业务流量。这类场景一般要求管理卡有极高的优先级，哪怕业务网拥塞也不能影响远程运维。很多人把管理口和业务口配在一起，结果业务流量一爆炸，SSH直接卡死。

我建议你在动手前，先在纸上把下面几个问题写清楚：两张卡的IP是什么、各自网关是谁、哪些网段必须走哪张卡、默认流量走哪张卡、如果一张卡挂了希望什么表现。这些问题的答案直接决定你要用普通路由还是策略路由，也决定metric值怎么设置。

1.2 优先级背后真正做主的是“路由表”而不是“配置文件”

明确场景之后，你需要接受一个事实：Linux双网卡优先级不是由ifcfg文件决定的，而是由最终写入内核路由表的那条记录决定的。我见过很多人在ifcfg-eth1里写了GATEWAY=10.0.0.1，ifcfg-eth2里也写了GATEWAY=192.168.1.1，然后理直气壮说“我两个网关都配了啊”，完全没意识到系统只认一条默认路由。

打开终端输一行命令ip route show，你会看到类似这样：

default via 192.168.1.1 dev eth2 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.100 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.100

注意看default这一行，系统只会生成一条默认路由。如果两张网卡都配置了网关，系统按照配置文件加载顺序或者接口启动顺序，谁后加载谁就覆盖前者，或者直接报冲突。这就是双网卡优先级问题的根源。你换个思路就明白了：路由表就像一张导航地图，上面每个目的地只能有一条主路径。你想让去不同地方的车走不同的路，就得给导航地图加规则，而不是光在地图上画两条都指向“任意目的地”的默认路径。

所以接下来的难题就变成了两个：第一，怎么让内核生成一条正确的默认路由；第二，怎么让非默认流量走指定的非默认网卡。前者是metric值的活，后者是策略路由的活，两者配合起来才能真正搞定双网卡优先级。

2. 路由优先级机制详解：metric值决定默认路由的去留

2.1 什么是metric值，它到底怎么工作

metric在Linux路由表里叫“路由度量值”，通俗讲就是给路由排优先级的数字。数值越小，优先级越高。系统在选路时不会放弃任何一条到达同一个目的地的路由，而是比较它们的metric值，挑最小的那条用。

你需要重点注意的是：metric值不仅作用于默认路由（default），也作用于任何网段路由。但在实际双网卡配置中，最常被我们操练的就是默认路由的metric值，因为默认路由决定了所有“没匹配到明细路由”的流量方向。

先看一个基础输出。你用ip route show看到下面内容：

default via 192.168.1.1 dev eth1 metric 100 default via 10.0.0.1 dev eth2 metric 200

这种情况说明系统知道你配置了两个默认网关，它没有扔掉任何一个，而是给每条默认路由分配了一个权重。当eth1这条路由的链路正常时，所有默认流量走192.168.1.1；当eth1链路断了或者网关不可达时，系统自动改用metric值较大的eth2。这个机制对于双出口冗余场景非常重要，因为它天然提供了链路切换能力。

但你要特别小心一个陷阱：在没有指定metric值的情况下，CentOS默认给所有接口配相同的metric值（通常是0），如果出现双重default路由且metric一致，内核会随机挑一条，或者按接口名排序挑一条。这就导致你每次重启网络服务后，默认出口可能都不一样，非常坑。

2.2 网关冲突与默认路由覆盖的底层逻辑

作为运维必须理解一下CentOS网络配置的默认行为。在ifcfg-ethX文件里，你写了GATEWAY=之后，系统会把这条地址作为该接口的默认网关。但CentOS的network服务从/etc/sysconfig/network和各个ifcfg文件里收集网关地址时，遇到多个网关存在的情况，最终执行策略是“只保留最后一个被处理的”。接口激活顺序影响非常大，谁在最后谁就是默认路由的主人，和你的业务优先级毫无关系。

之前处理过一个案例。某公司的服务器上业务网卡接的是10.0.0.0/8网段，备份网卡接的是192.168.50.0/24网段。ifcfg-eth0配置了GATEWAY=10.0.0.1，ifcfg-eth1配置了GATEWAY=192.168.50.1。重启之后默认路由显示从eth1走，业务流量全被丢到备份网里，出不了外网。排查了半天，原因就是eth1后加载，把默认路由覆盖了。

解决办法有两个，一个是在ifcfg-eth1中删除GATEWAY字段，因为备份网段不必提供默认路由；另一个是给两个接口都显式设metric值，让内核明确知道主备优先级。

这里再说清楚一个概念：如果你只需要“默认走A网卡，故障切B网卡”，那就设置metric值。如果你需要“去这个网段必须走A网卡，去那个网段必须走B网卡”，那必须做两条明细路由或策略路由。很多人混用这两个概念，导致配出来的效果完全不符合预期。

3. CentOS双网卡优先级配置实操：从ifcfg到nmcli全呼

3.1 编辑ifcfg文件设置metric值的基础操作

CentOS系列配置网络的经典方式就是编辑/etc/sysconfig/network-scripts/ifcfg-ethX。假设你有一个场景：两张网卡，eth0接外网网关192.168.1.1，eth1接内网核心10.0.0.1。你的业务要求默认流量全走外网，内网流量走内网。那么配置思路是：明确指定eth0为默认路由，并给它更高的优先级（更小的metric值），同时在eth1上不要设默认网关，让它只产生内网网段路由。

eth0的ifcfg-eth0文件长这样：

DEVICE=eth0 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 METRIC=100

eth1的ifcfg-eth1文件长这样：

DEVICE=eth1 BOOTPROTO=none ONBOOT=yes IPADDR=10.0.0.100 NETMASK=255.255.0.0 # 不配置GATEWAY，避免产生第二条默认路由

这里有几个细节值得说道。第一，METRIC=这个参数并非所有CentOS版本都支持直接写在ifcfg文件里，CentOS 6/7的network服务部分版本支持，我一般在CentOS 7.4以上的系统里验证过没有坑。如果你用的老版本，建议配合ip route命令在启动脚本里追加设置更稳。第二，eth1不配置GATEWAY是关键操作，它避免了系统生成第二条default路由，从源头切断冲突。第三，BOOTPROTO=none表示接口不用DHCP自动获取，避免系统自动拿网关覆盖你手动设置的GATEWAY。

改完文件之后，执行systemctl restart network或nmcli con reload让配置生效。然后马上用ip route show确认默认路由记录是否正确，这是每次配置后必做的验证动作。

3.2 用nmcli命令行配置metric的现代姿势

现在很多CentOS 8/9环境我推荐直接用nmcli操作，不仅反馈更直观，持久化也更可靠。先查一下当前连接名：

nmcli connection show

假设外网连接叫eth0-conn，内网连接叫eth1-conn，你可以这样配置：

# 设置eth0的自动连接和静态配置 nmcli connection modify eth0-conn ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual # 设置外网卡的路由metric值，数值小优先级高 nmcli connection modify eth0-conn ipv4.route-metric 100 # 设置内网卡，只配IP不配网关 nmcli connection modify eth1-conn ipv4.addresses 10.0.0.100/16 ipv4.method manual # 我们可以在这个连接上添加一条明细路由，确保内网流量走内网卡 nmcli connection modify eth1-conn +ipv4.routes "10.10.0.0/16 10.0.0.1"

这里ipv4.route-metric就是ifcfg文件里METRIC参数的nmcli对应项。nmcli的好处是修改完立刻生效，不需要重启网卡。改完执行nmcli connection up eth0-conn和nmcli connection up eth1-conn触发一次更新，再看路由表确认。

如果你不想重启整个网络造成业务闪断，可以用nmcli device reapply eth0这种细粒度命令，只刷新指定接口。CentOS 8以上版本对NetworkManager的依赖更强，用nmcli是最省心的路径。

3.3 临时调整路由优先级的应急命令

有些场景下你不能重启网络服务，或者只是临时做个切换验证，那就得用ip route命令直接操作运行中的路由表。

假设当前默认路由走eth0（metric 100），你想临时把默认流量切到eth1测试一下，可以这样：

# 先删掉原来的默认路由 ip route del default # 新增一条走eth1的默认路由，metric设小点 ip route add default via 10.0.0.1 dev eth1 metric 50

这个操作立刻生效，但重启网络服务后失效，所以只适合应急。更精细的操作是替换指定metric值的路由：

# 把metric为100的默认路由替换成走新网关 ip route replace default via 192.168.1.1 dev eth0 metric 50

注意这个命令如果有多条default路由存在，你必须在命令里指定原来的dev和metric，否则可能报RTNETLINK answers: File exists错误。应急命令的另一个常见用途是强制让路由表重新加载，比如ip route flush cache，这可以在修改路由后立即清空缓存，避免旧路由被继续引用。

在我自己的维护清单里，应急命令确实用得不多，因为改完重启就丢；但排查问题时很有用，你可以快速测试“流量走哪张网卡后表现更符合预期”，找到最优配置后再持久化到文件里。

3.4 配置完成后你必须做的三项验证

配好了不等于真的好了。我见过太多人改完ifcfg就交差，结果流量根本没按预期走。验证双网卡优先级配置是否生效，至少做三件事，缺一不可。

第一，看路由表全貌，确定默认路由和关键明细路由的走向。执行ip route show，确认default行后面写的dev是你要的网卡，metric值也符合预期。再看有没有你不想出现的第二条default。同时用ip route show table all查看全部路由表（策略路由多的时候该命令特别有用）。

第二，测试内网和公网连通性。内网联通用ping -I eth1 10.10.0.1这种方式强制指定从哪块网卡发包。公网联通用ping -I eth0 223.5.5.5，或者用curl --interface eth0 http://检测地址指定出口。重点不是通不通，而是你指定的接口必须与预期一致。如果你不指定接口，ping默认走路由表选路，没法验证网卡分流是否正确。

第三，检查链路状态和丢包情况。用ethtool eth0查看接口速率和Link detected状态，用ip -s link show eth0查看收发丢包数。如果链路不稳定，什么优先级配置都是空中楼阁。cat /proc/net/bonding/bond0这类信息在看bond配置时也要一并确认。

我建议你把这些验证步骤写成一个固定操作清单，每次改完配置照着走一遍，能省掉大量二次返工。

4. 策略路由进阶：按来源地址分流才是双网卡高级玩法

4.1 为什么普通路由配置解决不了所有问题

前面讲的metric只能决定默认路由选谁，但现实中很多双网卡需求光靠默认路由的优先级根本解决不了。举个例子。服务器有内网卡eth1（192.168.10.0/24）和外网卡eth0（公网IP），内网有多个网段，包括192.168.20.0/24、192.168.30.0/24。如果你只配置内网网段的明细路由走eth1，其他流量全走eth0，看起来没问题。但如果是多个内网网关呢？比如192.168.10.0/24网段的网关是192.168.10.1，192.168.20.0/24网段的网关却是192.168.20.1？两个网关分属不同物理网段，这种情况下普通路由完全解决办法有限，因为它们的目标前缀不同，本来就能各自独立配置。

真正的难题是这种情况：同一个目标网段你希望从不同来源IP访问时走不同出口。比如公司要求来自192.168.10.0/24的流量访问公网走电信出口，来自192.168.20.0/24的流量访问公网走联通出口。这种需求下普通路由表只有一个default，它完全无法区分流量发起方的来源，你怎么改metric都没用。必须上策略路由，让数据包在进入路由选择之前先做一次“来源地址匹配”，命中规则后直接走独立的路由表，绕开主路由表。

这其实就像高速收费站分车道：所有车都往一个方向走，但不同车牌号段被引导到不同收费口，各自走自己的通道下高速。策略路由就是那个分流指示牌。

4.2 基于来源IP的策略路由配置全过程

CentOS上配置策略路由的核心是ip rule和ip route add table两个命令配合。逻辑分三步：创建独立路由表、往表里写路由规则、创建策略路由规则让特定来源流量走对应路由表。

第一步，编辑/etc/iproute2/rt_tables，给自定义路由表分配编号和名字：

10 eth0_table 20 eth1_table

这里的编号只要不与已有表冲突即可，命名随意但最好有业务含义。rt_tables文件本身没有什么复杂的逻辑，就是建立编号与名称的映射。

第二步，往自定义表里写入路由。假设我们要让来源为192.168.10.0/24的流量默认走eth0出口，来源为192.168.20.0/24的流量默认走eth1出口：

# 往eth0_table里写默认路由，指向外网网关 ip route add default via 192.168.1.1 dev eth0 table eth0_table # 往eth1_table里写默认路由，指向内网网关（实际是另一个出口网关） ip route add default via 10.0.0.1 dev eth1 table eth1_table

注意，这里的表名用我们刚定义的eth0_table。除了默认路由，最好再往表里补充该接口对应的链路路由，避免出现回包路由丢失：

ip route add 192.168.1.0/24 dev eth0 src 192.168.1.100 table eth0_table ip route add 10.0.0.0/8 dev eth1 src 10.0.0.100 table eth1_table

第三步，用ip rule添加来源匹配规则：

ip rule add from 192.168.10.0/24 table eth0_table priority 100 ip rule add from 192.168.20.0/24 table eth1_table priority 200

这里的priority数字是策略规则的先后顺序，数字小的先匹配。匹配到一条之后就进入该规则指定的路由表，不再往下走。所以你可以把最具体的规则优先级数字设小，把通用规则数字设大，确保精确优先。

设置完之后执行ip route flush cache清空路由缓存，然后ip rule show和ip route show table eth0_table检查效果。测试时从192.168.10.0/24网段的一台机器过来访问服务器的公网地址，观察回包是否走eth0；同时从192.168.20.0/24网段过来访问，观察回包是否走eth1。用tcpdump -i eth0 icmp和tcpdump -i eth1 icmp辅助抓包验证最直观。

4.3 策略路由的持久化方案与踩坑提醒

很多人在命令行里策略路由配得好好的，一重启全没了，原因很简单：ip rule和ip route add table只是运行时的临时命令，默认不会自动恢复。所以必须持久化。

CentOS下的持久化手段我试过几种，最靠谱的是自己写一个systemd服务来托管。先把所有策略路由命令写成一个脚本，比如/usr/local/sbin/policy-routing.sh，执行权限加好：

#!/bin/bash ip route add default via 192.168.1.1 dev eth0 table eth0_table 2>/dev/null ip route add 192.168.1.0/24 dev eth0 src 192.168.1.100 table eth0_table 2>/dev/null ip route add default via 10.0.0.1 dev eth1 table eth1_table 2>/dev/null ip route add 10.0.0.0/8 dev eth1 src 10.0.0.100 table eth1_table 2>/dev/null ip rule add from 192.168.10.0/24 table eth0_table priority 100 2>/dev/null ip rule add from 192.168.20.0/24 table eth1_table priority 200 2>/dev/null

注意2>/dev/null在重复执行时不那么重要，但如果命令已经在路由表中存在，不加这个会让脚本在第二次执行时报错。

然后在/etc/systemd/system/policy-routing.service里写：

[Unit] Description=Policy routing rules After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/local/sbin/policy-routing.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target

最后systemctl daemon-reload，systemctl enable --now policy-routing.service。这样开机后会在网络完全在线之后把策略路由规则跑一遍。

这里有几个容易踩的坑必须提醒你。第一，不要用network服务启动时的post-up脚本来加载策略路由，因为网络服务重载时可能还没完全就绪，路由表写入时机不对就失败。第二，如果同时配合NetworkManager管理网卡，配置NetworkManager本身对自定义路由表的支持很有限，建议以systemd服务方式独立管理策略路由。第三，ip rule里如果没有指定priority，系统会按规则添加顺序生成不唯一的优先级数字，容易导致规则匹配顺序混乱。第四，rt_tables文件里的表名和数字不要与系统内置表（如local表255、main表254）冲突。

4.4 结合metric值和策略路由设计一个完整方案

讲到这里你可能会问：metric和策略路由到底怎么配合？如果策略路由已经能搞定分流，为什么还要metric？我的回答是：metric负责“兜底”，策略路由负责“精确”。

举个例子。服务器有eth0外网网关192.168.1.1，eth1内网网关192.168.100.1。你希望来自192.168.20.0/24的流量从eth1出，其余所有流量从eth0出。方案设计如下：main路由表里设默认路由走eth0，metric为100；eth1的默认路由设到独立表里，只在匹配策略规则时使用。然后配置策略规则：来源192.168.20.0/24的表table100里写默认路由走eth1。

这样做的意义在于，即使有遗漏的流量或者策略规则没匹配上，它们都会落到main表兜底走eth0，不会因为策略表缺失就导致网络完全不通。这种“兜底+精确”的设计方式在实际生产环境中让我少背了很多锅。

同时，eth0的metric值可以设更小（如100），eth1的metric值设大（如200），但要注意ifcfg文件里设置metric只影响main表，不影响自定义表，所以策略路由中的不同路由表按需定义即可，不用刻意通过metric控制。

5. 双网卡优先级配置常见问题与排查技巧实录

5.1 重启后路由配置丢失

这应该是双网卡问题里出现频率最高的，几乎每周都有同事问我。表现是：重启前用ip route配置好的路由全部正常，重启后只剩一条链路路由，默认路由不见踪影，或者默认路由变成了错误的网卡。

排查思路分三步走。第一，检查ifcfg文件中的GATEWAY配置，看是否有多个接口都配置了网关。如果有，删掉多余网卡的网关字段，只留真正需要走默认路由的那个。第二，检查/etc/sysconfig/network里是否也配置了GATEWAY=，这个全局配置会覆盖所有ifcfg文件里的网关设置，如果两边不一致，以全局为准。第三，确认NetworkManager是否接管了网络接口。如果NM接管了，ifcfg文件里的部分传统参数可能不生效，需要改用nmcli来管理。

如果出现的是“路由表有default但PID开机后没有自动恢复策略路由”，那就是持久化没做好，参照前面4.3节的systemd方案解决。

5.2 两个网卡同网段导致路由混乱

这就是“双网卡同段互搏”的经典坑。比如eth0和eth1都是192.168.1.0/24网段的地址，且都配置了网关。这种情况下系统路由表只会生成一条192.168.1.0/24的链路路由，它不属于特定接口，但内核根据接口负载和MAC地址选择出口，经常出现奇奇怪怪的丢包。

我的建议是：避免在服务器上让两张网卡处于同一网段，除非你有极强的理由（比如bonding）。如果无法避免，至少要把其中一张卡的网关删掉，只保留一张卡的默认路由。如果确实需要两张卡同网段做负载均衡，那就老老实实用bonding方案，而不是硬靠路由规则。

排查时用ip addr show确认两张卡是否同一网段，arping检测网关的MAC地址是否在原配置的网卡上。曾经有个案例，网关设备做了主备切换，对应MAC地址发生漂移，服务器因为ARP缓存没能正确更新，导致数据包发到了旧的网卡，怎么折腾路由表都没用，最终清了ARP缓存才解决。

5.3 网卡都up但流量仍然不通

遇到这个情况先别慌，按下面顺序逐项排查。第一，确认物理链路没问题，ethtool eth0看到Speed和Duplex正常，Link detected为yes。第二，检查IP地址配置，ip addr show确认IP、掩码是否正确。第三，检查路由表，确认目标网段有匹配的路由。第四，测试网关连通性，ping -c 3 网关IP，但要注意有些防火墙ICMP不可达，不一定代表网关不转发。

如果以上都正常还是不通，就要用到抓包了。在对应网卡上tcpdump -i ethX icmp观察是否有请求包发出、是否有回应包收到。如果发出去了没有回应，查路由和网关NAT；如果回应包到了但系统没回，查反向路由过滤（rp_filter）是否太严格。CentOS默认开启rp_filter的严格模式，如果两张网卡路由不对称，很容易丢包，可以临时sysctl -w net.ipv4.conf.all.rp_filter=0验证，确认后通过/etc/sysctl.conf持久化。

5.4 策略路由配置了但完全不生效

这是一个很容易误导自己的问题。现象是ip rule能看到规则，ip route show table xxx也有内容，但流量就是不按规则走。

第一个可能原因是策略规则的优先级设置得不合理。ip rule show输出的优先级数字如果默认是0，那会直接命中local表，后面自定义规则根本没机会执行。我建议显式给出priority值，并且数字不要太大，一般50~200之间比较合适。第二，检查是不是用错了from参数。ip rule add from匹配的是源IP，如果你测试流量经过NAT转换了源地址，那么规则匹配不到源IP。这时候要考虑用iif（入接口）参数去匹配。第三，确认策略路由表里到底有没有对应的默认路由，有的脚本只加rule不加route，必然无效。

排查命令我推荐用ip route get 8.8.8.8 from 192.168.10.100。它会告诉你8.8.8.8的流量从哪个源地址、哪个网卡、走哪条路由出去。这条命令是调试策略路由的神器，输出中会精确显示via、dev、table等关键信息。

5.5 DNS和路由选路之间的隐性冲突

双网卡配置优先级不只是路由表的事，DNS解析出错在外网卡和内网卡切换时很容易被忽略。典型场景是内网DNS地址是10.x.x.x，公网DNS地址是114.114.114.114。当默认路由切到内网卡后，外网DNS解析超时；切到公网卡后，内网域名解析失败。

我整理过一份通用排查对照表，贴出来供你参考。

5.6 一个典型的双网卡排障实战记录

最后分享一个我最近处理的案例。某公司一台CentOS 7服务器，双网卡，eth0接办公网，eth1接业务网。业务反馈服务器访问业务网网关时通，但访问业务网另一网段时不通。SSH登录上去排查，ip route show发现只有默认路由走eth0，没有任何走eth1的路由。这说明eth1虽然配置了IP，但从未写入任何关于业务网段的明细路由。

进一步检查ifcfg-eth1，发现ONBOOT=no被注释了，改成yes后重启网络服务，ip route show立刻出现了业务网段的明细路由。之后业务访问恢复正常。这个案例说明，双网卡优先级问题不总是“设置不对”，有时候是接口没有随系统启动，导致路由表根本缺失相关条目。

遇到类似问题，我养成了一个习惯：先看ip addr show确认所有网卡都拿到IP，再看ip route show table main确认路由完整性，最后用ping -I指定网卡测试。三步下来，90%的问题都能快速定位。

写在最后的实操建议

双网卡优先级配置的核心就是一句话：路由表里有什么路由，流量就走什么路。Metric值控制默认路由的优先级，明细路由和策略路由控制特定流量走向，持久化方案保证重启后不丢配置。我在实际配置中始终坚持一个原则：能简单就不上策略路由，能用metric解决就不写table，只有业务确实需要多出口分流时才启用策略路由。

最后再送大家一个实用技巧：配置完路由后，可以用ip route save把所有路由表内容保存到文件，出问题时ip route restore快速恢复，这在调试初期特别省事。任何配置改动前，先备份原文件，改完立即验证，验证通过后再批量应用到其他服务器，这是运维最基本的保命法则。