ARP-Tabelle updatet Port nicht

[obi]

Hallo ihr Lancom-Experten,

ich habe ein Problem mit meinem 1793VA und den angeschlossenen Access Points:
Über den 1793VA erfolgt die Verbindung mit dem Internet. An ETH-3 und ETH-4 hängen jeweils ein WLAN-Access Point (nicht von Lancom).
Wechselt nun ein Gerät von einem Access Point zum anderen kommen aus dem Internet keine Pakete mehr beim Gerät an, da in der ARP-Tabelle für etwa eine Minute noch der alte Ethernet Port steht. Wenn ich in den Access-Points den ARP-Proxy aktiviere geht es schneller, allerdings laden Websites dann nur halb, vermutlich müssen ein paar TCP Verbindungen noch resettet werden.

Das gleich Problem wurde bereits 2006 beschrieben: lancom-systems-router-aeltere-modelle-f ... t4130.html
Der Workaround mit dem Switch funktioniert natürlich, an der Stelle brauche ich aber sonst keinen Switch und es ist nur ein Gerät was zusätzlich Leistung aufnimmt, daher die Frage:

Gibt es eine Möglichkeit dieses Verhalten im Router direkt abzustellen? Oder zu konfigurieren, dass ETH-1 bis ETH-4 als reiner Switch zu betreiben sind?
Kann man vielleicht eine Regel bauen, durch welche der alte ARP Eintrag invalidiert wird?

Eine Sache die ich noch getestet habe war die undokumentierte Funktion LCOS Menu Tree: Setup/TCP-IP/Drop-gratuitous-ARP zu aktivieren, hat aber nichts gebracht.

Viele Grüße
obi

[backslash]

Hi obi

wenn der Client den AP wechselt, dann muß irgendwer ein gratitous ARP schicken, damit die Infrastruktur lernt, wo die MAC-Adresse jetzt ist. Ich kenne mich im WLAN nicht aus und weis daher nicht, ob das der Client selbst machen muß, oder ob das Aufghabe der APs ist - aber wie Alffed damals schon schrieb:

mit LANCOMs als APs dürfte so etwas übrigens
nicht passieren, weil LANCOM-APs mit aktiviertem
Roaming-Support nach Einbuchen eines Clients ein
spezielles Paket schicken, das zum Löschen der MAC-
Adresse im ARP-Cache führt.

dem ist eigenlich nichts mehr hinzuzufügen... (Alfred meinte damit wohl den gratitous ARP).
Beim Thema Workarround mit Switch muß man u.U. auch aufpassen - jenachdem wie intelligent die sind kann am Switch das gleiche passieren

Gruß
Backslash

[alf29]

Moin,

ich weiß jetzt ehrlich gesagt auch nicht mehr genau, in was für einem Zusammenhang ich das for 15 (!) Jahren geschrieben habe, aber ein Gratuitous ARP war es bestimmt nicht.

LANCOM-APs schicken ein Dummy-Layer2-Paket mit der MAC-Adresse des Clients als Quelle, damit alle Switche den neuen Pfad zu diesem Client lernen, und es gehen auch noch IAPP-Handovers raus. IAPP werden die Fremd-APs nicht schicken, irgendwelche L2-Pakete gehen nicht bis in den IP-Stack des LANCOM, und es gibt im 1793 auch keinen Mechanismus, mit dem der (Hardware-)Switch die Host-CPU im LANCOM über einen Update der Forwarding Database informieren könnte.

Ein Gratuitous ARP wäre alleine deswegen schon schwierig, weil der neue AP u.U. gar nicht die IP-Adresse des Clients kennt. Einen DHCP Renew gibt es ja nicht und der Client kann nach dem Wechsel auf den neuen AP selber erstmal 'still' sein.

Die einzig sichere Lösung, die ich empfehlen kann, ist wie auch schon damals, die Fremd-APs über einen externen kleinen Switch zusammenzuführen und mit einem Port des LANCOM zu verbinden.

Viele Grüße

Alfred

[obi]

Danke für eure Antworten!

