[gelöst] Keine Netzwerk-Verbindung zum kvm-Host

gehrke · 10 Nov. 2012

Hallo *,

ich habe ein Verbindungsproblem zwischen 2 Linux-Systemen und komme ohne Hilfe nicht mehr weiter. Bin selbst kein Profi, daher sorry, wenn ich mich doof anstelle...

System1: 172.16.11.8 - KVM-Host
System2 (aka vm1): 172.16.13.11 - VM innerhalb von System1

Das LAN ist gesplittet in mehrere Subnetze, in denen sich auch noch andere Systeme tummeln. Diese Subnetze werden von einer pfsense verwaltet, jedes Subnetz verfügt über ein eigens VLAN. pfsense implementiert für jedes Subnetz einen DHCP-Server.

Auszug:

172.16.11.0/24 - VLAN-ID 11
172.16.13.0/24 - VLAN-ID 13
...

Das funktioniert auch soweit seit geraumer Zeit für eine Reihe von VLANs und ca. ein bis zwei Dutzend Systeme.

Nun habe ich mit KVM eine Virtualisierungslösung eingeführt, bei welcher System1 den Host und System2 eine virtuelle Maschine innerhalb dieses Hosts darstellt. Zum Verständnis muss noch gesagt werden, dass System1 auch im Subnetz 11 nativ (ohne KVM) Dienste wie NFS anbietet. Weil hier sowohl VLAN 11 als auch VLAN 13 bedient werden sollen, ist die Konfiguration der Interfaces dort 'tagged'.

System2 soll ausschliesslich in VLAN 13 agieren und dort Samba anbieten.

Zur Konfiguration:
System1:

Code:

ifconfig
bond0 Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:7709916 errors:0 dropped:0 overruns:0 frame:0
TX packets:7986901 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:6725468916 (6.2 GiB) TX bytes:8063752904 (7.5 GiB)

bond0.11 Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
inet Adresse:172.16.11.8 Bcast:172.16.11.255 Maske:255.255.255.0
inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:2192729 errors:0 dropped:0 overruns:0 frame:0
TX packets:273647 errors:0 dropped:5 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:149546440 (142.6 MiB) TX bytes:6179965670 (5.7 GiB)

bond0.13 Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:5516285 errors:0 dropped:0 overruns:0 frame:0
TX packets:3707562 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:6467884432 (6.0 GiB) TX bytes:1603339944 (1.4 GiB)

bridge-media Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
inet Adresse:172.16.13.10 Bcast:172.16.13.255 Maske:255.255.255.0
inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:454213 errors:0 dropped:0 overruns:0 frame:0
TX packets:493737 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:27267359 (26.0 MiB) TX bytes:9286055001 (8.6 GiB)

eth0 Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:2164101 errors:0 dropped:0 overruns:0 frame:0
TX packets:7068784 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:146278678 (139.5 MiB) TX bytes:6707922006 (6.2 GiB)
Interrupt:16 Speicher:fba00000-fba20000

eth1 Link encap:Ethernet Hardware Adresse 00:25:90:27:AF:AC
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:5545816 errors:0 dropped:0 overruns:0 frame:0
TX packets:918118 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:6579190304 (6.1 GiB) TX bytes:1355831076 (1.2 GiB)
Interrupt:18 Speicher:fb900000-fb920000

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:119 errors:0 dropped:0 overruns:0 frame:0
TX packets:119 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:15948 (15.5 KiB) TX bytes:15948 (15.5 KiB)

vnet0 Link encap:Ethernet Hardware Adresse FE:54:00:0D:51:10
inet6 Adresse: fe80::fc54:ff:fe0d:5110/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2469739 errors:0 dropped:0 overruns:0 frame:0
TX packets:5106432 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX bytes:1475633591 (1.3 GiB) TX bytes:6510365055 (6.0 GiB)


cat /etc/sysconfig/network-scripts/ifcfg-bond0.11
DEVICE=bond0.11 BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
VLAN=yes

cat /etc/sysconfig/network-scripts/ifcfg-bond0.13
DEVICE=bond0.13
PHYSDEV=bond0
BOOTPROTO=none
ONBOOT=yes
VLAN=yes
BRIDGE=bridge-media

cat /etc/sysconfig/network-scripts/ifcfg-bridge-media
DEVICE=bridge-media
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
DELAY=0

