Konfiguration von Link Fragmentation and Interleaving (LFI) mit Campus ATM-Switches

Einleitung

Dieses Dokument bietet einen technischen Überblick über Link Fragmentation and Interleaving (LFI) über eine Frame Relay to ATM Interworking (IWF)-Verbindung (gemäß Definition im Frame Relay Forum oder gemäß FRF.8-Vertrag) sowie eine Beispielkonfiguration für die Verwendung des LS1010 oder Catalyst 8500 als IWF-Gerät in der WAN-Cloud. LFI nutzt die integrierten Fragmentierungsfunktionen der Multilink Point-to-Point Protocol (MLPPP)-Kapselung über ATM und Frame Relay, um eine End-to-End-Fragmentierungs- und Interleaving-Lösung für langsame Verbindungen mit Bandbreiten von bis zu 768 Kbit/s bereitzustellen.

Voraussetzungen

Anforderungen

Für dieses Dokument müssen folgende Punkte verstanden werden:

• Typische FRF.8-Umgebung und FRF.8-transparente und Übersetzungsmodi - Siehe Verständnis von transparenten und Übersetzungsmodi mit FRF.8.

• Kenntnis der Konfigurationsbefehle für LS1010 und Catalyst 8500 und der Art, wie der Channelized E1 Frame Relay Port Adapter oder der Channelized DS3 Frame Relay Port Adapter das Interworking zwischen einem Frame Relay-Endpunkt und einem ATM-Endpunkt durchführt

• Serialisierungsverzögerung und Jitter Siehe VoIP over PPP-Verbindungen mit Quality of Service (LLQ/IP RTP Priority, LFI, cRTP) und VoIP over Frame Relay mit Quality of Service (Fragmentierung, Traffic Shaping, IP RTP-Priorität).

Verwendete Komponenten

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

Konventionen

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

Warum MLPP über ATM und Frame Relay?

Die Fragmentierung ist eine Schlüsseltechnik zur Steuerung von Serialisierungsverzögerungen und Verzögerungsschwankungen bei langsamen Verbindungen, die sowohl Echtzeit- als auch Nicht-Echtzeit-Datenverkehr übertragen. Die Serialisierungsverzögerung ist die feste Verzögerung, die zum Takten eines Sprach- oder Daten-Frames an der Netzwerkschnittstelle erforderlich ist und sich direkt auf die Taktrate des Trunks bezieht. Ein zusätzliches Flag ist erforderlich, um die Frames für niedrige Taktraten und kleine Frame-Größen zu trennen.

LFI nutzt die integrierten Fragmentierungsfunktionen von MLPPP, um Verzögerungen und Jitter (Schwankungen der Verzögerung) zu verhindern, die durch große Pakete variabler Größe verursacht werden, die zwischen relativ kleinen Sprachpaketen in die Warteschlange gestellt werden. Bei LFI werden Pakete, die größer als eine konfigurierte Fragmentgröße sind, in einen MLPPP-Header gekapselt. RFC 1990 definiert den MLPPP-Header sowie Folgendes:

• (B)Das Ausgangsfragmentbit ist ein Ein-Bit-Feld, das auf dem ersten von einem PPP-Paket abgeleiteten Fragment auf 1 und auf 0 für alle anderen Fragmente desselben PPP-Pakets festgelegt ist.

• (E)nding fragment bit ist ein Ein-Bit-Feld, das auf dem letzten Fragment auf 1 und für alle anderen Fragmente auf 0 gesetzt wird.

• Das Sequenzfeld ist eine 24-Bit- oder 12-Bit-Zahl, die für jedes übertragene Fragment inkrementiert wird. Das Sequenzfeld ist standardmäßig 24 Bit lang, kann jedoch mit der nachfolgend beschriebenen LCP-Konfigurationsoption auf nur 12 Bit festgelegt werden.

Neben der Fragmentierung müssen verzögerungsempfindliche Pakete mit angemessener Priorität zwischen Fragmenten eines großen Pakets geplant werden. Durch die Fragmentierung wird Weighted Fair Queueing (WFQ) "bewusst", ob ein Paket Teil eines Fragments oder nicht fragmentiert ist. WFQ weist jedem eingehenden Paket eine Sequenznummer zu und plant anschließend die Pakete basierend auf dieser Nummer.

Die Layer-2-Fragmentierung bietet eine bessere Lösung als alle anderen Ansätze zur Lösung des "Big-Packet-Problems". In der folgenden Tabelle sind die Vor- und Nachteile anderer möglicher Lösungen aufgeführt.

Potenzielle Lösung	Vorteile	Nachteile
Die Übertragung des großen Pakets wird abgebrochen und hinter dem verzögerungsempfindlichen Datenverkehr wieder in die Warteschlange gestellt.	Verschiebt nur die Paketübertragung. Wenn das Paket erneut übertragen wird, kann das gleiche Problem auftreten. Wenn die Pakete ständig neu angefordert und sogar verworfen werden, kann es zu einem Verlust an Bandbreite kommen.	Einige physische Schnittstellen unterstützen keine abgebrochene Übertragung und führen dafür keine Leistungseinbußen ein (z. B. Zurücksetzen der gesamten Übertragungswarteschlange).
Fragmentieren Sie große Pakete mithilfe von Fragmentierungstechniken auf Netzwerkebene.	Sowohl IP als auch CLNP unterstützen die Fragmentierung auf allen Routern, wobei die Reassemblierung auf dem Zielhost erfolgt. Es kann vermieden werden, dass das große Paket mithilfe der MTU-Erkennung fragmentiert werden muss. Verwendet einen globalen Mechanismus, um ein lokales (Ein-Hop-)Problem zu überwinden - alle Downstream-Hops müssen eine größere Anzahl von zu versendenden Paketen verarbeiten, selbst wenn alle nachfolgenden Links schnell sind. Macht die Option der TCP/IP-Header-Komprimierung ungültig.	Viele Anwendungen akzeptieren keine Fragmentierung und setzen das Bit "Nicht fragmentieren" im IP-Header. Diese Pakete werden verworfen, wenn sie fragmentiert werden. Anwendungen, die keine fragmentierten Pakete akzeptieren können, werden in dieser Umgebung deaktiviert.
Fragmentieren Sie das Paket mithilfe von Link-Layer-Techniken.	Unterstützt durch alle Pakete auf Netzwerkebene oder überbrückte Pakete	Fragmentierung pro Verbindung anstelle der End-to-End-Übertragung fragmentierter Pakete Nur die Router, die an die langsame Verbindung angeschlossen sind, müssen die Verarbeitung und Reassemblierung zusätzlicher Pakete unterstützen.

Die ideale Fragmentgröße für Multilink Point-to-Point Protocol over ATM (MLPPPoATM) sollte es ermöglichen, dass die Fragmente in ein exaktes Vielfaches von ATM-Zellen passen. Eine Anleitung zur Auswahl von Fragmentierungswerten finden Sie unter Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuit.

MLPPPoA- und MLPPPoFR-Header

Eine typische Konfiguration von FRF.8 besteht aus den folgenden Komponenten:

• Ein Frame-Relay-Endpunkt

• Ein ATM-Endpunkt

• Ein Interworking (IWF)-Gerät

Jeder Endpunkt kapselt Daten- und Sprachpakete in einem Layer-2-Kapselungsheader, der das gekapselte und in dem Frame oder der Zelle transportierte Protokoll übermittelt. Sowohl Frame Relay als auch ATM unterstützen NLPID-Kapselungsheader (Network Layer Protocol ID). Das Dokument der ISO/International Electrotechnical Commission (IEC) TR 9577 definiert bekannte NLPID-Werte für eine ausgewählte Anzahl von Protokollen. PPP wird der Wert 0xCF zugewiesen.

RFC 1973 definiert PPP in Frame Relay und im MLPPPoFR-Header, während RFC 2364 PPP über AAL5 und den MLPPPoA-Header definiert. Beide Header verwenden den NLPID-Wert 0xCF, um PPP als gekapseltes Protokoll zu identifizieren.

