Link Fragmentation and Interleaving (LFI) configureren met Campus ATM-Switches

Inleiding

Dit document biedt een technisch overzicht van Link Fragmentation and Interleaving (LFI) via een Frame Relay-naar-ATM Interworking (IWF)-verbinding (zoals gedefinieerd in de Frame Relay Forum of de FRF.8-overeenkomst), evenals een voorbeeldconfiguratie voor het gebruik van de LS1010 of Catalyst 8500 als het IWF-apparaat in de WAN-cloud. LFI maakt gebruik van de ingebouwde fragmentatiemogelijkheden van MLPPP-insluiting (Multilink Point-to-Point Protocol) via ATM en Frame Relay om end-to-end fragmentatie- en interleaving-oplossing voor snelle links met bandbreedte van maximaal 768 kbps te bieden.

Voorwaarden

Vereisten

Dit document vereist inzicht in het volgende:

• Typische FRF.8-omgeving en FRF.8 transparante en vertaalmodi - Zie Transparante en vertaalmodi begrijpen met FRF.8.

• Bekendheid met de configuratieopdrachten van LS1010 en Catalyst 8500 en hoe de gekanaliseerde E1 Frame Relay-poortadapter of de gekanaliseerde DS3 Frame Relay-poortadapter interageren tussen een Frame Relay-endpoint en een ATM-endpoint.

• Serialisatievertraging en jitter. Zie VoIP over PPP Links met Quality of Service (LLQ/IP RTP-prioriteit, LFI, cRTP) en VoIP over Frame Relay met Quality of Service (Fragmentation, Traffic Shaping, IP RTP-prioriteit).

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Waarom MLPPP over ATM en Frame Relay?

Fragmentation is een zeer belangrijke techniek om serialisatievertraging en vertragingsvariatie op lage snelheidsverbindingen te controleren die zowel verkeer in real time als niet in real time dragen. De serialisatievertraging is de vaste vertraging die wordt vereist om een spraak- of gegevenskader op de netwerkinterface te klokkenen, en het is direct gerelateerd aan de kloksnelheid op de trunk. Een extra vlag is nodig om de frames te scheiden voor lage kloksnelheden en kleine framegrootte.

LFI gebruikt de ingebouwde fragmentatiemogelijkheden van MLPPP om vertraging en jitter (variaties in vertraging) te voorkomen die wordt veroorzaakt door grote pakketten met variabele afmetingen die in de wachtrij staan tussen relatief kleine spraakpakketten. Met LFI worden pakketten die groter zijn dan een geconfigureerde fragmentgrootte ingekapseld in een MLPPP-header. RFC 1990 definieert de MLPPP-kop en het volgende:

• (B) Een beginfragmentbit is een een-bits veld dat op 1 wordt ingesteld op het eerste fragment dat is afgeleid van een PPP-pakket en op 0 wordt ingesteld voor alle andere fragmenten van hetzelfde PPP-pakket.

• (E)nding fragment bit is een one bit field ingesteld op 1 op het laatste fragment en op 0 voor alle andere fragmenten.

• Het sequentieveld is een 24-bits of 12-bits getal dat wordt verhoogd voor elk verzonden fragment. In de standaardinstelling is het sequentieveld 24 bits lang, maar kan worden onderhandeld om slechts 12 bits te zijn met de hierna beschreven LCP-configuratieoptie.

Naast fragmentatie moeten vertragingsgevoelige pakketten met voldoende prioriteit tussen fragmenten van een groot pakket worden gepland. Met fragmentatie, wordt Weighted Fair Queueing (WFQ) zich "bewust" van of een pakket deel van een fragment uitmaakt of niet gefragmenteerd is. WFQ wijst een opeenvolgingsaantal aan elk aankomend pakket toe en plant dan pakketten die op dit aantal worden gebaseerd.

Layer 2-fragmentatie biedt een superieure oplossing voor alle andere benaderingen bij het oplossen van het "big-packet probleem." De volgende tabel geeft een overzicht van de voor- en nadelen van andere mogelijke oplossingen.

