1781EF+: ARP-Tabelle mit falschem Eintrag?

[Jirka]

Hallo zusammen,

im Zuge einer Glasfaserumstellung hatte ich vor kurzem einen LANCOM-Router 1781EF+ mit AON-Glasfasermodul verbaut. Nachdem das dann im zweiten Anlauf funktionierte, kamen dann so nach und nach Beschwerden mitunter würde es nicht funktionieren, allerdings auch nicht bei allen Geräten, sondern immer nur bei bestimmten WLAN-Geräten. Es war lange diffus und nebulös, insbesondere war anfangs das WLAN in Verdacht, aber irgendwie liegt die Ursache doch im 1781EF+, wie ich jetzt feststellen musste. Oder an irgendwas, was ich übersehen habe im 1781EF+.

Also, wir haben einen 1781EF+ mit 10.50-RU11, das ist die derzeit aktuellste Firmware. Am SFP-Port ist das AON-Modul, da kommt das Internet her. Bleiben fünf Ethernet-Ports übrig: WAN und ETH-1 bis ETH-4. Der alte LANCOM hatte ETH-1 bis ETH-4 und integriertes WLAN. Da alle Ethernet-Ports belegt waren und sauber dokumentiert sind, wurden diese eins zu eins auf den 1781EF+ übernommen. Und der alte LANCOM-Router wurde umkonfiguriert als WLAN-AP an den WAN-Ethernet-Port gehangen, dazu wurde dieser, wie alle ETH-Ports auch, dem LAN-1 zugewiesen. Alle fünf Ethernet-Ports sind also dem LAN-1 zugewiesen und sollten so genutzt werden, also als fünf gleichwertige geswitchte LAN-Ports. Die mehreren lokalen Netzwerke werden per VLAN mit auf das LAN-1 gelegt. Grundsätzlich funktioniert alles. Am WAN-Port hängt jetzt also ein (LANCOM) WLAN-AP, am ETH-1 und am ETH-2 ebenfalls. An den anderen Ethernet-Ports hängen schnurgebundene Geräte.

Nun funktioniert regelmäßig das WLAN nicht mehr, ein iPhone sagt z. B. "Das WLAN "SSID-Name" ist anscheinend nicht mit dem Internet verbunden." Wenn man da weiter geht, steht auch noch: "Keine Internetverbindung - Ist dies dein WLAN, versuche, das Modem und den Router neu zu starten oder wende dich an deinen Internetdienstanbieter." Das Schlimme ist, das würde tatsächlich helfen, aber das hat man nicht gemacht, auch weil ich sagte, das kann nicht sein, das Monitoring zeigt, dass der Router ok ist. Man hat dann festgestellt, dass wenn man das WLAN am WLAN-Client aus- und einschaltet, also hier z. B. am iPhone, dass dann alles wieder geht. Aber irgendwie ist das auf Dauer auch nervig. Nachdem ich dann irgendwann mal rausgefunden hatte, dass wir es hier doch nicht mit WLAN-Problemen zu tun haben, wie immer wieder angenommen wurde, kam ja nur noch der Router in Frage, der aber ja eigentlich auch funktionierte. Wieso sollte plötzlich irgendein WLAN-Client nicht mehr ins Internet dürfen? Die Konfig durchgeschaut, damit man nichts übersieht auch noch mal als Script, aber nichts gefunden. Dann habe ich mich im Fehlerfall anrufen lassen und habe dann geschaut, was auf dem 1781EF+ los ist. Und da musste ich irgendwie feststellen, dass die ARP-Tabelle den WLAN-Client am WAN-Port führt, obwohl er seit einer Stunde am AP am ETH-2-Port hängt. Der WLAN-Client war also, das kann man ja alles schön in den Logs nachvollziehen, mit dem AP am WAN verbunden, roamte dann rüber zu dem AP an ETH-2 und irgendwie kommt der 1781EF+ damit nicht klar, weil in der ARP-Tabelle der WLAN-Client immer noch an WAN aufgeführt wird. Teilweise eine Stunde später (ich weiß nicht, ob die eine Stunde damit zu tun hat, dass inaktive WLAN-Clients nach einer Stunde in den APs gelöscht werden), aber auch noch (kurz) nachdem im erstverbundenen AP stand "Disassociated WLAN station xyz due to idle timeout".

Das Problem tritt typischerweise so auf, man betritt das Gebäude und in dem Moment ist man mit dem AP am WAN verbunden. Dann geht man in der Regel nach oben oder unten und ist dann mit einem anderen AP verbunden, so dass das Problem auftritt. Tests die Ethernet-Ports zu vertauschen oder Roaming-Richtungen zu verändern konnten noch nicht durchgeführt werden. An ETH-2 befindet sich ein LN-630acn mit ursprünglich 10.34, dann 10.50 und mittlerweile 10.72-er Firmware. Das Updaten hat aber nichts gebracht, die Probleme blieben bestehen.