Jede dieser Kopfzeilen ist in Abbildung 1 unten dargestellt.

Abbildung 1. PPP over AAL5-Header, MLPPPoA-Header mit NLPID-Kapselung und MLPPPoA-Header mit VC-Multiplexing

Hinweis: Der MLPPPoFR-Header enthält auch das Ein-Byte-Flag-Feld 0x7e, das in Abbildung 1 nicht dargestellt ist. Nach den Headern startet das Byte Nummer 5 die PPP- oder MLPPP-Protokollfelder.

Tabelle 1 - FRF.8 Transparent vs. FRF.8 Translational

Abbildung 2. Fragmentierung des MLPPPoATM-Pakets mithilfe von NLPID

Abbildung 3: Fragmentierung des MLPPoATM-Pakets mithilfe von VC Multiplexing

Die Bedeutung der Bytewerte wird im Folgenden dargestellt:

• 0xFEFE - Identifiziert die Ziel- und Quell-Service-Access Points (SAPs) im LLC-Header (Logical Link Control). Der Wert 0xFEFE gibt an, dass als Nächstes ein NLPID-Header in Kurzform folgt, der mit Protokollen mit einem definierten NLPID-Wert verwendet wird.

• 0x03 - Kontrollfeld, das mit vielen Kapselungen verwendet wird, einschließlich High Level Data Link Control (HDLC). Zeigt außerdem an, dass der Paketinhalt aus nicht nummerierten Informationen besteht.

• 0xCF - Bekannter NLPID-Wert für PPP.

FRF.8 Transparent und Übersetzungsmodi

Die FRF.8-Vereinbarung definiert zwei Betriebsmodi für das IWF-Gerät:

• Transparent - Das IWF-Gerät leitet die Kapselungskopfzeilen unverändert weiter. Es führt keine Protokoll-Header-Zuordnung, Fragmentierung oder Reassemblierung durch.

• Übersetzung - Das IWF-Gerät führt eine Protokoll-Header-Zuordnung zwischen den beiden Kapselungsheadern durch, um kleine Unterschiede zwischen den Kapselungstypen zu berücksichtigen.

Der auf dem IWF-Gerät konfigurierte Modus, bei dem es sich um einen Cisco ATM-Campus-Switch oder einen Router der Serie 7200 mit einem PA-A3-ATM-Port-Adapter handeln kann, ändert die Anzahl der Layer-2-Header-Bytes auf den ATM- und Frame-Relay-Segmenten der Interworking-Verbindung. Sehen wir uns diese Gemeinkosten einmal genauer an.

Die folgenden beiden Tabellen enthalten die Overhead-Bytes für Datenpakete und VoIP-Pakete (Voice over IP).

Tabelle 2 - Datenverbindungs-Overhead in Byte für ein Datenpaket über eine FRF.8-Verbindung.

FRF.8-Modus			Transparent					Übersetzung
Richtung des Datenverkehrs			Frame-Relay an ATM			ATM-Frame-Relay		Frame-Relay an ATM			ATM-Frame-Relay
Rahmenrelais oder ATM-Schenkel aus PVC			Frame Relay		Geldautomat	Geldautomat	Frame Relay	Frame Relay	Geldautomat		Geldautomat		Frame Relay
Frame-Markierung (0x7e)			1		0	0	1	1	0		1		0
Frame Relay-Header			2		0	0	2	2	0		0		2
LLC DSAP/SSAP (0xfefe)			0		0	2	2	0	2		2		0
LLC Control (0x03)			1		1	1	1	1	1		1		1
NLPID (0xcf für PPP)			1		1	1	1	1	1		1		1
MLP-Protokoll-ID (0x003d)			2		2	2	2	2	2		2		2
MLP-Sequenznummer			4		4	4	4	4	4		4		4
PPP-Protokoll-ID (nur 1. Frag)			2		2	2	2	2	2		2		2
Nutzlast (Layer 3+)			0		0	0	0	0	0		0		0
ATM-Anpassungsschicht (AAL)5			0		8	8	0	0	8		8		0
Frame Check Sequence (FCS)			2		0	0	2	2	0		0		2
Gesamter Overhead (Byte)			15		18	20	17	15	20		20		15

Tabelle 3 - Datenverbindungsüberhang in Byte für ein VoIP-Paket über eine FRF.8-Verbindung.

FRF.8-Modus	Transparent				Übersetzung				Frame-Relay zu Frame-Relay
Richtung des Datenverkehrs	Frame-Relay an ATM		ATM-Frame-Relay		Frame-Relay an ATM		ATM-Frame-Relay
Rahmenrelais oder ATM-Schenkel aus PVC	Frame Relay	Geldautomat	Geldautomat	Frame Relay	Frame Relay	Geldautomat	Geldautomat	Frame Relay
Frame-Markierung (0x7e)	1	0	0	1	1	0	0	1	1
Frame-Relay-Header	2	0	0	2	2	0	0	2	2
LLC DSAP/SSAP (0xfefe)	0	0	2	2	0	2	2	0	0
LLC Control (0x03)	1	1	1	1	1	1	1	1	1
NLPID (0xcf für PPP)	1	1	1	1	1	1	1	1	1
PPP-ID	2	2	2	2	2	2	2	2	0
Nutzlast (IP + User Datagram Protocol (UDP) + RTP + Sprache)	0	0	0	0	0	0	0	0	0
AAL5	0	8	8	0	0	8	8	0	0
FCS	2	0	0	2	2	0	0	2	2
Gesamter Overhead (Byte)	9	12	14	11	9	14	14	9	7

Beachten Sie beim Überprüfen der obigen Tabellen Folgendes:

• Pakete, die kleiner als die angegebene Fragmentierungsgröße sind, werden nur in einen PPP-Header und nicht in einen MLPPP-Header gekapselt. Ebenso werden Pakete, die größer als die angegebene Fragmentierungsgröße sind, in einen PPP-Header und einen MLPPP-Header gekapselt. So haben VoIP-Pakete bis zu acht Byte weniger Overhead.

• Nur das erste Multilink PPP (MLP)-Fragment enthält ein PPP-Protokoll-ID-Feld. Das erste Fragment hat also zwei zusätzliche Bytes Overhead.

• Im transparenten Modus werden die Kapselungsheader unverändert durch das IWF-Gerät geleitet. Der Overhead variiert also in jeder Richtung und auf jedem Segment. Ein MLPPPoA-Header beginnt mit einem NLPID-Header in Kurzform von 0xFEFE. Im transparenten Modus wird dieser Header vom IWF-Gerät unverändert vom ATM-Segment an das Frame-Relay-Segment übergeben. In Richtung Frame-Relay zu ATM ist ein solcher Header jedoch in keinem Segment im transparenten Modus vorhanden.

• Im Übersetzungsmodus ändert das IWF-Gerät die Kapselungskopfzeilen. Der Overhead ist also in beiden Richtungen auf jedem Segment gleich. Insbesondere kapselt der ATM-Endpunkt das Paket in Richtung ATM-Frame-Relay in einen MLPPPoA-Header. Das IWF-Gerät entfernt den NLPID-Header, bevor der verbleibende Frame an das Frame-Relay-Segment übergeben wird. In Richtung Frame Relay to ATM (Frame-Relay zu ATM) verändert das IWF-Gerät den Frame erneut und stellt einen NLPID-Header vor, bevor der segmentierte Frame an den ATM-Endpunkt übergeben wird.

• Achten Sie beim Entwerfen von FRF-Verbindungen mit MLP darauf, die richtige Anzahl von Overhead-Bytes für die Datenverbindung zu berücksichtigen. Dieser Overhead beeinflusst die Menge an Bandbreite, die von jedem VoIP-Anruf beansprucht wird. Es spielt auch eine Rolle bei der Bestimmung der optimalen MLP-Fragmentgröße. Die Optimierung der Fragmentgröße zur Anpassung an eine ganzzahlige Anzahl von ATM-Zellen ist von entscheidender Bedeutung, insbesondere bei PVCs mit langsamer Geschwindigkeit, bei denen eine erhebliche Menge an Bandbreite verschwendet werden kann, wenn die letzte Zelle auf ein gerades Vielfaches von 48 Byte aufgefüllt wird.

Der Übersichtlichkeit halber gehen wir nun durch die Schritte des Paketkapselungsprozesses, wenn ein Paket mit dem transparenten Modus in Frame-Relay an ATM-Richtung übermittelt wird:

1. Der Frame-Relay-Endpunkt kapselt das Paket in einen MLPPPoFR-Header.

2. Das IWF-Gerät entfernt den zwei Byte großen Frame-Relay-Header mit dem Data Link Connection Identifier (DLCI). Anschließend leitet er das verbleibende Paket an die ATM-Schnittstelle des IWF weiter, die das Paket in Zellen segmentiert und über das ATM-Segment weiterleitet.

3. Der ATM-Endpunkt überprüft den Header des empfangenen Pakets. Wenn die ersten beiden Bytes des empfangenen Pakets 0x03CF sind, betrachtet der ATM-Endpunkt das Paket als gültiges MLPPPoA-Paket.

4. Die MLPPP-Funktionen am ATM-Endpunkt führen die weitere Verarbeitung durch.

Sehen Sie sich den Paketkapselungsprozess an, wenn ein Paket im ATM in die Frame-Relay-Richtung im transparenten Modus übertragen wird:

1. Der ATM-Endpunkt kapselt das Paket in einen MLPPPoA-Header. Anschließend werden die Pakete in Zellen segmentiert und aus dem ATM-Segment weitergeleitet.

2. Das IWF empfängt das Paket, leitet es an seine Frame-Relay-Schnittstelle weiter und stellt einen Frame-Relay-Header mit zwei Byte voran.

3. Der Frame-Relay-Endpunkt überprüft den Header des empfangenen Pakets. Wenn die ersten vier Bytes nach dem Zwei-Byte-Frame-Relay-Header 0xfefe03cf sind, behandelt IWF das Paket als legales MLPPPoFR-Paket.

4. Die MLPPP-Funktionen am Frame-Relay-Endpunkt führen die weitere Verarbeitung durch.

Die folgenden Abbildungen zeigen das Format von MLPPPoA- und MLPPPoFR-Paketen.

Abbildung 6: MLPPPoA-Overhead. Nur das erste Fragment trägt einen PPP-Header.

Abbildung 7: MLPPPoFR-Overhead. Nur das erste Fragment trägt einen PPP-Header.

VoIP-Bandbreitenanforderungen

Bei der Bereitstellung von Bandbreite für VoIP muss der Overhead der Datenverbindung in die Bandbreitenberechnungen einbezogen werden. Tabelle 4 zeigt die Bandbreitenanforderungen für VoIP pro Anruf in Abhängigkeit vom Codec und der Verwendung des komprimierten Real-time Transport Protocol (RTP). Bei den Berechnungen in Tabelle 4 wird von einem Best-Case-Szenario für die RTP-Header-Komprimierung (cRTP) ausgegangen, d. h. es werden keine UDP-Prüfsumme oder Übertragungsfehler ermittelt. Header werden dann konsistent von 40 Byte auf zwei Byte komprimiert.

Tabelle 4: Bandbreitenanforderungen pro VoIP-Anruf (Kbit/s).

FRF.8-Modus	Transparent				Übersetzung				Frame-Relay zu Frame-Relay
Richtung des Datenverkehrs	Frame-Relay an ATM		ATM-Frame-Relay		Frame-Relay an ATM		ATM-Frame-Relay
Rahmenrelais oder ATM-Schenkel aus PVC	Frame Relay	Geldautomat	Geldautomat	Frame Relay	Frame Relay	Geldautomat	Geldautomat	Frame Relay
G729 - 20 ms Samples - kein cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - 20 ms Beispiele - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - 30 ms Samples - kein cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - 30 ms Beispiele - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - 20 ms Samples - kein cRTP	83.6	106.0	106.0	84.4	83.6	106.0	106.0	83.6	82.8
G711 - 20 ms Beispiele - cRTP	68.4	84.8	84.8	69.2	68.4	84.8	84.8	68.4	67.6
G711 - 30 ms Samples - kein cRTP	76.3	97.9	97.9	76.8	76.3	97.9	97.9	76.3	75.8
G711 - 30 ms-Beispiele - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Da der Overhead auf jedem Abschnitt des PVC unterschiedlich hoch ist, empfehlen wir die Planung für den schlimmsten Fall. Nehmen wir als Beispiel einen G.279-Anruf mit 20 ms Sampling und cRTP über eine transparente PVC. Auf der Frame-Relay-Strecke wird eine Bandbreite von 12,4 Kbit/s in die eine Richtung und 13,2 Kbit/s in die andere Richtung benötigt. Aus diesem Grund empfehlen wir eine Bereitstellung mit 3,2 Kbit/s pro Anruf.

Zu Vergleichszwecken zeigt die Tabelle auch die VoIP-Bandbreitenanforderungen für ein End-to-End-Frame-Relay-PVC, das mit FRF.12-Fragmentierung konfiguriert ist. Wie in der Tabelle angegeben, benötigt PPP zwischen 0,5 Kbit/s und 0,8 Kbit/s zusätzliche Bandbreite pro Anruf, um die zusätzlichen Bytes des Kapselungsheaders zu unterstützen. Daher empfehlen wir die Verwendung von FRF.12 mit End-to-End-Frame-Relay-VCs.

Für komprimiertes RTP (cRTP) über ATM ist die Cisco IOS® Software, Version 12.2(2)T, erforderlich. Wenn cRTP mit MLPoFR und MLPoATM aktiviert ist, wird die TCP/IP-Header-Komprimierung automatisch aktiviert und kann nicht deaktiviert werden. Diese Einschränkung ergibt sich aus RFC 2509, der keine PPP-Aushandlung der RTP-Header-Komprimierung zulässt, ohne auch die TCP-Header-Komprimierung auszuhandeln.

Übersetzung und transparente Unterstützung auf Cisco Geräten

Ursprünglich erforderte LFI, dass IWF-Geräte den transparenten Modus verwenden. In letzter Zeit hat das Frame Relay Forum FRF.8.1 eingeführt, um den Übersetzungsmodus zu unterstützen. Cisco hat die Unterstützung für FRF.8.1 und den Übersetzungsmodus in den folgenden Versionen der Cisco IOS Software eingeführt:

• 12.0(18)W5(23) für die Serie LS1010 und Catalyst 8500 mit 4CE1 FR-PAM (CSCdt39211)

• 12.2(3)T und 12.2(2) auf Cisco IOS-Routern mit ATM-Schnittstellen, z. B. PA-A3 (CSCdt70724)

Einige Service Provider unterstützen noch keine PPP-Übersetzung auf ihren FRF.8-Geräten. In jedem Fall muss der Anbieter seine PVCs für den transparenten Modus konfigurieren.

Hardware und Software

Für diese Konfiguration wird folgende Hardware und Software verwendet:

• ATM-Endgerät - PA-A3-OC3 auf einem Router der Serie 7200 mit Cisco IOS Software, Version 12.2(8)T. (Hinweis: LFI wird nur auf PA-A3-OC3 und PA-A3-T3 unterstützt.) Es wird von den IMA- und ATM OC-12-Port-Adaptern nicht unterstützt.)

• IWF-Gerät - LS1010 mit kanalisiertem T3-Port-Adaptermodul und Cisco IOS Software, Version 12.1(8)EY.

• Frame-Relay-Endpunkt - PA-MC-T3 in einem Router der Serie 7200 mit Cisco IOS Software, Version 12.2(8)T.

Topologiediagramm

Konfigurationen

Dieser Abschnitt zeigt, wie die LFI-Funktion über eine FRF.8-Verbindung im transparenten Modus konfiguriert wird. Es wird eine virtuelle Vorlage auf den beiden Router-Endpunkten verwendet, von der die virtuelle Zugriffsschnittstelle des MLP-Pakets geklont wird. LFI unterstützt Dialer-Schnittstellen und virtuelle Vorlagen zur Angabe der Protokollschichtparameter von MLPPP. Mit Version 12.2(8)T der Cisco IOS Software kann die Anzahl der eindeutigen virtuellen Vorlagen, die pro Router konfiguriert werden können, auf 200 erhöht werden. Frühere Versionen unterstützten nur bis zu 25 virtuelle Vorlagen pro Router. Diese Einschränkung kann bei einem ATM-Distribution-Router ein Skalierungsproblem darstellen, wenn jeder PVC über eine eindeutige IP-Adresse verfügen muss. Verwenden Sie IP als Umgehungslösung ohne Nummerierung, oder ersetzen Sie virtuelle Vorlagen durch Dialer-Schnittstellen auf nummerierten Links.

Mit der Cisco IOS-Version 12.1(5)T wurde die Unterstützung von LFI über nur einen Mitgliedslink pro MLPPP-Paket eingeführt. Bei dieser Konfiguration wird daher an jedem Endpunkt nur eine VC verwendet. Für eine bevorstehende Version von Cisco IOS ist die Unterstützung mehrerer VCs pro Paket geplant.

Frame-Relay-Endpunkt

Für den Channelized T3-Port-Adapter müssen Sie eine Channel-Gruppe erstellen und die Timeslots (Zeitschlitze) angeben. Standardmäßig sind keine Schnittstellen vorhanden. FRAMEside#show ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 172.16.142.231 YES NVRAM up up Loopback1 191.1.1.1 YES NVRAM up up Verwenden Sie den Befehl show diag, um den installierten Port-Adapter zu ermitteln. In diesem Beispiel befindet sich der T3 PA in Steckplatz 3. Aktuelle Versionen von Cisco IOS zeigen jetzt die FRU-Teilenummer (Field Replaceable) an, die bei einem Hardware-Ausfall bestellt werden kann. FRAMEside#show diag 3 Slot 3: CT3 single wide Port adapter, 1 port Port adapter is analyzed Port adapter insertion time 13:16:35 ago EEPROM contents at hardware discovery: Hardware revision 1.0 Board revision A0 Serial number 23414844 Part number 73-3037-01 FRU Part Number: PA-MC-T3= (SW) Test history 0x0 RMA number 00-00-00 EEPROM format version 1 EEPROM contents (hex): 0x20: 01 A0 01 00 01 65 48 3C 49 0B DD 01 00 00 00 00 0x30: 50 00 00 00 00 10 30 00 FF FF FF FF FF FF FF FF Wenn Sie den Befehl show controller t3 ausführen, werden Warnungen und Statistiken auf physischer Ebene angezeigt. FRAMEside#show controller t3 3/0 T3 3/0 is up. Hardware is CT3 single wide port adapter CT3 H/W Version : 1.0.1, CT3 ROM Version : 1.1, CT3 F/W Version : 2.4.0 FREEDM version: 1, reset 0 resurrect 0 Applique type is Channelized T3 No alarms detected. FEAC code received: No code is being received Framing is M23, Line Code is B3ZS, Clock Source is Internal Rx throttle total 0, equipment customer loopback Data in current interval (75 seconds elapsed): 2 Line Code Violations, 1 P-bit Coding Violation 0 C-bit Coding Violation, 1 P-bit Err Secs 0 P-bit Severely Err Secs, 0 Severely Err Framing Secs 0 Unavailable Secs, 1 Line Errored Secs 0 C-bit Errored Secs, 0 C-bit Severely Errored Secs [output omitted] Wählen Sie im Konfigurationsmodus für den T3-Controller eine T1 aus, erstellen Sie eine Kanalgruppe, und weisen Sie der Gruppe Zeitschlitze zu. FRAMEside(config)#controller t3 3/0 b13-8-7204(config-controller)#? Controller configuration commands: cablelength cable length in feet (0-450) clock Specify the clock source for a T3 link default Set a command to its defaults description Controller specific description equipment Specify the equipment type for loopback mode exit Exit from controller configuration mode framing Specify the type of Framing on a T3 link help Description of the interactive help system idle Specify the idle pattern for all channels on a T3 interface loopback Put the entire T3 line into loopback mdl Maintenance Data Link Configuration no Negate a command or set its defaults shutdown Shut down a DS3 link (send DS3 Idle) t1 Create a T1 channel b13-8-7204(config-controller)#t1 ? <1-28> T1 Channel number <1-28> b13-8-7204(config-controller)#t1 1 channel-group ? <0-23> Channel group number b13-8-7204(config-controller)#t1 1 channel-group 1 ? timeslots List of timeslots in the channel group b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots ? <1-24> List of timeslots which comprise the channel b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots 1-2 b13-8-7204(config-controller)# 13:22:28: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to down 13:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down 13:22:46: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to up 13:22:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to up 13:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down Hinweis: Wenn die angeschlossene Remote-Schnittstelle nicht auf ähnliche Weise konfiguriert ist, wird die Verbindungsschicht der neuen kanalisierten Schnittstelle aktiviert, das Leitungsprotokoll bleibt jedoch inaktiv. Die serielle Schnittstelle 3/0/1:1 identifiziert die neue kanalisierte Schnittstelle. Konfigurieren Sie die Schnittstelle für die Frame Relay-Kapselung, und aktivieren Sie dann Frame Relay Traffic Shaping (FRTS) auf der Hauptschnittstelle. FRAMEside(config)#int serial 3/0/1:1 FRAMEside(config-if)#encapsulation frame-relay ietf FRAMEside(config-if)#frame-relay traffic-shaping !--- FRTS must be enabled for MLPoFR. Konfigurieren Sie eine Frame Relay-Zuordnungsklasse, um Traffic-Shaping-Parameter auf die Frame-Relay-VC anzuwenden (die unten erstellt wird). FRAMEside(config)#map-class frame-relay mlp FRAMEside(config-map-class)#frame-relay cir ? <1-45000000> Applied to both Incoming/Outgoing CIR, Bits per second in Incoming CIR out Outgoing CIR FRAMEside(config-map-class)#frame-relay cir 128000 FRAMEside(config-map-class)#frame-relay mincir 128000 FRAMEside(config-map-class)#frame-relay bc ? <300-16000000> Applied to both Incoming/Outgoing Bc, Bits in Incoming Bc out Outgoing Bc <cr> FRAMEside(config-map-class)#frame-relay bc 1280 !--- Configure a burst committed (Bc) value of 1/100th of the CIR or 1280 bps. FRAMEside(config-map-class)#frame-relay be 0 !--- Configure an excess burst (Be) value of 0. FRAMeside(config-map-class)#no frame-relay adaptive-shaping Erstellen einer QoS-Servicerichtlinie Verwenden Sie dieselben Parameter wie auf der ATM-Seite. Nachstehend finden Sie Referenzmaterial. FRAMEside#show policy-map example Policy Map example Class voice Weighted Fair Queueing Strict Priority Bandwidth 110 (kbps) Burst 2750 (Bytes) Class class-default Weighted Fair Queueing Flow based Fair Queueing Bandwidth 0 (kbps) Max Threshold 64 (packets) Erstellen Sie eine Schnittstelle für virtuelle Vorlagen, und wenden Sie MLPPP-Parameter an. Wenden Sie außerdem die QoS-Servicerichtlinie auf die VC an. FRAMEside(config)#interface Virtual-Template1 FRAMEside(config-if)#ip address 1.1.1.2 255.255.255.0 FRAMEside(config-if)#service-policy output example FRAMEside(config-if)#ppp multilink FRAMEside(config-if)#ppp multilink fragment-delay 10 FRAMEside(config-if)#ppp multilink interleave FRAMEside(config-if)#end Erstellen Sie eine Subschnittstelle, und weisen Sie die DLCI-Nummer (Frame Relay Data Link Connection Identifier) zu. Wenden Sie dann die PPP-Kapselung, die virtuelle Vorlage und die Map-Klasse an. FRAMEside(config)#int serial 3/0/1:1.1 point FRAMEside(config-subif)#frame-relay interface-dlci ? <16-1007> Define a switched or locally terminated DLCI FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp ? Virtual-Template Virtual Template interface FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp Virtual-Template 1 FRAMEside(config-fr-dlci)#class mlp Verwenden Sie den Befehl show frame-relay pvc, um die Virtual-Template- und Map-Class-Parameter auf der VC zu bestätigen. FRAMEside#show frame-relay pvc 20 PVC Statistics for interface Serial3/0/1:1 (Frame Relay DTE) DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial3/0/1:1.1 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:03:24, last time pvc status changed 00:03:24 Bound to Virtual-Access1 (down, cloned from Virtual-Template1) cir 128000 bc 1280 be 0 byte limit 160 interval 10 mincir 128000 byte increment 160 Adaptive Shaping none pkts 0 bytes 0 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued Verwenden Sie die Option show controller serial 3/0/1:1, um sicherzustellen, dass sich die Frame-Relay-Verbindung im Status "up" befindet und keine Alarme auf physischer Ebene vorliegen. Jeder kanalisierten Schnittstelle wird eine "VC"-Nummer zugewiesen. Im folgenden Ausgang wird der Kanalgruppe 1 (3/0/1:1) eine VC-Nummer von 0 zugewiesen. FRAMEside#show controller serial 3/0/1:1 CT3 SW Controller 3/0 ROM ver 0x10001, h/w ver 1.0.1, f/w ver 2.4.0, FREEDM rev 1 !--- FREEDM is the HDLC controller on the channelized T3 port adapter. It extracts data from the 24 timeslots of a T1, validates the CRC, and checks for any other frame errors. T3 linestate is Up, T1 linestate 0x00000002, num_active_idb 1 Buffer pool size 640, particle size 512, cache size 640, cache end 128/127 Rx desctable 0xF1A5A20, shadow 0x628C6AFC, size 512, spin 128 !--- When it initializes, the interface driver builds a control structure known as the receive ring. The receive ring consists of a list of 512 packet buffer descriptors. As packets arrive, FREEDM DMAs the data into the buffer to which a descriptor points. rx queue 0xF1B8000, cache 0xF1B8000, fq base 0xF1B8800 rdq base 0xF1B8000, host_rxrdqr 0xF1B8004, host_rxfqw 0xF1B8804 Tx desctable 0xF1A7A60, shadow 0x628B6AD0, size 4096, spin 256 !--- When it initializes, the interface driver also creates the transmit queue or transmit ring. In the case of the channelized T3 PA, the driver creates a queue of 4096 entries and sets all fields in the descriptors to NULL or empty. tx queue 0xF1C0000, cache 0xF1C0000 host_txrdqw 1802, fq base 0xF1C4000, host_txfqr 0xF1C5C20 dynamic txlimit threshold 4096 TPD cache 0x628C7A54, size 4096, cache end 4096/4094, underrun 0 RPD cache 0x628C7328, size 448, cache end 0 Freedm fifo 0x628AA7B0, head ptr 0x628AA7C8, tail ptr 0x628AB7A8, reset 0 PCI bus 6, PCI shared memory block 0xF1A454C, PLX mailbox addr 0x3D820040 FREEDM devbase 0x3D800000, PLX devbase 0x3D820000 Rx overruns 0, Tx underruns 0, tx rdq count 0 !--- The "tx rdq count" indicates the number of outstanding transmit packets in FREEDM's "transmit ready" queue. This queue holds a packet before it reaches the transmit ring. Tx bad vc 0 FREEDM err: cas 0, hdl 0, hdl_blk 0, ind_prov 0, tavail 0, tmac busy 0, rmac b usy 0 rxrdq_wt 0x2, rxrdq_rd 0x1, rxsfq_wt 0x201, rxsfq_rd 0x206 VC 0 (1:1) is enabled, T1 1 is enabled/Up, rx throttle 0 Interface Serial3/0/1:1 is up (idb status 0x84208080) xmitdelay 0, max pak size 1608, maxmtu 1500, max buf size 1524 started 8, throttled 0, unthrottled 0, in_throttle FALSE VC config: map 0xC0000000, timeslots 2, subrate 0xFF, crc size 2, non-inverted data freedm fifo num 3, start 0x628AA7B0, end 0x628AA7C0, configured = TRUE Rx pkts 0, bytes 0, runt 0, giant 0, drops 0 crc 0, frame 0, overrun 0, abort 1, no buf 0 Tx pkts 194313, bytes 2549490, underrun 0, drops 0, tpd udr 0 tx enqueued 0, tx count 0/36/0, no buf 0 tx limited = FALSE !--- The "tx count x/y/z" counter includes the following information: !--- "x" = Number of transmit ring entries in use. !--- "y" = Maximum number of packets allowed on the transmit queue. !--- "z" = Number of times that the transmit limit has been exceeded.

LS1010-Konfiguration

Verwenden Sie den Befehl show hardware, um zu überprüfen, ob Ihr LS1010 mit einem Channelized Frame Relay Port Adapter Module (PAM) ausgestattet ist. LS1010#show hardware LS1010 named LS1010, Date: 07:36:40 UTC Mon May 13 2002 Feature Card's FPGA Download Version: 11 Slot Ctrlr-Type Part No. Rev Ser No Mfg Date RMA No. Hw Vrs Tst EEP ---- ------------ ---------- -- -------- --------- -------- ------- --- --- 0/0 155MM PAM 73-1496-03 A0 02829507 May 07 96 00-00-00 3.1 0 2 1/0 1CT3 FR-PAM 73-2972-03 A0 12344261 May 17 99 00-00-00 3.0 0 2 2/0 ATM Swi/Proc 73-1402-03 B0 03824638 Sep 14 96 00-00-00 3.1 0 2 2/1 FeatureCard1 73-1405-03 B0 03824581 Sep 14 96 00-00-00 3.2 0 2 Mit dem Befehl show ip int brief können Sie die Controller-Schnittstelle identifizieren. LS1010#show ip int brief Interface IP-Address OK? Method Status Protocol ATM0/0/0 unassigned YES unset up up ATM0/0/1 unassigned YES unset down down ATM0/0/2 unassigned YES unset down down ATM0/0/3 unassigned YES unset down down ATM-P1/0/0 unassigned YES unset up up T3 1/0/0 unassigned YES unset up up Erstellen Sie eine Channelized-Schnittstelle, und wählen Sie die gleichen Timeslots wie der serielle Port-Adapter aus. LS1010(config)#controller t3 1/0/0 LS1010(config-controller)#channel-group 1 t1 ? <1-28> T1 line number <1-28> LS1010(config-controller)#channel-group 1 t1 1 timeslots ? <1-24> List of timeslots which comprise the channel LS1010(config-controller)#channel-group 1 t1 1 timeslot 1-2 LS1010(config-controller)# 2w1d: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up 2w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up Konfigurieren Sie die Frame Relay-Kapselung auf der neuen seriellen Schnittstelle. Ändern Sie außerdem den LMI-Typ (Local Management Interface) von NNI in DCE. LS1010(config)#int serial 1/0/0:1 LS1010(config-if)#encap frame ? ietf Use RFC1490 encapsulation LS1010(config-if)#encap frame ietf LS1010(config-if)#frame-relay intf-type dce Verwenden Sie den Befehl show interface serial, um die Frame Relay-Kapselung zu bestätigen. LS1010#show int serial 1/0/0:1 Serial1/0/0:1 is up, line protocol is up Hardware is FRPAM-SERIAL MTU 4096 bytes, BW 128 Kbit, DLY 0 usec, reliability 139/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) LMI enq sent 32, LMI stat recvd 0, LMI upd recvd 0 LMI enq recvd 40, LMI stat sent 40, LMI upd sent 0, DCE LMI up LMI DLCI 1023 LMI type is CISCO frame relay DCE !--- By default, the serial PAM and the serial PA use LMI type Cisco. The serial PAM should show DCE LMI status of "up", and the serial PA should show DTE LMI status of "up". Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input 00:00:03, output 00:00:05, output hang never Last clearing of "show interface" counters 00:06:40 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 44 packets input, 667 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 71 packets output, 923 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslots(s) Used: 1-2 on T1 1 Frames Received with: DE set: 0, FECN set :0, BECN set: 0 Frames Tagged : DE: 0, FECN: 0 BECN: 0 Frames Discarded Due to Alignment Error: 0 Frames Discarded Due to Illegal Length: 0 Frames Received with unknown DLCI: 5 Frames with illegal Header : 0 Transmit Frames with FECN set :0, BECN Set :0 Transmit Frames Tagged FECN : 0 BECN : 0 Transmit Frames Discarded due to No buffers : 0 Default Upc Action : tag-drop Default Bc (in Bits) : 32768 LS1010#show frame lmi LMI Statistics for interface Serial1/0/0:1 (Frame Relay DCE) LMI TYPE = CISCO< Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 Num Status Enq. Rcvd 120 Num Status msgs Sent 120 Num Update Status Sent 0 Num St Enq. Timeouts 0 Bevor Sie den PVC konfigurieren, stellen Sie sicher, dass die ATM-Schnittstelle aktiv ist. LS1010#show int atm 0/0/0 ATM0/0/0 is up, line protocol is up Hardware is oc3suni MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 2 packets/sec 253672 packets input, 13444616 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2601118 packets output, 137859254 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Zusätzlich zu den beiden physischen Schnittstellen nutzt der LS1010 eine logische Schnittstelle, um die ATM-Seite und die Frame-Relay-Seite zu verbinden. Die logische Schnittstelle wird auf der ATM-Pseudoschnittstelle mit "atm-p1" bezeichnet. LS1010#show int atm-p1/0/0 ATM-P1/0/0 is up, line protocol is up Hardware is ATM-PSEUDO MTU 4470 bytes, sub MTU 4470, BW 45000 Kbit, DLY 0 usec, reliability 0/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Keepalive not supported Encapsulation(s): 2000 maximum active VCs, 0 current VCCs VC idle disconnect time: 300 seconds Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Konfigurieren Sie im Konfigurationsmodus für die serielle Schnittstelle den Interworking-PVC. interface Serial1/0/0:1 no ip address encapsulation frame-relay IETF no arp frame-relay frame-relay intf-type dce frame-relay pvc 20 service transparent interface ATM0/0/0 1 100 Bestätigen Sie Ihre Konfiguration mit dem Befehl show vc interface atm. LS1010#show vc int atm 0/0/0 Interface Conn-Id Type X-Interface X-Conn-Id Encap Status ATM0/0/0 0/5 PVC ATM0 0/39 QSAAL UP ATM0/0/0 0/16 PVC ATM0 0/35 ILMI UP ATM0/0/0 1/100 PVC Serial1/0/0:1 20 UP

