Erweiterung der Firewall und Qos-Regeln

Wünsche und Vorschläge zur Verbesserung der LANCOM Produkte

Moderator: Lancom-Systems Moderatoren

Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Erweiterung der Firewall und Qos-Regeln

Beitrag von Casey »

In der Firewall bei den Filterregeln unter Dienste/Protokolle fehlt die Unterscheidungsmöglichkeit von Paketen nach ihrer Packetgröße, damit würden sich kleine Pakete per Qos-Regel priorisieren lassen.

Bei den QOS Regeln fehlt die Möglichkeit bestimmte Pakete als Bulktraffic mit niedrigster Priorität (unterhalb von normal) zu behandeln.
Das würde es z.B. ermöglichen das abgehender Mailtraffic und der Traffic eines Webservers im Lan den normalen Betrieb nicht mehr stört.
Zusätzlich könnte solcher Traffic als erstes gedroppt werden die Upstreamqueue im Router überläuft.

Es fehlt die Möglichkeit Traffic beim überschreiten eines Bandbreitenlimits zu queuen anstatt in zu droppen.
Das entlastet gerade bei RX-Limits den Downstream von den sonst notwendigen Neuübertragungen.
Lars
Beiträge: 36
Registriert: 23 Dez 2004, 23:21

Beitrag von Lars »

Gerade die ersten beiden Punkte fehlen mir auch sehr oft.

Gruß, Lars
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi Casey
In der Firewall bei den Filterregeln unter Dienste/Protokolle fehlt die Unterscheidungsmöglichkeit von Paketen nach ihrer Packetgröße, damit würden sich kleine Pakete per Qos-Regel priorisieren lassen.
Das würde nichts bringen, da das TCP beim Empfang die durch die Priorisierung umsortierten Pakete eh' wieder "richtige Reihenfolge" bringen würde und sich somit keine wirksame Priorisierung ergibt.

Ich weiß, es gibt da noch das "Problem" mit SSH und SCP, die in einer Session laufen, doch das läßt sich mit einer kleinen Mindestbandbreite von z.B. 1kBit/s lösen...
Bei den QOS Regeln fehlt die Möglichkeit bestimmte Pakete als Bulktraffic mit niedrigster Priorität (unterhalb von normal) zu behandeln.
Das würde es z.B. ermöglichen das abgehender Mailtraffic und der Traffic eines Webservers im Lan den normalen Betrieb nicht mehr stört.
Zusätzlich könnte solcher Traffic als erstes gedroppt werden die Upstreamqueue im Router überläuft
das wäre ggf. sinnvoll...
Es fehlt die Möglichkeit Traffic beim überschreiten eines Bandbreitenlimits zu queuen anstatt in zu droppen.
Das entlastet gerade bei RX-Limits den Downstream von den sonst notwendigen Neuübertragungen
Das LANCOM queued die Pakete, wenn das Limit überschritten wird - auch wenn als Aktion "drop" eingestellt werden muß. Es werden erst dann wirklich Pakete verworfen, wenn zu viele Pakete gequeued werden.

Wenn hingegen als Aktion "reject" eingestellt wird, dann wird die TCP-Verbindung sofort nach Überschreiten des Limits geschlossen.

Gruß
Backslash
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

backslash hat geschrieben:Das würde nichts bringen, da das TCP beim Empfang die durch die Priorisierung umsortierten Pakete eh' wieder "richtige Reihenfolge" bringen würde und sich somit keine wirksame Priorisierung ergibt.

