75x/76xx router - gedistribueerde functies configureren en controleren

Inleiding

Dit document helpt u bij het begrijpen, configureren en controleren van deze functies:

• Distributed Multilink Point to Point Protocol (dMLP)

• Distributed Link Fragmentation and Interleaving (LFI)

• Gedistribueerde LFI via huurlijn (LFIoLL)

• Gedistribueerde LFI via Frame Relay (dLFIoFR)

• Gedistribueerde LFI via ATM (dLFIoATM)

• Verschillen tussen gedistribueerde MLP (dMLP) en dLFIoLL

• Gedistribueerde multilink Frame Relay (dMLFR)

• Gedistribueerde Dial-on-Demand routing (DDR)

Voorwaarden

Vereisten

Lezers van dit document moeten kennis hebben van gedistribueerde functies voor Cisco 7500/7600/6500.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Alle Cisco 7500- en 7600-platforms

  Opmerking: de informatie in dit document is ook van toepassing op 6500 platforms.

• Relevante Cisco IOS®-softwarereleases, die in deze tabel worden opgesomd:

Ondersteuning van gedistribueerde functies voor elke tak en platform

Functie	Ondersteunde poortadapters (PA’s)1	7500 platforms		7600 platforms
		Belangrijke Cisco IOS-softwarereleases	Cisco IOS-softwarereleases (tijdelijk)	Belangrijke Cisco IOS-softwarereleases	Cisco IOS-softwarereleases (tijdelijk)
MLP	Chan-PA-4T+ PA-8T	12.0T 12.0S 12.1 12.1T 12.2 12.2T 12.3 12.3T 12.2S 12.1E2	12.0(3)T en later 12.0(9)S en later	12.2SX 12.1E2	—
LFIoLL	Chan-PA-4T+ PA-8T	12.2T 12.3 12.3T 12.0S	12.2(8)T en later 12.0(24)S en later	12,2 SX	12.2(17)SXB en later
dLFIoFR	Chan-PA-4T+ PA-8T	12.2T 12.3 12.3T	12.2(4)T3 en later	12,2 SX	12.2(17)SXB en later
LFIoATM	PA-A3-A6	12.2T 12.3 12.3T	12.2(4)T3 en later	12,2 SX	12.2(17)SXB en later
dMLFR	Chan-PA-4T+ PA-8T	12.0S 12.3T	12.0(24)S en later 12.3(4)T en later	12,2 SX	12.2(17)SXB en later
QoS op dMLP	Chan-PA-4T+ PA-8T	12.0S 12.2T 12.3 12.3T	12.0(24)S en later 12.2(8)T en later	12,2 SX	12.2(17)SXB en later
MPLS op dMLP MPLS op dLFIoLL	Chan-PA-4T+ PA-8T	12,2T 12,3	12.2(15)T11 en later 12.3(5a) en later	12,2 SX	12.2(17)SXB en later
Gedistribueerde DDR	PA-MC-x-T1 PA-MC-x1 PA-MC-x-TE1 PA-MCX-x-TE1	12,3T	12.3(7)T en later	—	—

Opmerking: Let op deze informatie:

1. Deze PA's ondersteunen gedistribueerde functies:

   • CT3IP

   • PA-MC-T3

   • PA-MC-2T3+

   • PA-MC-E3

   • PA-MC-2E1

   • PA-MC-2T1

   • PA-MC-4T1

   • PA-MC-8T1

   • PA-MC-8E1 switch

   • PA-MC-8TE1+

   • PA-MC-STM-1

2. Cisco IOS-softwarerelease 12.1E ondersteunt deze functies op zowel 7500 als 7600 platforms.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

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

Gedistribueerde functies

Deze functies worden in dit document uitgelegd:

• Gedistribueerde MLP

• Gedistribueerde LFI

• Gedistribueerde LFI via huurlijn

• Gedistribueerde LFI via Frame Relay

• Gedistribueerde LFI via ATM

• Verschillen tussen dMLP en dLFIoLL

• Gedistribueerde MLFR

• Gedistribueerde snelkiezer

• Platforms en lijnkaarten die gedistribueerde functies ondersteunen

Gedistribueerde MLPPP

Met de optie Distributed Multilink Point to Point Protocol (dMLP) kunt u volledige of fractionele T1/E1-lijnen in een lijnkaart (VIP, FlexWAN) op een Cisco 7500 of 7600 Series router combineren in een bundel die de gecombineerde bandbreedte van meerdere links heeft. Hiervoor gebruikt u een gedistribueerde MLP bundel. Een gebruiker kan het aantal bundels in een router en het aantal koppelingen per bundel kiezen. Dit staat de gebruiker toe om de bandbreedte van netwerkverbindingen te verhogen voorbij die van één enkele T1/E1 lijn zonder de noodzaak om een T3 lijn aan te schaffen. In niet-dMLP worden alle pakketten geschakeld door de Routeprocessor (RP); Daarom heeft deze implementatie gevolgen voor de prestaties van de RP, met een hoog CPU-gebruik voor slechts een paar T1/E1-lijnen met MLP. Met dMLP wordt het totale aantal bundels dat op de router kan worden verwerkt verhoogd, aangezien het gegevenspad wordt verwerkt en beperkt door lijnkaart CPU en geheugen. dMLP biedt u de mogelijkheid om fractionele T1/E1 te bundelen vanaf DS0 (64 Kbps).

Gedistribueerde LFI

De dLFI-functie ondersteunt het transport van realtime verkeer (zoals spraak) en niet-realtime verkeer (zoals gegevens) op Frame Relay- en ATM-virtuele circuits (VC’s) en op huurlijnen zonder buitensporige vertraging in het realtime verkeer te veroorzaken.

Deze optie wordt geïmplementeerd met behulp van multilink PPP (MLP) via Frame Relay, ATM en huurlijnen. De eigenschap fragmenten een groot gegevenspakket in een opeenvolging van kleinere fragmenten, om vertraging-gevoelige pakketten in real-time en niet-real-time pakketten toe te laten om de zelfde verbinding te delen. De fragmenten worden vervolgens met de realtime pakketten uitgewisseld. Aan de ontvangende kant van de link worden de fragmenten opnieuw gemonteerd en het pakje wordt gereconstrueerd.

De dLFI optie is vaak handig in netwerken die real-time verkeer via gedistribueerd Low Latency Queuing (zoals spraak) verzenden, maar heeft bandbreedteproblemen. Dit vertraagt het real-time verkeer als gevolg van het transport van grote, minder tijdgevoelige gegevenspakketten. U kunt de dLFI optie in deze netwerken gebruiken om de grote gegevenspakketten in verschillende segmenten te demonteren. De pakketten van het verkeer in real-time kunnen dan tussen deze segmenten van de gegevenspakketten worden verzonden. In dit scenario ervaart het real-time verkeer geen lange vertraging terwijl het voor de low-prioriteit gegevenspakketten wacht om het netwerk te verplaatsen. De gegevenspakketten worden opnieuw in elkaar gezet aan de ontvangende kant van de link, zodat de gegevens intacte worden geleverd.

De grootte van het fragment van de link wordt berekend op basis van de fragmentatievertraging op de multilink bundel, geconfigureerd met de opdracht ppp multilink fragment-vertraging in:

fragment size = bandwidth × fragment-delay / 8

Dit fragment vertegenwoordigt alleen IP-lading. Het bevat niet de insluitingsbytes (fragmentatiegrootte = gewicht - insluitingsbytes). De termen "gewicht" en "fragmentatiegrootte" zijn zoals gezien in de output van het tonen ppp multilink opdracht in de RP. Als de fragmentatievertraging niet is ingesteld, wordt de standaardgrootte van het fragment berekend voor een maximale fragment-vertraging van 30.

Opmerking: met links van verschillende bandbreedte is het gekozen fragment grootte gebaseerd op de link met de minste bandbreedte.

Gedistribueerde LFI via huurlijn

De dLFIoLL-functie breidt gedistribueerde link fragmentatie en interleaving-functies uit aan huurlijnen. Gedistribueerde LFI wordt ingesteld met de ppp multilink interleaving-opdracht op de multilink-groepsinterface. Het is raadzaam gedistribueerde LFI op multilink interfaces met een bandbreedte van minder dan 768 Kbps te gebruiken. Dit komt doordat de serialization vertraging voor 1500 byte-pakketten voor bandbreedte groter dan 768 Kbps binnen aanvaardbare vertragingslimieten is en niet hoeft te worden gefragmenteerd.

Gedistribueerde LFI via Frame Relay

De dLFIoFR-functie is een uitbreiding van de Multilink PPP over Frame Relay (MLPoFR). MLP wordt gebruikt voor de fragmentatie. Deze optie is gelijk aan FRF.12, dat fragmentatie ondersteunt en prioriteitspakketten kan samenvoegen via Low Latency Queuing.

De opdracht voor multilink tussen de ppp-opdracht op de virtuele sjabloon is vereist om interleaving op de bijbehorende virtuele-toegangsinterface mogelijk te maken. Naast het inschakelen van gedistribueerde CEF-switching op de seriële interface, is deze opdracht een voorwaarde voor gedistribueerde LFI om te kunnen werken.

Opmerking: Tenzij u Frame Relay op ATM-internet gebruikt, wordt aanbevolen om FRF.12 in plaats van dLFIoFR te gebruiken, omdat het bandbreedtegebruik beter is met FRF.12

