Kanalb{[uuml ]}ndelung wird von ISDN4LINUX zur Zeit in zwei Variationen unterst{[uuml ]}tzt:
slave
channels
)ibod
erreicht werden - siehe Frage
2channel_mpppconfig.
Raw bundling arbeitet {[auml ]}hnlich wie rawIP, nur mit mehreren Kan{[auml ]}len. Daher hat es auch die theoretischen Vor- und Nachteile von rawIP. Raw bundling ben{[ouml ]}tigt f{[uuml ]}r jeden benutzten Kanal ein Netzwerk-Interface. Eines davon, das sogenannte Master Interface, kontrolliert das Herstellen und Abbrechen der Verbindungen. F{[uuml ]}r jeden weiteren Kanal wird ein sogenanntes Slave Interface eingerichtet, das automatisch vom Master Interface aktiviert wird.
Das Master Interface wird wie normal mit
isdnctrl addif {[lt ]}master_interface{[gt ]}
isdnctrl addslave {[lt ]}master_interface{[gt ]} {[lt ]}slave_interface{[gt ]}
Raw bundling hat alle Vor- und Nachteile des rawIP. Im Vergleich zu MPPP hat raw bundling den Vorteil, da{[szlig ]} ISDN4LINUX die ben{[ouml ]}tigten abh{[auml ]}ngigen Kan{[auml ]}le selbst {[ouml ]}ffnet und schlie{[szlig ]}t. Leider hat raw bundling immer noch Probleme mit den Transferraten. Siehe weiter unten.
MPPP oder MP oder MPP (Warnung: MP ist auch eine Abk{[uuml ]}rzung von "Multi Processor") steht f{[uuml ]}r Multi Point to Point und bedeutet das B{[uuml ]}ndeln von mehreren Kan{[auml ]}len zu einem logischen Strom. Es ist eine Abart des normalen syncPPP. Deshalb erbt es auch dessen Vor- und Nachteile. Nur zur Information: ipppd betreibt MPPP nach RFC 1717 anstatt nach dem neueren RFC 1990 (MLP).
Im Gegensatz zu raw bundling wird als Interface zum ipppd nur ein Netzinterface ben{[ouml ]}tigt, da der ipppd alle seine Kan{[auml ]}le selbst verwaltet. Herein kommende Daten werden vom ipppd zuf{[auml ]}llig auf alle verf{[uuml ]}gbaren Kan{[auml ]}le verteilt. Diese Kan{[auml ]}le m{[uuml ]}ssen nicht unbedingt ISDN-Kan{[auml ]}le sein. Theoretisch k{[ouml ]}nnen Modemverbindungen mit ISDN-Kan{[auml ]}len vermischt werden. Hier jedoch besch{[auml ]}ftigen wir uns nur mit ISDN-Kan{[auml ]}len.
Ein Nachteil besteht darin, da{[szlig ]} der 2.Kanal 'manuell' aktiviert werden muss. Der ipppd kann den 2.Kanal nicht nach Bedarf an- oder abschalten. Die normalen automatischen Funktionen des ipppd sind entweder unzuverl{[auml ]}ssig (automatisches Auflegen) oder funktionieren {[uuml ]}berhaupt nicht (automatische Anwahl). Das gilt nicht f{[uuml ]}r die anderen Encapsulations. Die {[Uuml ]}bertragungsraten sind allerdings sehr gut (ca. 30 KB/s mit 4 Kan{[auml ]}en).
Zuerst muss die Unterst{[uuml ]}tzung f{[uuml ]}r MPPP bei der Kompilation der ISDN-Module aktiviert werden. Dann definierst Du ein (normales) Interface f{[uuml ]}r ipppd (i.a. 'isdnctrl addif ippp0', usw.). Dieses Interface wird als Master Interface benutzt. Anschlie{[szlig ]}end musst Du f{[uuml ]}r jeden zus{[auml ]}tzlichen Kanal ein Slave Device einrichten (z.B.: 'isdnctrl addslave ippp0 {[lt ]}slave{[lowbar]}interface{[gt ]}', mehr Details im I4L Manual). Die Aktivierung der Kanalb{[uuml ]}ndelung erfolgt durch die Option '+mp' beim Aufruf des ipppd un durch die Bindung beider Devices an ipppd. Achte darauf, da{[szlig ]} die Namen beider Devices mit "ippp" beginnen m{[uuml ]}ssen.
Zum Gebrauch der Kanalb{[uuml ]}ndlung musst Du zuerst das 'Master Device' aktivieren. Anschlie{[szlig ]}end werden die Slave Channels hinzugef{[uuml ]}gt:
isdnctrl addlink device
isdnctrl removelink ippp0
auto
sein muss. Zur manuellen Steuerung benutzt Du
isdnctrl dial slave
isdnctrl hangup slave
Bei syncPPP gibt es keine automatische Aktivierung der Slave
Devices. Sie m{[uuml ]}ssen manuell hinzugef{[uuml ]}gt und wieder entfernt
werden. Es gibt daf{[uuml ]}r jedoch das Programm ibod
, das das
automatisch erledigt. Du findest es auf:
(
{urlnam})
oder in einer von Karsten Keil erweiterten Version auf:
{urlnam}.
Ein Beispielscript findest Du in der Datei
etc/rc.isdn.syncppp.MPPP
im isdn4k-utils Paket (leider nicht
in allen I4L-Versionen).
Denke daran, da{[szlig ]} Dein Provider den Gebrauch dieser Features erlauben muss. Es kann auch vorkommen, da{[szlig ]} die Menge der gleichzeitig ge{[ouml ]}ffneten Kan{[auml ]}le limitiert ist und bei {[Uuml ]}berschreitung dieses Limits alle Verbindungen abgebrochen werden.
Du hast vergessen, die Unterst{[uuml ]}tzung f{[uuml ]}r MPPP/RFC1717 in das ISDN Subsystem zu kompilieren. Kompiliere den Kernel mit dieser aktivierten Option neu.
Das ist eine Eigenheit des ipppd. Er versucht, beiden Kan{[auml ]}len die gleiche MTU zuzuordnen und der Kernel kann kein entsprechendes Netzwerk-Device finden. Du kannst diese Meldung ohne Probleme ignorieren, MPPP sollte trotzdem funktionieren.