porque a ponte linux não funciona

Question

Gostaria de conectar dois pares de veth em uma ponte linux e tentar fazer ping de um par para outro, para testar a função de ponte.

O script abaixo é testado em várias máquinas, algumas delas funcionam como esperado e as outras não.

Após alguns problemas, descobri que:

• brctl showstp <br> informa que ambas as portas estão no estado de encaminhamento
• brctl showmacs <br> mostra os macs locais e externos corretamente

Perguntas:

• Por que a ponte não encaminha os pacotes? (não sei as diferenças entre essas máquinas)
• Ou, como devo continuar com a solução de problemas?

Todas as sugestões são bem-vindas.

-

#!/bin/bash

BR=br1

ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3
ip link add $BR type bridge
ip netns add ns0
ip netns add ns1
ip link set veth0 netns ns0
ip link set veth2 netns ns1
ip link set veth1 master $BR
ip link set veth3 master $BR
ip link set $BR up
ip link set veth1 up
ip link set veth3 up
ip netns exec ns0 ip link set veth0 up
ip netns exec ns1 ip link set veth2 up
ip netns exec ns0 ip addr add 172.30.0.1/24 dev veth0
ip netns exec ns1 ip addr add 172.30.0.2/24 dev veth2

ip netns exec ns0 ping 172.30.0.2

EDITAR

tcpdump -ni br1 mostra:

23:23:31.097396 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:23:31.097431 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
23:23:31.097443 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 1, length 64
23:23:32.096804 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 2, length 64
23:23:33.096803 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 3, length 64

ip netns exec ns1 tcpdump -ni veth2 mostra

23:33:58.198790 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:33:58.198823 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
^C

A ponte está conectando pacotes arp mas não conectando pacotes icmp?

    

Answer 1

Eu resolvi isso.

Acontece que é iptables quem descarta pacotes na bridge. Os pacotes viajam através de FORWARD chain da tabela filter , não correspondendo a nenhuma regra, de modo que a política padrão DROP se aplica.

Para testar se é causado pelo iptables, podemos tentar

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

veja se a ponte funciona.