Gedistribueerde LFI via ATM

De dLFIoATM-functie is een uitbreiding van de optie Multilink PPP over ATM (MLPoATM). MLP wordt gebruikt voor de fragmentatie.

De opdracht voor multilink tussen de ppp-opdracht op de virtuele sjabloon is vereist om interleaving op de bijbehorende virtuele-toegangsinterface mogelijk te maken. Naast het inschakelen van gedistribueerde CEF-switching op de seriële interface, is deze opdracht een voorwaarde voor gedistribueerde LFI om te kunnen werken.

Met dLFIoATM is het van groot belang dat u een fragmentatiegrootte selecteert die de pakketten op dusdanige wijze in ATM-cellen inpast dat ze geen onnodige toevoegingen in ATM-cellen veroorzaken. Als het geselecteerde fragment bijvoorbeeld 124 bytes is, betekent dit dat een IP-lading van 124 bytes zal gaan als 124 + 10 (MLP-header) + 8 (SNAP-header) = 142 bytes. Het is belangrijk om op te merken dat het eerste fragment zou uitgaan met 124 + 10 + 2 (Eerste fragment PID-headergrootte) + 8 = 144 bytes. Dit betekent dat dit pakket drie ATM-cellen gebruikt om de lading over te dragen en dus de cel het meest efficiënt zal gebruiken.

Verschillen tussen dMLP en dLFIoLL

dMLP ondersteunt fragmentatie aan de verzendzijde niet, terwijl dLFIoLL dat wel doet.

Opmerking: Interleaving en fragmentatie die met meer dan één verbinding in de multilink bundel voor spraakverkeer wordt gebruikt, garanderen niet dat het via meerdere verbindingen in de bundel ontvangen spraakverkeer op volgorde wordt ontvangen. De juiste volgorde van stem wordt in de bovenste lagen verwerkt.

Gedistribueerde MLFR

De gedistribueerde MLFR-functie introduceert functionaliteit op basis van de Frame Relay Forum Multilink Frame Relay UNI/NNI Implementatieovereenkomst (FRF.16) aan lijnkaart-enabled Cisco 7500 en 7600 Series routers. De gedistribueerde MLFR-optie biedt een kosteneffectieve manier om bandbreedte voor bepaalde toepassingen te vergroten, omdat meerdere seriële koppelingen in één bundel bandbreedte kunnen worden samengevoegd. MLFR wordt ondersteund op User-to-Network Interfaces (UNI) en Network-to-Network Interfaces (NNI) in Frame Relay-netwerken.

De bundel bestaat uit meerdere seriële koppelingen, bundelverbindingen genoemd. Elke bundelverbinding in een bundel komt overeen met een fysieke interface. Bundelkoppelingen zijn niet zichtbaar voor de Frame Relay datalink-laag, zodat Frame Relay-functionaliteit niet op deze interfaces kan worden geconfigureerd. De regelmatige functionaliteit van Frame Relay die u op deze verbindingen wilt toepassen moet op de gebundelde interface worden geconfigureerd. Bundelkoppelingen zijn zichtbaar voor peer-apparaten.

Gedistribueerde DDR

De gedistribueerde DDR optie maakt gedistribueerde switching op dialer interfaces mogelijk. Zonder deze optie moet al het inbelverkeer naar de host worden gestraft voor een switching. Daarmee worden alleen controlepakketten naar de RP verzonden, terwijl op de VIP's zelf een overstapbeslissing wordt genomen nadat een verbinding is opgezet.

Zowel de configuratie van het Verouderde Kiezer- als de configuratie van het Kiezerprofiel worden alleen ondersteund met PPP-insluiting. MLP op snelkiezerinterfaces wordt ook ondersteund. QoS wordt niet ondersteund met gedistribueerde switching op snelkiezerinterfaces.

Gedistribueerde functies, voorwaarden en beperkingen

Voorwaarden

Dit zijn algemene voorwaarden voor al deze gedistribueerde functies:

• Distributed Cisco Express Forwarding (dCEF)-switching moeten mondiaal ingeschakeld zijn.

• dCEF-switching moeten worden ingeschakeld op de seriële interface van het lid die deel uitmaakt van MLP-bundel.

• dCEF-switching moet worden ingeschakeld op fysieke link van dLFIoFR- en dLFIoATM-interfaces.

• De configuratie van het tussenstation is vereist om LFIoFR en LFIoATM te distribueren.

• Configureer de gewenste bandbreedte in de virtuele-sjabloon interface voor dLFIoFR en dLFIoATM-interfaces.

• Wanneer PPP debugs op RP is geactiveerd, zou u de MLP kunnen waarnemen: Verstuurd naar verkeerd interfacebericht op de routeprocessor (RSP). Omdat dit bericht verwarrend en ongewenst is - vooral als het bericht is voor pakketten van Cisco Discovery Protocol (CDP) - moet u geen cdp configureren om op de bundelkoppelingen door de lidstaten te activeren.

• Alle links van de bundel moeten de sluitingen in stand houden.

Beperkingen

Dit zijn algemene beperkingen voor al deze gedistribueerde functies:

• De lijnen T1 en E1 kunnen niet in een bundel worden gemengd.

• De maximaal ondersteunde differentiaalvertraging is 30 ms.

• Alle lijnen in een bundel moeten zich op dezelfde poortadapter (PA) bevinden.

• Hardware compressie wordt niet ondersteund.

• VIP of FlexWAN CEF is beperkt tot IP; alle andere protocollen worden naar de RSP gestuurd.

• Fragmentation wordt niet ondersteund aan de verzendzijde voor dMLP en dMLFR.

• Veel van de oudere wachtrijen mechanismen worden niet ondersteund door dLFI. Deze mechanismen omvatten:

  • Fair-wachtrij op een virtuele sjabloon-interface

  • Willekeurig detecteren op een virtuele sjablooninterface

  • Aangepaste wachtrij

  • Wachtrijen voor prioriteit

• Een eerlijke wachtrij, willekeurige detectie (dWRED) en prioriteitswachtrij kunnen in een verkeersbeleid met de modulaire QoS CLI worden ingesteld.

• Er wordt slechts één link per MLP bundel ondersteund wanneer u dLFIoFR of dLFIoATM gebruikt. Als er meer dan één link in een MLP-bundel wordt gebruikt bij het gebruik van dLFIoFR of dLFIoATM, wordt dLFI automatisch uitgeschakeld. Wanneer u dLFI via huurlijnen gebruikt, kan er meer dan één link worden geconfigureerd met dLFI in de MLP bundel.

• Met dLFIoATM worden alleen aal5magnetisch en aal5mux ondersteund. Encapsulation al5nlpid en aal5ciscopp worden niet ondersteund.

• Alleen Voice-over-IP wordt ondersteund. Voice over Frame Relay en Voice over ATM worden niet ondersteund door de dLFI-functie.

• De gecomprimeerde configuratie Real-Time Protocol (CRTP) moet niet op de multilink-interface worden geconfigureerd wanneer u deze functiecombinatie gebruikt:

  • Multilink-interface met LFI ingeschakeld

  • Multilink-bundel heeft meer dan één aangesloten koppelingen

  • QoS-beleid met prioriteitsfunctie is ingeschakeld op de multilink-interface

De dMLP- en dLFI-configuratie hebben geen hoofdpakketten van MLP en geen volgnummer, en MLP zal de prioriteitspakketten over alle koppelingen naar de lidstaten distribueren. Als resultaat hiervan kunnen pakketten die door CRTP worden gecomprimeerd op de ontvangende router uit-van-orde aankomen. Dit verbiedt CRTP de pakketheader te decomprimeren en dwingt CRTP om de pakketten te laten vallen.

Aanbevelingen

Het wordt aanbevolen dat de leden links in een bundel dezelfde bandbreedte hebben. Als u ongelijke bandbreedte-links aan de bundel toevoegt, zal dit leiden tot veel pakketherschikking, wat de algemene bundeldoorvoersnelheid zal verminderen.

Met deze gedistribueerde functies wordt het gebruik van VIP2-50 (met 8 MB RAM) of hoger aanbevolen.

Aantal bundels en links- en geheugenvereisten

Raadpleeg het gedistribueerde multilink point-to-point protocol voor Cisco 7500 Series routers.

Hardware en software MLPPP of MLFR op 7600 SIP-lijnkaarten

MLP en MLFR kunnen ofwel software- ofwel hardware-gebaseerd zijn. In op hardware gebaseerde MLP of MLFR biedt Freedm de multilink functionaliteit en worden de MLP headers toegevoegd door Freedm Chip. In op software gebaseerde MLP of MLFR biedt de SIP-lijnkaart CPU de multilink-functionaliteit (die gelijk is aan de VIP- en FlexWAN-implementaties).

Dit zijn de beperkingen en voorwaarden om op hardware gebaseerde MLP of MLFR te gebruiken.

• Er zijn slechts 336 bundels per lijnkaart en 168 bundels per veiligheidsbeoordeling (SPA) (Freedm).

• Er kan slechts een maximum van 12 DS1/E1 per bundel zijn.

• Alle links moeten tot dezelfde SPA (Freedm) behoren.

• Alle verbindingen in de bundel moeten met dezelfde snelheid werken.