Potentiële oplossing	Voordelen	Nadelen
Afbreken transmissie van het grote pakket en opnieuw in de wachtrij plaatsen achter het vertragingsgevoelige verkeer.	Stel alleen pakkettransmissie uit. Wanneer het pakket opnieuw wordt verzonden, kan het zelfde probleem voorkomen. Als de pakketten voortdurend in de rij worden geplaatst en zelfs worden gedropt, kan er bandbreedtehongersnood ontstaan.	Sommige fysieke interfaces ondersteunen geaborteerde transmissie niet of voeren hiervoor een prestatiemaatregel in (zoals het herstellen van de gehele verzendwachtrij).
Fragment het grote pakket met behulp van fragmentatietechnieken op de netwerklaag.	Zowel IP als CLNP ondersteunen fragmentatie op elke router, waarbij hermontage plaatsvindt op de doelhost. Kan de behoefte vermijden om het grote pakket met MTU ontdekking te fragmenteren. Maakt gebruik van een globaal mechanisme om het in wezen lokale (one-hop) probleem te overwinnen - alle downstream hops moeten omgaan met een groter aantal pakketten te switches, zelfs als alle daaropvolgende links snel zijn. Maakt de optie van TCP/IP-headercompressie ongeldig.	Veel toepassingen accepteren geen fragmentatie en stellen het bit "Do Not Fragment" in de IP-header. Deze pakketten worden als ze gefragmenteerd zijn gedropt. Toepassingen die geen gefragmenteerde pakketten kunnen accepteren, worden in deze omgeving onbruikbaar gemaakt.
Fragmenteer het pakket met link-layer technieken.	Ondersteund met een netwerklaagpakket of een overbrugd pakket.	Biedt fragmentatie per link in plaats van te vereisen dat gefragmenteerde pakketten van begin tot eind worden vervoerd. Alleen de routers die aan de langzame link zijn gekoppeld, hoeven de verwerking en hermontage van extra pakketten aan te passen.

De ideale fragmentgrootte voor multilink point-to-point protocol over ATM (MLPPPoATM) moet de fragmenten in een exact veelvoud van ATM-cellen laten passen. Zie Link Fragmentation and Interleaving voor Frame Relay en virtuele ATM-circuits voor richtlijnen bij het selecteren van fragmentatiewaarden.

Koppen voor MLPPPoA en MLPPPoFR

Een typische configuratie van FRF.8 bestaat uit het volgende:

• Een Frame Relay-endpoint

• Een ATM-endpoint

• Een interworking-apparaat (IWF)

Elk eindpunt kapselt gegevens en spraakpakketten in in een Layer 2-inkapselingsheader, die het protocol communiceert dat is ingekapseld en vervoerd in het frame of de cel. Zowel Frame Relay als ATM ondersteuning voor NLPID-inkapselingskoppen (Network Layer Protocol ID). Het document ISO/International Electrotechnical Commission (IEC) TR 9577 definieert bekende NLPID-waarden voor een geselecteerd aantal protocollen. Een waarde van 0xCF wordt toegewezen aan PPP.

RFC 1973 definieert PPP in Frame Relay en de MLPPPoFR-header, terwijl RFC 2364 PPP over AAL5 en de MLPPPoA-header definieert. Beide kopregels gebruiken een NLPID-waarde van 0xCF om PPP te identificeren als het ingekapselde protocol.

Elk van deze koppen wordt weergegeven in figuur 1 hieronder.

Afbeelding 1. PPP over AAL5-header, MLPPPoA-header met NLPID-insluiting en MLPPPoA-header met VC-multiplexing

Opmerking: de MLPPPoFR-header bevat ook een veld met een vlag van één byte van 0x7e, wat niet in afbeelding 1 wordt weergegeven. Na de kopregels begint byte nummer 5 de PPP- of MLPPP-protocolvelden.

Tabel 1 - FRF.8 Transparant vs. FRF.8 Translationeel.

Afbeelding 2. Hoe het MLPPPoATM-pakket wordt gefragmenteerd met NLPID.

Afbeelding 3. Hoe het MLPPPoATM-pakket gefragmenteerd is met VC Multiplexing.

De betekenis van de bytewaarden wordt hieronder weergegeven:

• 0xFEFE - identificeert de toegangspunten voor bestemming en bronservices (SAP's) in de kop Logical Link Control (LLC). Een waarde van 0xFEFE wijst erop dat wat volgt een kort-vormNLPID kopbal is, die met protocollen wordt gebruikt die een bepaalde waarde NLPID hebben.

• 0x03 - Control veld gebruikt met vele insluitingen, waaronder High Level Data Link Control (HDLC). Geeft ook aan dat de inhoud van het pakket bestaat uit ongenummerde informatie.

• 0xCF - bekende NLPID-waarde voor PPP.

FRF.8 Transparante versus vertaalmodi

De FRF.8-overeenkomst definieert twee operationele modi voor het IWF-apparaat:

• Transparent - IWF-apparaat stuurt de inkapselingskopregels ongewijzigd door. Het voert geen protocol-header mapping, fragmentatie of herassemblage uit.

• Vertaling - IWF het apparaat voert protocol-kopbal afbeelding tussen de twee inkapselingskopballen uit om rekening te houden met kleine verschillen tussen de inkapselingstypes.

De modus die is geconfigureerd op het IWF-apparaat, dat een Cisco ATM-switch of een 7200 Series-router met een PA-A3 ATM-poortadapter kan zijn, wijzigt het aantal Layer 2-headerbytes op de ATM- en Frame Relay-segmenten van de interworking link. Laten we deze overheadkosten wat gedetailleerder bekijken.

De volgende twee tabellen geven de overheadbytes voor gegevenspakketten en Voice-over-IP (VoIP)-pakketten weer.

Tabel 2 - Data link overhead in bytes voor een gegevenspakket via een FRF.8 link.

FRF.8-modus			Doorzichtig					Vertaling
Verkeersrichting			Frame Relay naar ATM			ATM naar Frame Relay		Frame Relay naar ATM			ATM naar Frame Relay
Frame Relay of ATM-deel van PVC			Frame Relay		ATM	ATM	Frame Relay	Frame Relay	ATM		ATM		Frame Relay
Frame Flag (0x7e)			1		0	0	1	1	0		1		0
Frame Relay-header			2		0	0	2	2	0		0		2
LLC DSAP/SAP (0xfefe)			0		0	2	2	0	2		2		0
LLC-beheer (0x03)			1		1	1	1	1	1		1		1
NLPID (0xcf voor PPP)			1		1	1	1	1	1		1		1
MLP Protocol-id (0x003d)			2		2	2	2	2	2		2		2
MLP-volgnummer			4		4	4	4	4	4		4		4
PPP-protocol-id (alleen 1e frame)			2		2	2	2	2	2		2		2
payload (Layer 3+)			0		0	0	0	0	0		0		0
ATM-aanpassingslaag (AAL)5			0		8	8	0	0	8		8		0
Frame Check Sequence (FCS)			2		0	0	2	2	0		0		2
Totaal overhead (bytes)			15		18	20	17	15	20		20		15

Tabel 3 - Datalink-overhead in bytes voor een VoIP-pakket via een FRF.8-link.

FRF.8-modus	Doorzichtig				Vertaling				Frame Relay naar Frame Relay
Verkeersrichting	Frame Relay naar ATM		ATM naar Frame Relay		Frame Relay naar ATM		ATM naar Frame Relay
Frame Relay of ATM-deel van PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
Frame Flag (0x7e)	1	0	0	1	1	0	0	1	1
Frame Relay-header	2	0	0	2	2	0	0	2	2
LLC DSAP/SAP (0xfefe)	0	0	2	2	0	2	2	0	0
LLC-beheer (0x03)	1	1	1	1	1	1	1	1	1
NLPID (0xcf voor PPP)	1	1	1	1	1	1	1	1	1
PPP-id	2	2	2	2	2	2	2	2	0
payload (IP+User Datagram Protocol (UDP)+RTP+Voice)	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
Totaal overhead (bytes)	9	12	14	11	9	14	14	9	7

Let bij het weergeven van de tabellen hierboven op het volgende:

• Pakketten kleiner dan de opgegeven fragmentatiegrootte worden alleen ingesloten in een PPP-header en niet in een MLPPP-header. Op dezelfde manier zijn pakketten die groter zijn dan de gespecificeerde fragmentatiegrootte ingekapseld in zowel een PPP-header als een MLPPP-header. Zodoende hebben VoIP-pakketten tot acht bytes minder overhead.

• Slechts omvat het eerste fragment Multilink PPP (MLP) een veld met PPP Protocol ID. Het eerste fragment draagt dus twee extra bytes van overhead.

• In de transparante modus worden de kopregels voor de inkapseling ongewijzigd door het IWF-apparaat doorgegeven. De overheadkosten variëren dus in elke richting en op elk segment. Een MLPPPoA-header begint met een NLPID-header van 0xFEFE in een kort formulier. In de transparante modus wordt deze header ongewijzigd doorgegeven door het IWF-apparaat van het ATM-segment aan het Frame Relay-segment. In de richting Frame Relay naar ATM bestaat een dergelijke header echter niet in de transparante modus op elk segment.

• In de vertaalmodus wijzigt het IWF-apparaat de kopregels voor de insluiting. De overhead is dus hetzelfde op elk segment in beide richtingen. Met name in de richting ATM en Frame Relay kapselt het ATM-eindpunt het pakket in een MLPPPoA-header in. Het IWF-apparaat verwijdert de NLPID-header voordat het resterende frame wordt doorgegeven aan het Frame Relay-segment. In Frame Relay naar ATM-richting manipuleert het IWF-apparaat opnieuw het frame en wordt een NLPID-header gestart voordat het gesegmenteerde frame wordt doorgegeven aan het ATM-eindpunt.

• Bij het ontwerpen van FRF-links met MLP, moet u rekening houden met het juiste aantal datalink-overheadbytes. Zulke overheadkosten beïnvloeden de hoeveelheid bandbreedte die door elke VoIP-oproep wordt verbruikt. Het speelt ook een rol in het bepalen van de optimale MLP fragmentgrootte. Optimaliseren van de fragmentgrootte om een integraal aantal ATM-cellen te passen is cruciaal, in het bijzonder op langzaam-snelheid PVC’s waar een aanzienlijke hoeveelheid bandbreedte kan worden verspild bij het opvullen van de laatste cel tot een even veelvoud van 48 bytes.

Voor helderheidsdoeleinden, lopen door de stappen van het proces van de pakketinkapseling wanneer een pakket in Frame Relay naar de richting van ATM met transparante wijze gaat:

1. Het Frame Relay-endpoint kapselt het pakket in een MLPPPoFR-header in.

2. Het IWF-apparaat verwijdert de 2-byte Frame Relay-header met de Data Link Connection Identifier (DLCI). Vervolgens wordt het resterende pakket doorgestuurd naar de ATM-interface van IWF, die het pakket in cellen segmenteert, en doorstuurt het naar het ATM-segment.

3. Het ATM-endpoint onderzoekt de header van het ontvangen pakket. Als de eerste twee bytes van het ontvangen pakket 0x03CF zijn, beschouwt het ATM-endpoint het pakket als een geldig MLPPPoA-pakket.

4. De MLPPP-functies op het ATM-endpoint voeren verdere verwerking uit.

Bekijk het pakketinkapselingsproces wanneer een pakket in ATM naar de Frame Relay-richting met transparante modus gaat:

1. Het ATM-eindpunt kapselt het pakket in een MLPPPoA-header in. Het segmenteert de pakketten dan in cellen en door:sturen hen uit het segment van ATM.

2. IWF ontvangt het pakket, door:sturen het aan zijn interface van Frame Relay, en prepends een twee-byte Frame Relay kopbal.

3. Het Frame Relay-endpoint onderzoekt de header van het ontvangen pakket. Als de eerste vier bytes na de twee-byte Frame Relay-header 0xfefe03cf zijn, wordt het pakket door IWF behandeld als een legaal MLPPPoFR-pakket.

4. De MLPPP-functies op het Frame Relay-endpoint voeren verdere verwerking uit.

De volgende illustraties tonen het formaat van MLPPPoA- en MLPPPoFR-pakketten.

Afbeelding 6. MLPPPoA-overheadkosten. Alleen het eerste fragment heeft een PPP-header.

Afbeelding 7. MLPPPoFR-overheadkosten. Alleen het eerste fragment heeft een PPP-header.

Vereisten voor VoIP-bandbreedte

Wanneer de provisioningbandbreedte voor VoIP van toepassing is, moeten de datalink-overheadkosten in de bandbreedteberekeningen worden opgenomen. Tabel 4 toont de bandbreedtevereisten per oproep voor VoIP afhankelijk van de codec en het gebruik van gecomprimeerd Real-time Transport Protocol (RTP). De berekeningen in tabel 4 gaan uit van een best-case scenario voor RTP-headercompressie (cRTP), met andere woorden, geen UDP-checksum of transmissiefouten. Koppen worden vervolgens consequent gecomprimeerd van 40 bytes naar 2 bytes.

Tabel 4 - bandbreedtevereisten voor gesprekken per VoIP (kbps).

FRF.8-modus	Doorzichtig				Vertaling				Frame Relay naar Frame Relay
Verkeersrichting	Frame Relay naar ATM		ATM naar Frame Relay		Frame Relay naar ATM		ATM naar Frame Relay
Frame Relay of ATM-deel van PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
G729 - 20 ms Steekproeven - Geen cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - 20 ms Steekproeven - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - 30 ms Steekproeven - Geen cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - 30 ms Steekproeven - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - 20 ms Steekproeven - Geen cRTP	83.6	106.0	106.0	84.4	83.6	106.0	106.0	83.6	82.8
G711 - 20 ms Steekproeven - cRTP	68.4	84.8	84.8	69.2	68.4	84.8	84.8	68.4	67.6
G711 - 30 ms Steekproeven - Geen cRTP	76.3	97.9	97.9	76.8	76.3	97.9	97.9	76.3	75.8
G711 - 30 ms Steekproeven - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Aangezien de overheadkosten op elk been van PVC variëren, adviseren wij ontwerpen voor een worstcasescenario. Neem bijvoorbeeld het geval van een G.279-oproep met 20 msec bemonstering en cRTP over een transparant PVC. Voor het Frame Relay-traject is de bandbreedtebehoefte 12,4 kbps in de ene richting en 13,2 kbps in de andere. Daarom raden we provisioning op basis van 3,2 kbps per oproep aan.

Voor vergelijkingsdoeleinden, toont de lijst ook de bandbreedte van VoIP vereiste op een van begin tot eind pvc van Frame Relay dat met FRF.12 fragmentatie wordt gevormd. Zoals in de tabel vermeld, verbruikt PPP tussen 0,5 kbps en 0,8 kbps extra bandbreedte per oproep om de extra bytes van de inkapselingsheader te ondersteunen. Daarom raden we het gebruik van FRF.12 met end-to-end Frame Relay VC’s aan.

Compressed RTP (cRTP) over ATM vereist Cisco IOS®-softwarerelease 12.2(2)T. Wanneer cRTP is ingeschakeld met MLPoFR en MLPoATM, wordt TCP/IP-headercompressie automatisch ingeschakeld en kan deze niet worden uitgeschakeld. Deze beperking vloeit voort uit RFC 2509, die PPP-onderhandeling van RTP-headercompressie niet toestaat zonder ook te onderhandelen over TCP-headercompressie.

Vertaling en transparante ondersteuning op Cisco-apparaten

Oorspronkelijk was voor LFI vereist dat IWF-apparaten een transparante modus gebruiken. Meer recentelijk, introduceerde het Frame Relay Forum FRF.8.1 om vertaalwijze te steunen. Cisco heeft ondersteuning geïntroduceerd voor FRF.8.1 en vertaalmodus in de volgende versies van Cisco IOS-software:

• 12.0(18)W5(23) voor de LS1010 en Catalyst 8500 Series met een 4CE1 FR-PAM (CSCdt39211)

• 12.2(3)T en 12.2(2) op Cisco IOS-routers met ATM-interfaces, zoals PA-A3 (CSCdt70724)

Sommige serviceproviders ondersteunen PPP-vertaling op hun FRF.8-apparaten nog niet. Wanneer dit het geval is, moet de leverancier hun PVC’s voor transparante modus configureren.

Hardware en software

Deze configuratie gebruikt de volgende hardware en software:

• ATM-eindpunt - PA-A3-OC3 in een router uit 7200 Series met Cisco IOS-softwarerelease 12.2(8)T. (Opmerking: LFI wordt alleen ondersteund op de PA-A3-OC3 en PA-A3-T3. Het wordt niet ondersteund op de IMA- en ATM OC-12-poortadapters.)

• IWF-apparaat - LS1010 met gekanaliseerde T3-poortadaptermodule en Cisco IOS-softwarerelease 12.1(8)EY.

• Frame Relay-endpoint - PA-MC-T3 in een 7200 Series router met Cisco IOS-softwarerelease 12.2(8)T.

Topologiediagram

Configuraties

Deze paragraaf laat zien hoe u de LFI-functie via een FRF.8 link in transparante modus kunt configureren. Het gebruikt een virtuele sjabloon op de twee router-endpoints, waarvan de virtuele toegangsinterface van de MLP-bundel wordt gekloond. LFI ondersteunt dialerinterfaces en virtuele sjablonen voor het specificeren van de protocollaagparameters van MLPPP. Cisco IOS-softwarerelease 12.2(8)T verhoogt het aantal unieke virtuele sjablonen dat per router kan worden geconfigureerd tot 200. Eerdere versies ondersteunen slechts 25 virtuele sjablonen per router. Deze beperking kan een het schrapen kwestie op een de distributierouterrouter van ATM zijn als elk pvc wordt vereist om een uniek IP adres te hebben. Als tijdelijke oplossing gebruikt u IP als ongenummerd of vervangt u virtuele sjablonen door dialerinterfaces op genummerde koppelingen.

Cisco IOS-softwarerelease 12.1(5)T introduceerde ondersteuning voor LFI via slechts één lidlink per MLPPP-bundel. Bij deze configuratie wordt dus slechts één VC op elk eindpunt gebruikt. Ondersteuning voor meerdere VC’s per bundel is gepland voor een aanstaande release van Cisco IOS.

Frame Relay-endpoint

De gekanaliseerde T3 poortadapter vereist dat u een kanaalgroep maakt en de tijdsduur specificeert. Standaard bestaan er geen interfaces. 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 Gebruik de opdracht diagrammen tonen om de geïnstalleerde poortadapter te bepalen. In dit voorbeeld is de T3 PA in sleuf 3. De huidige versies van Cisco IOS tonen nu het veld-replacable (FRU) onderdeelnummer dat bij een hardwarestoring op bestelling kan worden gemaakt. 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 Het uitvoeren van de show controller t3 commando toont fysieke laag alarmen en statistieken. 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] Selecteer een T1 van binnen T3 controlemechanisme-configuratie wijze, creeer een kanaal-groep, en wijs tijdsduur aan de groep toe. 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 Opmerking: Als de aangesloten externe interface niet op dezelfde manier is geconfigureerd, komt de link-laag van de nieuwe gekanaliseerde interface omhoog, maar blijft het lijnprotocol omlaag. Interface seriële 3/0/1:1 identificeert de nieuwe gekanaliseerde interface. Configureer de interface voor Frame Relay-insluiting en schakel vervolgens Frame Relay Traffic Shaping (FRTS) in op de hoofdinterface. 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. Configuratie van een Frame Relay-kaartklasse om traffic-shaping parameters toe te passen op de Frame Relay VC (die hieronder wordt gemaakt). 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 Maak een QoS-servicebeleid. Gebruik dezelfde parameters als de ATM-kant. Zie hieronder voor referentie. 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) Maak een virtuele sjablooninterface en pas MLPPP-parameters toe. Pas ook het QoS-servicebeleid op de VC toe. 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 Maak een subinterface en wijs het Frame Relay Data Link Connection Identifier (DLCI)-nummer toe. Dan pas PPP inkapseling, het virtuele malplaatje, en de kaart-klasse toe. 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 Gebruik de opdracht show frame relay pvc om uw virtuele sjabloon en kaartklasseparameters op de VC te bevestigen. 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 Gebruik serie 3/0/1:1 van de showcontroller om te bevestigen dat de Frame Relay-link in een omhooggaande status is en vrij van fysieke alarmen is. Elke gekanaliseerde interface wordt toegewezen een "VC" nummer. In de volgende output, wordt kanaalgroep 1 (3/0/1:1) toegewezen een VC aantal van 0. 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.

