bintec R232b MLPPPoE oder LoadBalancing

Ahem...das ist aber jetzt verwirrend. Multi Link PPP wird doch gerade zum Load balancing verwendet ??!!
Was meint der Ingenieur denn mit "....bis jetzt geht nur LoadBalancing" ???

Mit einem einzelnen WAN/DSL Link ist physisch erstmal überhaupt gar kein Load Balancing möglich ! Ohne MLPPP auch nicht mit 2 WAN Links, da funktionieren dann nur primitive Backup Mechanismen !

Auch deine angesprochenen Lösung mit einem Layer 3 Switch wird dir keine Load Balancing Lösung bescheren. Auf welchen der beiden Router (du hast Router und keine Modems !) soll denn deine default Route vom L3 Switch ins Internet zeigen ???
Das ist denn gleichzeitig auch der Router der benutzt wird für alle IP Sessions und der andere langweilt sich mit Nichtstun !
Ohne aktive Load Balancing Mechanismen ereichst du niemals ein Load Balancing.
Könnte dein Layer 3 Switch z.B. Policy based Routing könntest du sowas wie ein "quick and dirty" Load Balancing machen indem du zum Beispiel nach TCP Ports routest. Also z.B. Port 80 und 443 (Webtraffic) geht über Router 1 und Port 25 und 110 (Email) geht über Router 2. Ein richtiges Load Balancing mit Failover ist das aber niemals !

Lösen kannst du sowas nur mit externen Link Loadbalancern wie von z.B. F5, Foundry Networks oder Radware u.a. oder indem dein Router sowas aktiv supported mit z.B. MLPPP. MLPPP setzt aber zwingend voraus das dein Carrier auf der anderen Seite AUCH MLPPP supported sonst wird es nichts mit PPP Link Loadbalancing wenn du es nur einseitig machst !!
Derzeit machen Carrier sowas aber nicht für den DSL Consumer Bereich !

Richtig du hast Recht mit der Session- und Verbindunsorientierung. Allerdings wenn man es ganz genau nimmt erhöht MLPPP nicht die Geschwindigkeit, da die Taktung der Übertragung ja nicht automatisch größer wird. 2 DSL Links a 2 Mbit verhalten sich dann nicht wie eine 4Mbit Leitung von der reinen Übertragungsgeschwindigkeit her gesehen sondern können lediglich ein größeres Volumen handhaben durch die packetorientierte Verteilung der Daten, was dann letzlich bei höher belasteten Links mehr oder weniger den gleichen Effekt hat.
Ich denke die VisoZeichnung ist nicht nötig denn du liegst nicht falsch. Nur wie gesagt rein mit routingtechnischen Mitteln löst du kein Load Balancing Projekt auf parallele Uplinks. Dazu braucht es externen Balancer oder eben MLPPP. Wenn dein Carrier MLPPP supportet...um so besser
Deshalb wird dein Problem so wie du es vorhast auch nicht lösbar sein.
Die Modems sind passiv und die Forwarding Database im Router wird sich definitiv für eine MAC als Forwarding Adresse entscheiden und zwar die vom Router deines Carriers. Abgesehen davon wirst du sicher Probleme mit dem Verbindungsaufbau zum DSLAM bekommen. Ich denke nicht das der Routerport 2 parallele Sessions etablieren kann. So oder so wird vermutlich ein Link tot bleiben.

Gutes Beispiel !
Generell ist das richtig. Die Zeit delta t die ich aber vom Hinsetzen auf der Rutsche bis zum ersten Aufklatschen aufs Wasser brauche ist immer gleich, sofern die Rutschen baugleich sind. Deine Annahme geht davon aus das es beim Rutschen eine Wartezeit gibt und die Wartezeit halbiert sich dann...keine Frage. Wartezeit gibt es aber NUR wenn ich sowieso schon überfüllte Rutschen (sprich überfüllte WAN Verbindungen) habe, was ja erstmal nicht die Regel ist !
Aber auch mit Wartezeit ist die eigentliche Rutschzeit IMMER konstant (deshalb gibt es ja leider die Wartezeit...) !
Ist die eine Rutsche dann allerdings doppelt so steil bei gleicher Länge ist auch die Rutschzeit schneller (das ist die Taktungsgeschw. der Datenübertragung als Solches !)
Mit 2 Rutschen steigt lediglich die Kapazität aber nicht die Bandbreite ! Dein Blickwinkel ist also nicht ganz richtig

Der Bademeister ist gut
Das ist wirklich nicht einfach und ein kniffliges Problem. Natürlich kannst du im Tunnel priorisieren das ist aber alles für die Katz wenn der über ein öffentliches Carrier Netz läuft wo keine Priorisierung passiert. Jedenfalls dann wenn dein Tunnel belastet ist mit Traffic und du priorisieren musst.
Da du nicht im Consumerbereich mit deinem Carrier verhandelst ist es ggf. möglich hier über die IP Adressen zu priorisieren. Einen Haken hat das ganze allerdings:
Dein Carrier sieht ja nur deinen Tunnel aber nicht mehr die Anwendungen da drin. Er kann also nicht mehr dediziert eine Anwendung priorisieren, dazu müsste er in den Content sehen können und der ist sicher verschlüsselt.... Also wird das nicht wirklich was bringen.
Das Problem kann man dann wahrscheinlich nur noch mit "Bandbreite" erschlagen. Also gewissermaßen den Bademeister nach Hause schicken und für jeden Schwimmer ein Schwimmbad bauen

Das wäre dann ja auch noch Multichassis mit Multilink PPP. Ich denke mal nicht das das beides mit den Maschinen technisch realisierbar ist

Was du machen kannst ist erstmal 2 Links von den Maschinen zur Zentralen aufbauen und dann ggf. mit Policy Based Routing oder über getrennte Gateway Einträge in den Endgeräten den Traffic gewissermaßen händisch zu verteilen. Darauf wirds wohl hinauslaufen....