Multichassis Multilink PPP (MMP)

Inleiding

Dit document beschrijft ondersteuning voor Multilink PPP (MP) in een stack- of multichassisomgeving (soms MMP genoemd, voor Multichassis Multilink PPP) op de toegangsserverplatforms van Cisco Systems.

Voorwaarden

Vereisten

Er zijn geen specifieke voorwaarden van toepassing op dit document.

Gebruikte componenten

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

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een live netwerk werkt, zorg er dan voor dat u de potentiële impact van iedere opdracht begrijpt voor u deze gebruikt.

Verwante bepalingen

Dit is een lijst van termen die in dit document worden gebruikt:

• Access server—platforms voor Cisco-toegangsservers, inclusief ISDN en asynchrone interfaces voor externe toegang.

• L2F — Layer 2 (L2) Forwarding Protocol (Experimental Draft RFC). Dit is de onderliggende link-level technologie voor zowel multichassis MP als VPN.

• Link—Een verbindingspunt dat door een systeem wordt geboden. Een link kan een speciale hardware-interface zijn (zoals een asynchrone interface) of een kanaal op een multikanaals hardware-interface (zoals een PRI of BRI).

• MP—Multilink PPP Protocol (zie RFC 1717 ).

• Multichassis MP-MP + SGBP + L2F + Vtemplate.

• PPP—Point-to-Point Protocol (zie RFC 1331 ).

• Rotary Group—Een groep fysieke interfaces die zijn toegewezen om te bellen of gesprekken te ontvangen. De groep werkt als een pool van waaruit u elke link kunt gebruiken om te bellen of gesprekken te ontvangen.

• SGBP — Stack Group Bidding Protocol.

• Stack Group—Een verzameling van twee of meer systemen die zijn geconfigureerd om als groep te werken en MP-bundels met koppelingen op verschillende systemen te ondersteunen.

• VPDN—Virtual Private Dialup-netwerk. Het doorsturen van PPP-links van een Internet Service Provider (ISP) naar een Cisco Home Gateway.

• Vtemplate: virtuele sjablooninterface.

N.B.: Zie RFC’s en andere standaarden die worden ondersteund in Cisco IOS-softwarerelease 11.3-No. 523, een productbulletin voor informatie over RFC’s die in dit document worden genoemd; het verkrijgen van RFC's en normalisatiedocumenten; of RFC Index voor een koppeling rechtstreeks naar InterNIC.

Conventies

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

Probleemdefinitie

MP voorziet gebruikers van extra bandbreedte op aanvraag met de mogelijkheid om pakketten te splitsen en opnieuw te combineren over een logische pijp (bundel) die meerdere links vormen.

Dit vermindert transmissieletentie over de langzame WAN-koppelingen en biedt ook een methode om de maximale ontvangsteenheid te verhogen.

Op het overbrengende eind, voorziet MP voor de fragmentatie van één enkel pakket in veelvoudige pakketten die over veelvoudige PPP verbindingen moeten worden overgebracht. Op het ontvangende eind, verstrekt MP pakketherassemblage van veelvoudige PPP verbindingen terug in het originele pakket.

Cisco ondersteunt MP naar autonome eindsystemen, dat wil zeggen dat meerdere MP-koppelingen van dezelfde client kunnen eindigen op de toegangsserver. ISP's geven er echter bijvoorbeeld de voorkeur aan om eenvoudig één roterend nummer toe te wijzen aan meerdere PRI's over meerdere toegangsservers, en hun serverstructuur schaalbaar en flexibel te maken voor bedrijfsbehoeften.

In Cisco IOS®-softwarerelease 11.2 biedt Cisco dergelijke functionaliteit, zodat meerdere MP-koppelingen van dezelfde client kunnen worden afgesloten op verschillende toegangsservers. Hoewel individuele MP-links van dezelfde bundel daadwerkelijk kunnen eindigen op verschillende toegangsservers, wat de MP-client betreft, is dit vergelijkbaar met beëindiging op één toegangsserver.

Om dit doel te bereiken, gebruikt MP multichassis MP.

Functioneel overzicht

Afbeelding 1 illustreert het gebruik van MP op één Cisco-toegangsserver om deze functie te ondersteunen.

Afbeelding 1 - MP op één Cisco-toegangsserver

Afbeelding 1 illustreert hoe MP-lidinterfaces zijn verbonden met een bundelinterface. In een standalone systeem zonder multichassis MP ingeschakeld, zijn de lidinterfaces altijd fysieke interfaces.

Om een gestapeld milieu te steunen, naast MP, zijn deze drie extra subcomponenten noodzakelijk:

• GBP

• Vtemplate

• L2F

In de volgende gedeelten van dit document worden deze onderdelen nader toegelicht.

GBP

