Multichassis Multilink PPP (MMP) (deel 2)

Inleiding

Dit document blijft ondersteuning voor Multilink PPP (MP) in een "stapel"- of multichassis-omgeving (soms MMP genoemd, voor Multichassis Multilink PPP) op de toegangsserverplatforms van Cisco Systems.

Dit document maakt deel uit van een document dat uit twee delen bestaat. Raadpleeg deel één van dit document voor meer informatie.

Voorwaarden

De voorwaarden voor dit document zijn opgenomen in deel 1 van dit document.

Voorbeelden

AS5200 in een stapel (met snelkiezers)

Wanneer dialers op de fysieke interfaces zijn geconfigureerd, hoeft u de virtuele sjabloon-interface helemaal niet te specificeren. De virtuele toegangsinterface fungeert als een passieve interface, tussen de dialerinterface en de fysieke interfaces gekoppeld aan de dialerinterface.

In het kort hoeft u alleen de naam van de stackgroep, het algemene wachtwoord en de leden van de stackgroep over alle stapelleden te definiëren. Er wordt geen virtuele sjabloon-interface gedefinieerd, zoals in het volgende voorbeeld wordt getoond:

systema#config
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3

  username stackq password therock

  int dialer 1
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  ppp multilink

  controller T1 0
  framing esf                    
  linecode b8zs                  
  pri-group timeslots 1-24

  interface Serial0:23
  no ip address
  encapsulation ppp
  dialer in-band
  dialer rotary 1
  dialer-group 1

Het volgende voorbeeld komt van een E1-controller:

controller E1 0
  framing crc4  
  linecode  hdb3
  pri-group timeslots 1-31
  interface Serial0:15
  no ip address
  encapsulation ppp
  no ip route-cache
  ppp authentication chap
  ppp multilink

Nadat de bundelinterface is gecreëerd, wordt het gekloond met slechts de opdrachten in PPP van de dialerinterface. De volgende geprojecteerde PPP-koppelingen worden ook gekloond met de PPP-opdrachten in de dialerinterface. Afbeelding 3 toont hoe de dialer-interface bovenop de bundelinterface zit. Vergelijk het met Afbeelding 2, waarin er geen dialerinterface is.

PRI's en BRI's zijn standaard dialerinterfaces; Een PRI die zonder een expliciet dialer is ingesteld (door de opdracht dialer roteren) is nog steeds een dialerinterface op Serial0:23, zoals wordt getoond in het volgende voorbeeld:

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink

Een offload Server gebruiken

systema is aangewezen als offload server (met de sgbp seed-bid opdracht). Alle andere groepsleden moeten worden gedefinieerd met de sgbp seed-bid default opdracht (of als u de gbp seed-bid opdracht niet definieert, is deze standaard ingeschakeld).

systema#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  sgbp seed-bid offload
  username stackq password therock

  interface virtual-template 1
  ip unnumbered e0
  :

  ppp authen chap
  ppp multilink

Offload Server met fysieke interfaces

Als de aangewezen offload server ook fysieke interfaces (bijvoorbeeld PRI) heeft die dezelfde groep van de telco-jacht willen dienen als de andere leden van de stapel, kunt u deze ook configureren door configuraties te combineren die in de delen van dit document AS5200 in een Stack (met Kiezers) en een offload Server worden getoond.

Een geprojecteerde PPP-link en de gebundelde interfaces zijn afhankelijk van virtuele sjablonen voor een configuratiebron. Een verbinding die de eerste verbinding heeft arriveert bij een fysiek apparaat dat wordt aangesloten op een dialerinterface en de bron van de configuratie voor de bundelinterface en alle daaropvolgende geprojecteerde PPP-links is de configuratie van de dialer-interface. Vandaar dat deze variaties naast elkaar bestaan, afhankelijk van het stapellid waarop de eerste link aankomt.

Deze configuratie wordt niet aanbevolen vanwege de complexiteit van de configuraties die vereist zijn op de dialoogvensters en virtuele sjablooninterfaces.

Async-, seriële en andere niet-snelkiezerinterfaces