Ist dieses Verhalten dann nicht eigentlich ungewollt? Der IP-Router sieht doch, dass alle neuen Pakete von der entsprechenden IP von einem neuen Port kommen, warum wir der ARP-Table Eintrag dann nicht verworfen? Oder wird der eingehende Port nur bei ARP Paketen an den Router weitergegeben? Theoretisch wäre es ja wünschenswert, wenn man – auch beim Umstecken eines Geräts bei Ethernet – möglichst schnell wieder Pakete bekommt. Oder wird womöglich beim carrier loss auf Ethernet doch sofort die ARP-Table für diesen Anschluss gecleared?
Macht es Sinn bei Lancom dazu nochmal eine Supportanfrage zu erstellen?

Das schließt ja quasi in meinem Szenario systematisch fremde (Nicht-Lancom) Access Points aus: Ist das also vielleicht Strategie, weil wirtschaftlich?

Viele Grüße
obi

[alf29]

Moin,

Ist dieses Verhalten dann nicht eigentlich ungewollt?

Schon, aber die korrekte Lösung wäre eigentlich nicht, einen irgendwie gearteten zusätzlichen Update-Mechanismus zwischen Ethernet und ARP einzuziehen, sondern diese Information komplett aus der ARP-Tabelle zu entfernen, und den Software-Layer unterhalb vom TCP/IP diese Information managen zu lassen. Ein entsprechender Task steht seit Jahren auf der ToDo-Liste im LCOS und hat leider bisher nicht die erforderliche Prio bekommen, daß er mal angegangen wird. Offensichtlich treten solche Probleme, wie Du sie hast, nicht häufig genug auf, bzw. lassen sich anderweitig umgehen, als daß das in der Planung als wichtig genug erachtet wird.

Der IP-Router sieht doch, dass alle neuen Pakete von der entsprechenden IP von einem neuen Port kommen, warum wir der ARP-Table Eintrag dann nicht verworfen? Oder wird der eingehende Port nur bei ARP Paketen an den Router weitergegeben?

Das kann ich im Detail nicht beurteilen, aber m.W. ist es im Moment so, daß die ARP-Tabelle im LANCOM nur aus empfangenen ARP-Paketen aktualisiert wird. Sämtliche IP-Pakete auch noch mal zusätzlich am ARP vorbeizuleiten, würde vermutlich einiges an Overhead kosten und den Durchsatz verschlechtern.

Theoretisch wäre es ja wünschenswert, wenn man – auch beim Umstecken eines Geräts bei Ethernet – möglichst schnell wieder Pakete bekommt. Oder wird womöglich beim carrier loss auf Ethernet doch sofort die ARP-Table für diesen Anschluss gecleared?

Bei einem Linkverlust an einem Ethernet-Port geht jetzt schon eine Nachricht ans ARP, alle mit diesem Port verknüpften Einträge zu löschen. In Deinem Roaming-Szenario hast Du aber keinen Linkverlust, der Link zwischen dem Router und den APs steht die ganze Zeit.

Macht es Sinn bei Lancom dazu nochmal eine Supportanfrage zu erstellen?

Das kannst Du versuchen, ob das etwas nützt, kann ich nicht beurteilen. Die Tatsache, daß Du Fremd-APs benutzt, wird vermutlich nicht förderlich sein, auch wenn ich persönlich der Meinung bin, daß einem solche Probleme aktuell genauso gut mit LANCOM-APs passieren können. Jemand wird sich das anschauen, Rücksprache mit der Entwicklung wegen möglicher Aufwände halten, zu ermitteln versuchen, wie viele Kunden von diesem Problem betroffen sind, und die Sache entsprechend priorisieren. Angesichts der Tatsache, daß bei größeren (umsatzstärkeren) Kunden die APs und der Router eigentlich immer über irgendwelche Switches verbunden sind, und das Problem dann nicht auftritt, kann ich mir nicht vorstellen, daß die Priorität allzu hoch sein wird. Dann wäre schon längst etwas passiert (siehe oben...).

Das schließt ja quasi in meinem Szenario systematisch fremde (Nicht-Lancom) Access Points aus: Ist das also vielleicht Strategie, weil wirtschaftlich?

Vielleicht wäre ich auch aus eigenem Antrieb bei dem Problem aktiv geworden. Ich finde aber, daß ich mir als Entwickler nicht vorwerfen lassen muß, mutwillig die Interoperabilität mit Hardware anderer Hersteller zu torpedieren. Dazu habe ich zu lange im WLAN-Umfeld gearbeitet, wo ich mch eigentlich immer mit Clients anderer Hersteller herumschlagen mußte. Ich weiß nicht, ob ich jetzt immer noch Lust habe, das zu tun.

