Hallo,
Ihr habt von mir einen Record 1204.1611.8543.ACAL in Bearbeitung. Her wird beschrieben, dass der Content Filter immer Timeouts bringt. Ich habe zwischenzeitlich die Ursache gefunden. Da ich eine permanente Datenreplikation via VPN fahre, sind zwischenzeitlich recht umfangreiche QOS Rules in der Firewall definiert. Sobald ich auf meiner Seite die Replikation stoppe, funktioniert der CF wieder. Wie kann ich also alle CF Pakete zu den Rating Servern mit DSCP:EF priorisieren? In der CF Firewall Rule DSCP:EF einzutragen funktioniert schon mal nicht, wie zu sehen ist. Ich denke auch so etwas wie EF dafür wäre als Default eine gute Idee.
Vielen Dank
Henri
[IP-Router] 2012/04/24 20:12:54,796
IP-Router Rx (intern, RtgTag: 0):
DstIP: 206.253.225.98, SrcIP: meine, Len: 44, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 15153, Flags: S
Seq: 3274725865, Ack: 0, Win: 2920, Len: 0
Option: Maximum segment size = 1460
Route: WAN Tx (INTERNET)
7100 - CF TImeout & Firewall - 8.60
Moderator: Lancom-Systems Moderatoren
Hallo Henri,
in die CF-Firewall-Regel das EF einzutragen bringt nichts, da es sich hierbei um die Regel für die Pakete von Clients auf z. B. Port 80 handelt. Die Anfragen an die Rating-Server entstehen ja erst daraus und fallen nicht unter diese Firewall-Regel. Da sie intern entstehen (Inbound), kannst Du sie nicht über die Firewall greifen.
Ob EF dafür eine gute Idee ist, sei dahingestellt. Ich bin eher der Meinung, dass es das nicht ist. Ein verlorenes Paket kann nochmal geschickt werden, dauert dann halt minimal länger. Extrem schnell muss es auch nicht sein. Klar alles soll immer möglichst schnell sein, aber die Frage ist doch, ob die Pakete schneller sein sollen als die anderen noch zu sendenden.
Ich vermute ehrlich gesagt noch irgendeinen anderen Grund für die Timeouts. Weil bei mir diese Timeouts auch auftraten, wenn definitiv eine geringe Netzlast anlag. Und manchmal hatte ich den Eindruck, dass sie insbesondere auftreten, wenn der Content-Filter nach einer längeren Zeit wieder was zu tun hat.
Viele Grüße,
Jirka
in die CF-Firewall-Regel das EF einzutragen bringt nichts, da es sich hierbei um die Regel für die Pakete von Clients auf z. B. Port 80 handelt. Die Anfragen an die Rating-Server entstehen ja erst daraus und fallen nicht unter diese Firewall-Regel. Da sie intern entstehen (Inbound), kannst Du sie nicht über die Firewall greifen.
Ob EF dafür eine gute Idee ist, sei dahingestellt. Ich bin eher der Meinung, dass es das nicht ist. Ein verlorenes Paket kann nochmal geschickt werden, dauert dann halt minimal länger. Extrem schnell muss es auch nicht sein. Klar alles soll immer möglichst schnell sein, aber die Frage ist doch, ob die Pakete schneller sein sollen als die anderen noch zu sendenden.
Ich vermute ehrlich gesagt noch irgendeinen anderen Grund für die Timeouts. Weil bei mir diese Timeouts auch auftraten, wenn definitiv eine geringe Netzlast anlag. Und manchmal hatte ich den Eindruck, dass sie insbesondere auftreten, wenn der Content-Filter nach einer längeren Zeit wieder was zu tun hat.
Viele Grüße,
Jirka
Hallo Jirka,
ich habe hier einen KabelBW BIZ 6/100 Mbit, mehr Upstream gibt's leider nicht.
Aus der anderen Seite ist ein VDSL 10/50 Mbit, da gibt's auch nichts besseres.
Ich habe für die QOS Regeln ewig gebraucht um einen RSYNC zwischen 2 NAS Geräten via VPN so einzustellen, dass auch VOIP, RDP, SSH, VNC, SFTP, TSM Archive etc. vernünftig funktioniert. Das Problem hier ist immer der Upstream, der ist zwar nominal gut, aber im Verhältnis zum Downstream immer unzureichend. Ich habe momentan für die RSYNCs 65% Upstream Bandbreite eingestellt, wenn ich höher gehe funktioniert besonders RDP nur mit inakzeptablen Denkpausen. Ggf. gibt's bei SDSL weniger Probleme. Der Upstream ist jedenfalls 7*24 immer voll, wir replizieren hier lt. SFLOW 59.1 GB zu einer Seite und 37.5 Gb zur Anderen pro Tag. Ich habe ich HTTP, HTTPS etc. auf AF31, RDP auf AF41 gestellt, so funktioniert es. Ich denke das der Content Filter dann einfach auf der Strecke bleibt. Leider gibt's im LANCOM nichts um die Prio. für Rsync auf so etwas wie "was übrig bleibt" zu setzen, dann wär's viel einfacher.
Danke und viele Grüße
Henri
ich habe hier einen KabelBW BIZ 6/100 Mbit, mehr Upstream gibt's leider nicht.
Aus der anderen Seite ist ein VDSL 10/50 Mbit, da gibt's auch nichts besseres.
Ich habe für die QOS Regeln ewig gebraucht um einen RSYNC zwischen 2 NAS Geräten via VPN so einzustellen, dass auch VOIP, RDP, SSH, VNC, SFTP, TSM Archive etc. vernünftig funktioniert. Das Problem hier ist immer der Upstream, der ist zwar nominal gut, aber im Verhältnis zum Downstream immer unzureichend. Ich habe momentan für die RSYNCs 65% Upstream Bandbreite eingestellt, wenn ich höher gehe funktioniert besonders RDP nur mit inakzeptablen Denkpausen. Ggf. gibt's bei SDSL weniger Probleme. Der Upstream ist jedenfalls 7*24 immer voll, wir replizieren hier lt. SFLOW 59.1 GB zu einer Seite und 37.5 Gb zur Anderen pro Tag. Ich habe ich HTTP, HTTPS etc. auf AF31, RDP auf AF41 gestellt, so funktioniert es. Ich denke das der Content Filter dann einfach auf der Strecke bleibt. Leider gibt's im LANCOM nichts um die Prio. für Rsync auf so etwas wie "was übrig bleibt" zu setzen, dann wär's viel einfacher.
Danke und viele Grüße
Henri
Ich sollte noch sagen, dass ich mit dem 1823 auf der anderen Seite Monate lange Probleme hatte, bei der 8.60 RC* gab's Probleme das "Communication - Pooling Table" ICMP Requests zwar im Trace zu finden waren, allerdings nicht mehr im Wireshark zwischen 1823 und Modem. Daher wurde die Verbindung terminiert und damit auch der RSYNC. Ich habe jetzt ca. 2 TB nach zu synchronisieren, damit ist halt die Leitung recht voll.
Danke
Henri
Danke
Henri
Hi Henri
was hältst du eigentlich davon, dem rsync weniger Bandbreite zuzughestehen, denn offensichtlich ist dein upstream so voll, daß Pakete verworfen werden. Hinzu kommt, daß du das Problem für den CF durch dein AF-Tagging noch verschlimmerst, denn das führt dazu, daß die so getaggten Pakete vom LANCOM so "spät wie möglich" verworfen werden, was dazu führt, daß ungetaggte Pakete, z.B. die des CF, früher verworfen werden...
Du solltest die erlaubte Bandbreite für rsync so wählen, daß du keine Tagging-Orgien brauchst, um normal arbeiten zu können - z.B. max. 50% oder gar nur 25% der Upstreamrate - dann funktioniert's auch mit dem CF...
Backups sind nunmal "Hintergrundjobs", die die normale Arbeit nicht beeinträchtigen sollten.
Gruß
Backslash
was hältst du eigentlich davon, dem rsync weniger Bandbreite zuzughestehen, denn offensichtlich ist dein upstream so voll, daß Pakete verworfen werden. Hinzu kommt, daß du das Problem für den CF durch dein AF-Tagging noch verschlimmerst, denn das führt dazu, daß die so getaggten Pakete vom LANCOM so "spät wie möglich" verworfen werden, was dazu führt, daß ungetaggte Pakete, z.B. die des CF, früher verworfen werden...
Du solltest die erlaubte Bandbreite für rsync so wählen, daß du keine Tagging-Orgien brauchst, um normal arbeiten zu können - z.B. max. 50% oder gar nur 25% der Upstreamrate - dann funktioniert's auch mit dem CF...
Backups sind nunmal "Hintergrundjobs", die die normale Arbeit nicht beeinträchtigen sollten.
Gruß
Backslash
Hallo \,
erst einmal vielen Dank für die Antwort. Der -bwlimit Parameter für Rsync scheint bei den QNAPs leider nicht zu funktionieren (lt. Wiki). Es hat übrigens ca. 3 Jahre gebraucht um den Parameter überhaupt zu unterstützen. Ich habe auch bei OPEN-E angefragt (das sind die von uns eingesetzten Ersatzgeräte), dort wird der Parameter überhaupt nicht unterstützt. Es gibt auch kein root ssh.
Leider ist es bei den auf dem Markt angebotenen NAS Applicances nicht so einfach hier etwas einzustellen, und ein Packet Shaper für so etwas ist wohl unangebracht.
So habe ich wieder einmal ein Problem und keine Lösung.
Die QOS habe ich eingebaut, damit RDP und so etwas erträglich funktioniert.
Viele Grüße
Henri
erst einmal vielen Dank für die Antwort. Der -bwlimit Parameter für Rsync scheint bei den QNAPs leider nicht zu funktionieren (lt. Wiki). Es hat übrigens ca. 3 Jahre gebraucht um den Parameter überhaupt zu unterstützen. Ich habe auch bei OPEN-E angefragt (das sind die von uns eingesetzten Ersatzgeräte), dort wird der Parameter überhaupt nicht unterstützt. Es gibt auch kein root ssh.
Leider ist es bei den auf dem Markt angebotenen NAS Applicances nicht so einfach hier etwas einzustellen, und ein Packet Shaper für so etwas ist wohl unangebracht.
So habe ich wieder einmal ein Problem und keine Lösung.
Die QOS habe ich eingebaut, damit RDP und so etwas erträglich funktioniert.
Viele Grüße
Henri