ESXi网络配置踩坑实录：给Ubuntu虚拟机加第二张网卡后，为什么上不了网了？

ESXi双网卡配置实战：从故障排查到原理剖析

最近在实验室搭建测试环境时，遇到一个典型问题：给Ubuntu虚拟机添加第二块网卡后，不仅新网络无法访问，连原有网络也断了。这让我意识到，ESXi网络配置远不止"添加网卡-分配IP"这么简单。本文将结合实战案例，拆解双网卡配置中的四大关键陷阱，并给出可复用的解决方案。

1. 虚拟交换机的绑定误区：冗余≠负载均衡

很多新手容易混淆物理交换机与虚拟交换机的行为差异。在物理网络中，将两个网口接入同一交换机可以实现带宽叠加；但在ESXi的标准交换机(vSwitch)中，多网卡绑定默认采用故障切换策略而非负载均衡。

# 查看当前vSwitch绑定策略 esxcli network vswitch standard policy failover get -v vSwitch1

典型错误配置表现为：

  • 将两张物理网卡(vmnic)绑定到同一vSwitch
  • 未配置任何负载均衡策略
  • 误以为两张网卡会同时工作

实际上，这种配置会导致：

  1. 默认激活vmnic0作为主用网卡
  2. vmnic1仅在vmnic0故障时启用
  3. 若上游交换机开启STP协议，可能误判为环路而阻塞端口

正确做法：

| 场景 | 推荐配置 | 说明 | |---------------------|----------------------------|--------------------------| | 网络冗余 | 故障切换策略 | 保持简单，避免复杂配置 | | 带宽叠加 | 创建独立vSwitch | 每个vSwitch绑定单独物理网卡 | | 多网段隔离 | 使用不同端口组+VLAN | 物理网卡可复用 |

提示：生产环境中建议通过vCenter配置分布式交换机(DVS)，可获得更精细的流量控制能力。

2. Ubuntu netplan的配置陷阱

现代Ubuntu版本使用netplan进行网络配置，其YAML语法看似简单却暗藏玄机。最常见的错误是混用新旧语法导致路由冲突：

# 错误示例：混用gateway4和routes network: version: 2 ethernets: ens160: addresses: [192.168.1.10/24] gateway4: 192.168.1.1 # 旧语法 ens192: addresses: [10.0.0.10/24] routes: - to: 0.0.0.0/0 via: 10.0.0.1 # 新语法

这种配置会导致：

  • 系统存在两个默认路由(0.0.0.0/0)
  • 流量随机选择出口，造成网络不稳定
  • 特定子网访问异常

解决方案：

  1. 统一使用routes语法
  2. 为次要网卡配置更具体的路由规则
# 正确配置示例 network: version: 2 ethernets: ens160: addresses: [192.168.1.10/24] routes: - to: 0.0.0.0/0 via: 192.168.1.1 metric: 100 ens192: addresses: [10.0.0.10/24] routes: - to: 172.16.0.0/16 via: 10.0.0.1 metric: 200

关键参数说明：

  • metric：数值越小优先级越高
  • to：目标网络段，0.0.0.0/0表示默认路由
  • 使用netplan try测试配置，避免失联

3. VLAN配置的"隐形杀手"

当物理网络采用Trunk模式时，ESXi端口组的VLAN设置必须与上游交换机匹配。这个环节的问题往往最隐蔽：

  1. 现象排查流程：

    • 检查物理交换机端口模式：show interfaces trunk
    • 确认ESXi端口组VLAN ID：esxcfg-vswitch -l
    • 验证虚拟机网卡VLAN标签：ethtool -k ens192 | grep vlan

  2. 典型错误场景：

    • 端口组VLAN ID设为0(表示VLAN透传)，但虚拟机未配置802.1Q
    • 端口组VLAN ID设为10，而物理交换机未放行该VLAN
    • 虚拟机内网卡未启用VLAN感知功能

跨厂商兼容性测试矩阵：

交换机品牌ESXi VLAN模式测试结果备注
Cisco端口组VLAN 10成功需配置switchport trunk
H3CVLAN透传失败需启用hybrid端口
Huawei端口组VLAN 20成功需设置port link-type

经验：当遇到双网卡中只有一个能工作时，首先检查VLAN配置而非IP设置。

4. 系统服务的"隐形干扰"

即使网络配置完全正确，Ubuntu的系统服务仍可能导致网络异常。以下是需要重点检查的服务：

  1. NetworkManager：

    # 查看服务状态 systemctl status NetworkManager # 临时禁用测试 systemctl stop NetworkManager

  2. ufw防火墙：

    # 查看当前规则 ufw status verbose # 放行特定网卡 ufw allow in on ens192

  3. IP转发功能：

    # 检查是否误启用了IP转发 sysctl net.ipv4.ip_forward # 临时关闭 sysctl -w net.ipv4.ip_forward=0

服务影响对照表：

服务名称可能影响诊断命令解决方案
NetworkManager覆盖手动配置nmcli device show禁用或配置nm接管规则
systemd-networkd与netplan冲突networkctl list确保未激活冲突服务
ufw默认拒绝所有入站ufw status numbered添加针对性规则

5. 实战排错：从现象到根源

结合最近处理的一个真实案例，演示完整的诊断流程：

现象描述：

  • 添加ens192网卡后，ens160间歇性丢包
  • 新网卡无法ping通同网段网关
  • 重启网络服务后问题依旧

排查步骤：

  1. 检查路由表：

    ip route show table all

    发现存在两个默认路由，metric值相同

  2. 验证ARP解析：

    arp -an | grep ens192

    显示网关MAC地址不全

  3. 抓包分析：

    tcpdump -i ens192 -nn -v

    发现大量ARP请求未响应

  4. 最终定位：

    • 物理交换机端口误配为access模式
    • ESXi端口组VLAN ID与交换机不匹配
    • 虚拟机内存在路由冲突

根治方案：

  1. 交换机端口改为trunk并放行所需VLAN
  2. 统一netplan的路由metric值
  3. 添加持久化ARP条目：
    network: ethernets: ens192: arp: - ip: 10.0.0.1 mac: 00:50:56:xx:xx:xx

这个案例充分说明，网络问题往往需要从物理层到应用层逐层排查。掌握这些诊断方法后，再遇到类似问题就能快速定位了。