Configuratie LS1010

Gebruik de opdracht show hardware om te bevestigen dat uw LS1010 is uitgerust met een gekanaliseerde Frame Relay-poortadaptermodule (PAM). 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 Gebruik de korte opdracht show ip int om de controller-interface te identificeren. 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 Maak een gekanaliseerde interface en selecteer dezelfde tijdsduur als de seriële poortadapter (PA). 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 Configureer Frame Relay-insluiting op de nieuwe seriële interface. Bovendien wijzigt u het LMI-type (Local Management Interface) van 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 Gebruik de seriële opdracht van de showinterface om Frame Relay-insluiting te bevestigen. 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 Alvorens u pvc vormt, zorg ervoor dat de interface van ATM omhoog/omhoog is. 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 Naast de twee fysieke interfaces gebruikt de LS1010 een logische interface om de ATM-kant en de Frame Relay-kant met elkaar te verbinden. De logische interface wordt geïdentificeerd als "atm-p1" op de pseudo-interface van ATM. 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 In de seriële interfaceconfiguratiemodus configureert u het 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 Bevestig uw configuratie met de show vc interface ATM opdracht. 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-endpoint

Zorg ervoor dat u een verbeterde ATM PA of PA-A3 gebruikt. Gebruik het te bevestigen bevel van de showinterface ATM. 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] Configureer de ATM-laagparameters van het permanente virtuele circuit (PVC). In deze configuratie maken we gebruik van een point-to-point subinterface met een duurzame celsnelheid (SCR) van 150 kbps. Deze waarde werd geselecteerd om ongeveer 15% hoger te zijn dan CIR van het Frame Relay-eindpunt van 128 kbps. De extra 15% helpt ervoor te zorgen dat de VC een equivalente bandbreedte levert aan het werkelijke gebruikersverkeer aan beide zijden van de verbinding, terwijl de extra overhead van de ATM-kant meegenomen wordt. (Zie ook Traffic Shaping configureren op Frame Relay naar ATM Service Interworking (FRF.8) PVC’s.) 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. Bevestig dat uw VC in de VC-tabel verschijnt. Voer de opdracht show atm vc uit. Merk op dat de router een standaard maximale burst grootte (MBS) van 94 toewijst omdat we geen expliciete waarde hebben ingevoerd. 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 Maak een QoS-servicebeleid. In het beleid dat hieronder wordt getoond, hebben we vier klassen gemaakt, inclusief de door de router gemaakte class-default klasse. Maak een class-map voor de Voice-over-IP (VoIP) pakketten. 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. Creeer een klasse-kaart voor de stem signalerende pakketten. In dit voorbeeld wordt H.323 Fast Connect gebruikt. (Zie ook de sectie "LLQ Configuration Guidelines" van VoIP over PPP Links met 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 Maak een benoemde policy-map en wijs QoS-acties toe aan elke klasse. In dit voorbeeld wordt prioriteit aan de VoIP-gebruikerspakketten toegewezen met de prioriteitsopdracht en een minimumbandbreedtegarantie voor gesprekssignalering met de bandbreedte-opdracht. Al het andere verkeer gaat naar de class-default klasse, die het verkeer scheidt in IP-Layer stromen en een eerlijke wachtrij biedt tussen de stromen. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue Bevestig uw configuratie. ATMside#show policy-map example Policy Map example Class call-control bandwidth percent 10 Class voice priority 110 Class class-default fair-queue Maak een virtuele sjabloon en pas het QoS-servicebeleid erop toe. 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. Pas de virtuele sjabloon en multilink-PPP-insluiting toe op ATM PVC. 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 Bevestig de instellingen op 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 De router maakt automatisch een virtuele toegangsinterface. Als u geen MLPPP hebt geconfigureerd op het Frame Relay-endpoint, is de status van de virtuele-toegangsinterface omhoog/omlaag. 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

Opdrachten weergeven en debuggen

ATM-endpoint

Gebruik de volgende opdrachten op het ATM-eindpunt om te bevestigen dat LFI correct werkt. Voordat u debug-opdrachten uitgeeft, raadpleegt u Belangrijke informatie over debug-opdrachten.

• toon ppp multilink - LFI gebruikt twee virtuele toegangsinterfaces — één voor PPP en één voor de MLP bundel. Gebruik de show ppp multilink om tussen de twee te onderscheiden.

  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.
  
  

• toon interface virtuele toegang 1 - Bevestig dat de virtuele toegangsinterface omhoog/omhoog is en het verhogen van de input en outputpakkettellers.

  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 
  

• toon beleidskaart in Virtual-Access 2 - Bevestig dat het QoS-servicebeleid is gebonden aan de MLPPP-bundelinterface.

  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-pakket en debug ATM-pakket - Gebruik deze opdrachten als alle interfaces up/up zijn, maar u kunt niet end to end pingen. Daarnaast kunt u deze opdrachten gebruiken om PPP-keepalives op te nemen, zoals hieronder wordt geïllustreerd.

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

Gebruik de volgende opdrachten op het Frame Relay-eindpunt om te bevestigen dat LFI correct werkt. Voordat u debug-opdrachten uitgeeft, raadpleegt u Belangrijke informatie over debug-opdrachten.

• toon ppp multilink - LFI gebruikt twee virtuele toegangsinterfaces — één voor PPP en één voor de MLP bundel. Gebruik de show ppp multilink om tussen de twee te onderscheiden.

  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 
  

• toon beleid-kaart interface virtuele toegang - Bevestig dat het QoS-servicebeleid aan de MLPPP bundelinterface is gebonden.

  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 framepakket en debug ppp-pakket - Gebruik deze opdrachten als alle interfaces up/up zijn, maar u kunt niet van begin tot eind pingen.

  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
  
  

Wachtrijen en LFI

MLPPPoA en MLPPPoFR klonen twee virtuele toegangsinterfaces vanuit de dialerinterface of de virtuele sjabloon. Een van deze interfaces vertegenwoordigt de PPP link, en de andere de MLP bundelinterface. Gebruik het show ppp multilink commando om de specifieke interface gebruikt voor elke functie te bepalen. Vanaf dit schrijven, wordt slechts één VC per bundel ondersteund, en daarom zou slechts één virtuele toegangsinterface in de bundel-lid lijst in de show ppp multilink output moeten verschijnen.

Naast de twee virtuele toegangsinterfaces, is elk PVC gekoppeld aan een hoofdinterface en een subinterface. Elk van deze interfaces verstrekt één of andere vorm van het een rij vormen. Echter, alleen de virtuele toegangsinterface die de bundelinterface vertegenwoordigt ondersteunt fancy wachtrijen via een toegepast QoS-servicebeleid. De andere drie interfaces moeten een FIFO-wachtrij hebben. Wanneer het toepassen van een dienst-beleid op een virtueel-malplaatje, toont de router het volgende bericht:

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

Opmerking: op klasse gebaseerde Weighted Fair Queueing alleen ondersteund op MLPPP-bundelinterface.

Deze berichten zijn normaal. Het eerste bericht adviseert dat een dienst-beleid niet op de PPP virtuele toegangsinterface wordt ondersteund. Het tweede bericht bevestigt dat het servicebeleid wordt toegepast op de MLP-bundel virtuele toegangsinterface. Om het wachtmechanisme op de MLP bundelinterface te bevestigen, gebruik de bevelen tonen interface virtuele-toegang, tonen rij virtuele toegang, en tonen beleid-kaart interface virtuele-toegang.

MLPPPoFR vereist dat Frame Relay Traffic Shaping (FRTS) is ingeschakeld op de fysieke interface. FRTS activeert per-VC wachtrijen. Op platforms zoals de 7200, 3600 en 2600 Series is FRTS geconfigureerd met de volgende twee opdrachten:

• Frame Relay traffic-shaping op de hoofdinterface

• map-klasse met eventuele shaping opdrachten.

De huidige versies van Cisco IOS drukken het volgende waarschuwingsbericht als MLPPPoFR zonder FRTS wordt toegepast.

"MLPoFR not configured properly on Link x Bundle y"

Als u dit waarschuwingsbericht ziet, moet u ervoor zorgen dat FRTS op de fysieke interface is geconfigureerd en dat het QoS-servicebeleid aan de virtuele sjabloon is gekoppeld. Om de configuratie te verifiëren, gebruik de show in werking stellen-config seriële interface en toon in werking stelt-in werking stelt-in werking stelt virtuele malplaatjebevelen. Wanneer MLPPPoFR is geconfigureerd, verandert het mechanisme voor interfacewachtrijen in dubbele FIFO, zoals hieronder wordt weergegeven. De wachtrij met hoge prioriteit behandelt spraakpakketten en controlepakketten, zoals Local Management Interface (LMI), en de wachtrij met lage prioriteit behandelt gefragmenteerde pakketten, vermoedelijk gegevens- of niet-spraakpakketten.

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 maakt gebruik van twee lagen wachtrijen — MLPPP-bundelniveau, dat fancy wachtrijen ondersteunt, en PVC-niveau, dat alleen FIFO-wachtrijen ondersteunt. De bundelinterface handhaaft zijn eigen rij. Alle MLP-pakketten gaan eerst door de MLP-bundel en virtuele toegangslagen vóór de Frame Relay- of ATM-laag. LFI controleert de omvang van de hardwarerijen van de leden en dewachtrijen pakketten aan de hardwarerijen wanneer zij onder een drempel vallen, die oorspronkelijk een waarde van twee was. Anders, worden de pakketten in de MLP bundelrij een rij gevormd.

Problemen oplossen en bekende problemen

De volgende tabel geeft een overzicht van bekende problemen met LFI via FRF-links en focust op de stappen die u moet nemen om uw symptomen te isoleren naar een opgelost bug.

Symptoom	Stappen voor probleemoplossing	Opgeloste bugs
Verminderde doorvoersnelheid op ATM-poot of Frame Relay-poot	Ping met pakketten van verschillende grootte van 100 bytes naar Ethernet MTU. Ervaren grote pakketten onderbrekingen?	CSCdt59038 - Met pakketten van 1500 bytes en fragmentatie ingesteld op 100 bytes, zijn er 15 gefragmenteerde pakketten. De vertraging werd veroorzaakt door meerdere niveaus van wachtrijen. CSCdu18344 - Met FRTS worden pakketten langzamer in de wachtrij geplaatst dan verwacht. De functie MLPPP bundel dewachtrij controleert de wachtrijgrootte van de traffic shaping. FRTS was te traag in het verwijderen van deze wachtrij.
Niet-bestelbare pakketten	Voer het bevel van show ppp multilink uit. Kijk naar stijgende waarden voor "verloren fragmenten", "weggegooid" en "verloren ontvangen" tellers. 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 Schakel debug ppp multi events in en zoek naar "Lost fragment" en "Out of sync met peer" berichten. *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 - Wanneer de fysieke ATM-interface verstopt is, worden MLP-fragmenten op het externe uiteinde niet meer op orde gebracht of ontvangen. Dit probleem betreft alleen ATM-netwerkmodules op de 2600 en 3600 Series. Dit is het gevolg van de manier waarop het interfacestuurprogramma op een foutieve manier pakketten switchte op het snelle pad (zoals met snelle switching of Cisco Express Forwarding). Het tweede fragment van het huidige pakket is specifiek verzonden na het eerste fragment van het volgende pakket
Verlies van end-to-end connectiviteit wanneer 3600 Series IWF in transparante modus uitvoert	Verander de modus in translationeel en test het opnieuw.	CSCdw1409 - Zorgt ervoor dat CEF op de juiste bytelocatie kijkt om te beginnen met het verwerken van de inkapselingskopregels van MLPPP-pakketten

Gerelateerde informatie

• Link Fragmentation and Interleaving configureren voor Frame Relay en virtuele ATM-circuits
• Ontwerpen en implementeren van Multilink PPP via Frame Relay en ATM
• RFC 2364, PPP via 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-implementatieovereenkomst FRF.8
• Meer ATM-informatie
• Tools en resources - Cisco Systems
• Technische ondersteuning en documentatie – Cisco Systems