• De grootte van het TX-fragment kan 128, 256 of 512 zijn. Een CLI-ingesteld fragment is toegewezen aan de dichtstbijzijnde ondersteunde fragment.

  IF (0 < cli_fragment_size – 6 < 256)
  configured_fragment_size = 128
  Else IF (cli_fragment_size < 512)
  	configured_fragment_size = 256
  Else
  	configured_fragment_size = 512

• De grootte van RX-fragment kan 1 tot 9,6 KB zijn.

• Kan niet worden ondersteund door Cisco eigen formaat (MLFR).

In hardware LFI zal, indien er slechts één verbinding in de bundel is en indien dat DS1/E1 is, fragmentatie en interleaving door Freedm worden uitgevoerd.

De output van show ppp multilink laat zien of de hardwareimplementatie draait.

Multilink1, bundle name is M1
  Bundle up for 00:14:51
  Bundle is Distributed

  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
   Member links: 1 active, 0 inactive (max not set, min not set)
   Se6/1/0/1:0, since 00:14:51, no frags rcvd
  Distributed fragmentation on. Fragment size 512.  Multilink in Hardware.

Als multilink software-gebaseerd is, zal de uitvoer van de show ppp multilink geen Multilink in Hardware in de uitvoer hebben.

Leven van een pakket

RX-datapad

1. Packet ontvangen door chauffeur.

2. Insluiting wordt gecontroleerd: als volgt

   1. Basisinsluiting:

      1. In dMLP is het insluitingstype voor de ingangsinterface ET_PPP.

      2. In dMLFR is het insluitingstype voor de ingangsinterface ET_FRAME_RELAY.

      3. In dLFIoLL is het insluitingstype voor de ingangsinterface ET_PPP.

      4. In dLFIoFR is het insluitingstype voor de ingangsinterface ET_FRAME_RELAY.

      5. In dLFIoATM is het insluitingstype voor de ingangsinterface ET_ATM.

      6. In Kiezer is het insluitingstype ET_PPP.

   2. Aanvullende insluitingsverwerking:

      Voor ET_PPP, wordt de NLPID uitgesneld.

      • Voor dMLP is de NLPID MULTILINK.

      • Voor dLFIoLL moeten er twee dingen in overweging worden genomen:

        1. VoIP-pakketten—Deze hebben geen MLP-header en hebben een NLPID die IP aangeeft.

        2. Data Packets-NLPID is MULTILINK.

      • Voor Dialer hebben de pakketten geen MLP-header en hebben ze een NLPID die IP aangeeft.

        Opmerking: In dit geval kunt u dCRTP (Gedistribueerd gecomprimeerd real-time protocol) configureren. Als dit het geval is, wordt de header gedecompreseerd voordat hij verder wordt verwerkt.

3. Voor ET_FRAME_RELAY als de link waarop het pakket is ontvangen voor dMLFR is geconfigureerd dan wordt het pakket verwerkt voor dMLFR

4. Voor dLFIoFR en dLFIoATM is het insluitingstype respectievelijk ET_FRAME_RELAY en ET_ATM; maar daarbinnen is er een PPP-header. De PPP-header, zoals bij LFIoLL, geeft aan of het pakket een spraakpakket of een gegevenspakket is. Als dCRTP is geconfigureerd wordt de header gedecompreseerd voordat hij verder wordt verwerkt. Spraakpakketten worden direct geschakeld.

   Een gefragmenteerd pakket gegevens zal opnieuw moeten worden geassembleerd voordat het is ingeschakeld.

   Met ET_PPP, kunt u over PPP verbindingspakketten komen; en met ET_FRAME_RELAY, zou je over MLFR controlepakketten kunnen komen. Al deze controlepakketten worden aan RP voor verwerking gestraft.

5. Afhankelijk van de bovengenoemde decodering, wordt het pakket gecontroleerd op het type van omschakeling dat het vereist. Het type link bepaalt of het pakket IP-switched of MPLS-switched is. De pakketten worden dan aan de respectieve overschakelfuncties gegeven.

6. Met bundeling in combinatie met gedistribueerde functies wordt de IP turbo fast switching-vector gestolen. Dit gebeurt omdat het pakje op de link van het lid is ontvangen; zij moet echter zo worden behandeld dat zij op de bundel wordt ontvangen .

   U moet ook controleren op besturingspakketten die op de host worden geleid. Vooral in dMLFR zijn er pakketten van Local Management Interface (LMI) die geen MLFR-pakketten zijn. Hiervoor wordt een ander deel van de dLCI-nummerruimte gebruikt. Wanneer het dLCI wordt gedecodeerd om in deze ruimte te vallen, wordt het pakje tot de host punteerd, omdat het een LMI-pakket is.

   VoIP-pakketten (in de wachtrij in Low Latency Quwachtrij) worden net uitgeschakeld zonder dat de MLP-header wordt toegevoegd. De gedistribueerde functies kunnen pakketten ontvangen en opnieuw assembleren, wanneer gefragmenteerde gegevenspakketten worden ontvangen. Het hermontageproces wordt in een later gedeelte uitgelegd.

   Als het pakje tag-switched moet worden gebruikt, wordt het doorgegeven naar de tag-switching routine in dMLP. Anders, als het IP-geschakeld moet worden, wordt het doorgegeven aan de IP-switching routine.

   Opmerking: Alle niet-IP pakketten zijn gestraft naar host, in dMLFR.

7. IP: De IP-switching functie komt veel voor alle pakketten. Het gaat voornamelijk om drie dingen:

   • Voer de gewenste verwerking van de pakketten uit voor het geval dat er opties zijn ingesteld. Wanneer Gedistribueerde snelkiezer wordt gebruikt, voert u hier geen timer uit wanneer er een "interessant pakket" wordt ontvangen. Raadpleeg dialer-out (interface), dialer-snelste-instelverbinding (interface) en Een snelkiezerprofiel configureren voor informatie over de parameter voor het configureren van de stationaire timer.

   Op 75xx routers zal nabijheid de tx_acc_ptr voor de spanning interface aanduiden. Als de ress interface een virtuele toegangsinterface is, is de tx_acc_ptr NULL. In dit geval, maak de insluiting vast en krijg de tx_acc_ptr van de fib hwidb. Deze optie voor raadpleging en insluiting is nodig in dLFIoFR en dLFIoATM. In dLFIoLL wordt de link behandeld als deel van een multilink bundel.

   Opmerking: TTL voor het pakket is hier aangepast en de controle op IP-fragmentatie wordt uitgevoerd. De mci_status is voor alle pakketten ingesteld op RXTYPE_DODIP.

8. Als de switching beslissing wordt genomen, is het pakje klaar om vanuit de interface te worden verzonden. De interface wordt gecontroleerd om te bepalen of het lokale switching ondersteunt. Als dat wel het geval is, wordt het rechtstreeks via de snelweg verstuurd. Anders wordt er een poging gedaan om de route-cache switch te gebruiken.

   Merk op dat, als QoS voor de interface is geconfigureerd, de lokale switchvector door QoS wordt gestolen. HQF zal het pakje in de wachtrij plaatsen en het pakje verder verwerken, voordat het definitief uit de interface wordt verzonden. Dit is het geval bij dLFI. Voor dLFI wordt fragmentatie en interleaving ingesteld. QoS behandelt de invocatie van onze fragmentatie routine en vervlekt de gefragmenteerde pakketten met de spraakpakketten die in de prioriteitswachtrij zullen worden geplaatst (als LLQ is geconfigureerd). Dit waarborgt dat de VoIP-pakketten niet lijden aan de vertraging die nodig is om grote gegevenspakketten door de link te verzenden.

TX Data Path

De vip_dtq_consumer krijgt het pakje en krijgt het interfacenummer, waaruit het de idb krijgt. De snelle routine die correspondeert met de idb wordt genoemd:

i) Faststuurt

1. In dMFR wordt de fr_info structuur opgehaald uit de tabel die de if_index aanpast aan fr_info. Control-pakketten worden net verzonden. De header van het frame geeft het dLCI, waarmee u kunt bepalen of dit een LMI-pakket of een gegevenspakket is. Het dlci-veld in de frame-kop is overschreven met het dmfr-volgnummer. Voor LMI en gegevenspakketten worden afzonderlijke sequentienummers gebruikt.

   Opmerking: Voor afzonderlijke dLKI's worden afzonderlijke sequentienummers gebruikt.

2. In dMLP worden de controlepakketten verzonden met prioriteit die op hoog wordt ingesteld. Als dCRTP is geconfigureerd voor gegevenspakketten, wordt de header gecomprimeerd. De MLP-header met daarin de sequencinginformatie wordt toegevoegd en uit de koppelingen naar de lidstaten verzonden.

3. In dLFI, onderschept HQF de pakketten die door de interface moeten worden verzonden. Als het een spraakpakket is, wordt het spraakpakket in de prioriteitswachtrij geplaatst (als LLQ is geconfigureerd) en uit de interface verzonden zonder de MLP-insluiting. Met gegevenspakketten roept het de dLFI fragmentatiecode, die fragmenten naar QoS code terugkeert, die dan met het prioriteitsverkeer wordt doorgeleid zodat aan de vertragingsvereisten van het spraakverkeer wordt voldaan. Als dCRTP is ingesteld, wordt alleen de header voor het spraakpakket gecomprimeerd. Dataspakketkopregels blijven behouden zoals ze zijn.

