Erweiterung der Firewall und Qos-Regeln
Moderator: Lancom-Systems Moderatoren
Erweiterung der Firewall und Qos-Regeln
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.
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.
Hi Casey
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...
Wenn hingegen als Aktion "reject" eingestellt wird, dann wird die TCP-Verbindung sofort nach Überschreiten des Limits geschlossen.
Gruß
Backslash
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.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.
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...
das wäre ggf. sinnvoll...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 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.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
Wenn hingegen als Aktion "reject" eingestellt wird, dann wird die TCP-Verbindung sofort nach Überschreiten des Limits geschlossen.
Gruß
Backslash
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.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...
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 habe ich noch nicht gewusst, aber es steht meines Wissens nach auch nirgendwo.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.
Zuletzt geändert von Casey am 29 Dez 2004, 21:27, insgesamt 1-mal geändert.
Hi Casey
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.
Gruß
Backlsash
Warum priorisierst Du nicht einfach die Dienste?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.
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.
ich frage mich nur: wann und welche?Mit genau so einer Regel habe ich bei anderen Gelegenheiten schon sehr gute Erfahrungen gemacht
Den SYN/ACK Speedup gibt es seit Jahren (und er ist per Default eingeschaltet)...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.
Gruß
Backlsash
Weil ich z.B. das abrufen von Webseiten beschleunigen möchte ohne dabei HTTP Uploads mit zu priorisieren.Warum priorisierst Du nicht einfach die Dienste?
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.
Das ist mir völlig klar und es ist in keinster Weise relevant für das was ich gerne machen möchte.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.
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.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.
Selbst der billige Trafficshaper der Fritzcard lässt sich in Bezug auf die Paketgrösse konfigurieren, weshalb ist das bei euch nicht möglich?
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.ich frage mich nur: wann und welche?
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.Den SYN/ACK Speedup gibt es seit Jahren (und er ist per Default eingeschaltet)...
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.
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.
Hi Casey
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.
"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!!!
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).
Und es gibt nur beschränkte Entwicklungs-Ressourcen.
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...
Gruß
Backslash
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ößeWeil ich z.B. das abrufen von Webseiten beschleunigen möchte ohne dabei HTTP Uploads mit zu priorisieren.
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.)Weil es Dienste gibt die keine standardisierten Ports haben oder diese dynamisch aushandeln usw. usw.
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.
Und hier gilt wieder: Das TCP sortiert die Daten eh wieder "zurück", wodurch sich letztendlich *keine* Priorisierung ergibt.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
"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!!!
Soll ich es mal so formulieren(?): die Fritzcard ist für DAUs, die mit einer korrekten Firewall und Traffic-Shaper Konfiguration überfordert sind.Selbst der billige Trafficshaper der Fritzcard lässt sich in Bezug auf die Paketgrösse konfigurieren, weshalb ist das bei euch nicht möglich?
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).
Das ist jetzt 4 Jahre her...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.
Und es gibt nur beschränkte Entwicklungs-Ressourcen.
Die Priorität der Regeln hat nichts aber auch rein gar nichts mit der Priorität der Übertragung zu tun.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 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...
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...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
Gruß
Backslash
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.
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.
Du hast mich nicht verstanden, ein Seitenabruf erzeugt kleine Pakete im Upstream, ein Upload dagegen große.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
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.
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.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.)
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.
Ich benutze aber kein Deny All weil es aus schon genannten Gründen in meinem Scenario nicht zu nutzen ist.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.
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 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!
Und auf die Programmierung solcher Applikationen habe ich leider ebensowenig Einfluss wie auf den Source der Lancom Firmware.
Doch genau damit hat es zu tun auch wenn du das bisher nicht glauben möchtest.In jedem Fall hat auch das nichts aber auch rein gar nichts mit der Paketgröße zu tun!!!
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.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).
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 ist jetzt 4 Jahre her...
Und es gibt nur beschränkte Entwicklungs-Ressourcen.
Das bestreiten dieser Probleme von deiner Seite ändert aber leider auch nichts an den bestehenden Einschränkungen.
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.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...
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.
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
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.)
(Dan Rather, CBS-Fernsehreporter.)
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
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
Hi Casey
oder besser: was meinst Du eigentlich was "pro Verbindung" bedeutet?
"Pro Verbindung" bezieht sich auf einzelne TCP-Sessions und ist somit "pro IP"!
Das ist jetzt schon möglich...
- 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
Ansonsten kann ich nur Hart zustimmen...
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.
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.
Gruß
Backslash
Äh' was meinst Du bitte mit "pro IP"?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.
oder besser: was meinst Du eigentlich was "pro Verbindung" bedeutet?
"Pro Verbindung" bezieht sich auf einzelne TCP-Sessions und ist somit "pro IP"!
siehe dazu meine Antwort zu deinem Thread http://www.lancom-forum.de/topic,102,-F ... outer.htmlDamit würde sich dann mit einer einzigen Regel Fairqueueing für einen IP-Bereich bauen lassen.
Das ist jetzt schon möglich...
Liest Du eigentlich die Antworten auf deine Anfragen?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
- 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: 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...Du hast mich nicht verstanden, ein Seitenabruf erzeugt kleine Pakete im Upstream, ein Upload dagegen große.
Wie bereits oben gesagt: "pro Verbindung" ist "pro IP"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 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.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.
Ansonsten kann ich nur Hart zustimmen...
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.)Bei einer Consolensession werden aber nunmal meistens folgen von kleinen oder großen Paketen versendet, und bei dem Rest macht es zumindest keinerlei Probleme.
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...Und auf die Programmierung solcher Applikationen habe ich leider ebensowenig Einfluss wie auf den Source der Lancom Firmware
Also nur die Paketgrößen-Priorisierung macht also einen besseren Traffic-Shaper aus??? Das wage ich doch glatt zu bezweifeln.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
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.
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.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
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...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.
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...Was glaubst du als voreingenommener Entwickler denn wo ihr im Qosbereich mit eurer Hardware angekommen seid?
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.
Wenn Du deine Entscheidungen anhand der Aussage eines Entwicklers zu einem Thema fällst, dann tust du mir leid...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.
Gruß
Backslash
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....
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....