Dann würde ich mal behaupten, dass etwas mit deinem Mangement-LAN nciht stimmt.
Ich kenne die 100FDX-Meldung hauptsächlich dann, wenn das Kabel beschädigt ist. Solche Probleme, dass Access Points dauernd on/offline gehen, kommt daher, wenn mit der Netzwerkkonfiguration was nicht stimmt (in unserem Fall meistens DHCP).
z.B.:
mehrere DHCP-Server im Mgmt-Netz
Manamgent-VLAN eingetragen oder falsch
Subnetzmaske nicht ausreichend
IP-Konflikte
Falls Loop-Protection deaktiviert: loop
P.S.: ich könnte mir vorstellen, dass du dich auch mit einem Versuchsaufbau glücklich machen kannst (Ferien bieten es eh an):
Alles ausstecken bis auf: Opensense, 1 Switch, Controller, 1 Access Point
Wenn es dann geht, weißt du schon mal, dass das Problem nicht in der Konfiguration liegt. Dann kannst du auf die Suche gehen.
Und wenn du dann ganz pech hast, ist irgendwo ein defektes Gerät, welches das Netzwerk mit Paketen flooded (ein mal passiert, da kann man im Strahl…). Habs durch sukkzessives Abstecken rausgefunden - hätte man aber bestimmt auch mit Wireshark oder so ermitteln können. (<- vielleicht lohnt sich da auch mal ein Blick für dich?)
OMG … das klingt nach der Suche nach der sprichwörtlichen Nadel im Heuhaufen.
Was die 100FDX-Meldung angeht: Ich habe mir dabei bisher nie etwas gedacht, weil es nicht immer die gleichen Accesspoints waren. Und alle Kabel können kaum defekt sein. Manchmal reicht auch ein Neustart und es wird wieder 1GBit angezeigt.
Hallo Michael,
du betreibst deinen Unifi-Controller aber schon auf einem Linux-Server und nicht etwa auf einer UDM-Pro o.ä.?
Ein derartiges Verhalten konnten wir nämlich beobachten, als wir versucht haben unsere Unifi-Umgebung auf einer UDM-Pro zu betreiben. Die war schlicht und einfach überfordert damit.
LG
Daniel
auch ich beobachte schon seit Längerem immer wieder Meldungen, dass APs mal offline seien. Auch wenn das vielleicht nicht sauber ist, glaube ich nicht, dass es mit dem vorliegenden Problem zu tun hat, denn: die Meldungen haben wir schon ewig, das iPad-Problem trat erst seit Juni und plötzlich auf. Auch, dass Windows-Laptops im gleichen WLAN sauber funktionieren und nur die iPdas nicht, spricht imho dagegen.
Also nicht, dass man das auch mal angehen könnte aber ich glaube, wir müssen woanders suchen.
Hallo.
Wir haben eine Merkwürdigkeit im WLAN gefunden und geändert – seitdem laufen die iPads schnell und ohne Verbindungsabbrüche .
Ich beschreibe mal die gefundene Merkwürdigkeit – falls das in das Reich der Märchen und Mythen gehört und es keinen kausalen Zusammenhang mit den beobachteten Effekten geben kann, lasse ich mich gerne eines besseren belehren…
Aber der Reihe nach:
Es war einmal eine OPNSense, auf der war ein sehr großer DHCP-Bereich einstellt. Das Netz für das WLAN war ein /16er Netz und die DHCP-Range erstreckte sich von 172.16.1.1 bis 172.16.10.254.
Bei der Durchsicht der Leases stellte ich gestern fest, dass von der OPNSense an die iPads auch IP-Adressen wie z.B. 172.16.3.0 oder auch 172.16.9.255 vergeben wurden. Da wurde ich hellhörig: In kleinen /24er Netzen sind das ja gerade die Multicast-/Broadcastadressen, die man nicht verwenden kann.
Was, wenn es auf UniFi- oder Apple-Seite ein Problem damit gibt, wenn eine Gerät so eine IP-Adresse erhalten hat (auch wenn die Netzmaske zu einem /16er Netz gehört)?? Ich bin nicht Fachmann genug um beurteilen zu können, ob das auf den Tablets den beobachteten Stress verursacht hat.
Fest steht aber: Wir haben es geändert und die Probleme mit den Disconnects sind (nach allem, was ich heute gesehen habe) verschwunden.
Da stellt sich schon die Frage, ob das überhaupt die Ursache sein kann und ob das bei Euch auch so eingestellt ist?
Hallo Michael, hi @all,
laut „Lehrbuch“ sind .0 und .255 für Broadcast reserviert und dürfen nicht an „Endgeräte“ vergeben werden. So habe ich es zumindest gelernt
Danke für deinen Hinweis!
VG Andreas
ob die .0 und .255 reservierte Adressen sind hängt m.E. von der Netzmaske ab. Für ein 24-Netz sind sie reserviert, da sie die erste und die letzte IP-Adressen darstellen.
Z.B. in einem 16-Netz hingegen sind auch die erste und letzte IP reserviert, zwischendrin gibt es aber weitere .0 und .255 Adressen, diese sollten m.E. normal nutzbar sein.
Also dass das so ist mit den beiden einzigen „reservierten“ Adressen .0 und .255 ganz am Anfang und ganz am Ende des /16er Netzes steht außer Frage … die eigentliche Frage ist, ob ein Endgerät trotzdem mit so einer Adresse wie 172.16.3.0 oder 172.16.5.255 und /16er Netzmaske Probleme machen kann?
klingt komisch, da es ja nur einige wenige Geräte betroffen haben müsste, nämlich genau die, die eine x.0 oder y.255 bekommen haben. Bei uns waren das gefühlt deutlich mehr.
Hi Jochen – ja, klingt auch komisch und wie gesagt: ob das überhaupt „physikalisch“ möglich ist, müssen andere beurteilen.
Ich habe mir das in etwa so zusammengereimt: Ein Gerät erhält eine .255 am Ende und feuert auf seiner Adresse … für die anderen sieht das (fälschlich) wie ein Broadcast aus und sie reagieren ständig darauf?!? Dadurch wird das gesamte Netzwerk sehr langsam?!? Ist sowas denkbar?
Was wir geändert haben ist relativ einfach: In der OPNSense kann man im Bereich für den DHCP-Dienst verschiedene „zusätzliche Pools“ angeben. Wir haben also mehrere Ranges definiert und sie immer nur von .1 bis .254 laufen lassen. So werden also die Adressen mit der .0 und .255 gar nicht mehr vergeben.
Ja, erzähl mal, ob es danach auch bei Euch besser wird.
(Vielleicht sollte ich noch dazu sagen, dass bei uns der Unifi-Controller das WLAN nur als „VLAN only“ kennt. )
Nein, wir hatten ursprünglich (wie schon oben geschrieben) den Bereich von 172.16.1.1 bis 172.16.10.254, damit wir viel mehr als 254 Adressen zur Verfügung haben, wenn eigene Geräte mitgebracht werden usw usw.
Daher ja auch eine /16er Netzmaske.
Bei dieser Vorgehensweise hat man aber trotzdem die IP-Adressen
172.16.1.255
172.16.2.255
172.16.3.255
usw bis hin zu
172.16.9.255, die vom OPNSense-DHCPd an die Geräte verteilt werden.
Also unter’m Strich sind das 9 Geräte mit einer IP-Adresse, die in einem /24er Netz Stress machen würden!
Nein eher nicht. Wenn die Betriebssystem-Programmierer nicht geschlafen haben, dann haben sie die Standards (RFC) ordentlich implementiert und das Gerät verwendet IPs und Netzmasken wie im Standard vorgesehen, d.h. .0 und .255 sind nur in einem /24 für Netzadresse und Broadcast reserviert und für alle anderen Netzmasken ist es nur die erste .0-Adresse und die letzte .255-Adresse oder korrespondierende IP größer 0/kleiner 255.
Ich habe mich daraufhin nochmal auf einem solchen AP per ssh angemeldet und mit tail -f /var/log/messages beobachtet, was da los ist.
Eine der Meldungen lautet:
user.err libubnt[3481]: mcad[3481]: ace_reporter_trsp_curl.check_multi_info(): inform failed with curl code 52
– und zwar genau zu dem Zeitpunkt, wenn der Accesspoint als „Disconnected“ gemeldet wird. Tipp man allerdings info in der Konsole ein, steht dort bei uns immer : Status: Connected
Es kann also durchaus ein Fehlalarm sein?!
Ist das bei Dir auch so, @jochen ?
Viele Grüße,
Michael
ich denke ja, da gefühlt auch alles funktioniert hat, obwohl APs in den Notifications des Controllers als offline gemeldet wurden, es gab aber keine Beschwerden. Genau kann ich es jedoch nicht sagen, da ich mich nie zeitgleich auf einen der angeblich betroffenen APs verbunden habe. Werde ich versuchen, wenn es wieder dazu kommt.
Spannend: wir haben ja noch 1 Woche Ferien und dadurch keine Anmeldungen von Geräten oder Traffic. In den Controller-Logs tauchen aktuell auch keinerlei Meldungen von angeblichen offline APs auf! Bin mal gespannt, ob sich das wieder ändert, wenn die Schule wieder losgeht und werde berichten.
.
