业务、管理、存储三类流量需通过多网卡物理/逻辑隔离，分别承载于专用平面：业务平面高带宽、管理平面高安全、存储平面低延迟，并配合子网划分、策略路由与分平面防护实现“分得清、走得对、扛得住”。
多网卡不是插上就完事，关键在“分得清、走得对、扛得住”。业务、管理、存储三类流量混跑一张网卡，轻则性能下降，重则安全失守或故障扩散。真正有效的架构，是让每类流量走专属路径，彼此隔离又协同有序。
明确网卡用途与平面划分
先别急着配IP，先想清楚每块网卡承担什么角色。企业级常见四平面划分：
- 业务平面：承载用户请求、API调用等生产流量，通常走公网或内网业务VLAN，带宽要求高，需配置合理MTU（如1500）
- 管理平面：SSH、监控、日志采集、远程KVM等，必须独立物理通道，建议使用带外管理（OOB），安全等级最高，可设低带宽但高可靠性
- 存储平面：iSCSI、NFS、Ceph OSD通信等，对延迟和吞吐敏感，推荐启用Jumbo Frame（MTU 9000），避免小包碎片影响IO效率
- 集群/同步平面（可选）：数据库心跳、分布式锁、节点间状态同步等，需低延迟、高可用，常单独划VLAN并禁用ARP广播以减少干扰
子网与路由策略必须配套设计
只配IP不配路由，等于给车装了四个轮子却没画车道线。每个网卡对应一个子网，且子网之间不能重叠；默认网关只能归属一个出口，其余网段必须靠静态路由或策略路由显式引导。
- eth0（业务）配203.0.113.10/24，默认网关指向公网出口
- eth1（内网业务）配10.0.1.10/24，添加
ip route add 10.0.0.0/8 via 10.0.1.1 dev eth1 - eth2（管理）配172.16.1.10/24，添加
ip route add 172.16.0.0/16 via 172.16.1.1 dev eth2 - eth3（存储）配192.168.100.10/24，不设默认网关，仅允许访问后端存储网段（如192.168.101.0/24）
这样，系统就知道：访问10.x网段走eth1，管理操作走eth2，存储读写只认192.168.100.x，不会误入其他平面。
用策略路由（PBR）替代单一路由表
当多个网卡都连通不同网络时，Linux默认只用main路由表，容易导致“该走eth1的包走了eth0”。解决办法是启用策略路由，按源地址分流：
- 编辑
/etc/iproute2/rt_tables，新增三张表：200 business、201 mgmt、202 storage - 为每张表添加对应默认路由，例如：
ip route add default via 203.0.113.1 dev eth0 src 203.0.113.10 table business - 绑定规则：
ip rule add from 203.0.113.10/32 table business，同理为管理IP和存储IP分别添加rule - 验证用
ip rule show和ip route show table business
这套机制确保：从业务IP发出的包，强制查business表；管理登录来源，永远走mgmt表——彻底规避出口混乱。
基础防护与可观测性不能少
平面隔离不只是逻辑划分，还要有实际防护和监控支撑：
- 关闭非必要接口的IPv6和ICMP重定向：
sysctl -w net.ipv6.conf.ethX.disable_ipv6=1、net.ipv4.conf.ethX.accept_redirects=0 - 为各平面配置独立防火墙规则（如nftables），例如存储平面只放行iSCSI端口（3260），管理平面只允许可信IP的SSH
- 用
ss -tuln和ip -s link show ethX定期检查各网卡收发包统计，异常丢包或错包能快速定位是驱动、线缆还是交换机问题 - 在Prometheus+Node Exporter中为每个网卡单独打标，实现带宽、错误率、队列长度的分平面监控
不复杂但容易忽略。
