Multilink de multibase PPP (MMP)

Introduction

Este documento descreve o suporte a PPP Multilink (MP) em um ambiente de pilha ou multibase (às vezes chamado de MMP, para PPP Multilink Multibase), em plataformas de servidor de acesso da Cisco Systems.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Termos relacionados

Este é um glossário de termos que este documento usa:

• Servidor de acesso—Plataformas de servidor de acesso Cisco, incluindo ISDN e interfaces assíncronas para fornecer acesso remoto.

• L2F—Protocolo de Encaminhamento de Camada 2 (L2 - Layer 2 Forwarding Protocol) (RFC de Rascunho Experimental). Essa é a tecnologia de nível de enlace adjacente para os MP e VPN multibase.

• Link — Um ponto de conexão fornecido por um sistema. Um link pode ser uma interface de hardware dedicada (como uma interface assíncrona) ou um canal em uma interface de hardware multicanal (como uma PRI ou BRI).

• MP—Protocolo PPP Multilink (consulte RFC 1717 ).

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

• PPP—Protocolo Ponto-a-Ponto (consulte RFC 1331 ).

• Grupo giratório—Um grupo de interfaces físicas alocadas para fazer ou receber chamadas. O grupo atua como um pool do qual você pode usar qualquer link para fazer ou receber chamadas.

• SGBP — Protocolo de oferta de grupo de pilha.

• Grupo de Pilha—Uma coleção de dois ou mais sistemas configurados para operar como um grupo e suportar pacotes MP com links em sistemas diferentes.

• VPDN — Rede de discagem privada virtual. Encaminhamento de links PPP de um provedor de serviços de Internet (ISP) para um gateway local Cisco.

• Vtemplate — Interface de modelo virtual.

Observação: Para obter informações sobre RFCs referenciados neste documento, consulte RFCs e Outros Stds Suportados no Cisco IOS Release 11.3-No. 523, um boletim do produto; Obtendo RFCs e Documentos Padrão; ou RFC Index para um link diretamente ao InterNIC.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Definição do problema

O MP fornece aos usuários largura de banda adicional sob demanda com a capacidade de dividir e recombinar pacotes em um pipe lógico (pacote) formado por vários links.

Isso reduz a latência de transmissão nos links de WAN lentos e também fornece um método para aumentar a unidade máxima de recepção.

Na extremidade de transmissão, o MP faz a fragmentação de um pacote simples em vários pacotes a serem transmitidos por vários links PPP. Na extremidade receptora, o MP oferece a remontagem de pacote a partir de múltiplos enlaces de PPP para voltar ao pacote original.

A Cisco suporta MP para sistemas finais autônomos, ou seja, vários links MP do mesmo cliente podem terminar no servidor de acesso. No entanto, os ISPs, por exemplo, preferem alocar convenientemente um único número rotativo para várias PRIs em vários servidores de acesso e tornar sua estrutura de servidor escalável e flexível para as necessidades da empresa.

No Cisco IOS® Software Release 11.2, a Cisco fornece essa funcionalidade, de modo que vários links MP do mesmo cliente possam terminar em diferentes servidores de acesso. Embora links MP individuais do mesmo pacote possam realmente terminar em diferentes servidores de acesso, no que diz respeito ao cliente MP, isso é semelhante à terminação em um único servidor de acesso.

Para atingir esse objetivo, o MP usa MP multichassi.

Visão geral funcional

A Figura 1 ilustra o uso do MP em um único servidor de acesso Cisco para suportar esse recurso.

Figura 1 - MP em um único servidor de acesso Cisco

A figura 1 ilustra a maneira como as interfaces de membro MP estão conectadas a um feixe de interface. Em um sistema autônomo sem MP multichassi habilitado, as interfaces membros são sempre interfaces físicas.

Para suportar um ambiente empilhado, além do MP, estes três subcomponentes adicionais são necessários:

• SGBP

• Vtemplate

• L2F

As próximas seções deste documento explicam esses componentes em detalhes.

SGBP

Em um ambiente de vários servidores de acesso, o administrador de rede pode designar um grupo de servidores de acesso para pertencer a um grupo de pilhas.

Suponha que um grupo de pilha consiste no Sistema A e no Sistema B. Um cliente MP remoto chamado userx tem o primeiro link MP terminando no Sistema A (systema). O pacote userx é formado em systema. O próximo enlace MP do userx termina agora no Sistema B (systemb). O SGBP localiza esse pacote no local em que o usuário reside no sistema. Neste ponto, outro componente - L2F - projeta o segundo link MP do systemb para o systema. O link MP projetado unirá o pacote no sistema.

Assim, o SGBP localiza o local do pacote de um membro da pilha dentro de um grupo de pilhas definido. O SGBP também faz a intermediação de um membro de empilhamento designado da criação de pacote. No exemplo, quando o primeiro link MP é recebido no systema, tanto o systema como o systemb (e todos os outros membros do grupo de pilhas) realmente disputam a criação do pacote. A oferta do sistema é maior (porque ele aceitou o primeiro link), então o SGBP o designa para a criação do pacote.

Esta descrição do processo de licitação SGBP é um pouco simplista. Na prática, uma oferta SGBP de um membro da pilha é uma função de localidade, uma métrica ponderada configurável pelo usuário, tipo de CPU, número de pacotes MP e assim por diante. Esse processo de licitação permite a criação de pacotes em um sistema designado, mesmo em um sistema que não tenha interfaces de acesso. Por exemplo, um ambiente empilhado pode consistir em 10 sistemas de servidor de acesso e dois 4500s — um grupo de pilha de 12 membros de pilha.

Observação: quando os lances são iguais, como entre dois 4500s, o SGBP designa aleatoriamente um como o vencedor do lance. Você pode configurar os 4500s para que eles sempre ultrapassem os outros membros da pilha. Os 4500s, assim, tornam-se servidores MP multichassis de descarga especializados em fragmentadores e remontadores de pacotes MP—uma tarefa adequada para a sua maior potência de CPU em relação aos servidores de acesso.

Em resumo, SGBP é o local e o mecanismo de arbitração de MP multichassis.

Interfaces de acesso virtual

As interfaces de acesso virtual servem como interfaces de pacote (consulte as Figuras 1 e Figura 2) e links PPP projetados (consulte Figura 2). Essas interfaces são criadas dinamicamente e devolvidas ao sistema sob demanda.

As interfaces de modelo virtuais servem como repositórios de informações de configuração a partir dos quais as interfaces de acesso virtual são clonadas. As configurações da interface do discador servem como outra fonte de informações de configuração. O método para escolher a origem da configuração a partir da qual clonar uma interface de acesso virtual torna-se aparente no PPP Multilink Multichassi (MMP) (Parte 2).

L2F

O L2F fornece a projeção real do enlace PPP para um sistema final designado.

O L2F executa a operação PPP padrão até a fase de autenticação, onde o cliente remoto é identificado. A fase de autenticação não está localmente concluída. L2F, fornecido com o membro da pilha de destino do SGBP, projeta o enlace PPP para o membro da pilha de destino, em que a fase de autenticação é retomada e concluída no enlace PPP projetado. O sucesso ou a falha da autenticação final é, portanto, realizada no membro da pilha de destino.

A interface física original que aceitou a chamada recebida é dita como L2F encaminhada. A interface correspondente que L2F cria dinamicamente (quando a autenticação PPP é bem-sucedida) é uma interface de acesso virtual projetada.

Observação: a interface de acesso virtual projetada também é clonada da interface de modelo virtual (se definida).

A Figura 2 descreve um grupo de pilha stackq que consiste em systema, systemb e systemc.

Figura 2: Chamada de cliente em uma pilha

1. Chamadas userx do cliente. O primeiro link no sistema recebe a chamada. O SGBP tenta localizar qualquer pacote pelo userx existente entre os membros do grupo de pilha. Se não houver nenhum e como o MP é negociado no PPP, uma interface de pacote é criada no sistema.

2. systemb recebe a segunda chamada de userx. O SGBP ajuda a determinar se o sistema é onde o pacote reside. O L2F ajuda a encaminhar o link de systemb para systema. Um enlace de PPP projetado é criado no sistema. O enlace projetado é, em seguida, unido à interface do pacote.

3. systemc recebe a terceira chamada de userx. Novamente, o SGBP identifica que o pacote está no "systema". O L2F é usado para encaminhar o enlace de systemc para systema. Um enlace de PPP projetado é criado no sistema. O enlace projetado é, em seguida, unido à interface do pacote.

Observação: uma interface de pacote representa o pacote no sistema. Para cada chamador exclusivo, as interfaces de membro de MP desse mesmo chamador terminam em ou originam-se de um feixe de interface.

Interface de usuário final

A interface de usuário Vtemplate é especificada nominalmente aqui. Consulte a especificação funcional do molde virtual para obter detalhes.

SGBP

1. sgbp group <name>

   Esse comando global define um grupo de pilhas, atribui um nome ao grupo e torna o sistema um membro desse grupo de pilhas.

   Observação: você pode definir globalmente apenas um grupo de pilhas.

   Defina um grupo de pilha chamado stackq:

   systema(config)#sgbp group stackq
   

   Observação: o desafio PPP CHAP ou a solicitação PPP PAP do sistema agora tem o nome stackq. Quando você define o nome do grupo de pilhas no servidor de acesso, o nome geralmente substitui o nome de host definido para o mesmo sistema.

2. sgbp member <peer-name> <peer-IP-address>

   Esse comando global especifica os pares no grupo de pilhas. Nesse comando, <peer-name> é o nome do host e <peer-IP-address> é o endereço IP do membro da pilha remota. Portanto, é necessário definir uma entrada para cada membro de grupo da pilha exceto você. um Servidor de Nomes de Domínio (DNS) pode resolver os nomes de pares. Se você tiver um DNS, não precisará inserir o endereço IP.

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

