主页 / user-284347

cbix's questions

Martin Hope
cbix
Asked: 2017-01-23 06:52:37 +0800 CST
  • 0

我们在 Ubuntu 16.04 上运行 OpenNebula 5.0.2 环境，使用 OpenvSwitch 2.5 桥接虚拟接口和 LACP 中继两个 Gbit 端口，运行良好。

但是当我在虚拟机和它的主机之间运行 iperf3 带宽测试时，htop 显示运行该虚拟机的 qemu 的 CPU 负载为 100%，而 iperf3 仅获得 100-200 Mbps，即使没有其他高带宽需求的虚拟机正在运行。两个 VM 主机之间的 iperf3 让我几乎满载 1 Gbps 并且没有 CPU 负载。

当我们还在 2.0.2 上时，我曾经认为这是一个 OpenvSwitch 问题，但现在我认为它缺少一些虚拟网络优化......

virtualization performance kvm-virtualization bandwidth openvswitch
Martin Hope
cbix
Asked: 2016-04-19 17:43:36 +0800 CST
  • 0

我们的网络目前由同一链路上的 3 个子网组成：

  • 1.2.3.0/24 是全局子网
  • 10.1.0.0/16用于NAT（因为客户端远超200）
  • 192.168.0.0/16 是“访客网络”，具有用于未知主机的简单强制门户

我们的 dhcpd 主机具有以下 /etc/network/interfaces：

auto lo
iface lo inet loopback

auto eth0
allow-hotplub eth0
iface eth0 inet static
    address 1.2.3.2
    netmask 255.255.255.0
    gateway 1.2.3.1

iface eth0:1 inet static
    address 192.168.0.1
    netmask 255.255.0.0

iface eth0:2 inet static
    address 10.1.0.2
    netmask 255.255.0.0

而这个dhcpd.conf：

authoritative;
# option definitions common to all supported networks...
option domain-name "example.com";
option domain-search "example.com";
option domain-name-servers 8.8.8.8;
option ntp-servers 1.2.3.8;

default-lease-time 600;
max-lease-time 600;


shared-network "corp" {
  include "/etc/nat-classes.conf";

  subnet 1.2.3.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
    option broadcast-address 1.2.3.255;
    option routers 1.2.3.1;
    default-lease-time 600; 
    max-lease-time 600; 
    deny unknown-clients;
  }

  subnet 10.1.0.0 netmask 255.255.0.0 {
    option subnet-mask 255.255.0.0;
    option broadcast-address 10.1.255.255;
    option routers 10.1.0.1;
    default-lease-time 600;
    max-lease-time 600;

    include "/etc/nat-pools.conf"; # every user owns a pool of addresses
  }

  subnet 192.168.0.0 netmask 255.255.0.0 {
    pool {
      range 192.168.0.3 192.168.255.254;
      deny known-clients;
    }
    option subnet-mask 255.255.0.0;
    option broadcast-address 192.168.255.255;
    option routers 192.168.0.1;
    option domain-name-servers 192.168.0.1;
    filename "pxelinux.0";
    next-server 192.168.0.1;
    allow unknown-clients;
  }
}
# ... known host definitions ...

我们现在观察到以下情况：

  • 10.1/16 和 192.168/16 子网的 DHCP OFFER 包含带有服务器公共 IP 地址 (1.2.3.2) 的 DHCP 选项 54（DHCP 服务器标识符），此外，IP 标头的源地址为 1.2.3.2 和目标子网中的目标地址。
  • 在这些子网中的租约时间结束前不久，客户端尝试到达 1.2.3.2 以进行租约更新并失败（或者他们甚至没有尝试，因为它不是他们配置的子网中的地址？）
  • 至少在 Android 和 Win 10 上，这会导致短暂但重要的第 3 层断开连接。

我们知道根据 dhcpd.conf(5)有一个server-identifier选项：

The usual case where the server-identifier statement needs to be sent is
when a physical interface has more than one IP  address,  and
the  one  being  sent  by  default isn't appropriate for some or
all clients served by that interface.  Another common case is when an
alias is defined for the purpose of having a consistent IP
address for the DHCP server, and it is desired that the clients use this IP
address when contacting the server.

但是，当在所有 3 个相应的子网定义中设置此选项时，DHCP 将停止在 10.1/16 和 192.168/16 子网上工作，因为由于某种原因 DHCP OFFER（现在具有正确的 Src IP 和 DHCP 服务器标识符标头）不会到达客户端了。

尽管 600 的租用时间与我们的强制门户相结合并不是一个安全的解决方案，但我们如何才能使不同子网上的 DHCP 在租用时间用完后立即以正确的方式发出更新的客户端正常工作？

debian dhcp isc-dhcp