4. In Kiezer wordt het pakket geclassificeerd om de timer voor de uitvoerlink te resetten voordat het pakket wordt verzonden. Dit gebeurt nadat de uitvoerlink is geselecteerd, voor het geval dat verschillende links aan hetzelfde dialer zijn gebonden. Er wordt geen kop toegevoegd aan dialoogvensters. Aldus wordt het sequencing en opnieuw assembleren van pakketten niet ondersteund op de interfaces van de Kiezer.

Opmerking: In dMLP, dDialer, dMLFR en dLFI met verschillende verbindingen is de fysieke verbinding waarop het verkeer wordt doorgestuurd afhankelijk van de congestie van de verbinding. Als de link is geblokkeerd, verplaats dan de volgende link enzovoort. (dMLFR, dMLP zonder QoS en dDialer-functies kiezen ook voor links gebaseerd op het aantal bytes dat op de link wordt gezet. Het kiest de volgende link, als de huidige link al zijn bytes heeft verzonden, op een round-robin basis. Dit quotum wordt bepaald door frag_bytes voor de link. Voor de interfaces van het lid van Kiezer wordt frag_bytes ingesteld op de standaardwaarde van de bandbreedte van de interface.)

Opmerking: In HQF-configuraties op de interfaces van de stap-VIP steelt HQF de dtq_consumer-vector. Het pakket dat DMA naar het IP-adres heeft gebracht gaat eerst door de HQF-controle. Als QoS op de IP-telefoon is geconfigureerd, schakelt HQF in om het pakket te verwerken, voordat het pakket snel uit de interface wordt verzonden.

hermontage

Lijnbare snelkiezerinterfaces ondersteunen geen hermontage en sequencing. Om dit op dialer interfaces mogelijk te maken, zal MLP over dialer interfaces moeten worden geconfigureerd. Als dit gebeurt, zijn het Rx- en Tx-pad identiek aan dMLP-paden. Wanneer pakketten worden ontvangen, wordt het volgnummer gecontroleerd aan de hand van het verwachte volgnummer.

• Als de sequentienummers overeenkomen:

  1. Als het pakje een niet-gefragmenteerd pakje is, is het niet nodig het opnieuw te assembleren. Ga door met verdere stappen.

  2. Als het pakje een fragment is, controleer dan de bits beginnen en eindigen en construeer het pakje zoals en wanneer de fragmenten worden ontvangen.

• Als de sequentienummers niet overeenkomen:

  1. Als het sequentienummer zich in het verwachte venster van sequentienummers bevindt, plaats het dan in de gesorteerde "niet-toegewezen lijst van het fragment." Later, wanneer een verwacht volgnummer niet wordt ontvangen, wordt deze lijst gecontroleerd voor het geval dat het pakje hier is opgeslagen.

  2. Als het sequentienummer niet in het venster staat, gooi het dan weg en rapporteer "ontvangen verloren fragment". Als er later een time-out optreedt terwijl u op dit pakket wacht, wordt de ontvanger opnieuw geactiveerd en begint het opnieuw met het volgende ontvangen pakket.

In al die gevallen wordt een correct geordende pakketstroom uit deze interface verzonden. Als fragmenten worden ontvangen, wordt er een volledig pakket gevormd en vervolgens verzonden.

Gedistribueerde functies configureren, controleren en afbreken

Deze sectie beslaat de opdrachten voor het weergeven en debug die beschikbaar zijn om alle gedistribueerde functies te controleren en te reinigen.

dMFR configureren en controleren

MFR voorbeeldconfiguratie

interface MFR1
 no ip address

interface MFR1.1 point-to-point
 ip address 181.0.0.2 255.255.0.0
 frame-relay interface-dlci 16

Opmerking: de MFR-interface is als een andere FR-interface en ondersteunt dus de meeste FR-configuratie.

interface Serial5/0/0/1:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/2:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/3:0
 no ip address
 encapsulation frame-relay MFR1

Controleer de MFR-bundelstatus op RP

show frame-relay multilink

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
 Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
 Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0

Dit wijst erop dat twee interfaces correct worden toegevoegd, en één interface heeft de MLFR LIP berichten nog niet onderhandeld.

Om meer informatie te krijgen over de MFR - bundel en de koppelingen van de lidstaten, geeft u deze opdracht:

show frame-relay multilink mfr1 detailed

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
No. of bundle links = 3, Peer's bundle-id = MFR1
Rx buffer size = 36144, Lost frag timeout = 1000
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = , RTT = 0 ms
   Statistics:
   Add_link sent = 35, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 0, Hello rcv'd = 0,
   Hello_ack sent = 0, Hello_ack rcv'd = 0,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/2:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/1:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0

MFR-debug-opdrachten

Deze debugs zijn handig om problemen op te lossen waar een link niet aan de bundel wordt toegevoegd.

debug frame-relay multilink control

Opmerking: wanneer een specifieke MFR-interface of seriële interface niet is gespecificeerd, kan dit voor alle MFR-koppelingen worden gedebug. Dit kan overweldigend zijn, als de router een groot aantal MFR verbindingen heeft.

Om MFR-pakketten te zuiveren die bij RP worden ontvangen zowel als om de MFR controleactiviteiten te debug, is dit debug handig:

debug frame-relay multilink

N.B.: Bij zwaar verkeer kan dit de CPU’s overweldigen.

Controleer de dMLFR bundelstatus op de LC

show frame relais multilink

Opmerking: Op dit moment is deze optie niet beschikbaar op de werklijst, maar hij zal binnenkort worden toegevoegd. Tot dan, gebruik tonen ppp multilink.

Bundle MFR1, 2 members
  bundle 0x62DBDD20, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6019271C
  idb MFR1, vc 0, RSP vc 0
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x200
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial0/0:1, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x58E sent sequence
 DLCI: 16
  769719 lost fragments, 22338227 reordered, 
                                0 unassigned
  27664 discarded, 27664 lost received
  0xF58 received sequence, 0x8DE sent sequence
 timer count 767176
  Member Link: 2 active
   Serial0/0:0, id 0x1, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0
   Serial0/0:1, id 0x2, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0

MLP/LFIoL configureren en controleren

Multilink PPP-configuratie

interface Multilink1
 ip address 151.0.0.2 255.255.0.0
 no cdp enable
 ppp chap hostname M1
 ppp multilink
!

Monsterconfiguratie onder de seriële interface:

interface Serial5/0/0/4:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!
interface Serial5/0/0/5:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!

Opmerking: de ppp chap hostname M1 opdracht betekent niet dat de CHAP verificatie is ingeschakeld. De string M1 in deze opdracht werkt als de end-point-discriminator en is alleen vereist als er meer dan één multilink bundel tussen dezelfde twee routers zal zijn. In dat geval moeten alle verbindingen die tot een bundel behoren, dezelfde eindpuntdiscriminator hebben en mogen geen twee verbindingen die tot een verschillende bundel behoren, dezelfde eindpuntdiscriminator hebben.

Optionele configuratieparameters

[ neen ] pp multilink interleaving

Dit maakt het mogelijk om de multilink bundel te onderbreken. Dit werkt in combinatie met de modulaire QoS CLI. Packet met hoge prioriteit worden verzonden zonder de toevoeging van de MLP sequentie en header, terwijl andere pakketten gefragmenteerd en verzonden worden met de MLP sequentie en header.

Opmerking: als interleaving is ingeschakeld met meer dan één link, is het mogelijk dat het prioriteitsverkeer opnieuw wordt geordend. Als interleaving is ingeschakeld of uitgeschakeld, moet de bundel opnieuw worden ingesteld om ze op de lijnkaart te laten activeren.

ppp multilink mrru local value

Geeft de maximale ontvangsteenheid aan op de multilink; pakketten tot deze grootte worden geaccepteerd door de multilink interface. De grootte hier behalve de MLP header.

ppp multilink mrru remote value

Hiermee wordt de minimale MRRU aangegeven die door de afstandsbediening moet worden ondersteund. Als de MRRU op afstand kleiner is dan deze waarde, zal de gebundelde onderhandeling mislukken.

ppp multilink fragment delay seconds

Hiermee specificeert u de toegestane vertraging in milliseconden (ms) veroorzaakt door een gegevensfragment. Met andere woorden: de waarde van de vertraging wordt gebruikt om het maximaal toegestane fragment te berekenen. De gedistribueerde implementatie verschilt op deze manieren van de Cisco IOS-implementatie:

1. Fragmentation wordt niet uitgevoerd tenzij interleaving is ingeschakeld.

2. Met verbindingen van verschillende bandbreedte is de gekozen fragment grootte gebaseerd op de minste bandbreedte-interface.

ppp multilink fragment disable

Deze opdracht voegt geen enkele functionaliteit toe in de gedistribueerde implementatie. Fragmentation treedt alleen op wanneer interleaving is ingeschakeld; en, wanneer interleaving is ingeschakeld, wordt de opdracht voor het uitschakelen van het ppp multilink genegeerd.

Controleer de dMLP-bundelstatus op de RP

show ppp multilink

Multilink1, bundle name is M1
Endpoint discriminator is M1
Bundle up for 00:09:09, 1/255 load
Receive buffer limit 24000 bytes, frag timeout 1000 ms
Bundle is Distributed
  0/0 fragments/bytes in reassembly list
  0 lost fragments, 0 reordered
  0/0 discarded fragments/bytes, 0 lost received
  0x9 received sequence, 0x0 sent sequence