route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.13.0 * 255.255.255.0 U 0 0 0 bridge-media
172.16.11.0 * 255.255.255.0 U 0 0 0 bond0.11
link-local * 255.255.0.0 U 1004 0 0 bond0
link-local * 255.255.0.0 U 1005 0 0 bond0.11
link-local * 255.255.0.0 U 1007 0 0 bridge-media
default 172.16.11.1 0.0.0.0 UG 0 0 0 bond0.11

System2:

Code:

ifconfig
eth0 Link encap:Ethernet Hardware Adresse 52:54:00:0D:51:10
inet Adresse:172.16.13.11 Bcast:172.16.13.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5104574 errors:0 dropped:1855 overruns:0 frame:0
TX packets:2469795 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:6437470708 (5.9 GiB) TX bytes:1475640226 (1.3 GiB)
Interrupt:11 Basisadresse:0x8000

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:88 errors:0 dropped:0 overruns:0 frame:0
TX packets:88 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:7320 (7.1 KiB) TX bytes:7320 (7.1 KiB)

route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.13.0 * 255.255.255.0 U 0 0 0 eth0
default 172.16.13.1 0.0.0.0 UG 0 0 0 eth0

Was ist nun mein Problem???
Mein Problem ist, das ich von System2 keine Verbindung zu System1 bekomme. Nein, es liegt nicht an der pfsense-Firewall, auch lokales iptables und selinux kann als Ursache ausgeschlossen werden.

Code:

[root@vm1 ~]# ping -c 1 172.16.11.8
PING 172.16.11.8 (172.16.11.8) 56(84) bytes of data.
--- 172.16.11.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Hingegen ist die umgekehrte Richtung (System1 -> System2) möglich, ebenso von System2 zu anderen Systemen im selben VLAN 13 oder in VLAN 11 oder ins WAN.

Code:

[root@system1 ~]# ping -c 1 vm1
PING vm1.gehrke.local (172.16.13.11) 56(84) bytes of data.
64 bytes from vm1.gehrke.local (172.16.13.11): icmp_seq=1 ttl=64 time=0.234 ms
--- vm1.gehrke.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 0.234/0.234/0.234/0.000 ms

j3:~> ping -c 1 vm1 (autonomes System in VLAN 11)
PING vm1.gehrke.local (172.16.13.11) 56(84) bytes of data.
64 bytes from vm1.gehrke.local (172.16.13.11): icmp_seq=1 ttl=63 time=0.781 ms
--- vm1.gehrke.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.781/0.781/0.781/0.000 ms

[root@vm1 ~]# ping -c 1 172.16.13.9
PING 172.16.13.9 (172.16.13.9) 56(84) bytes of data.
64 bytes from 172.16.13.9: icmp_seq=1 ttl=60 time=0.357 ms
--- 172.16.13.9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.357/0.357/0.357/0.000 ms

[root@vm1 ~]# ping -c 1 172.16.11.6
PING 172.16.11.6 (172.16.11.6) 56(84) bytes of data.
--- 172.16.11.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.814/0.814/0.814/0.000 ms

[root@vm1 ~]# ping -c 1 heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=246 time=55.5 ms
--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 55.590/55.590/55.590/0.000 ms

Ich vermute, ich muss noch irgenwo eine Route definieren, aber ich weiß nicht wo und welche und meine bisherigen Versuche scheiterten kläglich. Kann jemand helfen?
TIA

cu, Paul

gehrke · 10 Nov. 2012

Ein Nachtrag: Die folgenden tcpdump-Mitschnitte verdeutlichen, was auf dem Host system1 ankommt.

Fall1: ping auf ein automes System im 11er Subnetz - funktioniert

Code:

[root@vm1 ~]# ping -c 1  172.16.11.7
PING 172.16.11.7 (172.16.11.7) 56(84) bytes of data.
64 bytes from 172.16.11.7: icmp_seq=1 ttl=63 time=0.946 ms

--- 172.16.11.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.946/0.946/0.946/0.000 ms

Code:

[root@system1 ~]# tcpdump -i bridge-media -X -n -vvv -s 1500 'icmp' 
tcpdump: listening on bridge-media, link-type EN10MB (Ethernet), capture size 1500 bytes
16:58:41.288079 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.7: ICMP echo request, id 32537, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 ca76 ac10 0d0b  E..T..@.@..v....
        0x0010:  ac10 0b07 0800 a617 7f19 0001 af79 9e50  .............y.P
        0x0020:  0000 0000 ba30 0c00 0000 0000 1011 1213  .....0..........
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
16:58:41.288739 IP (tos 0x0, ttl 63, id 52969, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.11.7 > 172.16.13.11: ICMP echo reply, id 32537, seq 1, length 64
        0x0000:  4500 0054 cee9 0000 3f01 3c8d ac10 0b07  E..T....?.<.....
        0x0010:  ac10 0d0b 0000 ae17 7f19 0001 af79 9e50  .............y.P
        0x0020:  0000 0000 ba30 0c00 0000 0000 1011 1213  .....0..........
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567

Fall2: ping zum kvm-Host - funktioniert nicht

Code:

[root@vm1 ~]# ping -c 1  172.16.11.8
PING 172.16.11.8 (172.16.11.8) 56(84) bytes of data.

--- 172.16.11.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Code:

[root@system1 ~]# tcpdump -i bridge-media -X -n -vvv -s 1500 'icmp' 
tcpdump: listening on bridge-media, link-type EN10MB (Ethernet), capture size 1500 bytes
16:59:21.160648 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 34329, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 ca75 ac10 0d0b  E..T..@.@..u....
        0x0010:  ac10 0b08 0800 3009 8619 0001 d779 9e50  ......0......y.P
        0x0020:  0000 0000 033f 0a00 0000 0000 1011 1213  .....?..........
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567

spoensche · 10 Nov. 2012

Hast du auf dem Linux Host auch die VLAN's mit vconfig eingerichtet? Wenn unter /proc/net kein Verzeichnis vlan existiert, dann hast du auf dem Linux Host kein VLAN eingerichtet. D.h. die Bridge arbeitet als Switch und wird vom Kernel gesteuert. Der Kernel weiss aber nichts von den VLAN's und daher auch die Pakete nicht getagged.

Das Interface bond0.13 befindet sich im VLAN 13 belegt einen Port an der Bridge (Switch). Für die VM's musst du eigenständige tap Interfaces anlegen, sobald die VM gestartet wird. KVM/Qemu bringen die notwendigen Scripte qemu-ifup und qemu-ifdown mit.

Dies ist einfach und verständl. erklärt unter http://qemu-buch.de.

gehrke · 11 Nov. 2012

Hallo spoensche,

vielen Dank für Deine Antwort.

spoensche schrieb:
Hast du auf dem Linux Host auch die VLAN's mit vconfig eingerichtet? Wenn unter /proc/net kein Verzeichnis vlan existiert, dann hast du auf dem Linux Host kein VLAN eingerichtet. D.h. die Bridge arbeitet als Switch und wird vom Kernel gesteuert. Der Kernel weiss aber nichts von den VLAN's und daher auch die Pakete nicht getagged.

Ich denke, die VLAN's sind auf system1 richtig konfiguriert, obwohl ich damals AFAIR nicht 'vconfig' verwendet habe:

Code:

cat /proc/net/vlan/bond0.13
bond0.13  VID: 13        REORDER_HDR: 1  dev->priv_flags: 2001
         total frames received      5573455
          total bytes received   6475983699
      Broadcast/Multicast Rcvd         4834

      total frames transmitted      3760419
       total bytes transmitted   1609337984
            total headroom inc            0
           total encap on xmit            0
Device: bond0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 

cat /proc/net/vlan/bond0.11
bond0.11  VID: 11        REORDER_HDR: 1  dev->priv_flags: 1
         total frames received      3289479
          total bytes received   1458922505
      Broadcast/Multicast Rcvd         1340

      total frames transmitted       733332
       total bytes transmitted   6743242003
            total headroom inc            0
           total encap on xmit            0
Device: bond0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 

cat /proc/net/vlan/config 
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.11       | 11  | bond0
bond0.13       | 13  | bond0

Wie angedeutet ist dieser Teil schon seit einiger Zeit im Betrieb, nur war bis zur Einführung von kvm bond0.13 wie bond0.11 ein ganz normales, natives Interface auf system1 und das Tagging hat problemlos funktioniert.

spoensche schrieb:
Das Interface bond0.13 befindet sich im VLAN 13 belegt einen Port an der Bridge (Switch). Für die VM's musst du eigenständige tap Interfaces anlegen, sobald die VM gestartet wird. KVM/Qemu bringen die notwendigen Scripte qemu-ifup und qemu-ifdown mit.

Dies ist einfach und verständl. erklärt unter http://qemu-buch.de.

Deinem Hinweis mit dem tap-Interface werde ich nachgehen, aber das wird wohl leider noch etwas dauern. Für einen interessierten Hobby-Admin ist das erstmal hartes Brot, daher bitte um etwas Geduld...
TNX

cu, Paul

spoensche · 11 Nov. 2012

VLAN techn. stimmt es bei dir.
Du kannst es dir einfach machen, in dem du 2x Bridges verwendest. Die erste Bridge bekommt bond0.13 zugewiesen und die 2. Bridge bond0.11. So kannst du dann beliebig viele VMś per TAP Interface in VLAN 11 oder VLAN 13 packen.

gehrke · 12 Nov. 2012

spoensche schrieb:
Das Interface bond0.13 befindet sich im VLAN 13 belegt einen Port an der Bridge (Switch). Für die VM's musst du eigenständige tap Interfaces anlegen, sobald die VM gestartet wird. KVM/Qemu bringen die notwendigen Scripte qemu-ifup und qemu-ifdown mit.

Dies ist einfach und verständl. erklärt unter http://qemu-buch.de.

Ich habe etwas nachgeforscht und vermute mitterweile, dass ich mit 'vnet0' schon von Beginn an ein tap-Interface am Start habe:

Code:

[root@system1 ~]# ip link show dev vnet0
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:54:00:0d:51:10 brd ff:ff:ff:ff:ff:ff

[root@system1 ~]# brctl show
bridge name  bridge idSTP enabled  interfaces
bridge-media 8000.00259027afac no                   bond0.13
                                                                              vnet0

'vnet0' verschwindet, wenn 'vm1' runtergefahren wird.

Ich denke, dass dies von libvirt schon implizit durch diese Konfiguration so umgesetzt wird:

Code:

[root@system1 ~]# virsh dumpxml vm1
...
    <interface type='bridge'>
      <mac address='52:54:00:0d:51:10'/>
      <source bridge='bridge-media'/>
      <target dev='vnet0'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...

Habe ich Recht, dass das schon ein tap-Device ist? Und wenn ja, wie löse ich den mein Problem???
TNX

cu, Paul

gehrke · 12 Nov. 2012

Hinweis: Bei der Einrichtung habe ich mich übrigens hieran orientiert:
https://access.redhat.com/knowledge...guration-Bridged_networking_with_libvirt.html

gehrke · 12 Nov. 2012

Ich erlaube mir noch einen weiteren Nachtrag, diesmal Dump's auf allen beteiligten Systemen als Reaktion auf ein traceroute. Dabei lausche ich auf system1 (alle Interfaces) und der pfsense mit den Interfaces für das 11er und 13er Subnetz.

System2:

Code:

[root@vm1 ~]# traceroute 172.16.11.8
traceroute to 172.16.11.8 (172.16.11.8), 30 hops max, 40 byte packets
 1  localhost (172.16.13.1)  1.043 ms  1.006 ms  0.927 ms
 2  * * *
 3  * * *<canceled>

System1:

Code:

[root@system1 ~]# tcpdump -i any -X -n -vvv -s 1500 'icmp' 
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 1500 bytes
17:09:46.273147 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 32525, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 ca75 ac10 0d0b  E..T..@.@..u....
        0x0010:  ac10 0b08 0800 2cb6 7f0d 0001 481f a150  ......,.....H..P
        0x0020:  0000 0000 99f8 0a00 0000 0000 1011 1213  ................
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
17:09:46.273161 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 32525, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 ca75 ac10 0d0b  E..T..@.@..u....
        0x0010:  ac10 0b08 0800 2cb6 7f0d 0001 481f a150  ......,.....H..P
        0x0020:  0000 0000 99f8 0a00 0000 0000 1011 1213  ................
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
17:09:46.273164 Out 52:54:00:0d:51:10 ethertype Unknown (0x000d), length 104: 
        0x0000:  0000 0800 4500 0054 0000 4000 4001 ca75  ....E..T..@.@..u
        0x0010:  ac10 0d0b ac10 0b08 0800 2cb6 7f0d 0001  ..........,.....
        0x0020:  481f a150 0000 0000 99f8 0a00 0000 0000  H..P............
        0x0030:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f  ................
        0x0040:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f  .!"#$%&'()*+,-./
        0x0050:  3031 3233 3435 3637                      01234567
17:09:46.273166 Out 52:54:00:0d:51:10 ethertype Unknown (0x000d), length 104: 
        0x0000:  0000 0800 4500 0054 0000 4000 4001 ca75  ....E..T..@.@..u
        0x0010:  ac10 0d0b ac10 0b08 0800 2cb6 7f0d 0001  ..........,.....
        0x0020:  481f a150 0000 0000 99f8 0a00 0000 0000  H..P............
        0x0030:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f  ................
        0x0040:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f  .!"#$%&'()*+,-./
        0x0050:  3031 3233 3435 3637                      01234567
17:09:46.273467  In 00:0d:b9:25:0a:b4 ethertype Unknown (0x000b), length 104: 
        0x0000:  0000 0800 4500 0054 0000 4000 3f01 cb75  ....E..T..@.?..u
        0x0010:  ac10 0d0b ac10 0b08 0800 2cb6 7f0d 0001  ..........,.....
        0x0020:  481f a150 0000 0000 99f8 0a00 0000 0000  H..P............
        0x0030:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f  ................
        0x0040:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f  .!"#$%&'()*+,-./
        0x0050:  3031 3233 3435 3637                      01234567
17:09:46.273467 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 32525, seq 1, length 64
        0x0000:  4500 0054 0000 4000 3f01 cb75 ac10 0d0b  E..T..@.?..u....
        0x0010:  ac10 0b08 0800 2cb6 7f0d 0001 481f a150  ......,.....H..P
        0x0020:  0000 0000 99f8 0a00 0000 0000 1011 1213  ................
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
^C

pfsense - 13er Subnetz:

Code:

[2.0.1-RELEASE][root@pfsense.gehrke.local]/root(1): tcpdump -i lagg0_vlan13 -X -n -vvv -s 1500 'icmp'
tcpdump: listening on lagg0_vlan13, link-type EN10MB (Ethernet), capture size 1500 bytes
17:09:45.967293 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 32525, seq 1, length 64
        0x0000:  4500 0054 0000 4000 4001 ca75 ac10 0d0b  E..T..@.@..u....
        0x0010:  ac10 0b08 0800 2cb6 7f0d 0001 481f a150  ......,.....H..P
        0x0020:  0000 0000 99f8 0a00 0000 0000 1011 1213  ................
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"# 
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567

pfsense - 11er Subnetz:

Code:

[2.0.1-RELEASE][root@pfsense.gehrke.local]/root(1): tcpdump -i lagg0_vlan11 -X -n -vvv -s 1500 'icmp'
tcpdump: listening on lagg0_vlan11, link-type EN10MB (Ethernet), capture size 1500 bytes
17:09:45.967463 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.13.11 > 172.16.11.8: ICMP echo request, id 32525, seq 1, length 64
        0x0000:  4500 0054 0000 4000 3f01 cb75 ac10 0d0b  E..T..@.?..u....
        0x0010:  ac10 0b08 0800 2cb6 7f0d 0001 481f a150  ......,.....H..P
        0x0020:  0000 0000 99f8 0a00 0000 0000 1011 1213  ................
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567

Ich sehe nirgendwo eine Antwort von 172.16.11.8.

spoensche · 12 Nov. 2012

vnet0 gehört zum default Netzwerk von libvirt. Das default Netzwerk wird mit NAT betrieben. D.h. ohne DNAT wirst du nicht in das Netz kommen. Du solltest das default Netz abschalten, ein neues anlegen und dabei darauf achten, das es ein geroutetes Netz ist oder aber du machst es, wie erwähnt mit dem tap Interface und der Bridge.
Die Konfiguration, die auf der Redhat Seite erklärt wird ist genau das was ich gesagt habe. Bridge + bond0.13 = alle VM's die in VLAN 13 sollen, Bridge2 + bind0.11 = alle VM's die in VLAN 11 sollen.

gehrke · 12 Nov. 2012

spoensche schrieb:
vnet0 gehört zum default Netzwerk von libvirt. Das default Netzwerk wird mit NAT betrieben. D.h. ohne DNAT wirst du nicht in das Netz kommen.

Aber ich komme doch in das Netz, nur nicht auf diese eine Maschine.
172.16.11.6 ->172.16.13.11 : OK
172.16.11.7 ->172.16.13.11 : OK
172.16.11.8 ->172.16.13.11 : OK
172.16.13.11->172.16.11.6 : OK
172.16.13.11->172.16.11.7 : OK
172.16.13.11->172.16.11.8 : keine Verbindung

Ich glaube nicht, dass hier NAT im Einsatz ist, sondern vielmehr ein geroutetes Netz vorliegt. Bei NAT dürften doch nur ausgehende Verbindungen funktionieren, oder?

Im virt-manager sehe ich unter Connection Details / Virtuelles Netzwerk / default / IPv4-Konfiguration das hier:

Netzwerk: 172.16.13.0/24
DHCP-Start: Deaktiviert
DHCP-Ende: Deaktiviert
Weiterleiten: Geroutetes Netzwerk

spoensche schrieb:
Du solltest das default Netz abschalten, ein neues anlegen und dabei darauf achten, das es ein geroutetes Netz ist oder aber du machst es, wie erwähnt mit dem tap Interface und der Bridge.
Die Konfiguration, die auf der Redhat Seite erklärt wird ist genau das was ich gesagt habe. Bridge + bond0.13 = alle VM's die in VLAN 13 sollen, Bridge2 + bind0.11 = alle VM's die in VLAN 11 sollen.

Genau das habe ich doch gemacht (nur dass es im Subnetz 11 keine VM's gibt, daher auch keine Bridge). Hier die Konfiguration:

Code:

[root@system1 ~]# virsh net-list --all
Name                 Status     Automatischer Start
-----------------------------------------
default              Inaktiv    yes       

[root@system1 ~]# virsh net-info default
Name            default
UUID            a873624e-a433-420e-aac9-03d9d6f2111c
Active:         no
Persistent:     yes
Automatischer Start: yes
Bridge:         virbr13

[root@system1 ~]# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>a873624e-a433-420e-aac9-03d9d6f2111c</uuid>
  <forward mode='route'/>
  <bridge name='virbr13' stp='on' delay='0' />
  <mac address='52:54:00:AA:F7:75'/>
  <ip address='172.16.13.1' netmask='255.255.255.0'>
  </ip>
</network>

BTW: Ich habe auf die Schnelle keine Möglichkeit gefunden, zu überprüfen, ob vnet0 tatsächlich ein tap-Interface ist. Der einzige Hinweis auf ein tap/tun-Interface ist das hier:

Code:

[root@system1 ~]# cat /dev/net/tun
cat: /dev/net/tun: Die Dateizugriffsnummer ist in schlechter Verfassung

Google sagt, das ist ein Zeichen für ein aktives Device.

gehrke · 13 Nov. 2012

spoensche schrieb:
vnet0 gehört zum default Netzwerk von libvirt.

Testweise habe ich versucht, das inaktive default-Netzwerk im virt-manager zu starten. Resultat:

Code:

Error starting network 'default': Interner Fehler Network is already in use by interface bridge-media

spoensche · 13 Nov. 2012

Die Konfiguration ist so nicht korrekt. Du musst die Bridge selber anlegen und nicht per virt-manager. Die Bridge sollte keine IP haben. In das VLAN 13 kommt sie durch die Zuweisung des Interfaces bond0.13.

Beispiel:

Code:

brctl addbr br0
brctl addif br0 bond0.13

Deine Libvirt Konfiguration sieht dann wie folgt aus:

Code:

<network>
  <name>default</name>
  <uuid>a873624e-a433-420e-aac9-03d9d6f2111c</uuid>
  <forward mode='bridge' />
  <bridge name="br0"/>
</network>

Die VM wird dann mit

Code:

<interface type='bridge'>
   <source bridge='br0'/>
</interface>

an die Bridge angeschlossen.

gehrke · 14 Nov. 2012

spoensche schrieb:
Die Konfiguration ist so nicht korrekt. Du musst die Bridge selber anlegen und nicht per virt-manager.

Ich hatte die Bridge 'bridge-media' von Hand via network-script angelegt (s. allererster Beitrag in diesem Thread) und nicht via virt-manager. Im virt-manager hatte ich nur testweise mal eine Bridge 'virbr13' angelegt, aber die ist wie oben zu sehen ja deaktiviert. Den Output davon hatte ich nur gepostet, weil Du schriebst, dass ich das default-Netz abschalten sollte und ich wollte zeigen, dass das schon deaktivert war.

spoensche schrieb:
Die Bridge sollte keine IP haben. In das VLAN 13 kommt sie durch die Zuweisung des Interfaces bond0.13.

Auf Deinen Hinweis hin habe ich jetzt das Script für die Bridge hinsichtlich 'BOOTPROTO' korrigiert, so dass die Bridge selbst nun keine IP mehr bekommt:

Code:

[root@system1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bridge-media 
DEVICE=bridge-media
#BOOTPROTO=dhcp
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge
DELAY=0

[root@system1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    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: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe27:afac/64 scope link 
       valid_lft forever preferred_lft forever
5: bond0.11@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
    inet 172.16.11.8/24 brd 172.16.11.255 scope global bond0.11
    inet6 fe80::225:90ff:fe27:afac/64 scope link 
       valid_lft forever preferred_lft forever
6: bond0.13@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe27:afac/64 scope link 
       valid_lft forever preferred_lft forever
7: bridge-media: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 00:25:90:27:af:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe27:afac/64 scope link 
       valid_lft forever preferred_lft forever
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:54:00:0d:51:10 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe0d:5110/64 scope link 
       valid_lft forever preferred_lft forever

Und was soll ich sagen: Kaum macht man es richtig, schon funktioniert's. Es ist immer wieder faszinierend...

Ich weiß auch gar nicht, warum eine Bridge eine IP haben sollte. Das ist natürlich sehr ärgerlich, dass dieser eine Fehler von mir hier so viel Ressourcen belegt hat, aber nachher ist man halt immer klüger.

@spoensche: Vielen herzlichen Dank!

cu, Paul

gehrke · 14 Nov. 2012

gehrke schrieb:
spoensche schrieb:

Für die VM's musst du eigenständige tap Interfaces anlegen, sobald die VM gestartet wird. KVM/Qemu bringen die notwendigen Scripte qemu-ifup und qemu-ifdown mit.

Zum Vergrößern anklicken....

Ich habe etwas nachgeforscht und vermute mitterweile, dass ich mit 'vnet0' schon von Beginn an ein tap-Interface am Start habe:
...
Ich denke, dass dies von libvirt schon implizit durch diese Konfiguration so umgesetzt wird:

Code:

[root@system1 ~]# virsh dumpxml vm1 ... <interface type='bridge'> <mac address='52:54:00:0d:51:10'/> <source bridge='bridge-media'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> ...

Habe ich Recht, dass das schon ein tap-Device ist? Und wenn ja, wie löse ich den mein Problem???

Ich bin jetzt noch über die passende Dokumentation gestolpert. Demnach handelt es sich um ein tun-Interface, was wohl nicht ganz so weit von einem tap-Device entfernt ist.

http://libvirt.org/formatdomain.html#elementsNICSBridge:

The guest VM will have an associated tun device created with a name of vnetN, which can also be overridden with the <target> element (see overriding the target element). The tun device will be enslaved to the bridge.

spoensche · 14 Nov. 2012

gehrke schrieb:
Es ist immer wieder faszinierend...

Genau so ist es.

gehrke schrieb:
Ich weiß auch gar nicht, warum eine Bridge eine IP haben sollte. Das ist natürlich sehr ärgerlich, dass dieser eine Fehler von mir hier so viel Ressourcen belegt hat, aber nachher ist man halt immer klüger.

@spoensche: Vielen herzlichen Dank!

So viele Resourcen waren es nicht. Keine Sorge ich hab genug CPU Power und RAM zur Verfügung.

[gelöst] Keine Netzwerk-Verbindung zum kvm-Host

gehrke

Administrator

gehrke

Administrator

spoensche

Moderator

gehrke

Administrator

spoensche

Moderator

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator

spoensche

Moderator

gehrke

Administrator

gehrke

Administrator

spoensche

Moderator

gehrke

Administrator

gehrke

Administrator

spoensche

Moderator