Viele Grüße

Alfred

[obi]

Moin Alfred,

Schon, aber die korrekte Lösung wäre eigentlich nicht, einen irgendwie gearteten zusätzlichen Update-Mechanismus zwischen Ethernet und ARP einzuziehen, sondern diese Information komplett aus der ARP-Tabelle zu entfernen, und den Software-Layer unterhalb vom TCP/IP diese Information managen zu lassen. Ein entsprechender Task steht seit Jahren auf der ToDo-Liste im LCOS und hat leider bisher nicht die erforderliche Prio bekommen, daß er mal angegangen wird. Offensichtlich treten solche Probleme, wie Du sie hast, nicht häufig genug auf, bzw. lassen sich anderweitig umgehen, als daß das in der Planung als wichtig genug erachtet wird.

schön, dass so etwas schon auf der Liste steht. Ich kann mir schon vorstellen, dass die meisten Kunden einen Switch hinter dem Router haben um dann auf Patchpanel zu verteilen o.ä.

Das kann ich im Detail nicht beurteilen, aber m.W. ist es im Moment so, daß die ARP-Tabelle im LANCOM nur aus empfangenen ARP-Paketen aktualisiert wird. Sämtliche IP-Pakete auch noch mal zusätzlich am ARP vorbeizuleiten, würde vermutlich einiges an Overhead kosten und den Durchsatz verschlechtern.

Ich habe gerade noch einmal die Pakete mitgeschnitten: Es kommt kurz nach Einwahl des Clients am Access Point ein ARP request der vom Lancom auch beantwortet wird. Daraufhin wird der Port im ARP Eintrag des Geräts aber scheinbar noch nicht geupdatet.

Bei einem Linkverlust an einem Ethernet-Port geht jetzt schon eine Nachricht ans ARP, alle mit diesem Port verknüpften Einträge zu löschen. In Deinem Roaming-Szenario hast Du aber keinen Linkverlust, der Link zwischen dem Router und den APs steht die ganze Zeit.

Mir ist klar, dass der Ethernet Link nicht verloren geht. Die Idee, die dabei mitschwang, war, dass es dafür ja anscheinend eine Art Updateschnittstelle vom unteren Layer Richtung TCP/IP geben muss die man vielleicht für dieses Problem erweitern könnte. Eine Grundlegende Lösung wie von Dir oben vorgeschlagen wäre aber natürlich zielführender.

Angesichts der Tatsache, daß bei größeren (umsatzstärkeren) Kunden die APs und der Router eigentlich immer über irgendwelche Switches verbunden sind, und das Problem dann nicht auftritt, kann ich mir nicht vorstellen, daß die Priorität allzu hoch sein wird. Dann wäre schon längst etwas passiert (siehe oben...).
Vielleicht wäre ich auch aus eigenem Antrieb bei dem Problem aktiv geworden. Ich finde aber, daß ich mir als Entwickler nicht vorwerfen lassen muß, mutwillig die Interoperabilität mit Hardware anderer Hersteller zu torpedieren. Dazu habe ich zu lange im WLAN-Umfeld gearbeitet, wo ich mch eigentlich immer mit Clients anderer Hersteller herumschlagen mußte. Ich weiß nicht, ob ich jetzt immer noch Lust habe, das zu tun.

Dass Du ein Entwickler bei Lancom bist wusste ich nicht und ich rechne Dir hoch an, dass Du hier so Kundennah unterwegs bist! Mit meiner Aussage zur Wirtschaftlichkeit meinte ich auch eher, dass es – wie Du ja auch schon gesagt hast – kein Prio 1 Problem ist und mit den Lancom Routern ja funktioniert. In manchem Management würde man solche technischen nicht zwingend nötigen Verbesserungen stark nachrangig behandeln. Dass ihr das aktiv torpediert wollte ich euch jedoch nicht unterstellen.
Die Probleme der Interoperabilität kann ich gut nachvollziehen. Ich arbeite selbst auf Hardwareebene auch mit Netzwerkschnittstellen und hatte erst letztlich einen Hersteller, der die GMII Spezifikation und ihr Timing besonders speziell ausgelegt hat...

Dann stelle ich demnächst mal einen Supportantrag, dann gibt es noch mal eine "offizielle" Anfrage.

Viele Grüße
obi