Taxa de download constantemente variável com uma configuração complexa de rede xen, por quê?

Question

A configuração de rede na configuração do meu Xen é a seguinte:

• o dom0 tem 3 placas de rede (eth0, eth1, eth2), 3 brigdes (xenbrE, xenbrI, xenbrD) e cada brigde integra a rede correspondente cartão. Apenas xenbrD tem um endereço IP configurado (192.168.78.2, um LAN) para que possa discutir com todos domU.
• há um domU que é um firewall / roteador e também contém 3 virtuais cartões (eth0, eth1, eth2). Ele faz o disfarce para o tráfego saindo eth0 (a interface externa que faz parte do xenbrE).

Meu problema é que quando eu faço o download de um arquivo grande da internet via HTTP em o dom0, a taxa de download não é estável. Sobe progressivamente e depois pára por alguns segundos e recomeça a subir progressivamente (e tudo isso em loop até que o download esteja completo). Durante as bancas, parece toda a rede está bloqueada na máquina (notada em sessões SSH interativas).

dom0                             │domU
     wget                        │
       ↕                         │
eth2↔xenbrD(192.168.78.2)↔vif2.2←┼→eth2(192.168.78.1/24)
                                 │   ↕ masquerading
eth0↔xenbrE↔vif2.0←——————————————┼→eth0(192.168.1.20/24)
 ↕
internet

Se eu fizer o mesmo download, mas usar um proxy HTTP (sem cache) executado em o firewall domU, a taxa de download é estável em seu valor máximo.

Como posso evitar esse problema?

Eu suspeito que seja um bug na pilha de redes, mas eu gostaria de ajuda para diagnosticar com mais precisão (e talvez encontrar uma solução alternativa).

Este é um sistema Debian Etch com o Xen 3.2 e o kernel 2.6.26-xen-686 do Debian Lenny (backports). As pontes são criadas com / etc / network / interfaces:

auto lo
iface lo inet loopback

auto xenbrE
iface xenbrE inet manual
        bridge_ports eth0
        bridge_maxwait 0

auto xenbrI
iface xenbrI inet manual
        bridge_ports eth1
        bridge_maxwait 0

auto xenbrD
iface xenbrD inet static
        address 192.168.78.2
        netmask 255.255.255.0
        gateway 192.168.78.1
        bridge_ports eth2
        bridge_maxwait 0

A configuração do xend não é complicada:

# grep '^(' /etc/xen/xend-config.sxp
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 150)
(dom0-cpus 0)
(vncpasswd '')

A configuração de rede Xen do domU é feita com:

# grep vif /etc/xen/xm.slis
vif = [ 'mac=00:16:3e:14:85:11, bridge=xenbrE', 'mac=00:16:3e:14:85:12, bridge=xenbrI', 'mac=00:16:3e:14:85:13, bridge=xenbrD' ]

E o único roteamento em dom0 redireciona para o domU via xenbrD:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.78.0    0.0.0.0         255.255.255.0   U     0      0        0 xenbrD
0.0.0.0         192.168.78.1    0.0.0.0         UG    0      0        0 xenbrD

No domU, a única configuração de iptables feita é iptables -t nat -A POSTROUTING -s 192.168.78.0/24 -o eth0 -j MASQUERADE .

    

Answer 1

realmente soa como um problema de memória para mim, isso explicaria como um proxy local também ajuda. porque ele meio que paralisa tudo um pouco, então talvez o Kernel consiga lidar com os Pacotes. Talvez verifique isso dando mais memória a Dom0. Eu tenho uma configuração semelhante aqui no trabalho, e desde que usamos para medições de velocidade eu sou muito intressado em qualquer coisa que você descubra sobre isso (mesmo que eu não experimente o problema aqui)

    

Answer 2

Talvez xen relacionado. Mas você poderia verificar com outro cliente além do dom0? Outro domu está funcionando? Isso poderia ser um problema na sua configuração NAT, como um problema mss / mtu?

    

Answer 3

Isso acontecerá se você estiver com pouca memória ... Verifique seu uso de memória e verifique também o uso de sua CPU. Se você tiver muito io_wait, obtenha mais memória e aloque mais para o dom0.