3. sgbp seed-bid {default | descarregamento | somente encaminhamento | <0-9999>}

   O peso configurável que o membro da pilha oferece para um pacote.

   Se o parâmetro padrão for definido para todos os membros da pilha, o membro da pilha que recebe a primeira chamada para o usuário userx sempre ganha a oferta e hospeda a interface do conjunto mestre. Todas as chamadas subseqüentes do mesmo usuário para o projeto de outro membro da pilha para este membro da pilha. Se você não definir um sgbp seed-bid, o default será usado.

   Se offload for definido, ele envia o bid pré-calibrado por plataforma que se aproxima da potência da CPU, menos a carga do pacote.

   Se < 0-9999 > estiver configurado, a oferta enviada será o valor configurado pelo usuário menos a carga do pacote.

   A carga do pacote é definida como o número de pacotes ativos no membro da pilha.

   1. Quando você tiver membros de pilha equivalentes empilhados para receber chamadas em um grupo rotativo através de várias PRIs, emita o comando sgbp seed-bid default all stack members. Um exemplo de membros de pilha equivalentes seria um grupo de pilha de quatro AS5200s. O membro da pilha que recebe a primeira chamada para o usuário userx sempre ganha a oferta e hospeda a interface de conjunto mestre. Todas as chamadas subseqüentes do mesmo usuário para outro membro da pilha são direcionadas a este membro da pilha. Se várias chamadas chegarem ao mesmo tempo em vários membros de empilhamento, o mecanismo de quebra de ligação do SGBP quebrará a ligação.

   2. Quando você tiver uma CPU de maior potência disponível como um membro da pilha em relação aos outros membros da pilha, talvez queira alavancar a potência relativa mais alta desse membro da pilha sobre o resto (por exemplo, uma ou mais CPUs de maior potência disponíveis como um membro da pilha em relação aos outros membros da pilha semelhantes; por exemplo, um 4500 e quatro AS5200s).Você pode definir o membro designado da pilha de alta potência como o servidor de descarga com o comando sgbp seed-bid offload. Neste caso, o servidor de descarga hospeda o pacote mestre. Todas as chamadas de outros membros da pilha são projetadas para esse membro da pilha. Na verdade, um ou mais servidores de descarga podem ser definidos; se as plataformas forem iguais (equivalentes), os lances serão iguais. O mecanismo tie-breaking do SGBP quebra o vínculo e designa uma das plataformas como vencedora.

      Observação: se você designar duas plataformas diferentes como servidores de descarga, aquela com maior potência de CPU ganhará a oferta.

   3. Se você tiver variado ou exatamente as mesmas plataformas e quiser designar uma ou mais plataformas como servidores de descarga, você pode definir manualmente o valor do lance para ser significativamente maior que o resto com o comando sgbp seed-bid 999. Por exemplo, um 4700 (designado pelo maior lance de semente), dois 4000s e um 7000. Para determinar o valor de oferta inicial associado às suas plataformas específicas, use show sgbp.

   4. Em um ambiente multichassi onde os membros da pilha de front-end sempre descarregam para um ou mais servidores de descarregamento, há casos em que o membro da pilha de front-end realmente não pode descarregar, como quando o grupo multilink é formado localmente. Esse problema poderá ocorrer, por exemplo, quando todos os servidores de descarga estiverem inativos. Se o administrador de rede preferir que a chamada recebida desligue, emita o comando sgbp seed-bid forward-only.

4. sgbp ppp-forward

   Quando o sgbp ppp-forward é definido, tanto as chamadas PPP quanto as MP são projetadas para o vencedor da oferta SGBP. Por padrão, apenas as chamadas MP são encaminhadas.

5. show sgbp

   Esse comando mostra o estado dos membros do grupo de pilhas. Os estados podem ser ACTIVE, CONNECTING, WAITINFO ou IDLE. ATIVO em cada membro do grupo de pilhas é o melhor estado. CONNECTING e WAITINFO são estados de transição e você só deve vê-los durante a transição para ATIVE. IDLE indica que o grupo de pilhas systema não pode detectar o membro da pilha remota systemd. Se systemd for desativado para manutenção, por exemplo, não há motivo para preocupação. Caso contrário, observe alguns problemas de roteamento ou outros problemas entre esse membro da pilha e systemd.

   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. show sgbp queries

   Exibe o valor de oferta de seed atual.

   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>

   Esse é o número de modelos virtuais pelo qual a interface de pacotes MP clona os parâmetros da interface. Veja um exemplo de como um MP se associa a um modelo virtual. Uma interface de modelo virtual também deve ser definida:

   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. show ppp multilink

   Esse comando exibe as informações do pacote para os pacotes 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)
   

   Este exemplo mostra, no sistema de membro de grupo de pilha no grupo de pilha stackq, que o userx do pacote tem sua interface de pacote definida como Virtual-Access4. Duas interfaces de membro estão unidas a essa interface de pacote. O primeiro é um canal PRI local e o segundo é uma interface projetada do membro do grupo de pilhas systemb.

Examples

Consulte PPP Multilink Multibase (MMP) (Parte 2) para ver estes exemplos:

• AS5200 em uma pilha com discadores

• Utilizando um servidor de offload

• Servidor de offload com interfaces físicas

• Interfaces assíncronas, seriais e outras interfaces não-discadoras

• Discagem a partir de um multichassi

• Discando para um multibase

E também consulte as seções sobre:

• Configuração e restrições

• Troubleshooting

Informações Relacionadas

• Páginas de suporte à tecnologia de discagem e acesso
• Suporte Técnico e Documentação - Cisco Systems