Nenhuma resposta ARP na tap0 (rede em ponte KVM)

4

Eu queria atribuir um endereço IP externo ao meu convidado KVM e seguir o caminho de rede em ponte. Infelizmente, o convidado não tem conectividade de rede e não sei por quê. Depois de investigar, parece que ele não recebe nenhuma resposta para suas solicitações ARP.

Eu tenho uma interface física: eth0, a interface em ponte: br0 e a interface de toque: tap0 criada pelo script qemu-ifup da kvm. A máquina host executa o último servidor Ubuntu. A máquina convidada executa o live-cd GKRML (baseado em slackware).

O que poderia ser um problema em potencial é que a máquina host e a máquina convidada estão em redes diferentes. Infelizmente, ambos os endereços IP foram atribuídos a mim pelo datacenter e não posso alterá-los.

Detalhes de configuração seguem. Abaixo de xx.xx são os mesmos para host e convidado.

Host / etc / network / interfaces:

# Loopback device:
auto lo
iface lo inet loopback

# Device: eth0
auto eth0
iface eth0 inet manual

# Device: br0
auto br0
iface br0 inet static
  address   xx.xx.110.69
  netmask   255.255.255.224
  network   xx.xx.110.64
  broadcast xx.xx.110.95
  gateway   xx.xx.110.65
  bridge_ports eth0
  bridge_fd 9
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off

Tabela de roteamento do host:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.110.64    0.0.0.0         255.255.255.224 U     0      0        0 br0
0.0.0.0         xx.xx.110.65    0.0.0.0         UG    100    0        0 br0

Scirpt / etc / qemu-ifup do host (não modificado, enviado com o pacote qemu):

#!/bin/sh
switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1

Saída de brctl show enquanto o convidado está sendo executado:

bridge name     bridge id               STP enabled     interfaces
br0             8000.4061862b90d5       no              eth0
                                                        tap0

Linha de comando do KVM:

kvm -cdrom grml_2009.10.iso -boot d -m 256 -vnc localhost:0 -net nic,macaddr=DE:AD:BE:EF:11:14 -net tap,script=/etc/qemu-ifup

Configuração da rede da máquina convidada (interface eth0 única):

$ ifconfig eth0 xx.xx.129.69/28 up
$ route add default gw xx.xx.129.65

Resultado de tcpdump -i tap0 ao tentar pingar qualquer coisa do convidado:

tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
23:38:13.659655 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:14.659687 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:15.659655 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:16.666350 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:17.666319 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:18.666324 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28

... e assim por diante, sem resposta.

Agradecemos antecipadamente por qualquer ajuda!

    
por MasterM 30.07.2010 / 23:45

2 respostas

1

  1. Você está executando o iptables? Em caso afirmativo, você ativou o tráfego de bridge? Por exemplo, o seguinte é uma solução que funciona no Fedora / Red Hat:

iptables -F AVANÇAR

iptables -I FORWARD -m physdev --physdev -sobstrui -j ACCEPT

iptables-save > / etc / sysconfig / iptables

  1. Você ativou o encaminhamento de IPv4 no sysctl.conf? Novamente no Fedora / Red Hat em /etc/sysctl.conf você precisa definir

net.ipv4.ip_forward = 1

    
por 31.07.2010 / 01:42
0

seu convidado está em uma rede e o host em outra. O tráfego passa pelo dispositivo de derivação e a ponte para a eth0, supõe-se que deve chegar à rede xx.xx.129.69 / 28? A configuração típica de trabalho seria ter a ponte IP e as VMs conectadas a ela na mesma rede e, se você quiser que o host não veja essa rede, deixe a ponte sem um IP. Você pode acompanhar o fluxo verificando o tcpdump na própria ponte e possivelmente na eth0 subjacente

    
por 30.10.2011 / 07:53