Ich weiß, es gibt da noch das "Problem" mit SSH und SCP, die in einer Session laufen, doch das läßt sich mit einer kleinen Mindestbandbreite von z.B. 1kBit/s lösen...
Ich möchte generell alle Pakete von verschiedenen Diensten unterhalb einer Größe von z.B. 600Byte im Upstream priorisieren, das ist für mich sinnvoll weil ich damit genau den Teil der Pakete abdecke die hier für mich und andere wichtig sind.
Mit genau so einer Regel habe ich bei anderen Gelegenheiten schon sehr gute Erfahrungen gemacht.
Nur war mir das damals leider noch nicht klar als ich den Syn/Ack Speedup mit auf die lange Wunschliste setzte die ich an euren Support gemailt hatte.
Das LANCOM queued die Pakete, wenn das Limit überschritten wird - auch wenn als Aktion "drop" eingestellt werden muß. Es werden erst dann wirklich Pakete verworfen, wenn zu viele Pakete gequeued werden.

Wenn hingegen als Aktion "reject" eingestellt wird, dann wird die TCP-Verbindung sofort nach Überschreiten des Limits geschlossen.
Das habe ich noch nicht gewusst, aber es steht meines Wissens nach auch nirgendwo.
Zuletzt geändert von Casey am 29 Dez 2004, 21:27, insgesamt 1-mal geändert.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi Casey
Ich möchte generell alle Pakete von verschiedenen Diensten unterhalb einer Größe von z.B. 600Byte im Upstream priorisieren, das ist für mich sinnvoll weil ich damit genau den Teil der Pakete abdecke die hier für mich und andere wichtig sind.
Warum priorisierst Du nicht einfach die Dienste?

Welchen Sinn soll es haben, innerhalb eines TCP-Streams kleine Pakete zu bevorzugen? Das TCP sortiert die Pakete sowieso wieder in die richtige Reihenfolge und damit kommen die vorgezogenen Pakete auch erst *nach* den nicht vorgezogenen bei der Applikation an.

Den einzigen Sinn, den ich in dieser Priorisierung sehe, ist der, manuelle User-Eingaben (also z.B. Telnet, SSH) zu beschleunigen. Das geht aber auch problemlos (und vor allem "sauberer") über eine Priorisierung der Dienste.
Mit genau so einer Regel habe ich bei anderen Gelegenheiten schon sehr gute Erfahrungen gemacht
ich frage mich nur: wann und welche?
Nur war mir das damals leider noch nicht klar als ich den Syn/Ack Speedup mit auf die lange Wunschliste setzte die ich an euren Support gemailt hatte.
Den SYN/ACK Speedup gibt es seit Jahren (und er ist per Default eingeschaltet)...

Gruß
Backlsash
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

Warum priorisierst Du nicht einfach die Dienste?
Weil ich z.B. das abrufen von Webseiten beschleunigen möchte ohne dabei HTTP Uploads mit zu priorisieren.
Weil es Dienste gibt die keine standardisierten Ports haben oder diese dynamisch aushandeln usw. usw.
Es gibt das Problem das Dienste kleine Pakete schnell befördert werden sollen weil jemand wartet, während im nächsten Moment eventuell auf einer anderen Verbindung desselben dienstes große Pakete verschickt werden die im Prinzip nicht schnell befördert werden müssen weil es sowieso länger dauert und daher auch nicht den Upstream verstopfen sollen.
Alle diese Anwendungen haben aber eines gemeinsam kleine Pakete sind wichtiger als große.
Welchen Sinn soll es haben, innerhalb eines TCP-Streams kleine Pakete zu bevorzugen? Das TCP sortiert die Pakete sowieso wieder in die richtige Reihenfolge und damit kommen die vorgezogenen Pakete auch erst *nach* den nicht vorgezogenen bei der Applikation an.
Das ist mir völlig klar und es ist in keinster Weise relevant für das was ich gerne machen möchte.
Den einzigen Sinn, den ich in dieser Priorisierung sehe, ist der, manuelle User-Eingaben (also z.B. Telnet, SSH) zu beschleunigen. Das geht aber auch problemlos (und vor allem "sauberer") über eine Priorisierung der Dienste.
Es gibt aber wie schon beschrieben genug Fälle in denen das nicht möglich ist weil die Größe das einzige ist was diese Pakete identifiziert.
Selbst der billige Trafficshaper der Fritzcard lässt sich in Bezug auf die Paketgrösse konfigurieren, weshalb ist das bei euch nicht möglich?
ich frage mich nur: wann und welche?
Wie ich noch den DSL/I-10 mit externem Modem benutzt hatte wollte ich mehr über die Möglichkeiten von meinem Anschluss erfahren und hab mir zu Diagnsosezwecken eine Fritzcard DSL besorgt und sie auch einige Zeit in einem PC-Router zum testen benutzt, da habe ich den Trafficshaper modifiziert und mit wenigen Regeln sehr gute Ergebnisse erzielt, das ist aber bei euch so nicht möglich. Deshalb der Wunsch mit dem Lancom ebenfalls nach Grösse priorisieren zu können.
Den SYN/ACK Speedup gibt es seit Jahren (und er ist per Default eingeschaltet)...
Ende 2000 als ich euch (Elsa) massig Featurewünsche für den DSL/I-10 geschickt habe waren die Möglichkeiten der Firmware aber noch vergleichsweise primitiv, bis der Speedup dann endlich für den Wanport funktionierte musste ich auch noch einige male schreiben weil der Trafficshaper fehlte und der Router anstatt zu queuen und zu priorisieren alles gleich ins Modem geblasen hatte.
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