Terwijl u asynchrone en seriële apparaten kunt configureren als dialerinterfaces (in welk geval het in een Stack terugkeert naar AS5200 (met Kiezers), zoals in dat gedeelte van dit document wordt getoond) kunt u ervoor kiezen om multichassis MP te ondersteunen zonder enige dialerconfiguratie voor asynchrone, seriële en andere niet-dialerinterfaces. De bron van alle configuratie wordt dan gedefinieerd in de virtuele sjablooninterface, zoals hieronder wordt getoond.

#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  username stackq password therock
  interface virtual-template 1
  ip unnumbered e0
  :
  ppp authen chap
  ppp multilink

  int async 1
  encap ppp 
  ppp multilink 
  ppp authen chap
  :

  line 1
  login 
  autoselect ppp 
  autoselect during-login
  speed 38400
  flow hardware

Uitbellen vanaf een multichassis

Op dit moment ondersteunt multi-chassis configuratie geen dialout, omdat het Layer 2 Forwarding (L2F) protocol geen dialout ondersteunt.

Daarom is er geen manier voor de offload server (waar een route gespoofd is, op een dialerprofiel enzovoort) om een wijzerplaat op de front-end stapellid in de zelfde stapelgroep te openen. Alle gespoofde routes moeten op de front-end stapelleden worden geïnstalleerd, omdat dit degenen zijn met de fysieke kiesverbindingen (zoals PRI).

De volgende pijnpunten:

• Wanneer de sgbp ppp-forward opdracht wordt gegeven op het front-end stapellid, betekent dit dat alle PPP en PPP multilink-oproepen automatisch worden doorgestuurd naar de winnaars van het Stack Group Bidding Protocol (SGBP), zoals een offload-server.

  U dient te vertrouwen op het Dialoogvenster Network Access Server (NAS) en IP-routingconvergentie (alleen voor IP) te laten uitvoeren. Om bijvoorbeeld 1.1.1.1 te draaien, plaats dit adres in het dialerkaartstatement op NAS en leg een statische route op NAS, als volgt, op:

    ip route 1.1.1.1 255.255.255.255 serial0:23
    int serial0:23
    ip address 3.3.3.3 255.0.0.0
    dialer map ip 1.1.1.1 howard 7771234
  

  Wanneer de draaiknop zich aansluit op de externe peer, wordt de PPP-verbinding gevormd tussen de externe peer en de offload server. Het voorste stapellid wordt volledig omzeild. PPP op de offload server installeert dan een host route naar de peer-1.1.1.1. Op dit punt converteert het IP-routeprotocol van naar de host-route op de offload-server omdat de routing metriek de route daar scherp volgt.

  Opmerking: Routing Convergence resulteert in vertraging.

• Wanneer de sgbp ppp-forward opdracht niet op het voorste stapellid is gedefinieerd, betekent dit dat alleen PPP multilink-oproepen automatisch worden doorgestuurd naar de SGBP bipolawinnaar, zoals een offload server. Dientengevolge, een dialer van het front-end stapellid aan een ver peer overspant de PPP verbinding tussen het front-end en de afstandspeer-het zelfde gedrag zoals als NAS geen deel van een stapelgroep maakte.

  Opmerking: Dit gebeurt zolang de verbinding rechte PPP (en niet PPP multilink) is.

Naar een multichassis bellen

