macvtap-Netzwerk und IPv4 Multicast

18/04/2015 - 13:24 von Marc Haber | Report spam
Hallo,

gegeben sei ein Linux-System (Debian Testing "aida"), auf dem in KVM
(mit libvirt konfiguriert) ein weiteres Debian Testing "parada" làuft.
Beide Systeme haben einen selbst gebauten Kernel 3.19.3. Die
Netzwerkanbindung ist mit macvtap (Source Mode: Bridge) gelöst:

|[1/105]mh@aida:~$ ip a
|1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| inet 127.0.0.1/8 scope host lo
| valid_lft forever preferred_lft forever
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
|2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
| link/ether 00:0d:b9:34:2a:fc brd ff:ff:ff:ff:ff:ff
|3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
| link/ether 00:0d:b9:34:2a:fd brd ff:ff:ff:ff:ff:ff
|4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
| link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff
| inet 192.168.251.251/24 brd 192.168.251.255 scope global eth2
| valid_lft forever preferred_lft forever
| inet6 2a01:238:4071:321e:20d:b9ff:fe34:2afe/64 scope global mngtmpaddr dynamic
| valid_lft 85954sec preferred_lft 13954sec
| inet6 fe80::20d:b9ff:fe34:2afe/64 scope link
| valid_lft forever preferred_lft forever
|6: macvtap0@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
| link/ether 52:54:00:85:05:d6 brd ff:ff:ff:ff:ff:ff
| inet6 fe80::5054:ff:fe85:5d6/64 scope link
| valid_lft forever preferred_lft forever
|[2/106]mh@aida:~$ ip r
|default via 192.168.251.254 dev eth2
|192.168.251.0/24 dev eth2 proto kernel scope link src 192.168.251.251
|[3/107]mh@aida:~$ ip -6 r
|2a01:238:4071:321e::/64 dev eth2 proto kernel metric 256 expires 85951sec
|fe80::/64 dev eth2 proto kernel metric 256
|fe80::/64 dev macvtap0 proto kernel metric 256
|default via fe80::210:75ff:fe1a:df14 dev eth2 proto ra metric 1024 expires 1351sec hoplimit 64
|[4/108]mh@aida:~$

|[1/59]mh@parada:~$ ip a
|1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| inet 127.0.0.1/8 scope host lo
| valid_lft forever preferred_lft forever
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
|2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
| link/ether 52:54:00:85:05:d6 brd ff:ff:ff:ff:ff:ff
| inet 192.168.251.63/24 brd 192.168.251.255 scope global eth0
| valid_lft forever preferred_lft forever
| inet6 2a01:238:4071:321e:5054:ff:fe85:5d6/64 scope global mngtmpaddr dynamic
| valid_lft 86395sec preferred_lft 14395sec
| inet6 fe80::5054:ff:fe85:5d6/64 scope link
| valid_lft forever preferred_lft forever
|[2/60]mh@parada:~$ ip r
|default via 192.168.251.254 dev eth0
|192.168.251.0/24 dev eth0 proto kernel scope link src 192.168.251.63
|[3/61]mh@parada:~$ ip -6 r
|2a01:238:4071:321e::/64 dev eth0 proto kernel metric 256 expires 86391sec
|fe80::/64 dev eth0 proto kernel metric 256
|default via fe80::210:75ff:fe1a:df14 dev eth0 proto ra metric 1024 expires 1791sec hoplimit 64
|[4/62]mh@parada:~$

Die IPv4-Adressen sind per DHCP vergeben; IPv6 per SLAAC und radvd.

Sowohl auf aida als auch auf parada laufen je ein avahi-daemon in
Defaultkonfiguration.

Wenn der avahi-daemon auf parada frisch gestartet ist, können andere
Systeme im LAN parada.local auflösen. Ich vermute, dass kommt daher,
dass der avahi-daemon bei seinem Start die von ihm veröffentlichten
Resource Records einmal ins Netz blàst.

Aber sobald diese Eintràge in den avahi-Daemons der Clients expired
sind, ist es vorbei mit der Namensauflösung. tcpdump auf beiden
Systemen zeigt, dass die IPv4-Multicasts an 224.0.0.251 auf aida zwar
gesehen werden, aber nicht bei parada ankommen. Die IPv6-Multicasts an
ff02::fb kommen jedoch an.