Eine weitere Einschränkung in diesem Bereich ist das die Reihenfolge mit der die Regeln beachtet werden müssen nichts mit der Priorität zu tun hat mit der der Traffic befördert werden müsste, bei euch ist aber beides einfach gleichgesetzt was die ganze Situation noch komplizierter macht.

Eure Router sind Klasse, aber der Firewall und Qosbereich ist was die Möglichkeiten angeht im Moment allenfalls im Grundschulalter angekommen, da bleibt für euch noch viel zu tun.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi Casey
Weil ich z.B. das abrufen von Webseiten beschleunigen möchte ohne dabei HTTP Uploads mit zu priorisieren.
genau hier würde die Größen-Priorisierung gar nicht greifen, da sowohl HTTP-Down- als auch Uploads nur große Pakete erzeugen. Hier wäre für dich eine Mindestbandbreite für den Downstream und eine Limitierung für den Upstream das Richtige - unabhängig von der Paketgröße
Weil es Dienste gibt die keine standardisierten Ports haben oder diese dynamisch aushandeln usw. usw.
Dienste ohne "standartisierten" Port kann man gar nicht nutzen. Auf welchem Port willst du so einen Dienst auch erreichen? (=> Und schon hast Du einen Port an den Du die Priorisierung binden kannst.)

Auch für Dienste mit dynamisch ausgehandeltem Port mußt Du erstmal eine Regel erstellen damit sie überhaupt übertragen werden (zumindest wenn du eine Deny-All Strategie fährts). Aber auch dann werden sie keine unterschiedliche Übertragungsraten für verschiedene Paketgrößen verlangen.

Es gibt das Problem das Dienste kleine Pakete schnell befördert werden sollen weil jemand wartet, während im nächsten Moment eventuell auf einer anderen Verbindung desselben dienstes große Pakete verschickt werden die im Prinzip nicht schnell befördert werden müssen weil es sowieso länger dauert und daher auch nicht den Upstream verstopfen sollen
Und hier gilt wieder: Das TCP sortiert die Daten eh wieder "zurück", wodurch sich letztendlich *keine* Priorisierung ergibt.

"Ernsthafte" Dienste nutzen für solche Dinge zum einen kein TCP sondern UDP, damit eben diese "Zurücksortierung" nicht geschieht. Zum anderen taggen die "wichtige" Pakete - und darauf kann man in der Firewall einen Trigger legen!

In jedem Fall hat auch das nichts aber auch rein gar nichts mit der Paketgröße zu tun!!!
Selbst der billige Trafficshaper der Fritzcard lässt sich in Bezug auf die Paketgrösse konfigurieren, weshalb ist das bei euch nicht möglich?
Soll ich es mal so formulieren(?): die Fritzcard ist für DAUs, die mit einer korrekten Firewall und Traffic-Shaper Konfiguration überfordert sind.
Außerdem sitzt die Fritzcard in einem Einzelplatz-Rechner, für den ein Traffic-Shaper eigentlich gar nicht nötig ist (außer man will P2P runterdrücken um noch mit akzeptablen Antwortzeiten Chatten zu können).
Ende 2000 als ich euch (Elsa) massig Featurewünsche für den DSL/I-10 geschickt habe waren die Möglichkeiten der Firmware aber noch vergleichsweise primitiv, bis der Speedup dann endlich für den Wanport funktionierte musste ich auch noch einige male schreiben weil der Trafficshaper fehlte und der Router anstatt zu queuen und zu priorisieren alles gleich ins Modem geblasen hatte.
Das ist jetzt 4 Jahre her...
Und es gibt nur beschränkte Entwicklungs-Ressourcen.
Eine weitere Einschränkung in diesem Bereich ist das die Reihenfolge mit der die Regeln beachtet werden müssen nichts mit der Priorität zu tun hat mit der der Traffic befördert werden müsste, bei euch ist aber beides einfach gleichgesetzt was die ganze Situation noch komplizierter macht.
Die Priorität der Regeln hat nichts aber auch rein gar nichts mit der Priorität der Übertragung zu tun.

Die Regeln werden automatisch so sortiert, daß die "allgemeinste" Regel unten steht. Bei der Bearbeitung eine IP-Pakets wird diese Regel-Liste "von oben nach unten" abgearbeitet, bis eine Regel matcht. Für das Paket werden dann die Aktionen ausgeführt, die diese Regel vorgibt.

Es kann nun aber vorkommen, daß die automatische Sortierung nicht dem entspricht, was der Anwender gerne hätte. Dafür gibt es die Prioritäten. Mit diesen kann der Anwender seine Regeln manuell sortieren - nicht mehr und nicht weniger...
Eure Router sind Klasse, aber der Firewall und Qosbereich ist was die Möglichkeiten angeht im Moment allenfalls im Grundschulalter angekommen, da bleibt für euch noch viel zu tun
Daß es noch viel zu tun gibt, bestreitet niemand. Aber das mit dem Grundschulalter möchte ich doch zurückweisen - Grundschulalter wäre m.E. eine Priorisierung nach Paketgrößen...

Gruß
Backslash
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

Wenn man im Qosbereich statt wahlweise "pro Verbindung" oder "global"
Die Möglichkeit hätte "global", "pro IP" und "pro Verbindung" gleichzeitig und mit verschachtelter Bandbreitenverteilung auszuwählen wäre schon viel getan.
Damit würde sich dann mit einer einzigen Regel Fairqueueing für einen IP-Bereich bauen lassen.

Gegenüber jetzt würde dann nur noch das "pro IP" mit der möglichkeit alle drei auszuwählen sowie die Unterscheidung nach Paketgröße (eventuell auch nach Flags), negative Prioritäten (Bulktraffic) und die Trennung von Priorität und Regelreihenfolge fehlen.
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

