[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bridging klappt nicht



Moin zusammen!

Ich versuche hier seit Tage ein funktionierendes Bridging für KVM auf einem neu aufgesetztem stable-System (Kernel+kvm aus backports) hin zu kriegen, aber es will mir ums verrecken nicht gelingen. Hier gibt's sicher einige mit reichlich Ethernet-Erfahrung, ich hoffe Ihr könnte mir helfen.

Also, jetzt mal im Fotoroman-style mein Versuch eine Bridge aufzusetzen:

Meine /etc/network/interfaces sieht so aus:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo br0

iface lo inet loopback

# Bridge
iface br0 inet dhcp
        bridge_ports eth1
        bridge_maxwait 5

Nach dem booten ist die Bridge auch da und mit einer IP vom dhcp-Server versorgt. Netz auf dem host funktioniert:

chef:~# ip addr show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:92:63:42:16 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21d:92ff:fe63:4216/64 scope link
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:1d:92:63:42:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.32/24 brd 192.168.178.255 scope global br0
    inet6 fe80::21d:92ff:fe63:4216/64 scope link
       valid_lft forever preferred_lft forever

chef:~# ping ftp.suse.de
PING ftp.suse.de (195.135.220.4) 56(84) bytes of data.
64 bytes from ftp.suse.de (195.135.220.4): icmp_seq=1 ttl=54 time=90.6 ms
64 bytes from ftp.suse.de (195.135.220.4): icmp_seq=2 ttl=54 time=95.8 ms

--- ftp.suse.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 90.682/93.256/95.831/2.592 ms


So weit, so gut. Eine Bridge mit nur einem Device ist natürlich sinnlos, also schnell ein weiteres erzeugen:

moritz@chef:~$ sudo tunctl -u moritz
Set 'tap0' persistent and owned by uid 1000
moritz@chef:~$ ip addr show dev tap0
5: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 500
    link/ether 00:ff:f8:de:7e:8b brd ff:ff:ff:ff:ff:ff

Ok, das hat also geklappt. Jetzt muss tap0 noch zur Brücke hinzugefügt werden:

chef:~# brctl addif br0 tap0
chef:~# brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     00:04:0e:XX:XX:XX       no                 4.68
  1     00:1d:92:63:42:16       yes                0.00
  1     00:40:05:XX:XX:XX       no                 0.78
  2     00:ff:f8:de:7e:8b       yes                0.00
chef:~# tcpdump -i tap0
tcpdump: bind: Network is down

Ok, die MAC-Adresse von tap0 ist bei der Brücke bekannt. Scheint also geklappt zu haben. Allerdings ist tap0 noch down, also hochfahren:

chef:~# ifconfig tap0 0.0.0.0 up
chef:~# ip addr show dev tap0
5: tap0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 500
    link/ether 00:ff:f8:de:7e:8b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2ff:f8ff:fede:7e8b/64 scope link
       valid_lft forever preferred_lft forever

Ok, tap0 ist jetzt aktiv, dann sollten auch Traffic zu sehen sein:

chef:~# tcpdump -i tap0
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
18:37:28.811479 IP moritz.ipp > 192.168.178.255.ipp: UDP, length 182
18:37:49.671079 IP moritz.netbios-dgm > 192.168.178.255.netbios-dgm: NBT UDP PACKET(138) 18:37:49.671100 IP moritz.netbios-dgm > 192.168.178.255.netbios-dgm: NBT UDP PACKET(138)
18:37:59.811010 IP moritz.ipp > 192.168.178.255.ipp: UDP, length 182

4 packets captured
4 packets received by filter
0 packets dropped by kernel

Ok, traffic gibts also auch auf tap0, dann sollte ja auch eine dhcp-Anfrage funktionieren. Tut sie aber nicht:

chef:~# dhclient tap0
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/tap0/00:ff:f8:de:7e:8b
Sending on   LPF/tap0/00:ff:f8:de:7e:8b
Sending on   Socket/fallback
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Auf tap0 sehe ich die Anfragen, aber auf br0 nicht:

chef:/home/moritz# tcpdump -i tap0
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
18:52:08.002762 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:ff:f8:de:7e:8b (oui Unknown), length 300 18:52:23.002085 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:ff:f8:de:7e:8b (oui Unknown), length 300
chef:/home/moritz# tcpdump -i br0 portrange 67-68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel

Was mache ich falsch?

Für jeden Hinweis dankbar,

	Arnd

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arnd Münzebrock                                    Arnd@nurfuerspam.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Seit ich das Alphabet kenne, versuche ich es zu benutzen...


Reply to: