MMP (Multicassis Multilink PPP)

Introduzione

In questo documento viene descritto il supporto per Multilink PPP (MP) in un ambiente stack o multicassis (talvolta denominato MMP, per Multilink PPP), sulle piattaforme access server di Cisco Systems.

Prerequisiti

Requisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Termini correlati

Questo è un glossario dei termini usati nel presente documento:

• Server di accesso: piattaforme server di accesso Cisco, incluse interfacce ISDN e asincrone per fornire accesso remoto.

• L2F—Layer 2 (L2) Forwarding Protocol (Experimental Draft RFC). Questa è la tecnologia sottostante a livello di collegamento sia per MP multicassis che per VPN.

• Collegamento (Link) - Punto di connessione fornito da un sistema. Un collegamento può essere un'interfaccia hardware dedicata (ad esempio un'interfaccia asincrona) o un canale su un'interfaccia hardware multicanale (ad esempio PRI o BRI).

• MP - Multilink PPP Protocol (fare riferimento alla RFC 1717 ).

• Multicassis MP—MP + SGBP + L2F + Vtemplate.

• PPP: protocollo point-to-point (fare riferimento alla RFC 1331 ).

• Gruppo rotante: gruppo di interfacce fisiche allocate per la chiamata in uscita o la ricezione di chiamate. Il gruppo funge da pool da cui è possibile utilizzare qualsiasi collegamento per effettuare chiamate in uscita o ricevere chiamate.

• SGBP—Stack Group Bidding Protocol.

• Stack Group - Insieme di due o più sistemi configurati per funzionare come gruppo e supportare bundle MP con collegamenti su sistemi diversi.

• VPDN: Virtual Private Dialup Network. Inoltro di collegamenti PPP da un provider di servizi Internet (ISP) a un Cisco Home Gateway.

• Vtemplate: interfaccia di modello virtuale.

Nota: per informazioni sulle RFC a cui si fa riferimento nel presente documento, vedere le RFC e gli altri std supportati in Cisco IOS versione 11.3-n. 523, un bollettino sul prodotto; Ottenere RFC e documenti relativi alle norme; o RFC Index per un collegamento diretto a InterNIC.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Descrizione del problema

MP offre agli utenti una larghezza di banda aggiuntiva su richiesta con la possibilità di dividere e ricombinare i pacchetti su una pipe logica (bundle) formata da più collegamenti.

Ciò riduce la latenza di trasmissione sui collegamenti WAN lenti e fornisce anche un metodo per aumentare l'unità di ricezione massima.

All'estremità di trasmissione, il protocollo MP consente di frammentare un singolo pacchetto in più pacchetti da trasmettere su più collegamenti PPP. All'estremità ricevente, MP consente di ricomporre il pacchetto da più collegamenti PPP al pacchetto originale.

Cisco supporta il protocollo MP su sistemi terminali autonomi, ovvero più collegamenti MP dello stesso client possono terminare sul server di accesso. Tuttavia, gli ISP, per esempio, preferiscono assegnare in modo conveniente un singolo numero di rotazione a più PRI su più server di accesso e rendere la loro struttura server scalabile e flessibile per le esigenze aziendali.

Nel software Cisco IOS® versione 11.2, Cisco offre tali funzionalità, in modo che più collegamenti MP dello stesso client possano terminare su server di accesso diversi. Mentre i singoli collegamenti MP dello stesso bundle possono in realtà terminare su server di accesso diversi, per quanto riguarda il client MP, ciò è simile alla terminazione su un singolo server di accesso.

Per raggiungere questo obiettivo, MP utilizza MP multicassis.

Panoramica funzionale

Nella figura 1 viene illustrato l'utilizzo di MP su un singolo server di accesso Cisco per supportare questa funzione.

Figura 1 - MP su un singolo server di accesso Cisco

La Figura 1 mostra come le interfacce membro MP sono collegate a un'interfaccia di bundle. In un sistema standalone senza MP multicassis abilitato, le interfacce membro sono sempre interfacce fisiche.

Per supportare un ambiente in stack, oltre a MP, sono necessari questi tre sottocomponenti aggiuntivi:

• SGBP

• Vtemplate

• L2F

Nelle sezioni seguenti di questo documento vengono descritti in dettaglio tali componenti.

SGBP

In un ambiente con più server di accesso, l'amministratore di rete può designare un gruppo di server di accesso come appartenente a un gruppo di stack.

Si supponga che uno stack group sia composto dal sistema A e dal sistema B. Un client MP remoto chiamato userx ha il primo collegamento MP terminato sul sistema A (sistema). Il bundle userx è formato in systema. Il successivo collegamento MP dell'utente x termina ora sul sistema B (systemb). SGBP individua il bundle in cui l'utente x risiede sul sistema. A questo punto, un altro componente, L2F, proietta il secondo collegamento MP da systemb a systema. Il collegamento MP proiettato si unisce al fascio in corrispondenza di systema.

In questo modo, SGBP individua la posizione del bundle di un membro dello stack all'interno di un gruppo di stack definito. Inoltre, SGBP sceglie un membro dello stack designato per la creazione del bundle. Nell'esempio, quando si riceve il primo collegamento MP su systema, sia systema che systemb (e tutti gli altri membri dello stack group) fanno un'offerta per la creazione del bundle. L'offerta di systema è più alta (perché ha accettato il primo collegamento), quindi SGBP la designa per la creazione del bundle.

La descrizione della procedura di gara per la SGBP è alquanto semplicistica. In pratica, un'offerta SGBP di un membro dello stack è una funzione della località, una metrica ponderata configurabile dall'utente, il tipo di CPU, il numero di bundle MP e così via. Questo processo di licitazione consente la creazione del bundle su un sistema designato, anche se non dispone di interfacce di accesso. Ad esempio, un ambiente in stack può essere composto da 10 sistemi server di accesso e da due switch 4500: un gruppo di stack di 12 membri.

Nota: quando le offerte sono uguali, ad esempio tra due 4500, SGBP ne designa casualmente uno come vincitore dell'offerta. È possibile configurare lo switch 4500 in modo che le loro offerte siano sempre superiori a quelle degli altri membri dello stack. Gli switch 4500 diventano quindi server MP multicassis offload specializzati in pacchetti MP, frammentatori e riassemblatori, un'attività adatta alla maggiore potenza della CPU rispetto ai server di accesso.

In breve, SGBP è la posizione e il meccanismo di arbitrato del MP multicassis.

Interfacce di accesso virtuale

Le interfacce di accesso virtuale fungono sia da interfacce di bundle (vedere la Figura 1 e la Figura 2) sia da collegamenti PPP proiettati (vedere la Figura 2). Queste interfacce vengono create dinamicamente e restituite al sistema su richiesta.

Le interfacce dei modelli virtuali fungono da repository di informazioni di configurazione da cui vengono clonate le interfacce di accesso virtuale. Le configurazioni dell'interfaccia dialer costituiscono un'altra fonte di informazioni di configurazione. Il metodo per scegliere l'origine della configurazione da cui duplicare un'interfaccia di accesso virtuale diventa evidente in Multicassis Multilink PPP (MMP) (Parte 2).

L2F

L2F fornisce la proiezione del collegamento PPP effettivo su un sistema terminale designato.

L2F esegue operazioni PPP standard fino alla fase di autenticazione, in cui viene identificato il client remoto. La fase di autenticazione non viene completata localmente. L2F, fornito con il membro dello stack di destinazione da SGBP, proietta il collegamento PPP sul membro dello stack di destinazione, dove la fase di autenticazione viene ripresa e completata sul collegamento PPP previsto. In questo modo, la riuscita o l'errore dell'autenticazione finale viene eseguito sul membro dello stack di destinazione.

L'interfaccia fisica originale che ha accettato la chiamata in ingresso è detta L2F inoltrata. L'interfaccia corrispondente creata dinamicamente da L2F (quando l'autenticazione PPP ha esito positivo) è un'interfaccia di accesso virtuale proiettata.

Nota: anche l'interfaccia di accesso virtuale prevista viene duplicata dall'interfaccia del modello virtuale (se definita).

La Figura 2 descrive uno stack group stackq composto da system, systemb e systemc.

Figura 2 - Chiamata client in uno stack

1. Chiamate utente client. Il primo collegamento di System riceve la chiamata. SGBP cerca di individuare un bundle in base all'utente x esistente tra i membri dello stack group. Se non è presente alcun pacchetto e poiché MP viene negoziato sul PPP, viene creata un'interfaccia di bundle sul sistema.

2. systemb riceve la seconda chiamata da userx. SGBP aiuta a determinare che il sistema è dove risiede il bundle. L2F consente di inoltrare il collegamento da systemb a systema. In System viene creato un collegamento PPP previsto. Il link proiettato viene quindi unito all'interfaccia del fascio.

3. systemc riceve la terza chiamata da userx. Anche in questo caso, SGBP individua il sistema in cui risiede il bundle. L2F viene utilizzato per inoltrare il collegamento da systemc a systema. In System viene creato un collegamento PPP previsto. Il link proiettato viene quindi unito all'interfaccia del fascio.

Nota: un'interfaccia di fascio rappresenta il fascio nel sistema. Per ogni chiamante univoco, le interfacce membro MP dello stesso chiamante terminano o hanno origine da un'interfaccia bundle.

Interfaccia utente finale

L'interfaccia utente di Vtemplate è specificata qui in modo nominale. Per ulteriori informazioni, consultare la specifica funzionale del modello virtuale.

SGBP

1. sgbp group <nome>

   Questo comando globale definisce un gruppo di stack, assegna un nome al gruppo e rende il sistema membro di tale gruppo.

   Nota: è possibile definire un solo gruppo di stack a livello globale.

   Definire un gruppo di stack chiamato stackq:

   systema(config)#sgbp group stackq
   

   Nota: la richiesta CHAP PPP o la richiesta PAP PPP inviata da system ora ha il nome stackq. Quando si definisce il nome del gruppo di stack sul server di accesso, in genere il nome sostituisce il nome host definito per lo stesso sistema.

2. sgbp member <nome-peer> <indirizzo-IP-peer>

   Questo comando globale specifica i peer nel gruppo di stack. In questo comando, <peer-name> è il nome host e <peer-IP-address> è l'indirizzo IP del membro remoto dello stack. Pertanto, è necessario definire una voce per ciascun membro del gruppo di stack che non sia l'utente stesso. un DNS (Domain Name Server) può risolvere i nomi dei peer. Se si dispone di un DNS, non è necessario immettere l'indirizzo IP.

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

3. seed-bid sgbp {predefinito | offload | forward-only | <0-9999>}

   Il peso configurabile offerto dal membro dello stack per un bundle.

   Se il parametro default viene definito su tutti i membri dello stack, il membro dello stack che riceve la prima chiamata per l'utente userx vince sempre l'offerta e ospita l'interfaccia del bundle principale. Tutte le chiamate successive dallo stesso utente a un altro progetto membro dello stack a questo membro dello stack. Se non si definisce un'offerta di vendita sgbp, viene utilizzata l'impostazione predefinita.

   Se è definito l'offload, invia l'offerta precalibrata per piattaforma che approssima la potenza della CPU, meno il carico del bundle.

   Se < 0-9999 > è configurato, l'offerta inviata è il valore configurato dall'utente meno il caricamento del bundle.

   Il carico del bundle è definito come il numero di bundle attivi sul membro dello stack.

   1. Quando si dispone di membri equivalenti dello stack impilati per ricevere chiamate in un gruppo rotante su più PRI, usare il comando sgbp seed-bid predefinito su tutti i membri dello stack. Un esempio di membri equivalenti dello stack è un gruppo di stack composto da quattro AS5200. Il membro dello stack che riceve la prima chiamata per l'utente userx vince sempre l'offerta e ospita l'interfaccia del bundle master. Tutte le chiamate successive allo stesso utente a un altro membro dello stack inviano un progetto a questo membro dello stack. Se le chiamate multiple pervengono simultaneamente su più membri dello stack, il meccanismo di interruzione del collegamento SGBP interrompe il collegamento.

   2. Quando si ha a disposizione una CPU di maggiore potenza come membro dello stack rispetto agli altri membri dello stack, si potrebbe desiderare di sfruttare la potenza relativamente più elevata di quel membro dello stack rispetto al resto (ad esempio, una o più CPU di maggiore potenza disponibili come membro dello stack rispetto agli altri membri simili dello stack; ad esempio, uno switch 4500 e quattro AS5200).È possibile impostare il membro dello stack ad alta potenza designato come server di offload con il comando sgbp seed-bid offload. In tal caso, il server offload ospita il bundle master. Tutte le chiamate da altri membri dello stack vengono proiettate su questo membro dello stack. In realtà, è possibile definire uno o più server offload; se le piattaforme sono uguali (equivalenti), le offerte sono uguali. Il meccanismo SGBP rompe il legame e designa una delle piattaforme come vincitrice.

      Nota: se si designano due piattaforme diverse come server offload, l'offerta verrà aggiudicata a quella con la potenza di CPU più elevata.

   3. Se si dispone di più piattaforme o se si desidera designare una o più piattaforme come server di offload, è possibile impostare manualmente il valore dell'offerta in modo che sia significativamente superiore al resto con il comando sgbp seed-bid 9999. Ad esempio, un 4700 (indicato dall'offerta di partenza più alta), due 4000 e un 7000. Per determinare il valore dell'offerta iniziale associato a una particolare piattaforma, usa show sgbp.

   4. In un ambiente a più chassis in cui i membri dello stack front-end scaricano sempre su uno o più server offload, in alcuni casi il membro dello stack front-end non può effettivamente eseguire l'offload, ad esempio quando il bundle multilink viene formato localmente. Questo può accadere, ad esempio, quando tutti i server offload sono inattivi. Se l'amministratore di rete preferisce interrompere la chiamata in arrivo, usare il comando sgbp seed-bid forward-only.

4. sgbp ppp-forward

   Quando si definisce sgbp ppp-forward, sia le chiamate PPP che le chiamate MP vengono proiettate al vincitore dell'offerta SGBP. Per impostazione predefinita, vengono inoltrate solo le chiamate MP.

5. show sgbp

   Con questo comando viene mostrato lo stato dei membri dello stack group. Gli stati possono essere ACTIVE, CONNECTING, WAITINFO o IDLE. Lo stato attivo su ciascun membro del gruppo di stack è il migliore. CONNECTING e WAITINFO sono stati di transizione e devono essere visualizzati solo durante la transizione ad ACTIVE. IDLE indica che il sistema del gruppo di stack non è in grado di rilevare il membro remoto del sistema dello stack. Se, ad esempio, il sistema viene disattivato per ragioni di manutenzione, non vi sono motivi di preoccupazione. In caso contrario, esaminare alcuni problemi di routing o altri problemi tra il membro dello stack e il dispositivo system.

   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. mostra query sgbp

   Visualizza il valore dell'offerta iniziale corrente.

   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
   

MP

1. multilink virtual-template <1-9>

   Questo è il numero del modello virtuale con cui l'interfaccia del bundle MP clona i propri parametri di interfaccia. Di seguito è riportato un esempio di associazione di un pannello di gestione a un modello virtuale. È inoltre necessario definire un'interfaccia di modello virtuale:

   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. mostra connessione multipla ppp

   Questo comando visualizza le informazioni sul bundle per i bundle MP:

   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)
   

   Nell'esempio viene mostrato, sul sistema membro dello stack group sullo stack group stackq, che l'interfaccia del bundle userx è impostata su Virtual-Access4. Due interfacce membro vengono unite a questa interfaccia del bundle. Il primo è un canale PRI locale, il secondo è un'interfaccia proiettata dal sistema membro dello stack group.

Esempi

Per ulteriori informazioni, fare riferimento al documento MMP (Multicassis Multilink PPP) (parte 2):

• AS5200 in uno stack con dialer

• Utilizzo di un server offload

• Server offload con interfacce fisiche

• Interfacce asincrone, seriali e altre interfacce non dialer

• Chiamata in uscita da un multicassis

• Connessione a uno chassis multicast

Consultare inoltre le sezioni relative a:

• Configurazione e limitazioni

• Risoluzione dei problemi

Informazioni correlate

• Pagine di supporto per la tecnologia di composizione e accesso
• Documentazione e supporto tecnico – Cisco Systems