Bridging onder linux, elke bridge ziet alles?

[Keiichi]

Ik heb een redelijk complex probleem. Op een server heb ik via KVM een firewall distro draaien. De host bevat bridges om fysieke devices met virtuele devices te verbindingen.

Ik heb hiervoor een aantal tap* netwerk devices en een 4-tal bridges.

De bridges zijn als volgt:

code:

root@fw:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00304898a50c       yes             eth0
                                                        tap0
br1             8000.00304898a50d       yes             eth1
                                                        tap1
br2             8000.00151777bdf5       yes             eth2
                                                        tap2
br4             8000.00ff69addb3a       yes             tap20
                                                        tap21

eth2 hangt native in een VLAN voor het beheer, hier staan eigenlijk alleen alle switches in + mijn PC.
tap2 hangt aan de VM.

Ik zou verwachten dat de bridge enkel en alleen de MAC adressen van de devices aan een van beide kanten kent, (via commando 'brctl showmacs br2') maar deze toont ALLES bekend in het netwerk! (eth0 hangt op een normale manier in het netwerk)

eth1 hangt op zijn beurt weer alleen maar aan een ADSL modem. Een kijkje naar de arp table van de gevirtualiseerde firewall laat het mac adres op ALLE devices zien, output voor de duidelijkheid:

firewall:/home/login # arp -n
Address HWtype HWaddress Flags Mask Iface
10.0.0.138 ether 00:90:D0:0B:72:68 C eth1
10.0.0.138 ether 00:90:D0:0B:72:68 C eth3
10.0.61.2 ether 00:FF:69:AD:DB:3A C eth3
10.0.60.117 ether 00:19:D1:75:64:91 C eth2
10.0.0.138 ether 00:90:D0:0B:72:68 C eth2
195.190.249.90 ether 00:90:D0:0B:72:68 C eth1

Ik denk dat de bridge in linux ergens rommelt of gewoon anders werkt dan ie zou moeten.

Heeft iemand ideeen over wat hier mis kan zijn?

[benoni]

Het is eventjes geleden dat ik me in bridging heb verdiept, dus ik kan het fout hebben... Als ik me goed kan herinneren is het dat als je op de bridging host zelf de bridges in je routetabel hebt staan, dat je dan het hele rijtje langs ziet komen. Als je vanaf een andere client scant zie je alleen wat er voor en achter de gebridgde verbinding zit. Als het goed is

[Hero of Time]

benoni schreef op zaterdag 26 juli 2008 @ 15:37:
Het is eventjes geleden dat ik me in bridging heb verdiept, dus ik kan het fout hebben... Als ik me goed kan herinneren is het dat als je op de bridging host zelf de bridges in je routetabel hebt staan, dat je dan het hele rijtje langs ziet komen. Als je vanaf een andere client scant zie je alleen wat er voor en achter de gebridgde verbinding zit. Als het goed is

Dat is nou net zijn probleem, de andere kant, de virtuele machine, ziet het hele netwerk van de bridges. Misschien moet hij het Spanning Tree protocol uitschakelen bij de bridges. Probeer dat eens. Gooi dan ook gelijk je arp cache leeg , krijg je geen foute informatie.

[Keiichi]

Ik heb dit probleem weer even terug opgepakt. Maar ben niets verder gekomen.

Wel een opmerkelijke bevinding:

- Als linux een who-has arp verzoekt krijgt, word deze doodleuk op de interfaces terug beantwoord met alle mac address van alle interfaces.(Waarom? als ik op eth0 voor het IP adres van eth1 krijg, moet eth0 z'n mond houden, eth1 reageert er wel op als deze in het broadcastdomain zit)

Misschien dat ik met een antwoord op deze vraag weer iets verder kan komen.

[blaataaps]

Volgens mij is dat /proc/sys/net/ipv4/conf/all/arp_filter , of een andere daar in de buurt.

[Keiichi]

ok, dat werkt voor dat deel. Geen rare arp responses meer

Maar echt verder ben ik nog niet. Ik heb nog steeds dezelfde config uit mijn OP (STP wel en niet aangezet, heeft geen effect)

De box zit fysiek alleen met eth0 met het netwerk verbonden. eth0 zit alleen in br0. Maar als ik met tcpdump -p -i br1 -n arp kijk, dan uit het arp request zich daar ook (Antwoord nu gelukkig niet)

Waar kan het nog meer mis zitten? (Ik laat de virtuele machines buiten kijf nu, ze staan niet aan)

[ Voor 7% gewijzigd door Keiichi op 24-12-2008 16:47 ]