Als u IP routing hebt (zoals Enhanced Interior Gateway Routing Protocol (DHCP) en Open Snelste pad eerst (OSPF) tussen de client en het stapellid dat uiteindelijk de bieding wint (zoals de offload server) zijn er een paar tips om te volgen:

Beletten dat een Connected Route op de clientzijde wordt geïnstalleerd

Configureer client 1.1.1.2 waarbij 1.1.1.2 het adres van de NAS (de transparante frame-expediteur) is, zoals hieronder wordt getoond.

  int bri0

  dialer map 1.1.1.2 ....

Als u, bijvoorbeeld, tussen de client en de offload server hebt lopen, wijst de routingtabel op de offload server erop dat om 1.1.1.2 te krijgen de route door de virtuele toegangsinterface moet gaan. Dit is omdat IPCP (PPPoIP Control Protocol) aan de clientzijde een aangesloten route 1.1.1.2 naar de BRI-interface installeert. Ecp adverteert dan deze route naar de offload server over de PPP zitting (over L2F). Hiermee geeft u op de offload server aan dat om 1.1.1.2 te bereiken, het naar de client moet leiden: route 1.1.1.1 van de client naar de virtuele toegangsinterface.

Nu, hebt u een pakket voor de client 1.1.1.1. IP-routing is bestemd. U stuurt het pakket naar de virtuele toegangsinterface. De virtuele toegangsinterface kapselt IP/User Data Protocol (UDP)/L2F/PPP-insluiting in en stuurt het pakket naar de L2F NAS-1.1.1.2. Alles is op dit punt normaal. In plaats van het pakket door (bijvoorbeeld) de Ethernet-interface te verzenden, stuurt IP-routing het door de virtuele toegangsinterface opnieuw. Dit komt doordat de routingtabel aangeeft dat om bij de NAS te komen, deze de client moet passeren. Dit creëert een routinglus en schakelt effectief invoer en uitvoer via de L2F-tunnel uit.

Om dit te voorkomen, laat IPCP niet toe om een aangesloten route aan de clientkant te installeren.

Opmerking: dit blijft alleen van toepassing wanneer u een of meer IP-routingprotocollen hebt die tussen de client en Cisco Home Gateway worden uitgevoerd.

De clientconfiguratie is als volgt:

  int bri0

  no peer neighbor-route

Kiezertoewijzingen op de client

Wanneer de klant op een multichassis omgeving draait, definieer altijd de dialers voor elke potentiële winnaar van de multilink bundel. Bijvoorbeeld, als er vier offload servers zijn in de multichassis stapel, moeten er vier dialer kaarten zijn die in de client worden gedefinieerd.

Bijvoorbeeld:

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

In dit voorbeeld is 1.1.1.3 slechts één offload server.

Een pakket dat voor 1.1.1.2 routes naar BRI bestemd is, en het dialer dialen de bestemming omdat er een dialerkaartmatch is. De offload-server 1.1.1.4 wint feitelijk het bod en de PPP-sessie wordt daar geprojecteerd. DHCP wordt uitgewisseld tussen de client en de offload server. De IP-routingtabel op de client is gevuld met een route 1.1.1.4 (offload server) naar BRI0. Nu wordt op de client een pakket dat voor 1.1.1.4 is bestemd, naar BRI0 verzonden. Het dialer kan echter niet bellen omdat er geen dialermatch is.

Toelichting: Vaststellen altijd dialerkaarten voor alle potentiële SGBP-biedwinnaars op klanten wanneer de toegang tot de offload servers een vereiste van de klanten is.

Configuratie- en beperkingen

• De j-image van de onderneming is vereist voor een meervoudig chassis MP.

• Er kan slechts één stapelgroep worden gedefinieerd voor elke toegangsserver.

• Hoog latentie WAN-verbindingen tussen de stapelleden, waardoor vertraging bij MP-hermontage optreedt, kan ervoor zorgen dat multichassis MP inefficiënt is.

• Interfaces worden ondersteund voor PRI, [M]BRI, seriële en asynchrone apparaten.

• Uitbel wordt niet ondersteund.

Configuratie van interfaceconfiguraties per protocol

Configureer voor alle praktische doeleinden geen specifiek protocoladres in de virtuele sjabloon.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

De virtuele sjabloon-interface is een sjabloon waaruit elk aantal virtuele toegangsinterfaces dynamisch is gekloond. U dient geen protocol-specifiek adres per interface voor de virtuele sjabloon-interface te specificeren. Omdat een IP-adres uniek moet zijn voor elke netwerkinterface is het opgeven van een uniek IP-adres in de virtuele sjabloon-interface onjuist. In plaats daarvan voert u de volgende handelingen uit:

  interface virtual-template 1

  ip unnum e0

  :

Configuratie van mondiale protocolconfiguraties

Een client die inbelt op één toegangsrouter en verwacht dat de toegangsserver een uniek mondiaal adres heeft (zoals DECnet), schakelt nu ook naar de groep van multilink-multilink-meerdere toegangsservers. In dit soort situatie, eindig de stapgroep vastberaden op één toegangsserver. Om dat te doen, geef de sgbp zaad-bid offload opdracht uit op de aangewezen toegangsserver (of geef het hoogste bod op).

Probleemoplossing

Het eerste wat te doen als je problemen hebt is terug te gaan naar één stapel lid, alle andere stapelleden uitschakelen. Test vervolgens uw PPP multilink-verbindingen en ga door de gebruikelijke Challenge Handshake Authentication Protocol (CHAP)-verificatie en interfaceconfiguratie voor fouten in configuratie enzovoort. Wanneer u tevreden bent, schakelt u de andere stapelleden in en gaat u als volgt te werk:

1. Zorg ervoor dat SGBP operationeel is.

2. Debug PPP multilink.

3. Debug VPN en L2F.

Zorg ervoor dat de GBP correct werkt

Geef het show sgbp-commando af om ervoor te zorgen dat alle lidstaten actief zijn. Anders let u op IDLE, AUTHOK of actieve staten. Zoals eerder vermeld is IDLE een geldige staat voor alle verre leden van de stapel die opzettelijk inactief zijn.

Als u een probleem vindt zoals hierboven beschreven, schakel de debug sgbp hellos in en debug sgbp error opdracht. De authenticatie tussen twee stapelleden, bijvoorbeeld tussen systema en systemb, dient als volgt te zijn (op systeem):

  systema# debug sgdp hellos

  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2)
  %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq
  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2)
  %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2)
  %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7
  %SGBP-5-ARRIVING: New peer event for member systemb

