por que a ponte linux não funciona

4

Eu gostaria de conectar dois pares de veth em uma ponte linux e tentar pingar 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.

Depois de alguns problemas, descobri que:

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

Questões:

  • 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?

Qualquer sugestão é apreciada.

- 

#!/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 shows 

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?

linux networking dastan
fonte

Respostas:

10

Eu resolvi isso.

Acaba por ser iptables quem deixa pacotes na ponte. Pacotes viajam através FORWARD cadeia do filter tabela, não correspondendo a nenhuma regra, para que a política padrão DROP aplica-se.

Para testar se é causado pelo iptables, podemos tentar 

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

então veja se a ponte funciona.

dastan
fonte