dLFI statistics:
          DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
            Fragmented          0          0          0          0
          UnFragmented          9       3150          0          0
           Reassembled          9       3150          0          0
      Reassembly Drops          0
   Fragmentation Drops          0
      Out of Seq Frags          0
Member links: 2 active, 0 inactive (max not set, min not set)
  Se5/0/0/4:0, since 00:09:09, 768 weight, 760 frag size
  Se5/0/0/5:0, since 00:09:09, 768 weight, 760 frag size

1. Wanneer deze bundel in de gedistribueerde modus staat, wordt dit weergegeven in de uitvoer van de multilink van het ppp:

   Bundel wordt gedistribueerd

   Zo niet, dan wordt de bundel om de een of andere reden niet verdeeld.

2. Wanneer ppp multilink interleaving is ingesteld en is ingeschakeld op de lijnkaart, omvat de output van showppp multilink de dLFI-statistieken waarin:

   • Fragmented—Geeft de tel van fragmenten aan die werden verzonden en ontvangen.

   • Ongefragmenteerd - Duidt op het aantal pakketten dat werd verzonden of ontvangen zonder gefragmenteerd te worden.

   • Geherassembleerd - Geeft het aantal volledige pakketten aan die opnieuw werden geassembleerd. Als interleaving niet is ingeschakeld, ziet de output er zo uit:

     Multilink1, bundle name is M1
       Endpoint discriminator is M1
       Bundle up for 00:00:00, 0/255 load
       Receive buffer limit 24000 bytes, frag timeout 1000 ms
       Bundle is Distributed
         0/0 fragments/bytes in reassembly list
         0 lost fragments, 0 reordered
         0/0 discarded fragments/bytes, 0 lost received
         0x0 received sequence, 0x2 sent sequence
       Member links: 2 active, 0 inactive (max not set, min not set)
         Se5/0/0/5:0, since 00:00:00, 768 weight, 760 frag size
         Se5/0/0/4:0, since 00:00:03, 768 weight, 760 frag size
     

Het fragment in het vorige voorbeeld is 760 bytes.

Controleer de MLP-bundelstatus op de LC

show ppp multilink