genau hier würde die Größen-Priorisierung gar nicht greifen, da sowohl HTTP-Down- als auch Uploads nur große Pakete erzeugen. Hier wäre für dich eine Mindestbandbreite für den Downstream und eine Limitierung für den Upstream das Richtige - unabhängig von der Paketgröße
Du hast mich nicht verstanden, ein Seitenabruf erzeugt kleine Pakete im Upstream, ein Upload dagegen große.
Und da ihr z.B. ein "pro IP" für einen Adressbereich nicht anbietet darf man dann zig Regeln als Workaround für etwas anlegen das mit der Paketgröße pro Verbindung in einer Regel erschlagen worden wäre.
Dienste ohne "standartisierten" Port kann man gar nicht nutzen. Auf welchem Port willst du so einen Dienst auch erreichen? (=> Und schon hast Du einen Port an den Du die Priorisierung binden kannst.)
Ob es nun spiele Filesharing oder sontwas ist, in vielen fällen suchen sich Anwender/Anbieter Ports aus wie sie gerade lustig sind, soll heissen der Port steht erst in dem Moment fest wo die Verbindung aufgebaut wird, das lässt sich ohne die Paketgröße nicht in eine Regel einbauen.
Viel Traffic der Zeitunkritisch ist wird der Effizienz wegen mit großen Paketen verschickt, kritischer Traffic dagegen meist mit kleinen und auch per UDP. Ich möchte aber trotzdem nicht UDP insgesamt priorisieren sondern nur die keleinen Zeitkritischen Pakete.
Auch für Dienste mit dynamisch ausgehandeltem Port mußt Du erstmal eine Regel erstellen damit sie überhaupt übertragen werden (zumindest wenn du eine Deny-All Strategie fährts). Aber auch dann werden sie keine unterschiedliche Übertragungsraten für verschiedene Paketgrößen verlangen.
Ich benutze aber kein Deny All weil es aus schon genannten Gründen in meinem Scenario nicht zu nutzen ist.
Und hier gilt wieder: Das TCP sortiert die Daten eh wieder "zurück", wodurch sich letztendlich *keine* Priorisierung ergibt.

"Ernsthafte" Dienste nutzen für solche Dinge zum einen kein TCP sondern UDP, damit eben diese "Zurücksortierung" nicht geschieht. Zum anderen taggen die "wichtige" Pakete - und darauf kann man in der Firewall einen Trigger legen!
Bei einer Consolensession werden aber nunmal meistens folgen von kleinen oder großen Paketen versendet, und bei dem Rest macht es zumindest keinerlei Probleme.
Und auf die Programmierung solcher Applikationen habe ich leider ebensowenig Einfluss wie auf den Source der Lancom Firmware.
In jedem Fall hat auch das nichts aber auch rein gar nichts mit der Paketgröße zu tun!!!
Doch genau damit hat es zu tun auch wenn du das bisher nicht glauben möchtest.
Soll ich es mal so formulieren(?): die Fritzcard ist für DAUs, die mit einer korrekten Firewall und Traffic-Shaper Konfiguration überfordert sind.
Außerdem sitzt die Fritzcard in einem Einzelplatz-Rechner, für den ein Traffic-Shaper eigentlich gar nicht nötig ist (außer man will P2P runterdrücken um noch mit akzeptablen Antwortzeiten Chatten zu können).
Tja trotzdem kann man sie zum routen benutzen und hat sie einen Trafficshaper der deutlich bessere Ergebnisse ermöglicht und einfacher per Textdatei zu konfigurieren ist als das was eure Router bisher bieten können.
Das ist jetzt 4 Jahre her...
Und es gibt nur beschränkte Entwicklungs-Ressourcen.
Klar gibt es die irgendwo müssen die Defizite ja her kommen, das es andere eventuell wichtigere Sachen als Qos gibt bestreitet auch niemand.
Das bestreiten dieser Probleme von deiner Seite ändert aber leider auch nichts an den bestehenden Einschränkungen.
Daß es noch viel zu tun gibt, bestreitet niemand. Aber das mit dem Grundschulalter möchte ich doch zurückweisen - Grundschulalter wäre m.E. eine Priorisierung nach Paketgrößen...
Nein, das ist eine Lösung für ein Problem das man mit eurer Hardware im Gegensatz zu anderen Produkten leider im Moment nicht lösen kann.
Was glaubst du als voreingenommener Entwickler denn wo ihr im Qosbereich mit eurer Hardware angekommen seid?
Dann kann ich mir ein Bild davon machen wie bei euch die Zukunft in diesem Bereich aussieht und zukünftige Entscheidungen davon abhängig machen.
Hart
Beiträge: 30
Registriert: 26 Dez 2004, 11:13
Wohnort: Oldenburg
Kontaktdaten:

Beitrag von Hart »

Hi alle miteinander!