In een omgeving met meerdere toegangsservers kan de netwerkbeheerder een groep toegangsservers aanwijzen die tot een stapelgroep behoren.

Stel dat een stapelgroep bestaat uit Systeem A en Systeem B. Een externe MP-client genaamd userx heeft de eerste MP-link die wordt afgesloten op Systeem A (systema). De bundelgebruiker x wordt gevormd bij systema. De volgende MP link van userx eindigt nu op System B (systemb). SGBP lokaliseert die bundel waar userX zich op systema bevindt. Op dit punt, een andere component-L2F-projecten de tweede verbinding van MP van systeem aan systeem. De geprojecteerde MP link sluit zich dan aan bij de bundel bij systema.

SGBP lokaliseert dus de bundellocatie van een stapellid binnen een bepaalde stapelgroep. SGBP arbitreert ook voor een aangewezen stapellid voor de bundelvorming. In het voorbeeld, wanneer de eerste MP link op systema wordt ontvangen, zowel systema als systemb (en alle andere leden van de stapelgroep) bieden eigenlijk voor de bundelcreatie. Het bod van systema is hoger (omdat het de eerste link accepteerde), dus SGBP wijst het aan voor bundelvorming.

Deze beschrijving van de aanbestedingsprocedure voor SGBP is enigszins simplistisch. In de praktijk is een SGBP-bod van een stapellid een functie van de locatie, een door de gebruiker instelbare gewogen metriek, CPU-type, aantal MP-bundels, enzovoort. Dit biedproces maakt het mogelijk om bundels te maken op een bepaald systeem, zelfs een systeem dat geen toegangsinterfaces heeft. Een gestapelde omgeving kan bijvoorbeeld bestaan uit 10 toegangsserversystemen en twee 4500s - een stapelgroep van 12 stapelleden.

Opmerking: Als de biedingen gelijk zijn, bijvoorbeeld tussen de twee 4500's, wijst SGBP willekeurig één aan als de winnaar van het bod. U kunt de 4500s zo configureren dat ze altijd overbieden de andere stapelleden. De 4500s worden dus offload multichassis MP servers gespecialiseerd in MP-pakketten fragmenters en reassemblers - een taak geschikt voor hun hogere CPU-vermogen in vergelijking met de toegangsservers.

Kortom, SGBP is het locatie- en arbitragemechanisme van multichassis MP.

Virtuele toegangsinterfaces

Virtuele toegangsinterfaces dienen zowel als bundelinterfaces (zie figuren 1 en figuur 2) en geprojecteerde PPP-koppelingen (zie afbeelding 2). Deze interfaces worden dynamisch gecreëerd en op verzoek teruggestuurd naar het systeem.

Virtuele sjablooninterfaces dienen als opslagplaatsen van configuratie-informatie waaruit virtuele toegangsinterfaces worden gekloond. Configuraties van snelkiezerinterfaces fungeren als een andere bron van configuratie-informatie. De methode om de bron van configuratie te kiezen waaruit om een virtuele toegangsinterface te klonen, wordt duidelijk in Multichassis Multilink PPP (MMP) (Deel 2).

L2F

L2F voorziet in de eigenlijke PPP-linkprojectie naar een aangewezen eindsysteem.

L2F voert standaard PPP-bewerkingen uit tot de verificatiefase, waarin de externe client wordt geïdentificeerd. De verificatiefase is niet lokaal voltooid. L2F, dat van het doelstapellid van SGBP wordt voorzien, projecteert de PPP verbinding aan het doelstapellid, waar de authentificatiefase bij de geprojecteerde PPP verbinding wordt hervat en voltooid. Het uiteindelijke authenticatie succes of falen wordt dus uitgevoerd op het doel stack lid.

De originele fysieke interface die de inkomende vraag goedkeurde wordt gezegd om L2F door:sturen te zijn. De bijbehorende interface die door L2F dynamisch wordt gemaakt (als PPP-verificatie slaagt) is een geprojecteerde virtuele toegangsinterface.

Opmerking: de geprojecteerde virtuele-toegangsinterface wordt ook gekloond vanuit de virtuele-sjablooninterface (indien gedefinieerd).

Afbeelding 2 beschrijft een stackgroepstackq die bestaat uit systema, systemb en systemc.

Afbeelding 2 - Cliënt die in een stapel roept

1. Clientgebruikersx bellen. De eerste link op systema ontvangt de oproep. SGBP probeert alle bundels te vinden door gebruikers die bestaan tussen de leden van de stackgroep. Als er geen is, en omdat MP op PPP wordt besproken, wordt een bundelinterface op systema gecreëerd.

2. systemb ontvangt de tweede oproep van userx. SGBP helpt te bepalen dat systeem de plaats is waar de bundel zich bevindt. L2F helpt om de link van systemb naar systema door te sturen. Een geprojecteerde PPP-link wordt op systema gemaakt. De geprojecteerde link wordt vervolgens aangesloten op de bundelinterface.

