Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Warum MLPP über ATM und Frame Relay?

MLPPPoA- und MLPPPoFR-Header

FRF.8 Transparent und Übersetzungsmodi

VoIP-Bandbreitenanforderungen

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

Hardware und Software

Topologiediagramm

Konfigurationen

Befehle anzeigen und debuggen

ATM-Endpunkt

Frame-Relay-Endpunkt

Warteschleifen und LFI

Fehlerbehebung und bekannte Probleme

Zugehörige Informationen

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

1. 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

2. 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

3. 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]

4. 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.

5. 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.

6. 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

7. 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)

8. 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

9. 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

10. 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

11. 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

1. 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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

1. 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]

2. 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.

3. 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

4. Erstellen einer QoS-Servicerichtlinie In der unten gezeigten Richtlinie wurden vier Klassen erstellt, einschließlich der vom Router erstellten Standardklasse.

1. 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.

2. 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

3. 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

4. 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

5. 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.

6. 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

7. 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

8. 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