Multichassis Multilink PPP (MMP)

Download-Optionen

PDF (299.1 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (98.3 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (135.2 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:29. Januar 2008

Dokument-ID:14942

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Verwandte Begriffe

Konventionen

Problemdefinition

Funktionsüberblick

SGBP

Virtuelle Zugriffsschnittstellen

L2F

Endbenutzeroberfläche

SGBP

Beispiele

Zugehörige Informationen

Einleitung

In diesem Dokument wird die Unterstützung von Multilink PPP (MP) in einer Stack- oder Multichassis-Umgebung (auch MMP genannt, für Multichassis Multilink PPP) auf den Access Server-Plattformen von Cisco Systems beschrieben.

Voraussetzungen

Anforderungen

Es sind keine besonderen Voraussetzungen erforderlich, um den Inhalt dieses Dokuments nachzuvollziehen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Problemdefinition

MP bietet Benutzern bei Bedarf zusätzliche Bandbreite und die Möglichkeit, Pakete über eine logische Leitung (ein Bündel) aufzuteilen und neu zu kombinieren, die mehrere Verbindungen umfasst.

Dadurch wird die Übertragungslatenz über die langsamen WAN-Verbindungen verringert, und es wird eine Methode zur Erhöhung der maximalen Empfangseinheit bereitgestellt.

Auf der Übertragungsseite sorgt MP für die Fragmentierung eines einzelnen Pakets in mehrere Pakete, die über mehrere PPP-Verbindungen übertragen werden. Auf der Empfangsseite ermöglicht MP die Zusammenfügung von Paketen aus mehreren PPP-Verbindungen zurück zum ursprünglichen Paket.

Cisco unterstützt MP zu autonomen Endsystemen, d. h. mehrere MP-Verbindungen vom gleichen Client können am Zugriffsserver terminiert werden. ISPs ziehen es jedoch z. B. vor, mehrere PRIs über mehrere Zugriffsserver hinweg bequem eine einzelne Dreh-Nummer zuzuweisen und ihre Serverstruktur skalierbar und flexibel an geschäftliche Anforderungen anzupassen.

In Version 11.2 der Cisco IOS® Software stellt Cisco diese Funktionalität bereit, sodass mehrere MP-Links vom gleichen Client an unterschiedlichen Zugriffsservern terminiert werden können. Während einzelne MP-Verbindungen desselben Bündels tatsächlich an unterschiedlichen Zugriffsservern enden können, ist dies, was den MP-Client betrifft, vergleichbar mit der Terminierung an einem einzigen Zugriffsserver.

Um dieses Ziel zu erreichen, verwendet MP Multichassis-MP.

Funktionsüberblick

Abbildung 1 zeigt die Verwendung von MP auf einem einzelnen Cisco Access Server zur Unterstützung dieser Funktion.

Abbildung 1: VA eines einzelnen Cisco Access Servers

Abbildung 1 zeigt, wie MP-Teilnehmer-Schnittstellen mit einer Paketschnittstelle verbunden sind. In einem Standalone-System ohne aktiviertes Multichassis MP sind Mitglieds-Schnittstellen immer physische Schnittstellen.

Um eine Stack-Umgebung zu unterstützen, sind zusätzlich zu MP drei weitere Unterkomponenten erforderlich:

SGBP
vTemplate
L2F

In den folgenden Abschnitten dieses Dokuments werden diese Komponenten im Detail erläutert.

SGBP

In Umgebungen mit mehreren Zugriffsservern kann der Netzwerkadministrator eine Gruppe von Zugriffsservern als zu einer Stapelgruppe gehörend festlegen.

Angenommen, eine Stack-Gruppe besteht aus System A und System B. Ein entfernter MP-Client mit dem Namen userx hat die erste MP-Verbindung, die an System A (systema) endet. Das Bundle userx wird bei systema gebildet. Der nächste MP-Link von userx endet nun bei System B (systemb). SGBP sucht nach dem Paket, in dem sich der Benutzer auf dem System befindet. An diesem Punkt projiziert eine andere Komponente - L2F - die zweite MP-Verbindung von systemb nach systema. Die projizierte MP-Verbindung tritt dann dem Paket bei systema bei.

SGBP lokalisiert somit die Bündelposition eines Stapelelements innerhalb einer definierten Stapelgruppe. SGBP arbitriert auch für ein designiertes Stack-Element für die Bündelerstellung. Wenn im Beispiel die erste MP-Verbindung auf systema empfangen wird, bieten sowohl systema als auch systemb (und alle anderen Mitglieder der Stack-Gruppe) die Erstellung des Pakets an. Das Gebot von systema ist höher (weil es den ersten Link akzeptiert hat), daher bestimmt SGBP es für die Bündelerstellung.

Diese Beschreibung des SGBP-Ausschreibungsverfahrens ist etwas zu simpel. In der Praxis ist ein SGBP-Gebot von einem Stack-Element eine Funktion der Lokalität, einer vom Benutzer konfigurierbaren gewichteten Metrik, des CPU-Typs, der Anzahl der MP-Pakete usw. Bei diesem Ausschreibungsverfahren kann das Paket auf einem dafür vorgesehenen System erstellt werden - auch auf einem System ohne Zugangsschnittstellen. Eine Stack-Umgebung kann beispielsweise aus zehn Zugriffsserversystemen und zwei 4500er-Systemen bestehen - eine Stack-Gruppe mit 12 Stack-Elementen.

Hinweis: Wenn die Gebote gleich sind, z. B. zwischen zwei 4500ern, bestimmt SGBP zufällig einen als Gewinner des Gebots. Sie können die 4500s so konfigurieren, dass sie die anderen Stapelelemente immer überbieten. Die 4500er werden somit zu ausgelagerten Multichassis-MP-Servern, die auf Fragmentierer und Reassemblierer von MP-Paketen spezialisiert sind - eine Aufgabe, die für ihre im Vergleich zu den Access-Servern höhere CPU-Leistung geeignet ist.

Kurz gesagt, SGBP ist der Standort- und Vermittlungsmechanismus von Multichassis MP.

Virtuelle Zugriffsschnittstellen

Virtuelle Zugriffsschnittstellen dienen sowohl als Paketschnittstellen (siehe Abbildungen 1 und 2) als auch als geplante PPP-Verbindungen (siehe Abbildung 2). Diese Schnittstellen werden dynamisch erstellt und bei Bedarf an das System zurückgegeben.

Virtuelle Vorlagenschnittstellen dienen als Repositorys für Konfigurationsinformationen, aus denen virtuelle Zugriffsschnittstellen geklont werden. Eine weitere Quelle für Konfigurationsinformationen sind Dialer Interface-Konfigurationen. Die Methode zur Auswahl der Konfigurationsquelle für das Klonen einer virtuellen Zugriffsschnittstelle wird in Multichassis Multilink PPP (MMP) (Teil 2) erläutert.

L2F

L2F stellt die tatsächliche PPP-Link-Projektion zu einem bestimmten Endsystem bereit.

L2F führt Standard-PPP-Operationen bis zur Authentifizierungsphase durch, in der der Remote-Client identifiziert wird. Die Authentifizierungsphase ist lokal nicht abgeschlossen. L2F, mit dem Ziel-Stack-Element von SGBP versehen, projiziert die PPP-Verbindung auf das Ziel-Stack-Element, wo die Authentifizierungsphase fortgesetzt und an der geplanten PPP-Verbindung abgeschlossen wird. Der endgültige Authentifizierungserfolg oder -fehler wird somit am Ziel-Stack-Element durchgeführt.

Die ursprüngliche physische Schnittstelle, die den eingehenden Anruf angenommen hat, wird als L2F weitergeleitet. Die entsprechende Schnittstelle, die L2F dynamisch erstellt (wenn die PPP-Authentifizierung erfolgreich ist), ist eine geplante virtuelle Zugriffsschnittstelle.

Hinweis: Die projizierte virtuelle Zugriffsschnittstelle wird auch von der virtuellen Vorlagenschnittstelle geklont (falls definiert).

Abbildung 2 beschreibt eine Stapelgruppen-StackQ, die aus systema, systemb und systemc besteht.

Abbildung 2: Client-Aufruf in einen Stack

Client-Benutzeranrufe. Der erste Link auf systema erhält den Anruf. SGBP versucht, ein beliebiges Bündel zu lokalisieren, indem unter den Stapelgruppenmitgliedern vorhandene Benutzer verwendet werden. Wenn keine vorhanden ist und MP auf der PPP ausgehandelt wird, wird eine Paketschnittstelle auf systema erstellt.
systemb erhält den zweiten Anruf von userx. SGBP hilft bei der Bestimmung, dass sich das System dort befindet, wo sich das Paket befindet. L2F unterstützt die Weiterleitung der Verbindung von systemb an systema. Eine geplante PPP-Verbindung wird auf dem System erstellt. Der geplante Link wird dann mit der Paketschnittstelle verbunden.
systemc erhält den dritten Anruf von userx. Auch hier findet SGBP das System, auf dem sich das Paket befindet. L2F wird für die Weiterleitung der Verbindung von systemc an systema verwendet. Eine geplante PPP-Verbindung wird auf dem System erstellt. Der geplante Link wird dann mit der Paketschnittstelle verbunden.

Hinweis: Eine Paketschnittstelle stellt das Paket auf systema dar. Für jeden einzelnen Anrufer enden die MP-Teilnehmer-Schnittstellen desselben Anrufers an einer Paketschnittstelle bzw. stammen von einer Paketschnittstelle.

Endbenutzeroberfläche

Die Vtemplate Benutzeroberfläche ist hier nominell angegeben. Weitere Informationen finden Sie in der Funktionsspezifikation für virtuelle Vorlagen .

SGBP

sgbp group <Name>

Dieser globale Befehl definiert eine Stapelgruppe, weist der Gruppe einen Namen zu und macht das System zu einem Mitglied dieser Stapelgruppe.

Hinweis: Sie können global nur eine Stack-Gruppe definieren.

Definieren Sie eine Stapelgruppe mit dem Namen stackq:
```
systema(config)#sgbp group stackq
```
Hinweis: Die PPP CHAP Challenge oder die PPP PAP Anfrage von systema trägt nun den Namen stackq. Wenn Sie den Namen der Stapelgruppe auf dem Zugriffsserver definieren, ersetzt dieser im Allgemeinen den für dasselbe System definierten Hostnamen.
sgbp member <Peer-Name> <Peer-IP-Adresse>

Mit diesem globalen Befehl werden Peers in der Stapelgruppe angegeben. In diesem Befehl ist <Peer-Name> der Hostname und <Peer-IP-Adresse> die IP-Adresse des Remote-Stapelelements. Daher müssen Sie einen Eintrag für jedes Stapelgruppenelement im Stapel definieren, außer Ihnen selbst. Ein Domain Name Server (DNS) kann die Peernamen auflösen. Wenn Sie über einen DNS verfügen, müssen Sie die IP-Adresse nicht eingeben.
```
systema(config)#sgbp member systemb 1.1.1.2
	
   systema(config)#sgbp member systemc 1.1.1.3 
```
sgbp seed-bid {default | entladen | Nur vorwärts | <0-9999>}

Das konfigurierbare Gewicht, mit dem das Stapelelement ein Gebot für ein Paket abgibt.

Wenn der Standard-Parameter für alle Stack-Elemente definiert ist, erhält das Stack-Element, das den ersten Aufruf für den Benutzer userx empfängt, immer den Zuschlag und hostet die Master-Paketschnittstelle. Alle nachfolgenden Aufrufe desselben Benutzers an einen anderen Stapelelement-Projekt an diesen Stapelelement. Wenn Sie kein sgbp seed-bid definieren, wird der Standardwert verwendet.

Wenn Offload definiert ist, wird das vorkalibrierte plattformbasierte Gebot gesendet, das sich der CPU-Leistung abzüglich der Paketlast nähert.

Wenn < 0-9999> konfiguriert ist, wird als Gebot der vom Benutzer konfigurierte Wert abzüglich der Paketlast gesendet.

Die Paketlast wird als die Anzahl der aktiven Pakete auf dem Stack definiert.
1. Wenn äquivalente Stack-Elemente gestapelt sind, um Anrufe in einer Dreh-Gruppe über mehrere PRIs zu empfangen, geben Sie den Befehl sgbp seed-bid default across all stack members (Standardeinstellung für sgbp seed-bid für alle Stack-Elemente) ein. Ein Beispiel für gleichwertige Stack-Elemente ist eine Stack-Gruppe mit vier AS5200. Das Stack-Element, das den ersten Aufruf für den Benutzer userx empfängt, gewinnt immer das Gebot und hostet die Master-Bundle-Schnittstelle. Alle nachfolgenden Aufrufe desselben Benutzers an ein anderes Stapelelement werden auf dieses Stapelelement projiziert. Wenn mehrere Aufrufe gleichzeitig über mehrere Stack-Elemente eingehen, unterbricht der SGBP-Mechanismus die Verbindung.
2. Wenn eine CPU mit höherer Leistung als Stack-Element im Vergleich zu den anderen Stack-Elementen verfügbar ist, können Sie die relativ höhere Leistung dieses Stack-Elements über den Rest nutzen (z. B. eine oder mehrere CPUs mit höherer Leistung, die als Stack-Element im Vergleich zu anderen ähnlichen Stack-Elementen verfügbar sind; z. B. ein 4500 und vier AS5200s).Mit dem Befehl sgbp seed-bid offload können Sie das designierte Stack-Element mit hoher Leistung als Offload-Server festlegen. In diesem Fall hostet der Offload-Server das Master-Paket. Alle Aufrufe von anderen Stapelelementen werden auf dieses Stapelelement projiziert. Tatsächlich können ein oder mehrere Offload-Server definiert werden. Wenn die Plattformen identisch sind (gleichwertig), sind die Gebote gleich. Der SGBP-Mechanismus zum Abbrechen der Bindung löst die Bindung auf und bestimmt eine der Plattformen als Gewinner.
  
  Hinweis: Wenn Sie zwei unterschiedliche Plattformen als Offload-Server festlegen, erhält die Plattform mit der höheren CPU-Leistung den Zuschlag.
3. Wenn Sie verschiedene oder genau dieselben Plattformen haben und eine oder mehrere Plattformen als Offload-Server festlegen möchten, können Sie den Gebotswert mit dem Befehl sgbp seed-bid 9999 manuell auf einen deutlich höheren Wert als der Rest festlegen. Beispiel: ein 4700 (durch das höchste Startgebot bezeichnet), zwei 4000er und ein 7000. Um den Wert des ersten Angebots für Ihre speziellen Plattformen zu bestimmen, verwenden Sie show sgbp.
4. In einer Multi-Chassis-Umgebung, in der die Front-End-Stack-Elemente immer auf einen oder mehrere Offload-Server ausgelagert werden, kann das Front-End-Stack-Element in bestimmten Fällen nicht ausgelagert werden, z. B. wenn das Multi-Link-Bündel lokal gebildet wird. Dies kann beispielsweise der Fall sein, wenn alle Offload-Server ausgefallen sind. Wenn der Netzwerkadministrator bevorzugt, dass der eingehende Anruf stattdessen auflegt, geben Sie den Befehl sgbp seed-bid forward-only ein.
sgbp ppp-forward

Wenn sgbp ppp-forward definiert ist, werden sowohl PPP- als auch MP-Aufrufe an den Gewinner des SGBP-Angebots weitergeleitet. Standardmäßig werden nur MP-Anrufe weitergeleitet.
sgbp anzeigen

Dieser Befehl zeigt den Status der Stapelgruppenelemente an. Die Status können "ACTIVE", "CONNECTING", "WAITINFO" oder "IDLE" sein. Der beste Zustand ist "ACTIVE" für jedes Element der Stapelgruppe. CONNECTING und WAITINFO sind Übergangszustände, die Sie nur sehen dürfen, wenn Sie auf ACTIVE umsteigen. IDLE gibt an, dass das Stapelgruppensystem das entfernte Stapelelementsystem nicht erkennen kann. Wenn beispielsweise systemd zur Wartung außer Betrieb genommen wird, besteht kein Grund zur Sorge. Andernfalls sehen Sie sich einige Routing-Probleme oder andere Probleme zwischen diesem Stack-Element und systemd an.
```
systema#show sgbp
  Group Name: stack Ref: 0xC38A529
  Seed bid: default, 50, default seed bid setting
	
     Member Name: systemb State: ACTIVE  Id: 1
     Ref: 0xC14256F
     Address: 1.1.1.2 
	
     Member Name: systemc State: ACTIVE  Id: 2
     Ref: 0xA24256D
     Address: 1.1.1.3 Tcb: 0x60B34439
	
     Member Name: systemd State: IDLE Id: 3
     Ref: 0x0
     Address: 1.1.1.4 
	
```

sgbp-Abfragen anzeigen

Zeigt den aktuellen Startbietungswert an.

systema# show sgbp queries
  Seed bid: default, 50
	
  systema# debug sgbp queries
  %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
  %SGBPQ-7-PB:    1.1.1.2 		State: Open_to_peer  Bid: 000  Retry: 0
  %SGBPQ-7-PB:    1.1.1.3		 State: Open_to_peer  Bid: 000  Retry: 0
  %SGBPQ-7-PB:    1.1.1.4		 State: Open_to_peer  Bid: 000  Retry: 0
  %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
  %SGBPQ-7-PB:    1.1.1.2		State: Rcvd     Bid: 000  Retry: 0
  %SGBPQ-7-PB:    1.1.1.3		State: Rcvd     Bid: 000  Retry: 0
  %SGBPQ-7-PB:    1.1.1.4		State: Rcvd     Bid: 000  Retry: 0
  %SGBPQ-7-DONE: Query #9 for bundle userX, count 1, master is local

MP

virtuelle Multilink-Vorlage <1-9>

Dies ist die Nummer der virtuellen Vorlage, mit der die MP-Paketschnittstelle ihre Schnittstellenparameter klont. Im Folgenden finden Sie ein Beispiel, wie eine VA einer virtuellen Vorlage zugeordnet wird. Außerdem muss eine Schnittstelle für virtuelle Vorlagen definiert werden:
```
systema(config)#multilink virtual-template 1
  systema(config)#int virtual-template 1
  systema(config-i)#ip unnum e0
  systema(config-i)#encap ppp
  systema(config-i)#ppp multilink
  systema(config-i)#ppp authen chap
```
ppp multilink anzeigen

Dieser Befehl zeigt die Bündelinformationen für die MP-Bündel an:
```
systema#show ppp multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
  0 discarded,  0 lost received, sequence 40/66 rcvd/sent
  members 2
    Serial0:4  
    systemb:Virtual-Access6    (1.1.1.2)
```
Dieses Beispiel zeigt auf dem Stack-Gruppenelementsystem in der Stack-Gruppe stackq, dass die Paketschnittstelle von Bündelbenutzer als Virtual-Access4 festgelegt ist. Zwei Mitgliedsschnittstellen sind mit dieser Bündelschnittstelle verbunden. Der erste Kanal ist ein lokaler PRI-Kanal, der zweite eine projizierte Schnittstelle vom Stack Group Member SystemB.