Irgendeine Idee? Das führt hier auf Supernodes dazu, dass Prefixe (nach meinem Gefühl) nur sehr sporadisch announced werden.
kernel: device br0 left promiscuous mode
radvd: br0 does not support multicast, forcing UnicastOnly
Ich habe vermutlich alles FAQs und Google-Resultate der ersten 3 Seiten „durch“.
Meist geht es um Leute, die im laufe des Threads feststellen, dass ihnen der Server geownt wurde und darüber dann die nächsten 3 Seiten diskutieren.
oder Leute die irgendwelche Desktop-Linuxe mit Wifi benutzen wollen.
Ich ahbe schon ein paar kombinationen durch, sowohl mit „ip link“ und auch was man so in im /sys/devices an optionen findet.
ip link set dev br0 multicast on promisc on
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
Das Problem ist, dass der Promiscous-Mode immer nur Sekundenbruchteile hält… erkommt etwa einmal pro Minute kurz.
Sep 9 07:23:43 hld-2 kernel: [ 7859.825208] device br0 entered promiscuous mode
Sep 9 07:23:43 hld-2 kernel: [ 7859.826557] device br0 left promiscuous mode
Und wenn der verloren geht erstmalig, schaltet der radvd um:
Sep 9 07:23:37 hld-2 kernel: [ 7853.168085] device br0 left promiscuous mode
Sep 9 07:23:38 hld-2 radvd[15851]: br0 does not support multicast, forcing UnicastOnly
Config z.B.
auto br0
iface br0 inet static
address 10.11.128.1
netmask 255.255.240.0
bridge_ports none
bridge_stp yes
post-up ip link set $IFACE promisc on multicast on
mir fehlt gefühlt irgendwie welche ports du Bridget bei uns sieht das so aus. ce: bat0
iface br0 inet manual
post-up ifconfig $IFACE up
post-up ifconfig $IFACE up
bridge_ports bat0 eth1
##Einschalten post-up:
# IP des Gateways am B.A.T.M.A.N interface:
post-up ip addr add 10.50.32.5/21 dev $IFACE
# Regeln, wann die fff Routing-Tabelle benutzt werden soll:
post-up ip rule add iif $IFACE table fff
post-up ip rule add from 10.0.0.0/8 table fff
post-up ip rule add to 10.0.0.0/8 table fff
# Route in die Fuerther Hood:
post-up ip route add 10.50.32.0/21 dev $IFACE table fff
# Start des DHCP Servers:
post-up invoke-rc.d isc-dhcp-server restart.
ist das eine Virtuelle Maschine ?
Passiert zufällig im gleichen Zeitfenster etwas auf dem darunter liegendem Host?
Welchen Netzwerk Treiber benutzt ihr falls es eine VM in benutzung von LibvirtD ist?
Was sagt „dmesg“ bevor diese Meldungen kommen ?
Funktionieren noch Programme wie tcpdump / iftop, die den promiscuous auch brauchen/aktivieren?
Schon,
Nur wäre das für mich rätselhaft, weil doch die br0 eine rein „vm-lokaler“ virtueller Switch ist auf dem (mit dem Batman) auch nur ein vm-lokales virtuelles Interface hängt.
Es ist also keine Verbindung irgendwo zu einer paravirt-Lankarte vorhanden bei diesen Geräten.
(Wenn das auf eth0/ens18 etc passieren würde: gekauft! Aber gerade die sind nicht betroffen.)
hi, vielleicht hilft das bei dem multicast Problem weiter nux: Enabling Multicast querier on bridges
If your router or switch does not support enabling a multicast querier, and you are using a classic linux bridge (not Open vSwitch), then you can enable the multicast querier on the Linux bridge by adding this statement to your /etc/network/interfaces bridge configuration:
post-up ( echo 1 > /sys/devices/virtual/net/$IFACE/bridge/multicast_querier ).
Ja, den hatte ich leider auch schon zu fassen:
auch bei direktem, sofortigen Neustart des Radvd:
Sep 9 23:27:52 Flingern-2 radvd[2315]: interface br0 does not support multicast
Sep 9 23:27:52 Flingern-2 radvd[2315]: do you need to add the UnicastOnly flag?
In der Bridge hängen aber nicht die L2TP Tunnel drin oder?
Wenn nein, hast Du schon mal versucht ob Du mit „macvlan“ Devices evt. das Problem umschiffen kannst ?
(Ähnlich wie mit dem Alfred Interface früher)
Entweder ein eher komplexes setup: (tap geht zu einem anderen Supernode, die taps sind die verschiedenen Batman-Netze), die ifs eth1 und eth2 gehen zu lokalen VMs, die via batman und als ip-client im Netz hängen für Monitoring)
(Also nicht der Ort in dem man debuggen möchte, weil so viele Szenarien denkbar.)
root@Flingern-2:/home/adorfer# batctl if
eth2: active
tap-ffdus-fl3: active
tap2: active
tap1: active
tap0: active
root@Flingern-2:/home/adorfer# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.cab1e1326564 no bat0
eth1
Aber hier ein eher einfaches Setup, das genauso betroffen ist:
root@hld-2:/home/adorfer# uname -a
Linux hld-2 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root@hld-2:/home/adorfer# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.02eeefca1175 yes bat0
root@hld-2:/home/adorfer# batctl if
tap0: active
Kunden frage ich ja normalerweise erst mal:
Ging das schon mal ?
Ab wann nicht mehr ?
Gilt das fuer alle Supernodes oder sind welche nicht betroffen ?
fand ich ganz interessant vom Ansatz, aber man hat da wohl auch keine Prozessinfos an der Hand.
(>>auditing)
Wenn der Modus wieder sehr schnell abgestellt wird, muesste es ja auch ein Mechanismus sein, der
dern Zustand dauernd polled. Das muesste sich ja auch nachweisen lassen. Also vermutlich eher ein Prozess, der dauernd laeuft und nichts, was im Shell accounting vorbeifliegt zeitnah.
Auch wenn Du den lokalen virtuellen Switch fuer unverdaechtig haeltst, das es den trifft, so koennte es ja auch noch ein Bug sein im Bereich Virtualisierung.
Tja… es ging mal als der Kernel noch ein 3.x irgendwas war beim einem relativ jungen Install von Ubuntu14.4LTS…
Oder damals hat der Kernel das noch nicht gemeldet im Syslog?
Wie auch immmer… ich habe den radvd jetzt von br0 auf bat0 (also von vom switch auf das Batman-Interface) umgestellt.
hehe also das Problem ist eigentlich ein relativ alter Hut, den Du jetzt mal in Angriff nehmen wolltest und die bat0 Alternative hattest Du schon in petto und bist guter Hoffnung, dass das Problem nicht wandert.
toi toi toi