systema stuurt een CHAP-stijl-uitdaging en krijgt een reactie van systemb. Op dezelfde manier stuurt systemb een uitdaging uit en krijgt ze een reactie van het systeem.

Als verificatie mislukt, ziet u:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Dit betekent dat het wachtwoord van het afstandssysteem voor stackq niet overeenkomt met het wachtwoord dat op systeem is gedefinieerd.

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

Dit betekent dat systema geen gebruikersnaam of wachtwoord heeft die lokaal of door TACACS+ is gedefinieerd.

In het algemeen, definieer een gemeenschappelijk geheim over alle Stackq stapels leden. U kunt ze lokaal of via TACACS+ definiëren.

Een lokale gebruikersnaam die op elk stapellid wordt gedefinieerd is:

  username stackq password blah

Dit gemeenschappelijk geheim is bedoeld om de BGB-inschrijver en de arbitrage te vergemakkelijken.

Raadpleeg het Afbrekende PPP-gedeelte van dit document voor een discussie van PPP-link-verificatie wanneer een externe client inbellen naar de stapelleden.

In het geval van bedrading of het routeren van problemen, is één gemeenschappelijke fout het van het bron IP adres van het stapellid te hebben (die eigenlijk in het hallo bericht van SGBP ontvangen wordt) verschillend van het lokaal bepaalde IP adres voor het zelfde stapellid.

  systema#debug sgbp error
  %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5

Dit betekent dat het IP-bronadres van de SGBP hallo van systemb niet overeenkomt met het IP-adres dat lokaal voor systemb is ingesteld (via de opdracht van het sgbp-lid). Corrigeer dit door te systematiseren en te controleren op meerdere interfaces waarmee de SGBP hallo het bericht kan verzenden.

Een andere veel voorkomende oorzaak van fouten is:

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

Dit betekent dat je geen systeem lokaal hebt gedefinieerd, maar een ander stapellid wel.

Debugging PPP-multilink

Het eerste te controleren ding is of de client en het stapellid correct op PPP geauthentiseerd zijn.

Dit voorbeeld laat zien dat CHAP-authenticatie krijgt, omdat het er meer bij betrokken is. Als bekend voorbeeld, gebruikt het een platform van Cisco als client samen met lokale gebruikersnamen (Terminal Access Control System Plus (TACACS+) wordt ook ondersteund, maar wordt niet hier weergegeven).

#config

username stackq password blah

#config

username userx password blah

Geen snelkiezerinterfaces betrokken

Aangezien er geen dialerinterface op de offload server is, moet er een andere bron van interfaceconfiguratie van virtuele toegangsinterfaces zijn. Het antwoord is virtuele sjablooninterfaces.