ATM-Endpunkt

Stellen Sie sicher, dass Sie einen erweiterten ATM PA oder PA-A3 verwenden. Verwenden Sie den Befehl show interface atm zur Bestätigung. ATMside#show int atm 1/0/0 ATM1/0/0 is up, line protocol is up Hardware is cyBus ENHANCED ATM PA MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5 4095 maximum active VCs, 0 current VCCs [output omitted] Konfigurieren Sie die ATM-Layer-Parameter des Permanent Virtual Circuit (PVC). In dieser Konfiguration wird eine Punkt-zu-Punkt-Subschnittstelle mit einer konstanten Zellrate (Sustained Cell Rate, SCR) von 150 Kbit/s verwendet. Dieser Wert wurde als um etwa 15 % höher als die CIR von 128 Kbit/s des Frame-Relay-Endpunkts ausgewählt. Die zusätzlichen 15 % tragen dazu bei, dass die VC eine dem tatsächlichen Benutzerdatenverkehr auf beiden Seiten der Verbindung entsprechende Bandbreite bereitstellt und gleichzeitig den zusätzlichen Overhead auf der ATM-Seite aufnimmt. (Siehe auch Konfigurieren von Traffic Shaping auf Frame-Relay-to-ATM-Service-Interworking (FRF.8)-PVCs.) ATMside(config)#int atm 1/0/0.1 point ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#vbr-nrt 300 150 ? <1-65535> Maximum Burst Size(MBS) in Cells <cr> ATMside(config-if-atm-vc)#vbr-nrt 300 150 ATMside(config-if-atm-vc)#end ATMside(config-if-atm-vc)#tx-ring-limit 4 !--- Tune down the transmit ring to push most queueing to the layer-3 queues, where our service policy will apply. Vergewissern Sie sich, dass Ihre VC in der VC-Tabelle erscheint. Führen Sie den Befehl show atm vc aus. Beachten Sie, dass der Router eine standardmäßige maximale Burst-Größe (MBS) von 94 zuweist, da kein expliziter Wert eingegeben wurde. ATMside#show atm vc VCD / Peak Avg/Min Burst Interface Name VPI VCI Type Encaps SC kbps kbps Cells Sts 1/0/0.1 1 1 100 PVC SNAP VBR 300 150 94 UP Erstellen einer QoS-Servicerichtlinie In der unten gezeigten Richtlinie wurden vier Klassen erstellt, einschließlich der vom Router erstellten Standardklasse. Erstellen Sie eine Class-Map für die VoIP-Pakete. ATMside(config)#class-map voice ATMside(config-cmap)#match ip rtp ? <2000-65535> Lower bound of UDP destination port ATMside(config-cmap)#match ip rtp 16384 ? <0-16383> Range of UDP ports ATMside(config-cmap)#match ip rtp 16384 16383 !--- Cisco IOS H.323 devices use this UDP port range to transmit VoIP packets. Erstellen Sie eine Klassenzuordnung für die Sprachsignalisierungspakete. In diesem Beispiel wird H.323 Fast Connect verwendet. (Siehe auch den Abschnitt "LLQ Configuration Guidelines" unter VoIP over PPP Links with Quality of Service (LLQ/IP RTP Priority, LFI, cRTP).) class-map voice-signaling match access-group 103 ! access-list 103 permit tcp any eq 1720 any access-list 103 permit tcp any any eq 1720 Erstellen Sie eine benannte Richtlinienzuordnung, und weisen Sie jeder Klasse QoS-Aktionen zu. In diesem Beispiel wird den VoIP-Benutzerpaketen eine Prioritätswarteschlange mit dem Befehl priority und eine garantierte Mindestbandbreite für Anrufsignalisierungspakete mit dem Befehl bandwidth zugewiesen. Der gesamte andere Datenverkehr wird an die Standardklasse weitergeleitet, die den Datenverkehr in IP-Layer-Flows aufteilt und eine faire Warteschlangenzuweisung zwischen den Flows ermöglicht. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue Bestätigen Sie Ihre Konfiguration. ATMside#show policy-map example Policy Map example Class call-control bandwidth percent 10 Class voice priority 110 Class class-default fair-queue Erstellen Sie eine virtuelle Vorlage, und wenden Sie die QoS-Servicerichtlinie darauf an. interface Virtual-Template1 bandwidth 150 ip address 1.1.1.1 255.255.255.0 service-policy output example ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave !--- You select a fragment size indirectly by specifying the maximum tolerable serialization delay. The recommended maximum per-hop serialization delay for voice environments is 10 milliseconds (ms). LFI also requires ppp multilink interleave. Wenden Sie die virtuelle Vorlage und die Multilink-PPP-Kapselung auf die ATM-PVC an. ATMside(config)#int atm 1/0/0.1 ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#protocol ppp ? Virtual-Template Virtual Template interface dialer pvc is part of dialer profile ATMside(config-if-atm-vc)#protocol ppp Virtual-Template 1 Bestätigen Sie Ihre Einstellungen auf der ATM-PVC. ATMside#show run int atm 1/0/0.1 Building configuration... Current configuration : 127 bytes ! interface ATM1/0/0.1 point-to-point pvc 1/100 vbr-nrt 300 150 tx-ring-limit 4 protocol ppp Virtual-Template1 ! end Der Router erstellt automatisch eine Schnittstelle für virtuellen Zugriff. Wenn auf dem Frame Relay-Endpunkt kein MLPPP konfiguriert ist, lautet der Status der Virtual-Access-Schnittstelle "up/down". ATMside#show int virtual-access 1 Virtual-Access1 is up, line protocol is down Hardware is Virtual Access interface Internet address is 1.1.1.1/24 MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Listen, multilink Closed Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 Cloned from virtual-template: 1