Irgendwie hat der 1781EF+ (bzw. der Nachfolger 1790EF) ja eine Sonderstellung mit den vielen Ports. Und nun bilde ich mir ein, dass der Router mit dem WAN-Port da als LAN-1 irgendwie nicht perfekt klar kommt. Weil was anderes fällt mir nicht ein. Das iPhone anzupingen bringt nichts, der Router macht keine ARP-Anfrage sondern richtet sich nach dem Eintrag in der ARP-Tabelle und schickt den Ping einfach am WAN-Port raus. Erst wenn das iPhone mal einen ARP-Request nach dem Router macht, macht es Klick im Router (Cache) und der Eintrag in der Tabelle springt um.

Ein IAPP-Netzwerk besteht. Im 1781EF+ sind aber die Default-Einstellungen bzgl. Multicast aktiv.

Wer hat Tipps? Oder wie sollte ich einen perfekten Trace machen, um der Sache weiter auf den Grund zu gehen?

P. S.: Ich kann den Fall erst in gut anderthalb Wochen weiter bearbeiten, will aber bis dahin Ideen sammeln.

Vielen Dank und viele Grüße
Jirka

[Dr.Einstein]

Hi Jirka,

falls es Konfigurationstechnisch möglich ist, setze die ETH-Ports, wo die APs dran hängen, auf LAN-2, LAN-3 bzw LAN-4 (alle Ports unterschiedlich, nicht gemeinsam), langebundene PCs bleiben auf LAN-1 und bringe sie alle in eine Bridge Gruppe BRG-2 z.B..

Gruß Dr.Einstein

[rotwang]

Irgendwie hat der 1781EF+ (bzw. der Nachfolger 1790EF) ja eine Sonderstellung mit den vielen Ports.

Die hätte ein 19xx auch. Den SFP-Port dann sogar als Kombo mit wahlweise Kupfer oder Faser.

Und nun bilde ich mir ein, dass der Router mit dem WAN-Port da als LAN-1 irgendwie nicht perfekt klar kommt.

Der WAN-Port am 1781EF+ hängt hardware-mässig genauso am internen Switch wie die ETH-1...ETH-4. Der einzige Unterschied ist der Name und die andere Default-Zuweisung.

Weil was anderes fällt mir nicht ein. Das iPhone anzupingen bringt nichts, der Router macht keine ARP-Anfrage sondern richtet sich nach dem Eintrag in der ARP-Tabelle und schickt den Ping einfach am WAN-Port raus. Erst wenn das iPhone mal einen ARP-Request nach dem Router macht, macht es Klick im Router (Cache) und der Eintrag in der Tabelle springt um.

Den Eintrag in der ARP-Tabelle manuell löschen würde vermutlich genauso helfen. Wenn eine MAC-Adresse auf einen anderen Port am internen Switch wechselt, bekommt der IP-Stack im LCOS davon erstmal nichts mit. In Deinem Szenario, wo alle Ports bis auf den SFP-Port auf LAN-1 gebunden sind, bekommt davon eigentlich noch nicht einmal das LCOS etwas mit, das macht der interne Switch selber. Dass dessen MAC-Tabelle richtig ist, wird man sich mit einem "show ethswitch atu" anschauen können.

Prinzipiell gibt's nach dem Roaming ein Broadcast-Paket vom neuen AP mit der MAC-Adresse des Clients als Quelle, damit alle Switche den Pfad zum Client umlernen. Nur die ARP-Tabelle im LCOS bekommt davon halt nichts mit...

[backslash]

Hi Jirka,

die ARP-Tabelle und die NDP-Tabelle für IPv6 machen eine Optimierung für die Bridge und spichern sich den Switch-Port über dne das Paket empfangen wurde... Bei einem Roaming wechselt die MAC-Adresse auf eine anderen Port, womit ARP/NDP-Tabelle nicht mehr mit der Realität übereinstimmt.
Diese Optimierung kannst du im CLI unter /setup/tcp-ip/ARP-Bridge-Optimization für IPv4 bzw. unter /Setup/IPv6/NDP/ARP-Bridge-Optimization für IPv6 abschalten. Dadurch speichert sich das ARP/NDP den Swicth-Port nicht mehr und zwingt die Bridge dazu, bei jedem Paket selbst einen MAC-Adreß-Lookup zu machen...

Aber eigentlich sollte das ARP auch auf ein gratuitous ARP des Geräts passend reagieren und den Port anpassen...

Gruß
Backslash

[Jirka]

Hallo zusammen,

falls es Konfigurationstechnisch möglich ist, setze die ETH-Ports, wo die APs dran hängen, auf LAN-2, LAN-3 bzw LAN-4 (alle Ports unterschiedlich, nicht gemeinsam), langebundene PCs bleiben auf LAN-1 und bringe sie alle in eine Bridge Gruppe BRG-2 z.B..

