Pacotes que não se movem através da ponte ethernet do linux

4

Estou tentando configurar uma máquina 8.3 Debian com eth0 e eth1 em ponte, mas não consigo fazer com que os pacotes percorram a ponte. Atualmente, o eth0 está conectado a uma LAN com muitos outros hosts, incluindo um servidor DHCP. A Eth1 está conectada a um comutador regular, com uma máquina conectada.

Este é o meu / etc / network / interfaces:

iface eth0 inet manual
iface eth1 inet manual

allow-hotplug br0
auto br0
iface br0 inet static
        bridge_ports eth0 eth1
        address 172.16.1.111
        netmask 255.255.0.0
        broadcast 172.16.255.255
        gateway 172.16.1.254
        dns-servers 172.16.1.1

/ proc / sys / net / ipv4 / ip_forward está definido como 1.

De acordo com o tcpdump em execução na máquina de teste conectada à rede eth1, a máquina de teste está enviando solicitações DHCP, mas, de acordo com o tcpdump em execução no host da ponte, ele não está recebendo solicitações desse tipo.

Outro host conectado ao switch conectado à eth1 também pode ver que a máquina de teste está realmente enviando solicitações DHCP, mas, novamente, a execução do tcpdump no host da bridge não mostra solicitações DHCP de entrada.

Quando executo o tcpdump na eth1 no host da bridge, vejo pacotes supostamente saindo da eth1 originados do lado eth0 da rede, mas mesmo que o tcpdump afirme que esses pacotes estão saindo da eth1, nenhum host na rede da eth1 pode veja qualquer um deles.

Se eu der à máquina de teste conectada à eth1 um IP estático de 172.16.1.112, ela não receberá nenhuma resposta ping do host da bridge (172.16.1.111). Outro host conectado ao switch pode ver o host de teste enviando arp who-has 172.16.1.111 requests, mas o tcpdump em execução no eth1 no host de bridge não mostra solicitações de arp de entrada.

Se eu apagar a bridge todos juntos, atribua eth1 um ip de 192.168.200.1 e a máquina de teste conectada a eth1 um ip de 192.168.200.2, então ping, ssh, e tudo mais funcionará, indicando que não há nada errado com as conexões de rede físicas. Além disso, "ifconfig ethx promisc up" para ambas as interfaces não ajudou.

De ifconfig:

br0       Link encap:Ethernet  HWaddr 00:22:19:d5:48:a5  
          inet addr:172.16.1.111  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::222:19ff:fed5:48a5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1789546 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7077 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:89574606 (85.4 MiB)  TX bytes:1096756 (1.0 MiB)

eth0      Link encap:Ethernet  HWaddr 00:22:19:d5:48:a5  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1796423 errors:0 dropped:6430 overruns:0 frame:0
          TX packets:7124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:123614592 (117.8 MiB)  TX bytes:1159358 (1.1 MiB)
          Interrupt:16 

eth1      Link encap:Ethernet  HWaddr 00:22:19:d5:48:a6  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6437 errors:0 dropped:6435 overruns:0 frame:0
          TX packets:1782083 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1737578 (1.6 MiB)  TX bytes:121076196 (115.4 MiB)
          Interrupt:17

Outros lugares falaram sobre ebtables, é isso que eu tenho:

root@face:~# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

E, iptables:

# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*mangle
:PREROUTING ACCEPT [160073:12825881]
:INPUT ACCEPT [125398:10762899]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2598:515898]
:POSTROUTING ACCEPT [2598:515898]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*filter
:INPUT ACCEPT [125467:10767745]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2631:519386]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*nat
:PREROUTING ACCEPT [59097:4965900]
:INPUT ACCEPT [24420:2902790]
:OUTPUT ACCEPT [513:27017]
:POSTROUTING ACCEPT [513:27017]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016

material brctl:

root@face:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.002219d548a5       no              eth0
                                                        eth1
root@face:~# bridge link show
2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4 
3: eth1 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 
root@face:~# 

Eu devo estar sentindo falta de algo bobo, mas não consigo ver o que é. O que estou fazendo errado?

edições: Eu posso de fato confirmar que o dump iptables-save colado acima era a totalidade da configuração do iptables em execução. Agora, após uma reinicialização, o comando iptables-save não retorna nada.

Eu também adicionei "bridge_fd 0" e "bridge_maxwait 1" à seção br0 da configuração das interfaces, mas já passou uns 10 minutos após uma reinicialização com essas mudanças, e ainda assim nenhum tráfego está chegando a lugar nenhum.

Troquei os cabos eth0 e eth1, e parece que, onde quer que eth0 esteja conectado, o br0 responderá aos pings. Ainda sem tráfego fazendo o seu caminho, depois de vários minutos de pings.

Para investigar mais detalhes, troquei os endereços mac em /etc/udev/rules.d/70-persistent-net.rules para que eth0 agora seja eth1 e eth1 tenha o antigo endereço eth0 mac. Depois de uma reinicialização, o br0 ainda tem o mac do que era eth0 e agora é eth1, que ainda é o único lado a reconhecer qualquer pacote de entrada. O br0 pode ser configurado para um terceiro endereço não eth0 ou eth1 mac?

    
por richd 25.03.2016 / 17:31

2 respostas

1

A configuração parece correta (ou seja, não consigo ver nada de errado com ela).

No entanto, está faltando um valor para o atraso da árvore de abrangência, o que significa que a ponte não encaminhará nenhum pacote para (o valor padrão) 15 segundos depois de ter sido exibido. Corrija adicionando bridge_fd à sua configuração de interface. Use o valor 0 se não houver outras pontes relevantes ou um valor maior se houver loops em sua rede.

Além disso, ao adicionar valores, sugiro que você diminua o tempo máximo de espera antes de prosseguir durante a inicialização da ponte. Acho que definir bridge_maxwait para um segundo a mais que o valor bridge_fd é geralmente suficiente.

bridge_fd 0
bridge_maxwait 1
    
por 25.03.2016 / 18:08
0

Essa é uma pergunta bastante antiga, mas pode ser útil para outras pessoas.

A ponte Linux pode soltar pacotes, se não estiver configurada corretamente. Eu tive um problema semelhante e poderia resolvê-lo com as seguintes informações:

Em suma, existem opções para configurar a ponte: por exemplo,

# do not query iptables for package routing
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

# no additional processing for multicast packages
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_querier
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
    
por 29.10.2018 / 14:08