dmlp_ipc_config_count 24
dmlp_bundle_count 2
dmlp_ipc_fault_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x615960E0, bundle 0x622AA060, 0x60579290, 0x6057A29C
1, store 0, hwidb 0x615985C0, bundle 0x622AA060, 0x60579290, 0x6057A29C
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Multilink1, 2 members
  bundle 0x622AA060, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6057B198
  idb Multilink1, vc 4, RSP vc 4
  QoS disabled, fastsend (qos_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 1, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 1
  next_xmit_link Serial0/0:3, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0xC3 received sequence, 0x0 sent sequence
  Member Link: 2 active
   Serial0/0:4, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0
   Serial0/0:3, id 0x2, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

Bij dMFR worden de sequentienummers per dLCI-basis gehandhaafd, waarbij het sequentienummer in de bundel wordt gebruikt voor LMI dLCI.

Veld	Beschrijving
dmlp_ipc_klaar_count	Aantal door de LC ontvangen IPC-berichten voor multilink of MLFR-configuratie
dmlp_bundle_count	Aantal MLP- en MLFR-bundels in de LC
dmlp_ipc_error_count	Aantal configuratieberichten die in LC resulteerden in een storing. moet 0 zijn; Als het niet nul is, kan er een probleem zijn.
merkvectoren	Geeft de idb aan tag_optimum_fs en de idb aan ip2tag_optimum_fs vectors die gebruikt worden in tag-switching.
bord_encap	Geeft de board_encap vector aan die wordt gebruikt om 2 bytes van de insluiting toe te voegen, als er gekanaliseerde verbindingen in een 7500 platform zijn. Zou NULL moeten zijn, als de link niet-gekanaliseerde interfaces bevat.
max_deeltjes	Maximumaantal deeltjes dat in de reassemblagebuffer kan worden vastgehouden
mrru	De maximum grootte van pakket dat wordt geaccepteerd zonder rekening te houden met de MLP insluiting. Niet van toepassing voor MLFR interface.
seq_window_size	De maximum venstergrootte voor sequentienummers
werkpak	Geeft de huidige pak aan die opnieuw wordt geassembleerd. NULL, bij geen enkele.
working_pak_cache	Pointer voor de statische pak die gebruikt wordt voor reassemblering. Dit wordt toegewezen wanneer het eerste onvolledige pakket door de bundel wordt ontvangen.
una_frag_list	Eerste vermelding in de herassemblagewachtrij. Als het item niet NULL is en niet wijzigt, geeft het aan dat de timer geen softwareprobleem runt.
una_frag_end	Laatste vermelding in de herassemblagewachtrij
rcved_end_bit	Geeft aan dat de bundel een eindbit heeft ontvangen, dus het jaagt even.
is_verloren_frag	Is waar, als een fragment verloren wordt verklaard. Dit wordt gewist als er een fragment met de verwachte sequentie wordt ontvangen.
resync_telling	Geeft het aantal keren aan dat de ontvanger niet sync was met zender en moest reageren door te beginnen met het laatst ontvangen gesequentiefragment.
onderbreking	Duidt op de onderbreking van de hermontage die is voorgekomen en de pakketten worden verwerkt van de herassemblagerij.
timer_starten	Aantal keren dat de timer voor opnieuw samenstellen is gestart
timer_actief	Geeft aan of de herassemblagetimer al dan niet actief is.
timer_tellen	Geeft het aantal keer aan dat de hermontagetimer is verlopen.
Volgende_mit_link	De link waarop het volgende pakket wordt verzonden
Lid	Bit veld dat de aanwezige leden aangeeft.
Congestie	Veld niet gebruikt in alle takken. Geeft aan welke koppelingen voor de leden niet zijn geblokkeerd.
dmlp_orig_pak_to_host	De vector die wordt gebruikt om pakketten op te geven aan de RP.
dmlp_orig_fastsend	De oorspronkelijke chauffeur vertoonde een snelle verbinding vóór MLP of MLFR... veranderde de snelheid van de chauffeur.
verloren fragmenten	Aantal verloren fragmenten (de ontvanger ontving deze fragmenten niet). Dit wordt gewist wanneer een update naar de host wordt verzonden.
opnieuw geordend	Aantal fragmenten die in de verwachte volgorde werden ontvangen. Dit wordt gewist wanneer een update naar de host wordt verzonden.
verworpen	Aantal afgedankte fragmenten omdat een volledig pakket niet kan worden gemaakt
verloren	Aantal ontvangen fragmenten waarvan werd gedacht dat ze verloren waren. Dit wijst erop dat de vertraging van de interlink groter is dan de demodulatie van 30 ms dMLP.

dLFIoFR en dLFIoATM configureren en controleren

class-map voip
 match ip precedence 3

policy-map llq
 class voip
  priority

int virtual-template1
 service-policy output llq
 bandwidth 78 
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment-delay 8


int serial5/0/0/6:0
encapsulation frame-relay
frame-relay interface-dlci 16 ppp virtual-template1

!--- Or 

int ATM4/0/0
  no ip address
int ATM4/0/0.1 point-to-point
  pvc 5/100
  protocol ppp virtual-template 1

Controleer de LFIoFR/ATM bundelstatus op de RP

show ppp multilink

Virtual-Access3, bundle name is dLFI
  Endpoint discriminator is dLFI
  Bundle up for 00:01:11, 1/255 load
  Receive buffer limit 12192 bytes, frag timeout 1524 ms
  Bundle is Distributed
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x0 received sequence, 0x0 sent sequence
  dLFI statistics:
            DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
              Fragmented          0          0          0          0
            UnFragmented          0          0          0          0
             Reassembled          0          0          0          0
        Reassembly Drops          0
     Fragmentation Drops          0
        Out of Seq Frags          0
  Member links: 1 (max not set, min not set)
    Vi2, since 00:01:11, 240 weight, 230 frag size

Opmerking: de bundel wordt alleen verdeeld als ppp multilink interleaving is ingesteld onder de virtuele sjabloon; zonder deze opdracht zal de bundel niet worden verdeeld .

Controleer de LFIoFR/ATM bundelstatus op de LC

Om te controleren of de dLFI inderdaad correct werkt bij de LC geeft u deze opdracht uit:

show hqf interface

Interface Number 6 (type 22) Serial0/0:5

   blt (0x62D622E8, index 0, hwidb->fast_if_number=35) layer PHYSICAL
   scheduling policy: FIFO
   classification policy: NONE
   drop policy: TAIL
   blt flags: 0x0

   qsize 0 txcount 3 drops 0 qdrops 0 nobuffers 0
   aggregate limit 16 individual limit 4 availbuffers 16
   weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
   visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
   quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     next layer HQFLAYER_FRAMEDLCI_IFC (max entries 1024)

     blt (0x62D620E8, index 0, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: FIFO
     classification policy: NONE
     drop policy: TAIL
     blt flags: 0x0
  
     qsize 0 txcount 1 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     blt (0x62D621E8, index 16, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: WFQ
     classification policy: PRIORITY_BASED
     drop policy: TAIL
     frag policy: root
     blt flags: 0x0
  
     qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       next layer HQFLAYER_PRIORITY (max entries 256)

       blt (0x62D61FE8, index 0, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       frag policy: leaf
       blt flags: 0x0
    
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 0 perc 0.99 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       blt (0x62D61CE8, index 1, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       blt flags: 0x0
       Priority Conditioning enabled
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 0 individual limit 0 availbuffers 0
       weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 0 allocated_bw 0 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       PRIORITY: bandwidth 32 (50%)
                 last 0 tokens 1500 token_limit 1500

       blt (0x62D61EE8, index 255, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: WFQ
       classification policy: CLASS_BASED
       drop policy: TAIL
       frag policy: MLPPP (1)
         frag size: 240, vc encap: 0, handle: 0x612E1320
       blt flags: 0x0
    
       qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 1 perc 0.01 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 1 credit 0 backpressure_policy 0 nothingoncalQ 1

           next layer HQFLAYER_CLASS_HIER0 (max entries 256)

           blt (0x62D61DE8, index 0, hwidb->fast_if_number=35) layer CLASS_HIER0
           scheduling policy: FIFO
           classification policy: NONE
           drop policy: TAIL
           frag policy: leaf
           blt flags: 0x0
        
           qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
           aggregate limit 8 individual limit 2 availbuffers 8
           weight 1 perc 50.00 ready 1 shape_ready 1 wfq_clitype 0
           visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
           quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

Er moet een prioriteitslaag en een WFQ-laag zijn. Fragmentation zal worden gedaan bij het WFQ blad van de blad.

dDDR configureren en controleren

Gedistribueerde DDR wordt geactiveerd wanneer u ip cef toelaat dat op de mondiale configuratie wordt gedistribueerd en ip routecache op de dialerinterfaces wordt verdeeld.

!--- Global configuration that enables distributed CEF switching.

ip cef distributed

--- Enable distributed switching on the dialer interface (on the D-channel interface).

int serial 3/1/0:23
	ip route-cache distributed

!--- Or, enable it on the dialer interface.

int Dialer1
	ip route-cache distributed

Er zijn geen andere speciale configuraties voor gedistribueerd DDR. Verdere configuratie volgt de normale DDR-configuratie.

Controleer gedistribueerde inbel-on-demand routing

BOX2002# show isdn status

Global ISDN Switchtype = primary-net5
ISDN Serial3/1/0:23 interface

--- Network side configuration.

        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED


The ISDN status should be MULTIPLE_FRAME_ESTABLISHED. This means that the physical layer is ready for ISDN connectivity.


    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Number of L2 Discards = 0, L2 Session ID = 6

EDGE# show dialer

Serial6/0:0 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Time until disconnect 119 secs
Current call connected never
Connected to 54321

Serial6/0:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is idle

Het dialoogvenster bevat het type dialer dat wordt gebruikt. ISDN impliceert de configuratie van het dialertype en PROFILE voor de configuratie van het dialerprofiel. De dialerstaat geeft de huidige status van het dialer aan. De status van een niet-aangesloten dialerinterface wordt leeg. De inactiviteittimer wordt opnieuw ingesteld wanneer er interessant verkeer wordt gezien. Als deze timer ooit verloopt, wordt de interface onmiddellijk losgekoppeld. De inactiviteittimer is een configureerbare parameter. Raadpleeg voor meer informatie het configureren van peer-to-peer DDR met snelkiezerprofielen.

show ppp multilink

!--- From LC for dialer profile.

dmlp_ipc_config_count 2
dmlp_bundle_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x0, bundle 0x0,
1, store 0, hwidb 0x0, bundle 0x0,
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Dialer1, 1 member
  bundle 0x62677220, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x0
  idb Dialer1, vc 22, RSP vc 22
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 56
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 200, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial1/0:22, member 0x1, congestion 0x1
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x60381298
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x0 sent sequence
  Member Link: 1 active
   Serial1/0:22, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

De variabelen zijn dezelfde als die voor dMLP.

Debugging dMLP en dDDR

Debugs beschikbaar bij RP

dDDR

debug dialer [events | packets | forwarding | map]

Geef deze opdracht uit om de functies van het bedieningspaneel, zoals aanroepen, enzovoort, te debug. Raadpleeg voor meer informatie de volgende informatie:

debug ip cef dialer

Geef deze opdracht uit om CEF-gerelateerde dialergebeurtenissen te debug. Raadpleeg voor meer informatie de Kiezer CEF.

Debugs beschikbaar bij LC

MLP

debugging van het snijpad: bug van multilink

debugging van het pad: fragmenten van multilink reinigen

Foutenbehandeling in datapad en controlepad: fout multilink debug

Debugging dMLP op SIP-lijnkaarten

Dumpingpakketten gebaseerd op CI: Data Packets en Control Packets kunnen op lijnkaarten worden gedumpt op basis van de controle ci en sequentie ci.

test hoe-module subsleuf_num dumpen ci CI-NUM [rx|tx] num_Packets_to_dumpen

De KI's kunnen op deze wijze worden verkregen:

!--- Issue show controller serial interface  for CTE1.

SIP-200-6# show controller serial 6/0/0:0

SPA 6/0 base address 0xB8000000 efc 1

Interface Serial6/0/0:0 is administratively down
Type 0xD Map 0x7FFFFFFF, Subrate 0xFF, mapped 0x1, maxmtu 0x5DC
Mtu 1500, max_buffer_size 1524, max_pak_size 1608 enc 84
ROM rev: 0, FW OS rev: 0x00000000 Firmware rev: 0x00000000
  idb=0x42663A30, pa=0x427BF6E0, vip_fci_type=0, port_per_spa=0
  SPA port type is set
  Host SPI4 in sync 
  SPA=0x427BF6E0 status=00010407, host=00000101, fpga=0x427EDF98
  cmd_head=113, cmd_tail=113, ev_head=184, ev_tail=184
  ev_dropped=0, cmd_dropped=0

!--- Start Link Record Information.

 tag 0, id 0, anyphy 0, anyphy_flags 3, state 0
 crc 0, idle 0, subrate 0, invert 0, priority 0
 encap hdlc
 corrupt_ci 65535, transparent_ci 1

!--- End Link Record Information.

Interface Serial6/0/0:0 is administratively down
Channel Stats:
  in_throttle=0, throttled=0, unthrottled=0, started=1
  rx_packets=0, rx_bytes=0, rx_frame_aborts=0,  rx_crc_errors=0
  rx_giants=0, rx_non_aligned_frames=0, rx_runts=0,  rx_overruns=0
  tx_packets=0, tx_bytes=0, tx_frame_aborts=0
  is_congested=0, mapped=1, is_isdn_d=0, tx_limited=1
  fast_if_number=15, fastsend=0x403339E4
  map=0x7FFFFFFF, turbo_vector_name=Copperhead to Draco switching
  lc_ip_turbo_fs=403A9EEC, lc_ip_mdfs=403A9EEC

Voor CT3 moet u het vc num verkrijgen, dat kan worden verkregen uit de uitvoer van show interface seriële CT3_interface_name.

Nu kan de CI informatie van de SPA console worden verkregen. Richt eerst de output van SPA console opdrachten naar de RP met de opdracht spa_redirect rp ct3_freedm336.

De spa_ct3_test freedm toont linkrec vc opdracht de benodigde CI informatie.

dMFR

debugging van het snijpad: debug dmfr-gebeurtenis

debugging van het pad: debug dmfr-pakketten

Foutenbehandeling in datapad en controlepad: fout dmfr debug

Dumpingpakketten gebaseerd op CI: Zie dMLP.

dLFI

debugging van het snijpad: debug van dlfi

debugging van het pad: fragmenten van dlfi debug

Foutenbehandeling in datapad en controlepad: debug van dlfi

dDDR

Er zijn geen speciale debugopdrachten; u moet dMLP-afvoerslangen gebruiken.

In het geval van dLFIoLL moeten mogelijk zowel dMLP- als dLFI-debugs worden gebruikt. Deze debugs zijn niet voorwaardelijk en zullen daarom voor alle bundels van kracht worden.

Veelgestelde vragen

1. Wat is dMLP?

   dMLP is kort voor gedistribueerde multilink PPP (zoals aangegeven in RFC1990 ). Deze optie wordt ondersteund door gedistribueerde platforms, zoals Cisco 7500 Series en 7600 Series. dMLP biedt u de mogelijkheid om T1/E1 lijnen te combineren—in een VIP op een Cisco 7500 Series router of een FlexWAN in een 7600 Series router—in een bundel die de gecombineerde bandbreedte van meerdere T1/E1 lijnen heeft. Hiermee kunnen klanten de bandbreedte groter maken dan T1/E1 zonder dat ze een T3/E3-lijn hoeven aan te schaffen.

2. Wat is "verdeeld" in dMLP?

   Het begrip "gedistribueerd" impliceert dat de pakketswitching door de VIP wordt uitgevoerd en niet door de RSP. Waarom? RSP-switchingmogelijkheden zijn vrij beperkt en hebben veel belangrijker taken. De VIP die in staat is om pakketten van deze activiteit te veranderen van RSP. Op RSP gebaseerde Cisco IOS beheert nog steeds de koppelingen. Het maken en verwijderen van bundels wordt uitgevoerd door de RSP. Bovendien wordt de PPP-controle-plane verwerking nog steeds uitgevoerd door RSP, inclusief de verwerking van alle PPP-pakketten (LCP, Verificatie en NCP’s). Zodra echter een bundel is opgericht, wordt de verwerking van MLP-pakketten overgezet naar de VIP voor overschakeling door de geïntegreerde CPU. De dMLP-motor (op de VIP) verwerkt alle MLP-procedures, inclusief fragmentatie, interleaving, insluiting, taakverdeling tussen meerdere koppelingen en het sorteren en opnieuw samenvoegen van inkomende fragmenten. De functies die door de VIP in een 7500-systeem worden uitgevoerd, worden door Flexwan/Enhanced-FlexWAN uitgevoerd in een 7600-gebaseerd systeem.

3. Hoe weet ik of de bundel al dan niet verdeeld is?

   Geef het opdracht voor multilink van de show op in de routerconsole:

   Router# show ppp multilink
   
   Multilink1, bundle name is udho2
     Bundle up for 00:22:46
     Bundle is Distributed
     174466 lost fragments, 95613607 reordered, 129 unassigned
     37803885 discarded, 37803879 lost received, 208/255 load
     0x4D987C received sequence, 0x9A7504 sent sequence
     Member links: 28 active, 0 inactive (max not set, min not set)
       Se11/1/0/27:0, since 00:22:46, no frags rcvd
       Se11/1/0/25:0, since 00:22:46, no frags rcvd
   
    !--- Output suppressed.
   
   

4. Als ik werk aan RSP16 of SUP720, zal mijn dMLP prestaties dan beter zijn?

   Nee. De switching prestaties van dMLP (of enige gedistribueerde optie) zijn afhankelijk van de VIP of FlexWAN in kwestie. De prestaties van een VIP6-80 zijn bijvoorbeeld beter dan die van VIP2-50.

5. Welke PA's kan ik met deze functie gebruiken?

   • PA-MC-T3

   • PA-MC-2T3+

   • PA-MC-E3

   • PA-MC-2E1

   • PA-MC-2T1

   • PA-MC-4T1

   • PA-MC-8T1

   • PA-MC-8E1 switch

   • PA-MC-STM-1

   • PA-MC-8TE1+

   • PA-4T+

   • PA-8T

   • CT3IP-50 (alleen 7500)

6. Hoeveel koppelingen kunnen in één bundel worden geconfigureerd?

   Dit antwoord heeft vele facetten. Het primaire knelpunt is de CPU-voeding van de lijnkaart (VIP/FlexWAN/Enhanced-FlexWAN2). De harde limiet is 56 koppelingen per bundel, maar vaak kunt u die niet veel configureren (en zoveel verkeersswitching hebben), of doordat CPU-voeding of beperkte buffers nodig hebben. Deze getallen zijn gebaseerd op dit richtsnoer (gebaseerd op de CPU en het geheugen op de VIP/FlexWAN/Enhanced-FlexWAN2):

   VIP2-50 (met 4MB SRAM) max T1s = 12

   VIP2-50 (met 8 MB RAM) max. T1s = 16

   VIP4-80 max. T1s = 40

   VIP6-80 max. T1s = 40

   FlexWAN max. T1s = Wordt binnenkort bijgewerkt

   Enhanced-FlexWAN max. E1s = 21 E1s per lade (totaal 42 E1s per lijnkaart)

7. Is er een verandering in prestaties als ik 3 bundels aanmaak met 3 T1s of 1 bundel met 9 T1s?

   Er is geen verandering in prestaties, zoals bewezen in laboratoriumtesten. Maar met een groot aantal T1s in één bundel (bijvoorbeeld 24 of 28 T1s in één bundel) zijn er problemen met het opraken van buffers. Het wordt sterk aanbevolen, dat u niet meer dan 8 leden (T1/E1) in één bundel hebt.

8. Hoe wordt de bandbreedte van een bundel bepaald?

   De bandbreedte van een bundel moet niet worden geconfigureerd. Het is de totale bandbreedte van alle aangesloten links. Als u 4 T1s in de bundel hebt, dan is de bandbreedte van de bundel 6.144Mbps.

9. Wat is beter? CEF-load-balancering of dMLP?

   Daar is geen eenvoudig antwoord op. Je behoeften beslissen welke beter is.

   PROS VAN MLP:

   • CEF-taakverdeling is alleen van toepassing op IP-verkeer. MLP zorgt voor een evenwichtige verdeling van al het verkeer dat over een bundel wordt verzonden.

   • MLP handhaaft het bestellen van pakketten. IP zelf is verdraagzaam voor het opnieuw bestellen, zodat dit voor u niet van belang kan zijn; De extra kosten die gepaard gaan met het behoud van de sequentie kunnen zelfs een reden zijn om MLP te vermijden. IP is bedoeld voor netwerken die datagrammen mogelijk niet op orde brengen, en alles wat IP gebruikt, zou met het opnieuw bestellen moeten kunnen omgaan. Maar ondanks dit feit is de realiteit dat een herordening nog steeds een reëel probleem kan vormen.

   • MLP biedt één logische verbinding met het peer-systeem.

   • QoS wordt ondersteund op multilink bundels.

   • MLP biedt dynamische bandbreedtefuncties, aangezien de gebruiker lidlinks kan toevoegen of verwijderen op basis van huidige behoeften.

   • MLP kan een groter aantal links bundelen, terwijl de taakverdeling voor CEF beperkt is tot 6 parallelle IP-paden.

   • Per-flow CEF lading balancerend beperkt de maximale bandbreedte van om het even welke bepaalde stroom aan één T1. Bijvoorbeeld, klanten die spraakgateways gebruiken kunnen veel vraag met de zelfde bron en bestemming hebben en, daarom, slechts één weg gebruiken.

   CONS VAN MLP:

   • MLP voegt extra overhead toe aan elk pakket of kader

   • MLP is CPU-intensief; dMLP is intensief met lijnkaart CPU.

10. Hoe kan ik meerdere bundels tussen twee routers configureren?

    Multilink bepaalt welke bundel een link zich zal aansluiten op basis van de naam en de endpointdiscriminatie van de peer. Om meerdere afzonderlijke bundels tussen twee systemen te creëren, is de standaardmethode om bepaalde koppelingen te dwingen zich anders te identificeren. Aanbevolen methode is het gebruik van de ppp chap hostname opdracht.

11. Kan ik links van leden van verschillende PA's hebben?

    Nee. Als u dMLP wilt uitvoeren, wordt dit niet ondersteund. Als echter koppelingen tussen lidstaten van verschillende PA's worden toegevoegd, wordt de controle overgedragen aan RSP en zijn dMLP niet meer. MLP functioneert nog steeds, maar de voordelen van dMLP zijn verdwenen.

12. Kan ik links van beide stralen vermengen?

    Nee. Als u dMLP wilt uitvoeren, wordt dit niet ondersteund. Als echter koppelingen tussen lidstaten van verschillende PA's worden toegevoegd, wordt de controle aan RSP gegeven en is de MLP niet meer de enige. MLP functioneert nog steeds, maar de voordelen van dMLP zijn verdwenen.

13. Kan ik links tussen verschillende VIP’s of FlexWAN’s laten zien?

    Nee. Als u dMLP wilt uitvoeren, wordt dit niet ondersteund. Als echter koppelingen tussen lidstaten van verschillende PA's worden toegevoegd, wordt de controle overgedragen aan RSP en zijn dMLP niet meer. MLP functioneert nog steeds, maar de voordelen van dMLP zijn verdwenen.

14. Kan ik links tussen verschillende havens laten zien van één enkele PA?

    (Bijvoorbeeld, één aangesloten verbinding van elke CT3 haven van een PA-MC-2T3+.)

    Ja. Zolang het van dezelfde PA afkomstig is, zijn er geen problemen.

15. Kan ik T3- of E3-poorten bundelen?

    Nee. Alleen DS0, n*DS0, T1 en E1 snelheden zijn toegestaan met dMLP voor 7500/VIP, 7600/FlexWAN en 7600/FlexWAN2.

    Opmerking: Gedistribueerde MLPPP wordt alleen ondersteund voor koppelingen tussen lidstaten die zijn geconfigureerd op T1/E1 of die T1/E1 subsnelheden. Gekanaliseerde STM-1/T3/T1 interfaces ondersteunen ook dPPP op T1/E1 of subsnelheden van T1/E1. Gedistribueerde MLPPP wordt niet ondersteund voor lidstaten die zijn ingesteld op Clear Channel T3/E3 of hogere interfacesnelheden.

16. Wat zijn "herordende" fragmenten?

    Als het ontvangen fragment of pakket niet overeenkomt met het verwachte sequentienummer, wordt de opnieuw geordende teller verhoogd. Voor verschillende pakketformaten zal dit zeker gebeuren. Voor pakketten met een vaste grootte kan dit ook gebeuren omdat het PA-stuurprogramma de pakketten verwerkt die op één link zijn ontvangen en niet op een round-robin-basis gaat (zoals wordt gedaan in dMLP bij het verzenden van de pakketten). Herstelt betekent niet dat pakketverlies optreedt.

17. Wat zijn "verloren" fragmenten?

    Wanneer het fragment of het pakje uit de bestelling is ontvangen en u ontdekt dat uit bestelfragmenten of pakketten op alle koppelingen worden ontvangen, wordt de verloren fragmenten teller verhoogd. Een ander geval is wanneer de "out of order" fragmenten in de lijst worden opgeslagen en een grens bereikt (bepaald op basis van het SRAM op VIP en wat voor de bundel wordt toegewezen), de verloren fragmenten worden verhoogd en het volgende volgnummer in de lijst wordt gebruikt voor verwerking.

18. Hoe detecteert dMLP verloren fragmenten?

    1. Volgnummers: Als je wacht op een fragment met volgnummer N, en alle links een fragment ontvangen met een sequentienummer hoger dan N, weet je dat fragment N verloren moet worden, omdat het juridisch niet kan aankomen achter meer genummerde fragmenten op dezelfde link.

    2. Time-out: Als je te lang op een fragment wacht, zul je het uiteindelijk als verloren beschouwen en verder gaan.

    3. Overflow reassembleringsbuffer: Als je wacht tot fragment N aankomt, en ondertussen andere fragmenten (met sequentienummers hoger dan N) aankomen op sommige van de verbindingen, dan moet je die fragmenten in een herassemblagebuffer parkeren tot fragment N opduikt. Er is een limiet aan hoeveel je kunt bufferen. Als de buffer overstroomt, verklaar je opnieuw dat fragment N verloren is, en ga verder met verwerken met wat zich in de buffer bevindt.

19. Wat worden "verloren ontvangen"?

    Er zijn twee mogelijke redenen voor verloren ontvangen fragmenten of pakketten:

    1. Als het ontvangen fragment of pakket niet binnen het verwachte bereik van de sequentie valt, wordt het pakket gedropt door het te markeren op basis van ontvangen informatie.

    2. Als het ontvangen fragment of pakket binnen het verwachte venster van het sequentiebereik valt, maar u kunt geen pakketheader toewijzen om dit pakket opnieuw te parent te geven, dan wordt het pakje ingetrokken en gemarkeerd als verloren ontvangen.

20. Wordt encryptie ondersteund met dMLP?

    Nee.

21. Ondersteuning van PFC-headercompressie?

    Nee, niet op het gedistribueerde pad. De verre eindrouter wordt niet aanbevolen om PFC headercompressie te configureren omdat we terug vallen naar niet-gedistribueerde modus als we gecomprimeerde headerframes of pakketten ontvangen. Als u wilt doorgaan met het uitvoeren van dMLP, moet de PFC-headercompressie aan beide eindpunten worden uitgeschakeld.

22. Wordt softwarecompressie ondersteund met dMLP?

    Nee, omdat de software compressie niet werkt in het gedistribueerde pad.

23. Wordt fragmentatie ondersteund aan de verzendzijde?

    Niet met Vanilla dMLP. Er doen zich geen problemen voor bij het ontvangen van fragmenten met Vanilla dMLP, maar bij het verzenden gebeurt er geen fragmentatie. De fragmentatie van de kant-en-tegel wordt ondersteund wanneer ppp multilink interleaving is ingesteld op de dMLP-interface.

24. Kunnen we de koppelingen tussen de lidstaten van een MLP bundel ping?

    Nee, u kunt geen IP-adres op de aangesloten koppelingen configureren.

25. Is er enige afhankelijkheid van de verbinding MTU en de grootte van het MLP-fragment?

    Nee. De grootte van de MTU heeft niets te maken met de grootte van het MLP-fragment, behalve de duidelijke beperking die een MLP-fragment, net als elk ander frame, niet kan overschrijden de grootte van de MTU van de seriële koppelingen.

26. Is het mogelijk om twee MLP bundels tussen één paar routers te configureren?

    Ja, het is mogelijk. Dit zou echter kunnen leiden tot een verzwakking van de taakverdeling. Het kan handig zijn op testbedden, om meer dan twee routers te simuleren met slechts twee routers, maar het heeft geen duidelijke echte waarde.

    Alle verbindingen die naar een gemeenschappelijk peer gaan moeten in dezelfde bundel worden geplaatst. Per definitie is een bundel de reeks verbindingen die naar een bepaald peer gaan.

    Een "peer" wordt geïdentificeerd door de waarden van de Username- en Endpoint Discriminator die het tijdens de LCP- en de authenticatiefase aanbiedt. Als u meerdere bundels tussen twee routers probeert te creëren, betekent het dat u probeert elke router maskerade te maken als meer dan één peer aan zijn tegenhanger. Zij moeten zich naar behoren identificeren.

27. Kunnen de lidstaten links verschillende wachtende algoritmen hebben?

    Alle wachtrijen-mechanismen met betrekking tot een bundel moeten worden toegepast op het bundelniveau en niet op het koppelingsniveau van de leden. Het configureren van een rijalgoritme zou echter geen effect moeten hebben op de manier waarop de pakketten uit de bundel worden geschakeld.

28. Waarom is de belasting-quque-limit ingesteld op 26 als default voor lidlinks voor een multilink bundel wanneer dMLP is ingeschakeld op een Cisco 7500?

    Voor elke seriële interface van bandbreedte T1/E1 is de limiet van de X-wachtrij rond 4 of 5. Wanneer u T1s/E1s in multilink bundelt, zal de bandbreedte voor de bundel toenemen. Omdat het overschakelen op basis van de bandbreedte van de MLP interface zou plaatsvinden, moet u de belasting-wachtrij-limiet van de lidlinks verhogen. Slechts één van de aangesloten links, de genoemde primaire verbinding, wordt gebruikt voor het veranderen, daarom moet zijn belasting-wachtrij-limiet worden verhoogd.

    Ook is deze waarde een empirische die na het testen en vervolgens afstemmen op deze waarde is gekozen. In het algemeen hebben de implementaties niet meer dan 4 tot 6 T1/E1-verbindingen in een bundel. Met een waarde van 26 kunt u 6 tot 8 T1/E1-koppelingen perfect verwerken en dus is deze waarde geselecteerd.

29. Wat is differentiële vertraging en de waarde ervan in de dMLP-implementatie?

    dMLP ondersteunt een differentiële vertraging van 30 ms. Dat zou betekenen dat als er een fragment op T ontvangen wordt en dat het buiten werking is (verwacht een sequentienummer 100, maar we hebben er 101 ontvangen). Als sequentie 100 niet wordt ontvangen tot T+30 ms, zou 100 verloren worden verklaard en als je vanaf 101 kunt beginnen met verwerken, zou je dat doen. Indien u niet kunt starten met 101 (als het een middenfragment is), dan zoekt u het fragment dat het beginfragment heeft (bijvoorbeeld 104) en begint u vervolgens.

30. Wat gebeurt wanneer pakketten op IP niveau met multilink op 7500 gefragmenteerd zijn?

    Als pakketten op het niveau van IP gefragmenteerd zijn, dan worden zij getransporteerd zonder hermontage bij de tussenliggende hop maar worden opnieuw gemonteerd op de bestemmingsrouter.

31. Wat gebeurt er als pakketten op MLP niveau op 7500 zijn gefragmenteerd?

    Als de pakketten op het niveau MLP gefragmenteerd zijn en als de geherassembleerde pakketten groter zijn dan MRRU, worden de pakketten op multilink gedropt. Verzendzijdige fragmentatie wordt alleen met dLFI ondersteund op dMLP. Packets zijn alleen gefragmenteerd op MLP niveau als de Packet_size groter is dan frag_size en kleiner dan de MRRU. Als pakketten meer dan de MRRU worden verzonden en als het op het IP niveau niet gefragmenteerd is, laat het andere eind alle pakketten vallen die op het MLP niveau niet gefragmenteerd zijn omdat de pakketten meer dan MRRU zijn.

32. Hoe wordt MRRU berekend?

    De MRRU wordt berekend op basis van deze voorkeuren:

    1. Voor de nieuwe koppelingen die binnenkomen, wordt opnieuw onderhandeld over MRRU op LCP-niveau volgens de MRRU die op de koppelingen tussen de lidstaten is ingesteld.

    2. De waarde ingesteld op de link interface met de opdracht multi-link mru interface.

    3. Indien niet geconfigureerd, de waarde die is geërfd van de configuratie van het ppp multilink mru-opdracht op de parent-interface.

    4. Als beide waarden aanwezig zijn, heeft de waarde van de link interface voorrang.

    5. De standaard MRRU van 1524.

Verbeteringen in debug

Deze verbeteringen zullen in de toekomst worden overgenomen. De planning is nog niet voltooid.

• Schakel de opdracht frame-relais in op de LC.

• Vergroot de huidige debug CLIs per interface en het gespecificeerde aantal pakketten.

• Voor dDDR wordt QoS-functionaliteit nog niet ondersteund. Dit kan alleen worden opgelost met goede zakelijke argumenten.

Gerelateerde informatie

• Kiezer CEF
• Peer-to-peer DDR configureren met snelkiezerprofielen
• MPLS-multi-link PPP-ondersteuning
• Gedistribueerd multilink point-to-point protocol voor Cisco 7500 Series routers
• Gedistribueerde multilink Frame Relay (FRF.16)
• Gedistribueerde Link Fragmentation and Interleaving via huurlijnen
• VoIP over PPP Links met Quality of Service (LLQ/IP RTP-prioriteit, LFI, cRTP)
• TechNotes voor probleemoplossing - Cisco 7500 Series router
• Productondersteuningspagina voor routers - Cisco-systemen
• Technische ondersteuning en documentatie – Cisco Systems