IPv6 não funciona sobre a ponte

5

Eu instalei o servidor Ubuntu 14.04 há uma semana. Eu uso-o como um host de máquina virtual (tasksel instalado). ou seja, estou executando com kvm + libvirt.

Eu configurei a mesma ponte que eu tinha em 13.10.

auto p4p1
iface p4p1 inet manual
    up ifconfig $IFACE up
    down ifconfig $IFACE down

auto br0
iface br0 inet static
    address 46.182.xxx.xxx
    netmask 255.255.255.240
    gateway 46.182.xxx.xxx
    dns-nameservers 46.182.xxx.xxx 46.182.xxx.xxx
    bridge_ports p4p1
    bridge_stp off
    bridge_maxwait 0

iface br0 inet6 auto

Contra o br0 eu conecto minhas máquinas virtuais com <source bridge='br0'/> definido no libvirt.

Minhas máquinas virtuais recebem mensagens de anúncio do roteador sem problemas. Todas as máquinas virtuais recebem endereços IPv6.

Meu problema é que o IPv6 não funciona na ponte. Mas funciona quando eu ligo o tcpdump contra br0 para solução de problemas. Tentei configurar a interface manualmente no modo promíscuo, mas isso não faz com que funcione, ifconfig br0 promisc .

Por que eu tenho os endereços IPv4 na ponte? Eu não sei, velho hábito, nunca questiono isso. O IPv6 não funciona no host da máquina virtual, mas o host obtém o endereço IPv6 pelo RA, assim como as máquinas virtuais.

    
por Niklas Hagman 04.05.2014 / 08:17

3 respostas

4

Todos os endereços IPv6, até os locais de link, assinam automaticamente um grupo de multicast com base em seus últimos 24 bits. Se o rastreamento multicast estiver habilitado, a bridge filtra (quase) todo o tráfego multicast por padrão. Quando um endereço IPv6 é atribuído a uma interface, o sistema deve informar à rede que essa interface está interessada nesse grupo de difusão seletiva específico e deve ser excluída pelo filtro. Segue-se um bom vídeo introdutório: link

A espionagem multicast está presente para evitar inundações na rede com pacotes multicast que a maioria dos sistemas não está interessada. Você pode desabilitar o rastreamento multicast em pequenas implantações sem notar nenhuma grande diferença. Mas isso pode ter um impacto significativo no desempenho em implantações maiores.

Você pode desativar a espionagem com:

echo -n 0 > /sys/class/net/<brif>/bridge/multicast_snooping

Se você deseja proteger suas VMs contra tráfego indesejado e processamento de pacotes desnecessário, pode deixar a detecção ativada, mas também habilitar um Consultor multicast na rede. Um Querier periodicamente transmitirá pacotes de consulta e atualizará os filtros de rastreamento em switches e pontes. É possível ativar um Consultor no seu sistema com:

echo -n 1 > /sys/class/net/<brif>/bridge/multicast_querier

Se você tiver snooping ativado, você também deve ter um querier na rede.

Não há necessidade de ativar o STP. É provavelmente mais seguro desativá-lo, a menos que você saiba que está conectando segmentos que resultam em caminhos circulares. Também é irrelevante se você tiver o SLAAC ativado (por exemplo, autoconf=1 , accept_ra=1 ). Ativar o modo PROMISC na bridge desativa implicitamente a snooping.

Aqui está um bom resumo dos modernos desafios do IPv6 Neighbor Discovery (ND) e MLD (Multicast Listener Discovery) .

    
por forcefsck 23.10.2015 / 14:04
3

você ativou o IPv6 na interface? se o dispositivo de bridge for br0, faça isso:

sysctl net.ipv6.conf.br0.disable_ipv6=0
sysctl net.ipv6.conf.br0.autoconf=1
sysctl net.ipv6.conf.br0.accept_ra=1
sysctl net.ipv6.conf.br0.accept_ra_defrtr=1
    
por Paul M 04.07.2014 / 19:01
0

O único problema óbvio que vejo com sua configuração é:

    bridge_stp off

Por vários motivos o STP precisa ser ativado em pontes libvirt.

Altere a configuração para:

    bridge_stp on

Você também pode ativá-lo imediatamente sem reiniciar a rede:

$ sudo brctl stp br0 on
    
por Michael Hampton 20.08.2014 / 19:41