Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Waarom MLPPP over ATM en Frame Relay?

Koppen voor MLPPPoA en MLPPPoFR

FRF.8 Transparante versus vertaalmodi

Vereisten voor VoIP-bandbreedte

Vertaling en transparante ondersteuning op Cisco-apparaten

Hardware en software

Topologiediagram

Configuraties

Opdrachten weergeven en debuggen

ATM-endpoint

Frame Relay-endpoint

Wachtrijen en LFI

Problemen oplossen en bekende problemen

Gerelateerde informatie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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