场景:
公司业务在一个新的云平台上线，该云平台使用的是比较传统的VMware vSphere来做的虚拟化，而且该云平台网络也是我们不清楚的，反正就是不能设置(不能像现在主流云平台自定义网络或者是地址段)，是一个政府的云平台，具体各种奇葩的限制就不说啦，你懂的……
根据我们自身业务的需求，我们需要一个内网地址段，和对方协商后给我们开了一个10网段，20的子网，然后要了两台带有外网ip的服务器，一个用来做跳板机，一个用来做反向代理。然后等了两天对方吧服务器给我们开好了，我们登录跳板机，发现只有外网ip的服务器才能上网，其他的均不能上网，做nat也不能上，但是跳板机是公网，没有内网，可以通内网的ip服务器，所以猜测网络策略肯定是他们在交换机上做的。然后我们自己yum源来安装一些中间件。（不说了，后面还有一堆的奇葩问题，进入正题吧）
后期问题
当我们把业务部署上线以后，运行一段时间后出现微服务之间调用超时，然后我们登录服务器排查网络问题，在服务器之间ping内网没问题，ping注册中心、数据库都没问题。服务器有公网，然后公网之间ping都没问题，网络层面没有任何的问题，查看系统日志也有发现错误，然后单独的吧借口地址拿出来进行curl能过但是有点慢，然后就吧这个命令写在脚本里面，让他每30秒跑一次，然后追加日志，跑了两三个小时，我们查看日志，日志里面也有超时现象，奇怪了，然后吧这个问题联系对方云平台的工程师，系统工程师、网络工程师拉群讨论，最后对方系统工程师提示我们让我们吧路由的Metric值两个网卡不要一样，对Metric刚开始一年懵逼，先不管，解决问题再说：
修改Metric(内网卡)
1
2
3$ route -n
$ sudo route add -net 10.10.20.0/22 dev ens160 metric 98
$ sudo route del -net 10.10.20.0/22 dev ens160 metric 100记住是先添加删除，顺序不要颠倒
查看路由
1
2
3
4
5
6$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 119.126.116.254 0.0.0.0 UG 100 0 0 ens192
10.10.20.0 0.0.0.0 255.255.252.0 U 98 0 0 ens160
119.126.116.128 0.0.0.0 255.255.255.128 U 100 0 0 ens192ens192(外网卡)
ens160(内网卡)
涉及到的业务服务器都修改，修改Metric值以后，我们curl一次，速度比以前快多了，又跑了一次脚本，观察了几个小时没问题，观察了两天，业务没有出现问题，日志里面也没有出现超时，问题得到解决
Metric 介绍
为路由指定所需跃点数的整数值（范围是 1 ~ 9999），它用来在路由表里的多个路由中选择与转发包中的目标地址最为匹配的路由。所选的路由具有最少的跃点数。跃点数能够反映跃点的数量、路径的速度、路径可靠性、路径吞吐量以及管理属性。Metric的值越小，优先级越高；如果两块网卡的Metric的值相同，就会出现抢占优先级继而网卡冲突，将会有一块网卡无法连接
更多介绍参考