hmm, das ist aber eher ein schlechter Workaround. Und erklärt ja auch überhaupt nicht, warum es so nicht funktioniert bzw. lässt die Ursache dafür im Unklaren. Davon abgesehen müsste dann gewisser Traffic über die Bridge gehen, was glaube ich auch nicht so ganz ohne ist.
Ich meine klar, ich könnte jetzt auch einen Switch hinter den 1781EF+ hängen, ist wegen der Anbindung eines anderen Gebäudes eh geplant, aber das klärt doch nicht auf, wieso es so wie es jetzt ist nicht funktioniert. Irgendwas ist doch da nicht funktional. Und das muss doch irgendeine Ursache haben. Und wenn es meine Blödheit ist, dann weiß ich wenigstens fürs nächste Mal Bescheid.

Den Eintrag in der ARP-Tabelle manuell löschen würde vermutlich genauso helfen.

Vermutlich, aber das ist ja auch keine Dauerlösung.

Wenn eine MAC-Adresse auf einen anderen Port am internen Switch wechselt, bekommt der IP-Stack im LCOS davon erstmal nichts mit. In Deinem Szenario, wo alle Ports bis auf den SFP-Port auf LAN-1 gebunden sind, bekommt davon eigentlich noch nicht einmal das LCOS etwas mit, das macht der interne Switch selber. Dass dessen MAC-Tabelle richtig ist, wird man sich mit einem "show ethswitch atu" anschauen können.

Ok, das werde ich tun. Das ist ein sehr guter Tipp mal nach der MAC-Adresse-Tabelle des Switches zu schauen.
Aber wozu ist dann die ARP-Tabelle im LANCOM (unter st/tcp/arp/t)?
Was passiert mit Paketen, die der LANCOM-Router aus dem Internet dem Client zustellen will? Wenn in der ARP-Tabelle im LANCOM der WAN-Port steht, werden die Pakete dann dem Switch übergeben mit der Anweisung schiebe sie auf dem WAN-Port raus? Oder darf der Switch selber denken und sieht dann, dass der Client eigentlich an ETH-2 hängt und schiebt es da raus?

Prinzipiell gibt's nach dem Roaming ein Broadcast-Paket vom neuen AP mit der MAC-Adresse des Clients als Quelle, damit alle Switche den Pfad zum Client umlernen.

Ok, das ist mir bekannt. Soll ich mal nach dem Paket Ausschau halten, ob es im LANCOM ankommt?

Nur die ARP-Tabelle im LCOS bekommt davon halt nichts mit...

Also ist es keine gute Idee einen LANCOM-Router zu nehmen, drei LANCOM-APs anzuklemmen und dann die WLAN-Cients zwischen den APs roamen zu lassen? Muss da zwingend ein Switch dazwischen? Das ging doch aber früher alles problemlos.

Interessant ist ja auch Folgendes und damit habe ich ja u. a. auch rausgefunden, dass die WLAN-Verbindungen ok sind: Vom iPhone aus kann man im Safari-Browser das WEBconfig des LANCOM-Routers aufrufen. Auf eine normale Internetwebseite kommt man aber (immer noch) nicht. Aber der Aufruf von WEBconfig läuft ja auch anders, da wird ja der LANCOM-Router selber angesprochen, da ist glaube ich die ARP-Tabelle wieder egal, weil dahin zurückgeschickt wird, wo es hergekommen ist.

Aber eigentlich sollte das ARP auch auf ein gratuitous ARP des Geräts passend reagieren und den Port anpassen...

Also Du meinst das Paket, was der AP abschickt, wenn ein WLAN-Client zu ihm gekommen ist, damit die Switches lernen, dass die MAC-Adresse jetzt an diesem Port ist.
Aber irgendwie scheint das ja nicht zu funktionieren. Soll ich dem noch mal nachgehen oder hätte ich bei dieser Konstellation die von Dir angesprochene ARP-Bridge-Optimization abschalten müssen? Davon habe ich allerdings noch nie was gewusst.

Dadurch speichert sich das ARP/NDP den Swicth-Port nicht mehr und zwingt die Bridge dazu, bei jedem Paket selbst einen MAC-Adreß-Lookup zu machen...

Hmm, ich habe gedacht, wenn ich das bzw. die lokalen Netzwerke direkt dem logischen Interface LAN-1 zuordne, dass dann die Bridge doch eigentlich gar nicht involviert ist.

Irgendwie wird der Fall schon wieder komplexer, als ich annahm...

Vielen Dank und viele Grüße
Jirka

[backslash]

Hi Jirka

Aber eigentlich sollte das ARP auch auf ein gratuitous ARP des Geräts passend reagieren und den Port anpassen...