Also die Sache mit den Ports will mir nicht wirklich in den Kopf. Es ist sicherlich richtig das viele Anwendungen die Möglichkeit bieten die entsprechenden Ports zu bestimmen, trotzdem bezweifle ich das ein Anwender vor jeder Session die entsprechenden Ports neu einstellt. Der Sinn, welcher dahinter stecken könnte, bleibt mir verborgen.

Gerade in einer Multiuserumgebung mit einem Router oder eventuell sogar Routern ist es nach meinem Verständis notwendig die entsprechenden Ports einmal firmenweit zu bestimmen um so den Diensten eine Priorität zuweisen zu können oder direkte Verbindungen zwischen einzelnen Rechnern (falls notwendig) zu ermöglichen.

Man möge mich korregieren wenn ich das jetzt völlig falsch sehen, aber unter diesem Umständen will mir die Anforderung nach Paketgrößen zu priorisieren nur teilweise in den Kopf.

Das Beispiel beim HTTP Verkehr kleine Pakete zu bevorzugen, weil es bei großen Paketen eventuell um unerwünschten HTTP Upload handelt, welcher über das "normale" Surfen hinausgeht, will mir zumindest im Ansatz noch in den Kopf. Aber außer in Sonderfällen, fällt mir jetzt kein Grund ein, warum so etwas standardmäßig verfügbar sein sollte.

Wäre mal interessant zu hören, wann dies in der Praxis tatsächlich erforderlich sein könnte.

Bei uns im Unternehmen sehe ich eine entsprechenden Bedarf im Moment jedenfalls nicht gegeben.

Gruß, Daniel
Irren ist menschlich. Aber wenn man richtig Mist bauen will, braucht man einen Computer.
(Dan Rather, CBS-Fernsehreporter.)
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

OK vieleicht braucht es doch ein Beispiel:
Du gehst in einen Supermarkt mit mehreren normalen Kassen und einer Schnellkasse, vor jeder Kasse sind lange Schlangen zum Teil mit vollen, zum Teil mit fast leeren Einkaufswagen.

Weg Nummer 1: (Packetgröße)
Es gibt die Unterscheidungsmöglichkeit nach Artikelmenge im Einkaufswagen, um die Schnellkasse benutzen zu dürfen kann man beliebige Artikel, aber insgesamt nur eine kleine Menge davon einpacken. Kunden die nur mal eben schnell wenig einkaufen möchten kommen schnell durch die Kasse.

Weg Nummer 2: (Der Lancom Weg)
Es können nur wenige Artikel einer bestimmten Sorte an einer Schnellkasse bezahlt, damit die Leute mit wenigen Artikeln trotzdem eine Schnellkasse benutzen können baut der Laden soviele Schnellkassen auf wie es Artikel und Kominationen der Artikel im Laden gibt.

Der erste ist ohne Frage der bessere Weg
Lars
Beiträge: 36
Registriert: 23 Dez 2004, 23:21

Beitrag von Lars »

Es ist schon richtig, dass die kleinen Packete meist die sind, die man priorisiert haben möchte. Ob es nun Chats sind, Konsolenbefehle, Voip oder sonstige Informationen. Praktisch immer haben die großen Mengen Daten Zeit und die kleinen haben es eilig.

Gruß, Lars
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi Casey
Wenn man im Qosbereich statt wahlweise "pro Verbindung" oder "global" die Möglichkeit hätte "global", "pro IP" und "pro Verbindung" gleichzeitig und mit verschachtelter Bandbreitenverteilung auszuwählen wäre schon viel getan.
Äh' was meinst Du bitte mit "pro IP"?
oder besser: was meinst Du eigentlich was "pro Verbindung" bedeutet?

"Pro Verbindung" bezieht sich auf einzelne TCP-Sessions und ist somit "pro IP"!
Damit würde sich dann mit einer einzigen Regel Fairqueueing für einen IP-Bereich bauen lassen.
siehe dazu meine Antwort zu deinem Thread http://www.lancom-forum.de/topic,102,-F ... outer.html

