perché il bridge linux non funziona


7

Vorrei collegare due coppie di veth su un bridge Linux e provare a eseguire il ping da una coppia all'altra per testare la funzione bridge.

Lo script seguente viene testato su più macchine, alcune funzionano come previsto e altre no.

Dopo un po 'di risoluzione dei problemi, ho scoperto che:

  • brctl showstp <br> indica che entrambe le porte sono in stato di inoltro
  • brctl showmacs <br> mostra correttamente sia i mac locali che quelli esterni

Domande:

  • Perché il bridge non inoltra i pacchetti? (non conosco le differenze tra quelle macchine)
  • Oppure, come devo continuare la risoluzione dei problemi?

Eventuali suggerimenti sono apprezzati.

-

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

MODIFICARE

tcpdump -ni br1 Spettacoli:

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 Spettacoli

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

Il bridge sta collegando i pacchetti arp ma non collegando i pacchetti icmp?

Risposte:


14

Ho risolto questo.

Risulta essere iptableschi rilascia i pacchetti sul bridge. I pacchetti viaggiano attraverso la FORWARDcatena della filtertabella, senza corrispondere ad alcuna regola di essa, quindi si DROPapplica la politica di default .

Per verificare se è causato da iptables, possiamo provare

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

quindi vedere se il ponte funziona.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.