Also Du meinst das Paket, was der AP abschickt, wenn ein WLAN-Client zu ihm gekommen ist, damit die Switches lernen, dass die MAC-Adresse jetzt an diesem Port ist.

genau das meine ich

Aber irgendwie scheint das ja nicht zu funktionieren. Soll ich dem noch mal nachgehen oder hätte ich bei dieser Konstellation die von Dir angesprochene ARP-Bridge-Optimization abschalten müssen? Davon habe ich allerdings noch nie was gewusst.

Das Abschalten der Bridge-Optimierung ist eigentlich für Fälle, in denen kein gratuitous ARP kommt. Bei APs sollte das aber eigentlich kommen und somit die Optimierung aktiv bleiben können...

Dadurch speichert sich das ARP/NDP den Swicth-Port nicht mehr und zwingt die Bridge dazu, bei jedem Paket selbst einen MAC-Adreß-Lookup zu machen...

Hmm, ich habe gedacht, wenn ich das bzw. die lokalen Netzwerke direkt dem logischen Interface LAN-1 zuordne, dass dann die Bridge doch eigentlich gar nicht involviert ist.

Das Abschalten der Bridge-Optimierung funktioniert auch nur, wenn die Bridge aktiv ist - dazu müssen die lokalen Netze an Bridge-Gruppen gebunden sein. Ohne Bridge-Gruppe läßt sich die Optimierung nicht abschalten

Gruß
Backslash

[Jirka]

Hallo Backslash,

Das Abschalten der Bridge-Optimierung funktioniert auch nur, wenn die Bridge aktiv ist - dazu müssen die lokalen Netze an Bridge-Gruppen gebunden sein. Ohne Bridge-Gruppe läßt sich die Optimierung nicht abschalten.

hmm. Es sind alle Netze direkt an LAN-1 gebunden und alle Ports, bis auf der SFP-Port, auch LAN-1 zugewiesen. Ein paar Netze sind VLAN-getaggt und werden an den APs entsprechend ausgegeben.

Mal angenommen es kommt im IP-Router als Rückantwort auf den Aufruf der Webseite https://1.1.1.1 folgende Rückantwort:

[IP-Router] 2023/08/22 13:14:36,918
IP-Router Rx (INTERNET, RtgTag: 19):
DstIP: 10.10.19.10, SrcIP: 1.1.1.1, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 64413, SrcPort: 443, Flags: SA
Seq: 815242536, Ack: 1535651135, Win: 65160, Len: 0
Option: Maximum segment size = 1460
Option: SACK permitted
Option: 08 = 2a 1e 18 5e 13 c0 9d 7e
Option: NOP
Option: Window scale = 13 (multiply by 8192)
Route: LAN-1 Tx (INTRANET)

Wie wird das Paket jetzt zugestellt vom LANCOM-Router? Ziel-IP steht da, wo kommt die zugehörige MAC-Adresse her? Aus der ARP-Tabelle? Und dann? Sollte es dem Switch übergeben werden und der Switch stellt es entsprechend seiner Address Lookup Table zu oder schaut der LANCOM in die ARP-Tabelle und sagt dem Switch, dass er es an dem WAN-Port rausschicken soll? Wann wird also auf die ARP-Tabelle zurückgegriffen? Nur für die ARP-Auflösung oder auch den Port? Die Bridge hat ja wiederum auch noch wieder ihre eigene Address-Table.

Vielen Dank und viele Grüße
Jirka

[backslash]

Hi Jirka,

natürlich wird in die ARP-Tabelle geschaut. In der steht nunmal drin, welche MAC-Adresse zu der IP-Adresse gehört und außerdem, über welches LAN-Interface (z.B. LAN-1) und welchen Switch-Port (z.B. ETH-2) das Paket rausgehen soll.
Die MAC-Tabelle des Switches kann nicht genutzt werden, weil LANCOMs die Switchports in logische LAN-Interfaces aufteilt - näheres dazu kann dir sicherlich Rotwang erklären

Wenn das LAN-Interface an eine Bridge-Gruppe gebunden ist, dann merkt sich die Bridgeguppe die Zuordnung von MAC-Adresse, logischem LAN-Interface und Switch-Port. Wenn dem Paket die Info aber schon mitgegeben wurde, dann macht die Bridge den Lookup nicht mehr, sondren glaubt der Information an dem Paket. Das ist die Bridge-Optimierung...

Wenn du dein INTRANET nicht an LAN-1 sondern an eine Bridge-Gruppe (z.B. BRG-1) bindest (die natürlich LAN-1 enthalten muß), dann kannst du die Bridge-Optimierung abschalten und die Bridge den Lookup anhand der MAC-Adresse machen lassen. Das kostet zwar ein bischen Performance, erlaubt aber ein Roaming, selbst wenn kein gratuitous ARP vom AP kommt, auf den der Client geroamt ist.