Das ist jetzt schon möglich...
Gegenüber jetzt würde dann nur noch das "pro IP" mit der möglichkeit alle drei auszuwählen sowie die Unterscheidung nach Paketgröße (eventuell auch nach Flags), negative Prioritäten (Bulktraffic) und die Trennung von Priorität und Regelreihenfolge fehlen
Liest Du eigentlich die Antworten auf deine Anfragen?

- Die Firewall reagiert auf DiffServ-Flags
- Die Priorisierung nach Paketgröße ist fragwürdig
- Bulk-Traffic wäre sinnvoll
- Die Prioritäten der Regeln haben nichts, rein gar nichts mit Paket-Prioritäten zu tun


Du hast mich nicht verstanden, ein Seitenabruf erzeugt kleine Pakete im Upstream, ein Upload dagegen große.
Du hast mich nicht verstanden: eine Limitierung des Upstreams bremst (nur) den Upload aus. Beim Download hingegen wandern reine ACKs (ohne Daten) in Richtung Upstream. Ich hab jetzt zwar den Sourcecode nicht zur Hand, aber die ACKs sollten in die Limitierung nicht eingehen...
Und da ihr z.B. ein "pro IP" für einen Adressbereich nicht anbietet darf man dann zig Regeln als Workaround für etwas anlegen das mit der Paketgröße pro Verbindung in einer Regel erschlagen worden wäre.
Wie bereits oben gesagt: "pro Verbindung" ist "pro IP"
Ob es nun spiele Filesharing oder sontwas ist, in vielen fällen suchen sich Anwender/Anbieter Ports aus wie sie gerade lustig sind, soll heissen der Port steht erst in dem Moment fest wo die Verbindung aufgebaut wird, das lässt sich ohne die Paketgröße nicht in eine Regel einbauen.
wie gesagt: Wenn Du nicht weisst, auf welchem Port ein Server läuft, dann kannst Du ihn auch nicht kontaktieren - und wenn Du es weisst, dann kannst du auch eine passende Regel erstellen.

Ansonsten kann ich nur Hart zustimmen...

Bei einer Consolensession werden aber nunmal meistens folgen von kleinen oder großen Paketen versendet, und bei dem Rest macht es zumindest keinerlei Probleme.
Und gerade bei Consolensessions willst Du alle Pakete so schnell wie möglich übertragen haben - egal wie groß sie sind. Also priorisierst Du den jeweiligen Dienst (Telnet, SSH, VNC etc.)
Und auf die Programmierung solcher Applikationen habe ich leider ebensowenig Einfluss wie auf den Source der Lancom Firmware
Applikationen, die bestimme Diensgüten benötigen - hier ist allem voran Voice over IP zu nennen - benutzen DiffServ-Tagging. Du kannst bei diesen Applikationen sogar vorgeben welche Tags sie verwenden (Normalerweise AF für die Signalisierung und EF für die Voice-Daten). Auf diese Tags kannst Du im LANCOM priorisieren...
Tja trotzdem kann man sie zum routen benutzen und hat sie einen Trafficshaper der deutlich bessere Ergebnisse ermöglicht und einfacher per Textdatei zu konfigurieren ist als das was eure Router bisher bieten können
Also nur die Paketgrößen-Priorisierung macht also einen besseren Traffic-Shaper aus??? Das wage ich doch glatt zu bezweifeln.