3. system ontvangt de derde oproep van userx. Opnieuw vindt SGBP dat systema de plaats is waar de bundel zich bevindt. L2F wordt gebruikt om de verbinding van systeem aan systeem door:sturen. Een geprojecteerde PPP-link wordt op systema gemaakt. De geprojecteerde link wordt vervolgens aangesloten op de bundelinterface.

Opmerking: Een bundelinterface vertegenwoordigt de bundel op systema. Voor elke unieke beller, MP-lid interfaces van dezelfde beller beëindigen of voortkomen uit één bundel interface.

Eindgebruikersinterface

De Vtemplate gebruikersinterface wordt hier nominaal gespecificeerd. Raadpleeg de Functionele Specificatie van de virtuele sjabloon voor meer informatie.

GBP

1. sgbp-groep <name>

   Dit globale bevel bepaalt een stapelgroep, wijst een naam aan de groep toe, en maakt tot het systeem een lid van die stapelgroep.

   Opmerking: u kunt slechts één stapelgroep globaal definiëren.

   Definieer een stackgroep met de naam stackq:

   systema(config)#sgbp group stackq
   

   Opmerking: de PPP CHAP-uitdaging of het PPP PAP-verzoek van systema draagt nu de naam stackq. Wanneer u de naam van de stapelgroep op de toegangsserver definieert, vervangt de naam over het algemeen de hostnaam die voor hetzelfde systeem is gedefinieerd.

2. sgbp-lid <peer-name> <peer-IP-adres>

   Dit globale bevel specificeert peers in de stapelgroep. In deze opdracht is <peer-name> de hostnaam en <peer-IP-adres> het IP-adres van het externe stapellid. U moet dus een ingang definiëren voor elk lid van de stapelgroep in de stapel, behalve uzelf. Een Domain Name Server (DNS) kan de peer-namen oplossen. Als u een DNS hebt, hoeft u het IP-adres niet in te voeren.

   systema(config)#sgbp member systemb 1.1.1.2
   	
      systema(config)#sgbp member systemc 1.1.1.3 

3. sgbp seed-bid {default | offload | Uitsluitend voorwaarts | <0-999>}

   Het configureerbare gewicht dat het stapellid met voor een bundel biedt.

   Als de standaardparameter over alle stapelleden wordt bepaald, wint het stapellid dat de eerste vraag voor de gebruikersgebruiker ontvangt altijd het bod, en gastheren de hoofdbundelinterface. Alle daaropvolgende oproepen van dezelfde gebruiker naar een ander stapellid project naar dit stapellid. Als u geen sgbp seed-bid definieert, wordt de default gebruikt.

   Als offload is gedefinieerd, wordt de vooraf gekalibreerde offerte per platform verzonden die de CPU-voeding benadert, minus de bundelbelasting.

   Als < 0-9999 > is geconfigureerd, is het uitgezonden bod de door de gebruiker ingestelde waarde minus de bundellading.

   De bundellading is gedefinieerd als het aantal actieve bundels op het stapellid.

   1. Wanneer u gelijkwaardige stapelleden hebt gestapeld om oproepen in een roterende groep over meerdere PRI's te ontvangen, geef het sgbp zaad-bod gebrek over alle stapelleden bevel uit. Een voorbeeld van gelijkwaardige stapelleden is een stapelgroep van vier AS5200s. Het stapellid dat de eerste oproep voor de gebruiker userx ontvangt wint altijd het bod, en host de master bundle interface. Alle daaropvolgende oproepen naar dezelfde gebruiker naar een ander stack lid projecten naar dit stack lid. Als de meerdere aanroepen tegelijkertijd via meerdere stackleden binnenkomen, verbreekt het SGBP-mechanisme de tijd.

   2. Als u een CPU met een hoger vermogen beschikbaar hebt als stacklid in vergelijking met de andere stackleden, kunt u de relatieve hogere capaciteit van dat stacklid ten opzichte van de rest willen gebruiken (bijvoorbeeld een of meer CPU’s met een hoger vermogen die beschikbaar zijn als stacklid in vergelijking met andere vergelijkbare stackleden; bijvoorbeeld één 4500 en vier AS5200s).U kunt het aangewezen krachtige stapellid als offload server instellen met de opdracht sgbp seed-bid offload. In dat geval, de offload server host de master bundel. Alle oproepen van andere stackleden worden geprojecteerd op dit stacklid. In feite kunnen een of meer offload servers worden gedefinieerd; als de platforms hetzelfde zijn (gelijkwaardig), zijn de biedingen gelijk. Het SGBP koppelmechanisme breekt de band en duidt een van de platforms aan als de winnaar.

      Opmerking: als u twee verschillende platforms als offload servers aanwijst, wint de platform met de hogere CPU-voeding het bod.

   3. Als u verschillende of exact dezelfde platforms hebt toegewezen en u een of meer platforms wilt aanwijzen als offload servers, kunt u de biedwaarde handmatig instellen op aanzienlijk hoger dan de rest met de opdracht sgbp seed-bid 9999. Bijvoorbeeld een 4700 (aangeduid met het hoogste bod), twee 4000 en een 7000. Om de initiële biedwaarde te bepalen die aan uw specifieke platforms is gekoppeld, toont u sgbp.

   4. In een multichassisomgeving waarin de voorste stackleden altijd offload naar een of meer offload servers, zijn er gevallen waarin het voorste stacklid feitelijk niet kan offload, zoals wanneer de multilink-bundel lokaal wordt gevormd. Dit kan bijvoorbeeld gebeuren als alle offload servers zijn uitgeschakeld. Als de netwerkbeheerder de inkomende oproep liever ophangen, geeft u de opdracht sgbp seed-bid alleen voorwaarts uit.

