Next Previous Contents

19. 2channel: Kanalbündelung (MPPP, raw bundling)

19.1 2channel_whatis: Was ist Kanalbündelung und wie kann ich es verwenden?

Kanalbündelung wird von ISDN4LINUX zur Zeit in zwei Variationen unterstützt:

Beide Variationen haben ihre Vor- und Nachteile. Schau Dir die folgenden Fragen an. Eine dynamische Handhabung für MPPP kann mit dem Programm ibod erreicht werden - siehe Frage 2channel_mpppconfig.

19.2 2channel_raw: Was ist 'raw bundling'?

Raw bundling arbeitet ähnlich wie rawIP, nur mit mehreren Kanälen. Daher hat es auch die theoretischen Vor- und Nachteile von rawIP. Raw bundling benötigt für jeden benutzten Kanal ein Netzwerk-Interface. Eines davon, das sogenannte Master Interface, kontrolliert das Herstellen und Abbrechen der Verbindungen. Für jeden weiteren Kanal wird ein sogenanntes Slave Interface eingerichtet, das automatisch vom Master Interface aktiviert wird.

19.3 2channel_rawconfig: Wie konfiguriere ich raw bundling?

Das Master Interface wird wie normal mit


isdnctrl addif <master_interface>

erstellt und konfiguriert. Für alle benötigten abhängigen Kanäle werden dann Slave Interfaces mit dem Befehl:
isdnctrl addslave <master_interface> <slave_interface>

erstellt und wie üblich konfiguriert (z.B. 'isdnctrl sdelay slave_interface delay').

19.4 2channel_rawgoodbad: Was sind die Vor- und Nachteile des raw bundling?

Raw bundling hat alle Vor- und Nachteile des rawIP. Im Vergleich zu MPPP hat raw bundling den Vorteil, daß ISDN4LINUX die benötigten abhängigen Kanäle selbst öffnet und schließt. Leider hat raw bundling immer noch Probleme mit den Transferraten. Siehe weiter unten.

19.5 2channel_mppp: Was ist MPPP?

MPPP oder MP oder MPP (Warnung: MP ist auch eine Abkürzung von "Multi Processor") steht für Multi Point to Point und bedeutet das Bündeln von mehreren Kanä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ötigt, da der ipppd alle seine Kanäle selbst verwaltet. Herein kommende Daten werden vom ipppd zufällig auf alle verfügbaren Kanäle verteilt. Diese Kanäle müssen nicht unbedingt ISDN-Kanäle sein. Theoretisch können Modemverbindungen mit ISDN-Kanälen vermischt werden. Hier jedoch beschäftigen wir uns nur mit ISDN-Kanälen.

19.6 2channel_mpppgoodbad: Was sind die Vor- und Nachteile von MPPP?

Ein Nachteil besteht darin, daß 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ässig (automatisches Auflegen) oder funktionieren überhaupt nicht (automatische Anwahl). Das gilt nicht für die anderen Encapsulations. Die Übertragungsraten sind allerdings sehr gut (ca. 30 KB/s mit 4 Kanäen).

19.7 2channel_mpppconfig: Wie richte ich MPPP ein?

Zuerst muss die Unterstützung für MPPP bei der Kompilation der ISDN-Module aktiviert werden. Dann definierst Du ein (normales) Interface für ipppd (i.a. 'isdnctrl addif ippp0', usw.). Dieses Interface wird als Master Interface benutzt. Anschließend musst Du für jeden zusätzlichen Kanal ein Slave Device einrichten (z.B.: 'isdnctrl addslave ippp0 <slave_interface>', mehr Details im I4L Manual). Die Aktivierung der Kanalbündelung erfolgt durch die Option '+mp' beim Aufruf des ipppd un durch die Bindung beider Devices an ipppd. Achte darauf, daß die Namen beider Devices mit "ippp" beginnen müssen.

Zum Gebrauch der Kanalbündlung musst Du zuerst das 'Master Device' aktivieren. Anschließend werden die Slave Channels hinzugefügt:


isdnctrl addlink device

Sie werden mit dem Befehl:
isdnctrl removelink ippp0

wieder deaktiviert. Dies ist anders als bei den anderen encapsulations von ISDN4LINUX! Meldet addlink einen Fehler -2 so sind keine Slave Devices eingerichtet. Der Fehler -5 bedeutet, daß ippp0 nicht verbunden ist. Beachte auch, daß das Slave Device dazu im Wählmodus auto sein muss. Zur manuellen Steuerung benutzt Du
isdnctrl dial slave

und
isdnctrl hangup slave

Bei syncPPP gibt es keine automatische Aktivierung der Slave Devices. Sie müssen manuell hinzugefügt und wieder entfernt werden. Es gibt dafür jedoch das Programm ibod, das das automatisch erledigt. Du findest es auf: ( http://www.compound.se/ibod.html) oder in einer von Karsten Keil erweiterten Version auf: http://www.suse.de/~kkeil/xibod/.

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ß Dein Provider den Gebrauch dieser Features erlauben muss. Es kann auch vorkommen, daß die Menge der gleichzeitig geöffneten Kanäle limitiert ist und bei Überschreitung dieses Limits alle Verbindungen abgebrochen werden.

19.8 2channel_mpppcompile: Ich habe MPPP ausprobiert aber es funktioniert nicht. Der ipppd schreibt im debug log so etwas wie das: ' ... rcvd (0)(proto=0x3d) c0 00 00 00 80 fd 01 01 00 0a ... sent (0)(LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...'

Du hast vergessen, die Unterstützung für MPPP/RFC1717 in das ISDN Subsystem zu kompilieren. Kompiliere den Kernel mit dieser aktivierten Option neu.

19.9 2channel_cantlocateippp1: Beim Versuch mit MPPP bekomme ich die Fehlermeldung 'modprobe: Can't locate module ippp1' und 'ipppd: ioctl(SIOCSIFMTU): No such device...'?

Das ist eine Eigenheit des ipppd. Er versucht, beiden Kanä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.


Next Previous Contents