Aber eigentlich sollte der AP, auf den der Client roamt, ein gratuitous ARP (für den Client) senden und das sollte auch beim LANCOM ankommen. Wenn das nicht passiert, dann solltest du untersuchen, wo das gratuitous ARP verloren geht

Gruß
Backslash

[rotwang]

Also eigentlich ist es so, daß LCOS-APs (wie's beim LX aussieht weiß ich nicht) nach dem Assoziieren eines Clients ein Broadcast-Paket mit der MAC-Adresse des Clients, LLC-Framing (DSAP=SSAP=0x00) und einer dekorativen aber irrelevanten Klartextmeldung als Payload verschicken. Das ist unabhängig von IAPP, das IAPP läuft ja u.U. in einem anderen (Management-)VLAN als die Clients. Die sehen im Ethernet-Trace etwa so aus:

Code: Alles auswählen

[Ethernet] 1900/01/01 01:29:45,531
Received 118 byte Ethernet packet via LAN-1:
Physical Port       : ETH-1
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : ec:e5:55:ff:d0:7f (Hirschmann-Automation ff:d0:7f)
IEEE frame len      : 104
-->LLC Header
DSAP                : 00 [I]
SSAP                : 00 [C]
Frame type          : U P/F=0 M=0
Body                : 44 65 61 72 20 73 77 69 Dear swi
                      74 63 68 65 73 2c 20 77 tches, w
                      65 27 64 20 6c 69 6b 65 e'd like
                      20 74 6f 20 64 72 61 77  to draw
                      20 79 6f 75 72 20 61 74  your at
                      74 65 6e 74 69 6f 6e 20 tention 
                      74 6f 20 74 68 65 20 66 to the f
                      61 63 74 20 74 68 61 74 act that
                      20 61 64 64 72 65 73 73  address
                      20 65 63 3a 65 35 3a 35  ec:e5:5
                      35 3a 66 66 3a 64 30 3a 5:ff:d0:
                      37 66 20 68 61 73 20 6d 7f has m
                      6f 76 65 64 2e          oved.

Der originäre Zweck wird aus dem Text klar, es ist aber auch so, dass LCOS-Router auf solche Pakete hören und als Reaktion darauf die Client-MAC aus ihrem ARP-Cache löschen. Zumindest taten sie das bis einschliesslich zur 10.50, auf auf dem 17881EF+ soll ja eine solche laufen...

Also bitte einmal auf dem 1781 schauen, ob da solche Pakete ankommen.

[backslash]

Hi rotwang,

man lent nie aus... ich dachte echt, da würde ein gratuitous ARP gesendet... Aber wenn das nur ein "unspezifisches" Paket ist, dann kann das ARP selbst nichts machen und muß hoffen, daß das Paket vom Ethernet-Treiber korrekt erkannt wird und daß dieser dem ARP auch sagt, daß es die Adresse löschen soll (da stellt sich mir glatt die Frage: werden die Adressen auch aus dem IPv6 Neigbor-Cache glöscht?).

@Jirka
am Ende bleibt dir dann wirklich nur der Weg mit der Bridge - oder du schaltest noch einen Switch vor das LANCOM, so daß alle Clients nur über einen Port reinkommen

Gruß
Backslash

[rotwang]

man lent nie aus... ich dachte echt, da würde ein gratuitous ARP gesendet...

Das tut - wenn überhaupt - nur der Client. Wenn das Roaming im WLAN "gut", d.h. sanft läuft, dann sollte der IP-Stack auf dem Client überhaupt nichts davon mitbekommen, und auch keine Veranlassung haben, einen gratuitous ARP zu schicken. Und der AP, zu dem der Client geroamt ist, kennt die IP-Adresse des Clients u.U. gar nicht.

Aber wenn das nur ein "unspezifisches" Paket ist, dann kann das ARP selbst nichts machen und muß hoffen, daß das Paket vom Ethernet-Treiber korrekt erkannt wird und daß dieser dem ARP auch sagt, daß es die Adresse löschen soll

Wurde es bis einschliesslich zur 10.50, danach ist das Feature bei Umbauten verloren gegangen...ist eine etwas subtile Sache. Aber wie Jirka schrieb, soll auf seinem 1781EF+ ja eine 10.50 laufen.

(da stellt sich mir glatt die Frage: werden die Adressen auch aus dem IPv6 Neigbor-Cache glöscht?).

Das Feature ist deutlich älter als der IPv6-Stack im LCOS...

[Jirka]

Hallo zusammen,

irgendwie hochinteressant was ihr hier so schreibt, bin echt begeistert. Dass ich bisher nicht antworten konnte, hatte andere Gründe.

natürlich wird in die ARP-Tabelle geschaut.

Das wollte ich ja nur bestätigt haben! Wenn da natürlich nichts drinsteht, folgt ein ARP-Request, auch klar.

Die MAC-Tabelle des Switches kann nicht genutzt werden, weil LANCOMs die Switchports in logische LAN-Interfaces aufteilt - näheres dazu kann dir sicherlich Rotwang erklären

Hmm. Das beruhigt mich insofern, dass ich bisher ja auch immer von der normalen ARP-Tabelle ausgegangen war und bisher nie in die "show ethswitch atu" geschaut habe.

Wenn das LAN-Interface an eine Bridge-Gruppe gebunden ist, dann merkt sich die Bridgegruppe die Zuordnung von MAC-Adresse, logischem LAN-Interface und Switch-Port. Wenn dem Paket die Info aber schon mitgegeben wurde, dann macht die Bridge den Lookup nicht mehr, sondern glaubt der Information an dem Paket. Das ist die Bridge-Optimierung...

Danke, verstanden.

Wenn du dein INTRANET nicht an LAN-1 sondern an eine Bridge-Gruppe (z.B. BRG-1) bindest (die natürlich LAN-1 enthalten muß), dann kannst du die Bridge-Optimierung abschalten und die Bridge den Lookup anhand der MAC-Adresse machen lassen. Das kostet zwar ein bisschen Performance, erlaubt aber ein Roaming, selbst wenn kein gratuitous ARP vom AP kommt, auf den der Client geroamt ist.

Das wäre dann die - ja Lösung will ich eigentlich nicht sagen, weil dafür finde ich es arg krass - also eher die Möglichkeit, es in bisheriger Konstellation (fehlerfrei) zum Laufen zu bekommen. Und unter den bisher hier erläuterten Fakten verstehe ich es auch. Dr. Einstein, liest Du eigentlich auch noch mit? Sicher, oder? Das ist doch schon sehr crazy, findest Du nicht auch?
Also nur noch mal zum Verständnis: Man hat einen LANCOM-Router ohne WLAN (also die Volumenmodelle), der steht standardmäßig im Intranet auf LAN-1 und die ETH-Ports sind auch LAN-1 zugeordnet. Nun schließt da jemand (direkt) zwei oder mehr LANCOM-APs an und landet dann bei so heftigen, schwer nachvollziehbaren Problemen? Und muss eine Bridge-Gruppe erstellen/zuordnen und dann die Bridge-Optimierung abstellen, damit es fehlerfrei läuft? Wie soll das denn jemand in der Praxis hinbekommen? Das geht doch gar nicht. Also ich meine es ehrlich, das ist doch eine bescheidene Situation. Ich habe zwar auch keine Lösung, die ich aus dem Ärmel schütteln kann, aber irgendwie muss da doch was geändert werden, wenn sich bestätigt, dass sich da der LANCOM-Router nicht korrekt verhält. Oder es muss ein Warnhinweis auf dem Gerät angebracht werden. Kann sich noch jemand an die orangen Aufkleber auf den alten VoIP-Geräten (1722/1723/1724/1823) erinnern da hinten auf den Ports. So ein Warnaufkleber, wo dann draufsteht, Vorsicht, diese Ports arbeiten nur als Switch wie man ihn für gewöhnlich kennt, wenn die logischen LAN-Interfaces in Brige-Gruppen gepackt werden und die Bridge-Optimierung ausgestellt wird. Na gut, das ist wohl unrealistisch und übertrieben, aber ich überlege gerade, wo ich überall solche Situationen habe. Also ein AP gleich am Router gibt es häufiger mal, die weiteren sind dann oft hinter einem Switch, aber das Problem würde dann ja auch auftreten. Und irgendwie kann ich mich definitiv an Fälle erinnern, da flog das LANCOM-WLAN möglicherweise deswegen raus (schöne neue LN-APs). Es waren Kunden von Systemhäusern, wo ich noch mal gebeten wurde, über die Konfig zu schauen, da waren zwar Fehler drin, aber die Probleme blieben.

Also eigentlich ist es so, daß LCOS-APs (wie's beim LX aussieht weiß ich nicht) nach dem Assoziieren eines Clients ein Broadcast-Paket mit der MAC-Adresse des Clients, LLC-Framing (DSAP=SSAP=0x00) und einer dekorativen aber irrelevanten Klartextmeldung als Payload verschicken.

Das mit der dekorativen aber irrelevanten Klartextmeldung ist aber schön ausgedrückt.
Die Pakete kenne ich und habe ich glaube ich schon 2005 in Wireshark gesehen, da hieß das noch Ethereal. Und erinnern kann ich mich daran nur wegen der "dekorativen Klartextmeldung".
Zur Info übrigens: Das Paket kommt, aber das hat mittlerweile ja auch keiner mehr angezweifelt. Es ist also da. Ich sehe es im Ethernet-Trace. Aber im ARP-Trace ist davon nichts zu sehen, weil, wie Backslash ja schreibt, dann noch eine IP-Adresse drin sein müsste, die der AP selber aber ja auch erst mal nicht hat.

Der originäre Zweck wird aus dem Text klar, es ist aber auch so, dass LCOS-Router auf solche Pakete hören und als Reaktion darauf die Client-MAC aus ihrem ARP-Cache löschen. Zumindest taten sie das bis einschließlich zur 10.50, auf auf dem 1781EF+ soll ja eine solche laufen...

Wenn, wie Du schreibst, als Reaktion auf das Paket die Client-MAC aus dem ARP-Cache gelöscht wird, dann müsste ich das doch im ARP-Trace sehen, oder? Da sehe ich keine Reaktion (also nur andere Pakete). Ethernet-Trace (gefiltert) und ARP-Trace (ungefiltert) liefen parallel. Ich habe heute noch mal versucht den Fall nachzustellen, allerdings war nur jemand vor Ort mit einem Samsung Galaxy. Das verhält sich anders. Direkt nach jedem Roaming macht es einen ARP-Request nach der IP-Adresse des Default-Gateways, also dem LANCOM-Router, was der natürlich dann gleich abspeichert. So sehe ich auch nicht, ob vorher was gelöscht wurde.

man lernt nie aus... ich dachte echt, da würde ein gratuitous ARP gesendet...

Wenn Du das schon sagst...

am Ende bleibt dir dann wirklich nur der Weg mit der Bridge - oder du schaltest noch einen Switch vor das LANCOM, so daß alle Clients nur über einen Port reinkommen

Das ist ok. Aber das hilft leider noch nicht der Allgemeinheit und der Verwendung von LANCOM-Produkten wie man es erwarten würde, weswegen man meiner Ansicht nach irgendwie doch noch mal scharf darüber nachdenken müsste, ob es da nicht doch noch eine Möglichkeit gibt, das Ganze irgendwie zu greifen.

Wurde es bis einschließlich zur 10.50, danach ist das Feature bei Umbauten verloren gegangen...ist eine etwas subtile Sache.

Krass. Aber müsste da nicht angesetzt werden, das zu korrigieren?

Aber wie Jirka schrieb, soll auf seinem 1781EF+ ja eine 10.50 laufen.

Genau. Eine andere/neuere habe ich nicht und bei einer älteren (10.34 oder 10.42 z. B.) liefe das AON-SFP-Modul dann nicht.

Schon komisch alles.
Also ich liefere definitiv noch detaillierte Infos nach. Es kann nur leider dauern, und nach Stand heute sogar wesentlich länger, als bisher von mir angenommen. Es könnten gar 3 Wochen werden, deswegen hatte ich heute ja noch mal einen Versuch gestartet, der aber auch nur aufzeigte, dass das Verhalten eben auch noch Client-abhängig ist.

An dieser Stelle noch mal vielen Dank für die vielen Antworten und Infos, es war eine gute Entscheidung, das hier mal darzustellen. Ist ja auch immer eine Zeitfrage, widmet man sich jetzt ausführlich dem Problem? Aber bei gewissen Sachen will ich es einfach verstehen und nicht an der Oberfläche kratzen und einen billigen Workaround machen und hier war es eben auch so, es ist mir einfach unklar gewesen, wie bei so einer Konfiguration, wo man denkt sie müsste fehlerfrei funktionieren, dass sie es dann eben doch nicht tut.

Vielen Dank und viele Grüße
Jirka

[Dr.Einstein]

Das wäre dann die - ja Lösung will ich eigentlich nicht sagen, weil dafür finde ich es arg krass - also eher die Möglichkeit, es in bisheriger Konstellation (fehlerfrei) zum Laufen zu bekommen. Und unter den bisher hier erläuterten Fakten verstehe ich es auch. Dr. Einstein, liest Du eigentlich auch noch mit? Sicher, oder? Das ist doch schon sehr crazy, findest Du nicht auch?

Natürlich, aber ich hab bei dem Thema aufgegeben. Die Optimierung kam irgendwann mit 10.xx rein, und macht in solchen Konstellationen nur Ärger. Auch wenn du z.B. Huawei SD-WAN an den Lancom anklemmst und diese via proprietären Backupprotokoll die MAC-Adressen je nach Aktiv-Gerät hin- und herschwenken. Der Lancom beißt sich in solchen Fällen viel zu lange an den falschen ETH-Port fest. Das entbehrt jeglicher Grundlagen, die man zu Switchen gelernt hat. Ein Frame kommt auf ETH-1 rein, Quell-MAC wird ETH-1 zugeordnet, ein Frame mit gleicher Quell-MAC kommt auf ETH-2 rein, Tabelle wird umgeschrieben. Wenn man sich auf solche Basics nicht verlassen kann, gute Nacht, egal ob ARP, Switching Tabelle, Bridge-Tabelle oder was auch immer im LCOS alles existiert. Die Entwickler haben uns damals gesagt: Work as designed, sind ja immerhin Router und keine Switche, auch wenn man anders als bei den Cisco Routern eine Switchfunktion hat.

[tstimper]

Diesen Threat verfolge ich interessiert.

Das ähnelt dem Problem, das um WLC-Tunnel Betrieb
der WLC-Tummel im WLC auf eine Bridge gebunden
werden muss da man ansonsten ein UDP Flooding an alle APs erzeugen kann.

Einfach weil dem WLC ohne diese Konfiguration
bei UDP Requests die MAC Adresse des APs fehlt an dem der Client hängt.

LCOS hat dafür einfach keine Tabelle.

Sind die Rooming Pakete auch UDP?
Das würde das Verhalten erklären.

Geändert wurde das Verhalten mit LCOS 10.34,
weil bei einem Projektkunden Multifunktionsdrucker
im WLAN nicht gefunden wurden. (sagte mir vor zwei Jahren der Support)

Das triggernde Problem war wohl Multicast DNS.


Allgemein gilt wieder:

Klare Spezifikation, auf die mal sich verlassen
Und berufen kann.

Alles andere ist ein NoGo.
Niemand von uns hat Zeit für Rätsel raten.

Viele Grüße

ts

[backslash]

Hi Dr.Einstein

Die Optimierung kam irgendwann mit 10.xx rein, und macht in solchen Konstellationen nur Ärger.

NEIN! Die Möglichkeit die Optimierung abzuschalten kam da rein...

ganz ehrlich: Da will man helfen und es geht direkt wieder der Forums-Shitstorm los, statt LANCOM einfach mal dafür zu loben, daß sie für ein Problem, daß ALLE Switchbausteine haben und bei dem ALLE Hersteller von Switchbausteinen weigern es zu beheben, eine Softwarelösung gefunden hat!

Andere Router (aka. Fritzbox) haben das Problem nicht weil sie die Swichtbausteine nicht ausnutzen oder einfach gar keinen Switch einbauen (Cisco).

Ich hatte ja gehofft, daß Rotwang das genau erklärt, denn das ist nicht meine Baustelle und ich kann hier nur mit gefährlichem Halbwissen glänzen. Aber ich versuche es trotzdem mal:

Das Problem liegt im Switchbaustein! Wenn man Switchports gruppiert, dann switchen sie auch sauber untereinander - nur nicht in Richtung des Hostports - den sehen die Hersteller der Switchbausteine offenbar nur dazu, die Konfigoberfläche anzuschließen, nicht aber um in einem Router auch Daten darüber laufen zu lassen. Sobald man die Gruppierung einschaltet, verhalten sich die Gruppen vom Hostport aus gesehen wie Hubs, d.h. ein Paket, daß an eine Gruppe gesendet wird, geht auf ALLEN Ports raus, die zu der Gruppe gehören - es sei denn, man sagt dem Switch explizit, auf welchem Port das Paket rausgehen soll.

Würde LANCOM diese Port-Vorgabe nicht machen, dann ginge hier der Shitstorm los, daß alle Pakete auf allen Ports rausgehen würden und welcher Dreck das denn wäre...

Hier hat LANCOM die Lösung gefunden, das mit der ARP-Tabelle zu verknüpfen, was normalerweise auch funktioniert, wenn jeder, der das Netzinterface wechselt (aka roamt), auch ein gratuitous ARP sendet.
Offenbar ist es aber bei WLAN-Clients so, daß diese das nicht machen, weshalb - wie Rotwang es beschrieb - die LANCOM-APs das Spezial-Paket schicken. Auch eine Lösung für ein Problem, das NICHT bei LANCOM liegt.

Und ja, daß die ARP-Tabelle sich den Port merkt, macht Probleme in gewissen Szenarien - Dazu gibt es die Lösung (oder nennt es Workarround) mit der Bridgegruppe - denn die Bridge merkt sich ja genau die Zuordnung. Nur wird die auch erstmal nur verwendet, wenn zwischen (externen) Bridge-Ports gebridged wird. Wenn Pakete vom Router kommen, spart sich die Bridge den Lookup, weil der Port ja vorgegeben wird. Da LANCOM nur das Verhalten der Bridge ändern kann und nicht das des Switchbausteins, wurde der Schalter "Bridge-Optimierung" genannt. Und da der zusätzliche Lookup Performance kostet, ist die Bridge-Optimierung im Default aktiv und kann jederzeit vom Anwender abgeschaltet werden.

Warum man das nur auf dem CLI machen kann ist eine Entscheidung des Produktmanagements

Gruß
Backslash