Befehle anzeigen und debuggen

ATM-Endpunkt

Verwenden Sie die folgenden Befehle am ATM-Endpunkt, um sicherzustellen, dass LFI richtig funktioniert. Bevor Sie Debug-Befehle ausgeben, lesen Sie bitte Wichtige Informationen zu Debug-Befehlen.

• show ppp multilink - LFI verwendet zwei Virtual-Access-Schnittstellen - eine für PPP und eine für das MLP-Paket. Verwenden Sie den Befehl show ppp multilink, um zwischen den beiden Verbindungen zu unterscheiden.

  ATMside#show ppp multilink 
  Virtual-Access2, bundle name is FRAMEside 
  
  !--- The bundle interface is assigned to VA 2.
  
    Bundle up for 01:11:55 
    Bundle is Distributed 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x1E received sequence, 0xA sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:11:55, last rcvd seq 00001D  187 weight 
  
  !--- The PPP interface is assigned to VA 1.
  
  

• show interface virtual-access 1: Bestätigen Sie, dass die Schnittstelle für virtuellen Zugriff aktiv/aktiv ist, und erhöhen Sie die Zähler für das Eingangs- und das Ausgangspaket.

  ATMside#show int virtual-access 1 
  Virtual-Access1 is up, line protocol is up 
    Hardware is Virtual Access interface 
    Internet address is 1.1.1.1/24 
    MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, 
       reliability 255/255, txload 1/255, rxload 1/255 
    Encapsulation PPP, loopback not set 
    DTR is pulsed for 5 seconds on reset 
    LCP Open, multilink Open 
    Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 
    Cloned from virtual-template: 1 
    Last input 01:11:30, output never, output hang never 
    Last clearing of "show interface" counters 2w1d 
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
    Queueing strategy: fifo 
    Output queue :0/40 (size/max) 
    5 minute input rate 0 bits/sec, 0 packets/sec 
    5 minute output rate 0 bits/sec, 0 packets/sec 
       878 packets input, 13094 bytes, 0 no buffer 
       Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
       0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
       255073 packets output, 6624300 bytes, 0 underruns 
       0 output errors, 0 collisions, 0 interface resets 
       0 output buffer failures, 0 output buffers swapped out 
       0 carrier transitions 
  

