[ubuntu] Bridged networking in KVM aan de praat krijgen

[Boudewijn]

Hoi,

Ik zit momenteel op het werk met een 12.04 Ubuntu machine die ik als KVM bak wil gebruiken.
Thuis heb ik dat draaiend met Xubuntu en bridged networking, en dat werkte out of the box...echter krijg ik het hier niet werken.

Wat heb ik bekeken:

- Ubuntu wiki, kvm, networking.
- libvirt wiki
- http://techtips-tom.blogs...untu-1204-kvm-server.html


Wat is de situatie?

- eth0 hangt aan een netwerk waar ik een DHCP lease krijg. Werkt prima.
- mac adres voor het guest OS wordt gefixeerd ivm mac restrictie


Mijn huidige host settings:

code:

br0       Link encap:Ethernet  HWaddr 00:19:99:c6:a6:f0  
          inet addr:172.16.0.148  Bcast:172.16.0.255  Mask:255.255.255.0
          inet6 addr: 2001:680:18:d0d0:298a:f93c:b0c4:8989/64 Scope:Global
          inet6 addr: 2001:680:18:d0d0:5883:7c4d:d019:2bea/64 Scope:Global
          inet6 addr: 2001:680:18:d0d0:51b6:aec5:b407:dc17/64 Scope:Global
          inet6 addr: 2001:680:18:d0d0:219:99ff:fec6:a6f0/64 Scope:Global
          inet6 addr: fe80::219:99ff:fec6:a6f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9361 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7788 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:8631651 (8.6 MB)  TX bytes:1316352 (1.3 MB)

eth0      Link encap:Ethernet  HWaddr 00:19:99:c6:a6:f0  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10678 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8892305 (8.8 MB)  TX bytes:1384856 (1.3 MB)
          Interrupt:20 Memory:fe400000-fe420000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:480 (480.0 B)  TX bytes:480 (480.0 B)

virbr0    Link encap:Ethernet  HWaddr 8e:f0:80:94:33:7b  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Alsmede de interfaces file:

code:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp on
        bridge_fd 0
        bridge_maxwait 0

En nee het is geen wireless device, daarop is bridgen wat lastiger .
Ook zien we dat de bridge netjes is aangemaakt:

code:

bridge name bridge id       STP enabled interfaces
br0     8000.001999c6a6f0   yes     eth0
virbr0      8000.000000000000   yes

Ik zie in mijn guest OS dat ik een DHCP lease krijg, maar vervolgens kan ik niet eens de DNS / gateway bereiken. Ik vermoed dus dat er iets fout zit in de bridge oid... alhoewel het wel heel raar is dat ik dan wel een DHCP lease krijg.
En die lease krijg ik niet van mijn host os, maar van een externe server.
Het guest os hangt dan ook netjes op br0 volgens kvm.

Komt iemand dit bekend voor?


Edit:

code:

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0

Komt ook netjes uit de output van sysctl.

Ik heb zowel een lege iptables als deze gebruikt:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     state RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

En ik zie als ik ga wiresharken op de host ook netjes mijn DHCP pakketjes voorbij komen...

[ Voor 16% gewijzigd door Boudewijn op 25-05-2012 17:17 ]

[Verwijderd]

Het zou handig zijn om te weten:
1) hoe je KVM start
2) waarom je twee bridges (br0 en virbr0) hebt aangemaakt?
3) waarom is er geen tap0 device te vinden in je output van ifconfig? Zou automatisch aangemaakt moeten worden door kvm.

Enkel br0 zou in jouw geval voldoende moeten zijn. Tevens kun je de definitie van eth0 uit /etc/network/interfaces weghalen (aangezien deze is aangemerkt als bridge_port van br0).

Ook in de output van "brctl show" ontbreekt de tap-device. Die zou gekoppeld moeten worden aan br0, bijvoorbeeld:

code:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.001517649890       no              eth0
                                                        tap0
                                                        tap1
                                                        tap2

[Hero of Time]

Hier heb je het probleem:

- eth0 hangt aan een netwerk waar ik een DHCP lease krijg. Werkt prima.
- mac adres voor het guest OS wordt gefixeerd ivm mac restrictie
...

code:

iface br0 inet dhcp

Als je MAC restricties hebt op je netwerk, dan is de switch ook slim genoeg om te zien dat er 2 IP adressen actief zijn op 1 poort, waardoor het in shutdown gaat. Kan je Host er nog wel bij? Je geeft ook niet op in wat voor netwerkomgeving je dit hebt hangen: is het thuis, op werk, heb jij het netwerk in beheer, wat voor netwerkapparatuur wordt er gebruikt?

Dus dat DHCP werkt zegt niet zo veel. Dat je vervolgens het netwerk niet op komt veel meer.

[Boudewijn]

Nou het nieuwe mac adres is aangegeven door de lokale BOFH, en dat zou allowed moeten zijn op het netwerk.
Het is dus werk en ik heb het netwerk niet in beheer, en weet niet wat er gebruikt wordt (en nee dat ga ik ook niet vragen ).


Ik had eerlijk gezegd verwacht dat als er een MAC-adres blokkering op zou zitten ik uberhaupt geen DHCP lease zou krijgen.
De host kan er nog prima bij trouwens.


@Cyberknutselaar:

- Start gewoon mee met ubuntu. Vermoed een initscriptje.
- Doet ubuntu standaard, de br0 is voor bridging, en virbr0 is voor NAT.
- TAP: goede vraag... ik heb geen idee waarom . Geen bewust keuze.

[Hero of Time]

Tja, als je lokale BoFH het heeft gegeven, dan even vragen voor hulp uit zijn kant, wat hij in logs e.d. ziet op het netwerk? Persoonlijk zou ik eerst even kijken of het nog werkt als je de Host uit het netwerk haalt, oftewel, je weigert een IP op te halen. Je zet br0 dus op manual. Of je maakt het static met 0.0.0.0/8. Als het maar niet het netwerk op gaat.

Bovendien, 2 gelijke MAC adressen op het netwerk kan niet goed gaan. De Host krijgt de packets eerst te verwerken en de Guest kan hiermee uitgesloten worden van het netwerk. DHCP is dan iets wat net wel gaat, maar daarna houd het op en dropt de Host 't verkeer omdat 't er niet om heeft gevraagd. Zou theoretisch niet moeten, maar theorie werkt nou eenmaal niet altijd in de praktijk.

[Boudewijn]

Nee de VM heeft een eigen MAC adres, en het host OS ook. Ik ben geen complete noob .


Zal de bofh eens porren, die was er vrijdag niet meer.

[Boudewijn]

Zo, ik heb net de BOFH gesproken , en kom erachter dat hij vergeten is me aan de MAC allowlist toe te voegen.
Kennelijk geven Cisco switches dan wel DHCP leases door, daarom had ik dit niet overwogen (en ik vertrouw ook op de competentie van de BOFH).

Iig fix0red.

[Hero of Time]

Hehe, een echte bastard dus, dat hij het vergeten is. Je mag 'm een schop geven wat mij betreft. Hij verdient iig niet om systeembeheerder van het jaar te worden .

[Boudewijn]

Mja als ik hem schop is mijn ~ zo leeg. Moet ik niet hebben .

Verklaart wel prima waarlijk het niet aan de gang kreeg, alhoewel ik het raar blijf vinden dat dhcp wel door die switches heen komt...

[Hero of Time]

Switches staan multi-cast zoals DHCP toe. Pas als er proper TCP/IP wordt gepraat, begint de switch z'n werk te doen.

[Boudewijn]

Ah okay die wist ik niet... had verwacht dat ook daar wat MAC filtering in zat. Nou ja weer wat geleerd.
Dank je voor de info.

[blaataaps]

Dhcp is volgens mij broadcast en geen multicast, en ik denk eerder dat er iets als ip helper address staat ingesteld voor dhcp waardoor dat wel werkt dan dat alle broad- en multicast doorgelaten wordt voor geblokkeerde macadressen.