Hallo. Ich würde gerne eine Kanalbündelung / Flusskontrolle einrichten, der folgende Internetverbindungen kombiniert: 1x ETH [10 Mbit/s Ethernet] (quota auf 1024 Kbit/s) als Low Latency Kanal ohne Trafficbegrenzung (Aber mit Waittime-Quota) 2x UMTS (1x T-Mobile und 1x O2) als High Speed Verbindung, aber nur für HTTP, FTP und IMAP Protokolle. Der FTTP/FTP/IMAP Traffic soll über beide UMTS Sticks laufen, solange diese noch nicht in der Begrenzung sind (T-mobile: 3 GB, O2: 5GB). Nachdem die UMTS Sticks in der Begrenzung sind (nur noch ca 64 Kbit/s) soll ETH mit ins Boot geholt werden. Das Problem beim Ethernetanschluss ist, dass es Richtung Internet einen "Waittime Quota" auf ca 1024 kbit/s hat. d.h sobald man die Verbindung auslastet, geht die Latenz tierisch hoch, da das Quota auf absichtlicher Paketverzögerung basiert. (Raster ca 1 Sekunde) Bei Downloads steigt die Latenz bis auf ca 1100 ms, während sie normalerweise im Leerlauf ca 60 ms beträgt. Durch dieses Waittime Quota scheitert VOIP und Onlinegaming. VOIP und Onlinegaming sind seitens des Ethernetbetreibers offiziell nicht unterstützt. Offiziell ist es nur zum "Surfen", so dass man dort keine Notwendigkeit sieht, irgendwas zu ändern. Und einem geschenkten Gaul sollte man sowieso nicht zu tief ins maul schauen. Man kann das Waittime Quota entschärfen, indem man in einem eigenen Router QOS einrichtet und z.B. HTTP/FTP/IMAP auf 100 kbit/s drosselt, aber das ist auch keine akzeptable Lösung, da dann Downloads erstrecht ewig dauern. Ich wollte daher 2 UMTS Sticks mit ins Boot holen, um Downloads mit hoher Geschwindigkeit (Bis ca 7 Mbit/s, bzw 14 Mbit/2 bei 2 Sticks) zu ermöglichen, 8 GB Gesamtguthaben sollte erst mal reichen. Danach kann man immer noch über ETH gehen (unter inkaufnahme der Nachteile). Und Linux Images o.ä kann man nachts laden, so dass man UMTS Traffic spart, von den Nachteilen im Ethernet trotzdem nicht betroffen ist. Wie kann an sowas gut einrichten? Kennt ihr gute Howtos? Achja: Derzeit verwende ich VPN und "telefoniere nach Hause", um das mitlesen zu erschweren. Und um zu vermeiden, dass alles was ich online mache geloggt wird. Das VPN läuft über einen Linux Server PC.
Gast
#2412061
Nico --- schrieb: > Kennt ihr gute Howtos? such mal nach "linux advanced routing and traffic control" im allgemeinen funktioniert es aber ehr schlecht verbindungen über unterschiedlich schnelle interfaces zu balancen, was geht sind gleiche default routen womit dann komplette verbindungen immer einem anderen interface zugewiesen werden.
Danke, Tom. Ich werde diesen Begrff mal bei Google rein hauen. Richtige "Kanalbündelung" ist problematisch bei stark unterschiedlichen Kanälen, das stimmt. Ich wollte deswegen protokollbasiertes Routing machen, http, ftp, imap über UMTS (VPN1) Rest über LAN (VPN2). Bei UMTS wäre es eventuell noch vertretbar, einen Wechselbetrieb zu machen. Wenn die O2 Karte "verbraucht ist" oder wegen Netzproblemen zu wenig Durchsatz kommt, schalte auf T-Mobile um, bzw umgekehrt. Die o2 Karte ist ein richtiger Mobile Internet Tarif. Die T-Mobilekarte ist nur eine TwinSIM Karte vom Smartphonetarif (mit sonstwo gekauftem UMTS Stick), die würde dann einfach als Fallback benutzt werden. Größere Downloads, die nicht so schnell wie möglich da sein müssen (z.B. Linux images) wollte ich eh nachts über das LAN machen. Jenachdem was es ist, kann man dafür sogar auf VPN verzichten (z.B. der Download eines Linux images kann ruhig geloggt werden)
Gast
#2412172
Nico --- schrieb: > Ich wollte deswegen protokollbasiertes Routing machen, http, ftp, imap > über UMTS (VPN1) Rest über LAN (VPN2). ja, das geht ohne probleme (solange die interfaces zur verfügung stehen, automatisches umschalten bei ausfall gibts nicht, dazu braucht es bash-magie). im wesentlichen musst du mit iptables die verbindungen entsprechend markieren, dann kannst du anhand der markierungen in der routingtable entscheiden lassen über welche route das paket geht. das hier gibt ein paar ideen: http://linux-ip.net/html/adv-multi-internet.html
Das LAN seitige Quota von 1024 kbit/s Traffic greift übrigens nur bei ausgehenden Paketen / Ack Paketen, die verzögert werden. Eingehend wird nicht verzögert, da wird nur gemessen. Wenn man die Verbindung auslastet, sieht man, wie die Daten Tröpchenweise fließen. Kurz fließen sie so, wie es das 10 Mbit/s Ethernet hergibt. Und dann kommt eine Pause von mehreren 100 ms. Begrenzt man die Bandbreite clientseitig auf deutlich unter 1024 kbit/s (also z.B. 100 kbit/s), kann man verhindern, dass die Latenz wegen der absichtlichen Verzögerung deutlich steigt. Eingehene Pakete werden nicht begrenzt. Wenn man eine Gegenseite hat, die nicht auf ACKs wartet, sondern einfach mehr schickt (und man die Pakete erst rückwirkend "en block" bestätigt), kann man das Quota bei Downloads auch aushebeln, weil die verzögerungszeit irgendwo ein maximum hat. Eventuell kann man da drauf aufbauen, dass man es irgendwie hinbiegt, dass man keine merkliche Latenzsteigerung hat, und sich trotzdem nicht noch selbst massiv drosselt, um Latenzerhöhung durch das Quota zu vermeiden.