• show policy-map int virtual-access 2 - Vergewissern Sie sich, dass die QoS-Servicerichtlinie an die MLPP-Paketschnittstelle gebunden ist.

  ATMside#show policy-map int virtual-access 2 
   Virtual-Access2 
  
    Service-policy output: example 
  
      queue stats for all priority classes: 
        queue size 0, queue limit 27 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
  
      Class-map: call-control (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: access-group 103 
        queue size 0, queue limit 3 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Bandwidth: 10%, kbps 15 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 
  
      Class-map: class-default (match-any) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        queue size 0, queue limit 5 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Fair-queue: per-flow queue limit 2
  

• debug ppp packet and debug atm packet - Verwenden Sie diese Befehle, wenn alle Schnittstellen aktiv/aktiv sind, Sie jedoch nicht in der Lage sind, einen End-to-End-Ping zu senden. Darüber hinaus können Sie diese Befehle verwenden, um PPP-Keepalives zu erfassen, wie unten dargestellt.

  2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 
  2w1d: 
  2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 
  
  !--- This side received an Echo Request and responded with an outbound Echo Reply.
  
  2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 
  2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 
  2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up
  
  !--- This side transmitted an Echo Request and received an inbound Echo Reply.
  
  

Frame-Relay-Endpunkt

Verwenden Sie die folgenden Befehle am Frame-Relay-Endpunkt, um die ordnungsgemäße Funktion von LFI zu überprüfen. Bevor Sie Debug-Befehle ausgeben, lesen Sie bitte Wichtige Informationen zu Debug-Befehlen.

• show ppp multilink - LFI verwendet zwei Virtual-Access-Schnittstellen - eine für PPP und eine für das MLP-Paket. Verwenden Sie den Befehl show ppp multilink, um zwischen den beiden Verbindungen zu unterscheiden.

  FRAMEside#show ppp multilink 
  
  Virtual-Access2, bundle name is ATMside 
    Bundle up for 01:15:16 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x19 received sequence, 0x4B sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:15:16, last rcvd seq 000018  59464 weight 
  

• show policy-map interface virtual-access: Überprüfen Sie, ob die QoS-Servicerichtlinie an die Schnittstelle des MLPP-Pakets gebunden ist.

  FRAMEside#show policy-map int virtual-access 2 
   Virtual-Access2 
    Service-policy output: example 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Weighted Fair Queueing 
          Strict Priority 
          Output Queue: Conversation 264 
          Bandwidth 110 (kbps) Burst 2750 (Bytes) 
          (pkts matched/bytes matched) 0/0 
          (total drops/bytes drops) 0/0 
  
      Class-map: class-default (match-any) 
        27 packets, 2578 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        Weighted Fair Queueing 
          Flow Based Fair Queueing 
          Maximum Number of Hashed Queues 256 
          (total queued/total drops/no-buffer drops) 0/0/0 
  
  

• debug frame packet and debug ppp packet: Verwenden Sie diese Befehle, wenn alle Schnittstellen aktiv/aktiv sind, Sie jedoch keinen Ping-Befehl von Ende zu Ende senden können.

  FRAMEside#debug frame packet 
  Frame Relay packet debugging is on 
  FRAMEside# 
  FRAMEside#ping 1.1.1.1 
  Type escape sequence to abort. 
  Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: 
  !!!!! 
  Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms 
  FRAMEside# 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
  
  

Warteschleifen und LFI

MLPPPoA und MLPPPoFR klonen zwei Virtual-Access-Schnittstellen von der Dialer-Schnittstelle oder virtuellen Vorlage. Eine dieser Schnittstellen stellt die PPP-Verbindung dar, die andere die Schnittstelle des MLP-Pakets. Verwenden Sie den Befehl show ppp multilink, um die spezifische Schnittstelle für die einzelnen Funktionen zu ermitteln. Zum Zeitpunkt dieses Schreibens wird nur eine VC pro Bündel unterstützt. Daher sollte in der Bündelteilliste in der Ausgabe von show ppp multilink nur eine Virtual-Access-Schnittstelle erscheinen.

Zusätzlich zu den beiden Schnittstellen für den virtuellen Zugriff ist jeder PVC einer Hauptschnittstelle und einer Subschnittstelle zugeordnet. Jede dieser Schnittstellen stellt Warteschlangen bereit. Allerdings unterstützt nur die Virtual-Access-Schnittstelle, die die Paket-Schnittstelle darstellt, Fancy Queueing über eine angewendete QoS-Servicerichtlinie. Die anderen drei Schnittstellen müssen über FIFO-Warteschlangen verfügen. Wenn eine Dienstrichtlinie auf eine virtuelle Vorlage angewendet wird, zeigt der Router die folgende Meldung an:

cr7200(config)#interface virtual-template 1
cr7200(config)#service-policy output Gromit
Class Base Weighted Fair Queueing not supported on interface Virtual-Access1

Hinweis: Class Based Weighted Fair Queueing wird nur an der MLPPP-Paketschnittstelle unterstützt.

Diese Meldungen sind normal. In der ersten Meldung wird darauf hingewiesen, dass eine Dienstrichtlinie auf der PPP Virtual-Access-Schnittstelle nicht unterstützt wird. Die zweite Meldung bestätigt, dass die Service-Richtlinie auf die Schnittstelle des MLP-Pakets für den virtuellen Zugriff angewendet wird. Um den Warteschlangenmechanismus auf der MLP-Paketschnittstelle zu bestätigen, verwenden Sie die Befehle show interface virtual-access, show queue virtual-access und show policy-map interface virtual-access.

Für MLPPPoFR muss Frame Relay Traffic Shaping (FRTS) auf der physischen Schnittstelle aktiviert sein. FRTS aktiviert VC-basierte Warteschlangen. Auf Plattformen wie der 7200-, 3600- und 2600-Serie wird FRTS mit den folgenden beiden Befehlen konfiguriert:

• Frame-Relay Traffic-Shaping an der Hauptschnittstelle

• map-class mit beliebigen Shaping-Befehlen.

Bei aktuellen Versionen von Cisco IOS wird die folgende Warnmeldung ausgegeben, wenn MLPPoFR ohne FRTS angewendet wird.

"MLPoFR not configured properly on Link x Bundle y"

Wenn diese Warnmeldung angezeigt wird, stellen Sie sicher, dass FRTS für die physische Schnittstelle konfiguriert wurde und dass die QoS-Servicerichtlinie der virtuellen Vorlage beigefügt wurde. Verwenden Sie zum Überprüfen der Konfiguration die serielle Schnittstelle show running-config und die Befehle show running-config virtual-template. Wenn MLPPPoFR konfiguriert ist, ändert sich der Warteschlangenmechanismus für die Schnittstelle in einen dualen FIFO, wie unten dargestellt. Die Warteschlange mit hoher Priorität verarbeitet Sprachpakete und Steuerungspakete wie Local Management Interface (LMI), während die Warteschlange mit niedriger Priorität fragmentierte Pakete, vermutlich Daten- oder Nicht-Sprachpakete, verarbeitet.

Router#show int serial 6/0:0 
    Serial6/0:0 is up, line protocol is down 
      Hardware is Multichannel T1 
      MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, 
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation FRAME-RELAY, crc 16, Data non-inverted 
      Keepalive set (10 sec) 
      LMI enq sent  236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down 
      LMI enq recvd 353, LMI stat sent  0, LMI upd sent  0 
      LMI DLCI 1023  LMI type is CISCO  frame relay DTE 
      Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
      Last input 00:00:02, output 00:00:02, output hang never 
      Last clearing of "show interface" counters 00:39:22 
      Queueing strategy: dual fifo 
      Output queue: high size/max/dropped 0/256/0
 !--- high-priority queue

      Output queue 0/128, 0 drops; input queue 0/75, 0 drops
 !--- low-priority queue

      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         353 packets input, 4628 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         353 packets output, 4628 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
      no alarm present 
      Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags

LFI verwendet zwei Warteschlangenebenen: MLPP-Bündelebene, die Fancy Queueing unterstützt, und PVC-Ebene, die nur FIFO-Warteschlangen unterstützt. Die Paketschnittstelle unterhält eine eigene Warteschlange. Alle MLP-Pakete durchlaufen vor dem Frame-Relay oder der ATM-Ebene zunächst das MLP-Paket und die virtuellen Access-Layer. LFI überwacht die Größe der Hardwarewarteschlangen der Mitglieds-Links und löscht Pakete aus den Hardwarewarteschlangen, wenn sie unter einen Schwellenwert fallen, der ursprünglich ein Wert von zwei war. Andernfalls werden die Pakete in der MLP-Paketwarteschlange in die Warteschlange gestellt.

Fehlerbehebung und bekannte Probleme

In der folgenden Tabelle werden bekannte Probleme mit LFI über FRF-Verbindungen aufgelistet und die Schritte zur Fehlerbehebung erläutert, die Sie durchführen müssen, um Ihre Symptome auf einen behobenen Fehler zu beschränken.

Symptom	Schritte zur Fehlerbehebung	Behebte Fehler
Reduzierter Durchsatz für ATM- oder Frame Relay-Leg	Senden Sie einen Ping-Befehl mit Paketen verschiedener Größe von 100 Byte an die Ethernet-MTU. Gibt es bei großen Paketen Zeitüberschreitungen?	CSCdt59038 - Bei 1500-Byte-Paketen und einer Fragmentierung von 100 Byte gibt es 15 fragmentierte Pakete. Die Verzögerung wurde durch mehrere Warteschlangenebenen verursacht. CSCdu1834 - Mit FRTS werden Pakete langsamer aus der Warteschlange entfernt als erwartet. Die MLPP-Bundle-Dequeue-Funktion überprüft die Warteschlangengröße der Traffic Shaper-Warteschlange. FRTS hat diese Warteschlange zu langsam geleert.
Nicht in Ordnung befindliche Pakete	Führen Sie den Befehl show ppp multilink aus. Suchen Sie nach inkrementierenden Werten für die Zähler "verlorene Fragmente", "verworfen" und "verloren gegangene empfangene". Virtual-Access4, bundle name is xyz Bundle up for 03:56:11 2524 lost fragments, 3786 reordered, 0 unassigned 1262 discarded, 1262 lost received, 1/255 load 0x42EA1 received sequence, 0xCF7 sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 03:59:02, last rcvd seq 042EA0 400 weight Aktivieren Sie debug ppp multi events und suchen Sie nach "Lost fragment" und "Out of sync with peer" Nachrichten. *Mar 17 09:14:08.216: Vi4 MLP: Lost fragment 3FED9 in 'dhartr21' (all links have rcvd higher seq#) *Mar 17 09:14:08.232: Vi4 MLP: Received lost fragment seq 3FED9, expecting 3FEDC in 'dhartr21' *Mar 17 09:14:08.232: Vi4 MLP: Out of sync with peer, resyncing to last rcvd seq# (03FED9) *Mar 17 09:14:08.236: Vi4 MLP: Unusual jump in seq number, from 03FEDC to 03FEDA	CSCdv89201 - Wenn die physische ATM-Schnittstelle überlastet ist, werden MLP-Fragmente am Remote-Ende verworfen oder außer Betrieb genommen. Dieses Problem betrifft nur die ATM-Netzwerkmodule der Serien 2600 und 3600. Dies ist darauf zurückzuführen, dass der Schnittstellentreiber Pakete im Fast Path falsch vertauscht hat (z. B. mit Fast Switching oder Cisco Express Forwarding). Das zweite Fragment des aktuellen Pakets wurde nach dem ersten Fragment des nächsten Pakets gesendet.
Ausfall der End-to-End-Verbindung bei IWF-Betrieb im transparenten Modus der Serie 3600	Ändern Sie den Modus in "Translational", und testen Sie ihn erneut.	CSCdw11409 - Stellt sicher, dass CEF an der richtigen Byte-Position sucht, um mit der Verarbeitung der Kapselungsheader von MLPP-Paketen zu beginnen

Zugehörige Informationen

• Konfiguration der Link-Fragmentierung und des Interleaving für Frame-Relay- und ATM-Virtual Circuits
• Design und Bereitstellung von Multilink PPP over Frame Relay und ATM
• RFC 2364, PPP over AAL5, Juli 1998
• RFC 1973, PPP in Frame Relay, Juni 1996
• RFC1717, The PPP Multilink Protocol (MP), November 1994
• Frame Relay/ATM PVC Service Interworking Implementation Agreement FRF.8
• Weitere ATM-Informationen
• Tools und Ressourcen - Cisco Systems
• Technischer Support und Dokumentation für Cisco Systeme