tcpdump auf aida eth2:
|22:26:33.872271 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)
|22:26:33.872893 IP 192.168.251.21.5353 > 224.0.0.251.5353: 0 A (QM)? parada.local. (30)
|22:26:34.873764 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)
|22:26:34.874172 IP 192.168.251.21.5353 > 224.0.0.251.5353: 0 A (QM)? parada.local. (30)
|22:26:36.876135 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)
|22:26:36.876210 IP 192.168.251.21.5353 > 224.0.0.251.5353: 0 A (QM)? parada.local. (30)

tcpdump auf parada eth0:
|22:26:33.874132 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)
|22:26:34.875766 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)
|22:26:36.878080 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 A (QM)? parada.local. (30)

Ein Avahi-Daemon in Defaultkonfiguration jedoch antwortet nicht, wenn
eine Anfrage für einen A-Record über IPv6 rein kommt.

Erwartungsgemàß ist alles fein, wenn man in der Gegenprob enach dem
AAAA-Record fragt.

tcpdump auf aida:
|12:31:40.839231 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 AAAA (QM)? parada.local. (30)
|12:31:40.839341 IP 192.168.251.21.5353 > 224.0.0.251.5353: 0 AAAA (QM)? parada.local. (30)
|12:31:40.840733 IP6 2a01:238:4071:321e:5054:ff:fe85:5d6.5353 > ff02::fb.5353: 0*- [0q] 1/0/0 (Cache flush) AAAA 2a01:238:4071:321e:5054:ff:fe85:5d6 (52)

tcpdump auf parada:
|12:31:40.835442 IP6 2a01:238:4071:321e:224:d7ff:fed0:5adc.5353 > ff02::fb.5353: 0 AAAA (QM)? parada.local. (30)
|12:31:40.835871 IP6 2a01:238:4071:321e:5054:ff:fe85:5d6.5353 > ff02::fb.5353: 0*- [0q] 1/0/0 (Cache flush) AAAA 2a01:238:4071:321e:5054:ff:fe85:5d6 (52)

Auch hier kommt das IPv4-Paket nicht zu parada durch; das macht aber
nichts, weil der avahi-Daemon auf parada auf die Frage nach AAAA zu
antworten gewillt ist.

Woran kann das liegen? Hat jemand eine Idee? Hat macvtap grundsàtzlich
ein Problem mit IPv4 Multicast?

Der überall genannte Bug im Kernel bezüglich IGMP Snooping scheint
hier nicht einschlàgig zu sein, denn erstens taucht der eher bei
Bridges und nicht bei macvtaps auf, und der Normalfall 224.0.0.0/24
passt hier ebenfalls.

Der Trick mit
/sys/devices/virtual/net/(interface)/bridge/multicast_snooping greift
hier ebenfalls nicht, weil macvtap0 eben keine Bridge ist und in
seinem /sys-Verzeichnis kein Unterverzeichnis bridge existiert.

Ideen?

Grüße
Marc
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 

Lesen sie die antworten

#1 Marc Haber
19/04/2015 - 14:23 | Warnen spam
Marc Haber <mh+ wrote:
gegeben sei ein Linux-System (Debian Testing "aida"), auf dem in KVM
(mit libvirt konfiguriert) ein weiteres Debian Testing "parada" làuft.
Beide Systeme haben einen selbst gebauten Kernel 3.19.3. Die
Netzwerkanbindung ist mit macvtap (Source Mode: Bridge) gelöst:



Umgestellt auf "richtige" bridge, geht, fertig:

|1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| inet 127.0.0.1/8 scope host lo
| valid_lft forever preferred_lft forever
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
|2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
| link/ether 00:0d:b9:34:2a:fc brd ff:ff:ff:ff:ff:ff
|3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
| link/ether 00:0d:b9:34:2a:fd brd ff:ff:ff:ff:ff:ff
|4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
| link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff
|5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
| link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff
| inet 192.168.251.251/24 brd 192.168.251.255 scope global br0
| valid_lft forever preferred_lft forever
| inet6 2a01:238:4071:321e:20d:b9ff:fe34:2afe/64 scope global mngtmpaddr dynamic
| valid_lft 85938sec preferred_lft 13938sec
| inet6 fe80::20d:b9ff:fe34:2afe/64 scope link
| valid_lft forever preferred_lft forever
|6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 500
| link/ether fe:54:00:85:05:d6 brd ff:ff:ff:ff:ff:ff
| inet6 fe80::fc54:ff:fe85:5d6/64 scope link
| valid_lft forever preferred_lft forever

Grüße
Marc
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Ähnliche fragen