libvirt problema de rede: o host não pode acessar a Internet (enquanto os convidados podem!)

Question

Eu rodei uma máquina Ubuntu que hospeda via libvirt várias VMs convidadas (também Ubuntu). Os convidados podem acessar a Internet, enquanto o host só pode acessar a rede local, incluindo o gateway. Isso parece estranho e eu não tenho idéia do que pode ser a causa raiz.

Não consigo me lembrar de onde, ao longo da linha, esse problema ocorreu primeiro ou de qual alteração o acionou. Então, eu apenas descrevo a situação atual em termos de configuração e saída:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         a.b.c.1    0.0.0.0         UG    0      0        0 eth0
a.b.c.0    0.0.0.0         255.255.255.0   U     0      0        0 br0
a.b.c.0    0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 br0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Isso parece dizer basicamente o mesmo:

$ ip route show
default via a.b.c.1 dev eth0  proto static 
a.b.c.0/24 dev br0  scope link 
a.b.c.0/24 dev eth0  proto kernel  scope link  src a.b.c.38  metric 1 
169.254.0.0/16 dev br0  scope link  metric 1000 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 

/ etc / network / interfaces:

auto lo
iface lo inet loopback

auto br0 
iface br0 inet static
    address a.b.c.38
    netmask 255.255.255.0
    network a.b.c.0
    broadcast a.b.c.255
    gateway a.b.c.1
    dns-nameserver XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
    bridge_ports all
    bridge_stp yes
    bridge_fd 0
    post-up /sbin/ethtool -s eth0 wol g
    post-down /sbin/ethtool -s eth0 wol g

Este comando falha:

$ sudo ifdown eth0 && sudo ifup eth0
ifdown: interface eth0 not configured
Ignoring unknown interface eth0=eth0.   

Outro comando referente à ponte:

$ brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.14dae9726e93       no              eth0
                                                        vnet0
                                                        vnet1
                                                        vnet2
virbr0          8000.000000000000       yes

Isso parece suspeito:

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
a.b.c.50                    (incomplete)                              eth0
a.b.c.63                    (incomplete)                              eth0
a.b.c.1             ether   00:00:0c:07:ac:3d   C                     br0
a.b.c.63            ether   4c:72:b9:8f:b8:6c   C                     br0
a.b.c.50                    (incomplete)                              br0
a.b.c.40            ether   52:54:00:2f:79:ac   C                     br0
a.b.c.39            ether   00:25:90:7c:f8:94   C                     br0
a.b.c.1                     (incomplete)                              eth0
a.b.c.48            ether   3c:07:54:13:7c:55   C                     br0
a.b.c.2             ether   f0:f7:55:2a:15:00   C                     br0

    

Answer 1

Para começar, /etc/network/interfaces define uma interface br0 , mas não uma interface eth0 , portanto, é claro que você esperaria ifup eth0 falhar. Você poderia tentar ifdown br0; ifup br0 . Você esperaria ver a rota padrão em seu sistema saindo de br0 e não eth0 , considerando sua configuração.

eth0 não deve ter nenhum endereço IP atribuído.

Note que derrubar a ponte pode interromper o acesso à Internet de suas máquinas virtuais, de forma que elas precisem ser reiniciadas (não tenho certeza se será ou não, mas não posso testar isso no momento) .

    

Answer 2

Parece ter havido uma causa externa. A rede comutada foi configurada de uma maneira que não executa o STP (Spanning Tree Protocol) e, portanto, desconecta as portas que enviam pacotes STP. Na configuração de rede bridge_stp yes levou ao envio desses pacotes. No entanto, não está claro como os convidados da VM ainda podem se comunicar com a Internet externa. Enfim, o problema está resolvido - obrigado!