Ansonsten scheinst Du offen nicht glücklich werden zu können, wenn du nichts zu meckern hast. Und wenn die die Firewall-Konfiguration per LANconfig zu kompliziert ist, dann mache es doch über Telnet. Dann kannst du alle Konfigurationsmöglichkeiten ausnutzen und objektorientiert arbeiten - nur solltest Du diese Konfiguration nicht mehr mit LANconfig bearbeiten, weil LANconfig dann alles wieder auseinandernimmt und es wieder unübersichtlich wird.
Klar gibt es die irgendwo müssen die Defizite ja her kommen, das es andere eventuell wichtigere Sachen als Qos gibt bestreitet auch niemand.
Das bestreiten dieser Probleme von deiner Seite ändert aber leider auch nichts an den bestehenden Einschränkungen
Ich bestreite keine Probleme - ich sehe nur keinen Sinn in einer Regel, die allen Traffic erstmal pauschal zuläßt um ihn dann nach Paketgrößen zu priorisieren. Das sollte immer anhand der Dienste erfolgen.
Nein, das ist eine Lösung für ein Problem das man mit eurer Hardware im Gegensatz zu anderen Produkten leider im Moment nicht lösen kann.
Also wenn du als einzige Lösung nur einen Schalter "kleine Pakete bevorzugen" akzeptierst, kann ich dir auch nicht mehr helfen. Das ändert aber nichts daran, das dies eine Lösung für "Spielzeuge" ist. Eine sauber konfigurierte Firewall ist auch mehr als ein Schalter "Firewall Ein/Aus", der für den Homeuser trotzdem ausreichend ist...
Was glaubst du als voreingenommener Entwickler denn wo ihr im Qosbereich mit eurer Hardware angekommen seid?
Wie bereits gesagt: es gibt noch viele Dinge die machbar sind, wie z.B. das (im übrigen auch von dir angeregte) Fair-Queuing, Bulk-Traffic, policy-based Routing, Load-Balancing und und und...

QoS anhand der Paketgröße ist aber m.E. unnötig oder gar unsinnig, da es u.U. Pakete bevorzugt, die du nicht willst: überlege dir mal was bei einem flood-ping passiert - richtig: die pings werden bevorzugt und alles andere wird unterdrückt.
Dann kann ich mir ein Bild davon machen wie bei euch die Zukunft in diesem Bereich aussieht und zukünftige Entscheidungen davon abhängig machen.
Wenn Du deine Entscheidungen anhand der Aussage eines Entwicklers zu einem Thema fällst, dann tust du mir leid...

Gruß
Backslash
Casey
Beiträge: 177
Registriert: 23 Dez 2004, 15:34

Beitrag von Casey »

Server und Clients sind melden sich an Verzeichnisservern an.
dort sind die Daten wie Protokoll und Port eingetragen und zwar pro Server sehr viele Clients die alle UDP mit beliebigen Ports und IPs benutzen, das einzige was den Bandwithhog vom Lowlatency User unterscheidet ist die Paketgröße weil sie die Zeit bis zur Verarbeitung beeinflusst, flags benutzen die Anwendungen nicht, erstens habe ich darauf keinen Einfluss und zweitens beachtet sie sowieso kaum ein Homerouter weshalb sowas nicht unterstützt wird.
Ich möchte nun gerne die Lowlatency Anwendungen mit den kleinen Paketen priorisieren ohne dabei die großen Packete mit zu priorisieren, kann das aber nicht weil die Firewall zu billig gestrickt ist mir ein Sizefeld anzubieten.

Und zu dem pro IP, ich möchte *eine* Regel für einen großen IP Bereich anlegen und darin jeder *IP* eine gewisse Bandbreite *pro IP* zusichern.
Mit global und pro Verbindung ist da nichts zu machen weil es hunderte Regeln erfordern würde oder wie *pro Verbindung* in diesem Fall nicht zu gebrauchen ist.

Ausserdem interessiert mich erstmal nur der Upstream weil der Downstream aufgrund der Bandbreite unkritisch ist.

Tja, du tust mir auch leid ein Entwickler der so einen billigen Zusammenhang nicht erkennt ist mir auch schon lange nicht mehr untergekommen.

Und zu der Spielzeugsache, andere Produkte bieten diese Möglichkeiten, bei Firewall und Qos demnach scheint es bei der Lancom Firewall noch nicht mal als Spielzeug zu taugen.

Eigentlich sollte das nur ein Featurewunsch sein, aber wenn man hier gleich alles begründen und verteidigen muss, als wenn man vor Gericht steht, kannst du das haben....
Antworten