1. Zorg er eerst voor dat het wereldwijde virtuele sjabloonnummer van meerdere verbindingen op elk stapellid is gedefinieerd.

     #config
     Multilink virtual-template 1
   

2. Als u geen dialerinterfaces voor de fysieke interfaces in kwestie hebt geconfigureerd (zoals PRI, BRI, asynchrone en synchrone seriële), kunt u definiëren:

     interface virtual-template 1
     ip unnumbered e0
     ppp authen chap
     ppp Multilink
   

   N.B.: U definieert geen specifiek IP-adres op de virtuele sjabloon. Dit komt doordat geprojecteerde virtuele toegangsinterfaces altijd vanaf de virtuele sjabloon-interface worden gekloond. Als een volgende PPP-link ook wordt geprojecteerd op een stapellid met een virtuele access interface die al gekloond en actief is, hebt u identieke IP-adressen op de twee virtuele interfaces, waardoor IP onjuist tussen deze interfaces wordt getransporteerd.

Betrokken snelkiezerinterfaces

Wanneer dialers op de fysieke interfaces worden ingesteld, hoeft u geen virtuele sjabloon-interface te specificeren, omdat de interfacemodatie zich in de dialerinterface bevindt. In dit geval werkt de virtuele access interface als een passieve interface, ingedrukt tussen de dialer-interface en de aangesloten interfaces gekoppeld aan de dialerinterface.

Opmerking: De dialerinterface, Kiezer 1, wordt als volgt weergegeven in de PPP multilink-sessie:

  systema#show ppp Multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  Dialer interface is Dialer1
  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.1)

LCP en NCP’s

De LCP staten op alle lidstaten interfaces moeten UP zijn. IPCP, ATCP en andere NCP’s mogen alleen op de bundelinterface staan.

De bundelinterface Virtual-Access4-weergave moet als volgt luiden:

  router#show int  Virtual-Access4
  Virtual-Access4 is up, line protocol is up 
          :
      LCP Open, Multilink Open
      Open: ipcp
              :

Alle andere lid interfaces moeten de volgende show in output hebben:

  router# show int Serial0:4
  Serial0:4 is up, line protocol is up 
          :
  LCP Open, Multilink Open
  Closed:  ipcp

VPN/L2F-filtering

Zet de volgende opties aan:

  debug vpn event
  debug vpn error

Wanneer de fysieke interface de inkomende vraag accepteert en nu aan het doelstapellid wordt doorgestuurd, ziet u het volgende:

  Serial0:21 VPN Forwarding 
  Serial0:21 VPN vpn_forward_user userx is forwarded

Op het doel stapellid, als u het volgende ziet:

  Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
  Virtual-Access1 VPN PPP LCP not accepting sent CONFACK

Controleer vervolgens uw definitie van de virtuele sjablooninterface. Over het algemeen moet de virtuele sjabloon-interface overeenkomen met de PPP-interfaceparameters van de fysieke interface die een inkomende oproep heeft geaccepteerd.

Herinner de minimum configuratie (het gebruiken van CHAP als voorbeeld):

  #config
  multilink virtual template 4
  int virtual-template 4
  ip unnum e0
  encap ppp
  ppp authen chap 
  ppp Multilink

Mogelijk ziet u het volgende:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Als u het bovenstaande bericht ziet, betekent dit dat L2F met succes de PPP-link van het stapellid heeft geprojecteerd die eerst de inkomende oproep naar het stapellid heeft gebracht waar de bundelinterface voor dezelfde client verblijft (of zal maken, zoals in het offload-scenario).

Een veel voorkomende fout is het niet definiëren van de gebruikersnaam voor de gemeenschappelijke stapelnaam (stackq) of het niet aanpassen van het stapelwachtwoord op alle stapelleden.

Geef de volgende opdracht uit:

  debug vpdn l2f-error

De volgende resultaten van het bericht:

  L2F Tunnel authentication failed for stackq

Corrigeer de gebruikersnaam en de wachttijd op elk stapel lid in dit geval.

Gerelateerde informatie

• Deel 1 van dit document
• Virtual Access PPP-functies in Cisco IOS-software
• Inzicht VPDN
• Technische ondersteuning - Cisco-systemen