4. sgbp voorwaarts

   Wanneer sgbp ppp-forward is gedefinieerd, worden zowel PPP- als MP-oproepen geprojecteerd op de winnaar van het SGBP-bod. Standaard worden alleen MP-oproepen doorgestuurd.

5. Sgbp weergeven

   Dit bevel toont de staat van de leden van de stapelgroep. De statussen kunnen ACTIEF, CONNECTING, WAITINFO of IDLE zijn. ACTIEF op elk lid van de stapelgroep is de beste staat. CONNECTING en WAITINFO zijn overgangsstaten en u moet ze alleen zien wanneer u in de overgang naar ACTIVE. IDLE geeft aan dat het stack groep systeem het remote stack systeem niet kan detecteren. Als bijvoorbeeld het systeem voor onderhoud wordt afgebouwd, is er geen reden tot zorg. Anders, bekijk sommige routeringskwesties of andere problemen tussen dit stapellid en systeem.

   systema#show sgbp
     Group Name: stack Ref: 0xC38A529
     Seed bid: default, 50, default seed bid setting
   	
        Member Name: systemb State: ACTIVE  Id: 1
        Ref: 0xC14256F
        Address: 1.1.1.2 
   	
        Member Name: systemc State: ACTIVE  Id: 2
        Ref: 0xA24256D
        Address: 1.1.1.3 Tcb: 0x60B34439
   	
        Member Name: systemd State: IDLE Id: 3
        Ref: 0x0
        Address: 1.1.1.4 
   	

6. sgbp-vragen tonen

   Toont de huidige waarde van het zaadbod.

   systema# show sgbp queries
     Seed bid: default, 50
   	
     systema# debug sgbp queries
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2 		State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-DONE: Query #9 for bundle userX, count 1, master is local
   

parlementslid

1. virtuele multilink-sjabloon <1-9>

   Dit is het virtuele sjabloonnummer waarmee de MP bundelinterface zijn interfaceparameters kloont. Hier is een voorbeeld van hoe een MP associeert met een virtuele sjabloon. Er moet ook een virtuele sjablooninterface worden gedefinieerd:

   systema(config)#multilink virtual-template 1
     systema(config)#int virtual-template 1
     systema(config-i)#ip unnum e0
     systema(config-i)#encap ppp
     systema(config-i)#ppp multilink
     systema(config-i)#ppp authen chap
   

2. ppp-multilink weergeven

   Deze opdracht geeft de bundelinformatie weer voor de MP-bundels:

   systema#show ppp multilink
     Bundle userx 2 members, Master link is Virtual-Access4
     0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
     0 discarded,  0 lost received, sequence 40/66 rcvd/sent
     members 2
       Serial0:4  
       systemb:Virtual-Access6    (1.1.1.2)
   

   Dit voorbeeld laat zien, op stack group systema op stack group stackq, dat bundel userx zijn bundel interface heeft ingesteld als Virtual-Access4. Twee leden interfaces zijn aangesloten bij deze bundel interface. Het eerste is een lokaal PRI-kanaal en het tweede is een geprojecteerde interface van het systeem van stapelgroepleden.

Voorbeelden

Raadpleeg Multichassis Multilink PPP (MMP) (Deel 2) om deze voorbeelden te zien:

• AS5200 in een stack met kieslijsten

• Een offload-server gebruiken

• Offload-server met fysieke interfaces

• Async, seriële en andere niet-snelkiezer interfaces

• Uitbellen vanuit een multichassis

• Naar een multichassis bellen

Zie ook de paragrafen over:

• Configuratie en beperkingen

• Probleemoplossing

Gerelateerde informatie

• Technologische ondersteuningspagina’s voor inbellen en toegang
• Technische ondersteuning en documentatie – Cisco Systems