WAN : Point-to-Point Protocol (PPP)

Multilink de multibase PPP (MMP)

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice

L2F
MP

Introdução

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.

Pré-requisitos

Requisitos

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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 termo que este documento use:

  • Servidor de acesso — Plataformas de servidor de acesso Cisco, incluindo o ISDN e os interface assíncrono para fornecer o Acesso remoto.

  • L2F — Protocolo de encaminhamento da camada 2 (L2) (esboço experimental RFC). Essa é a tecnologia de nível de enlace adjacente para os MP e VPN multibase.

  • Link — Um ponto de conexão que um sistema forneça. Um link pode ser uma interface de hardware dedicada (tal como um interface assíncrono) ou um canal em uma interface de hardware multichannel (tal como um PRI ou um BRI).

  • MP — Protocolo do Multilink PPP (refira o RFC 1717leavingcisco.com ).

  • Multichassis MP — MP + SGBP + L2F + vtemplate.

  • PPP — Protocolo Point-to-Point (refira o RFC 1331leavingcisco.com ).

  • Grupo giratório — Um grupo de interface física atribuído para discar para fora ou receber atendimentos. O grupo atua como um pool de que você pode usar todo o link para discar para fora ou receber atendimentos.

  • SGBP — Protocolo stack group bidding.

  • Grupo de pilhas — Uma coleção de dois ou mais sistemas que são configurados para se operar como um grupo e para apoiar pacotes MP com links em sistemas diferentes.

  • VPDN — Virtual Private Dialup Network. Encaminhamento de links PPP de um provedor de serviços de Internet (ISP) para um gateway local Cisco.

  • Vtemplate — Relação virtual do molde.

Nota: Para obter informações sobre dos RFC providos neste documento, veja os RFC e os outros STD apoiados no Cisco IOS Release 11.3-No. 523, um boletim de produto; Obtendo RFC e documentos dos padrões; ou deslocamento predeterminado RFCleavingcisco.com para um link diretamente ao InterNIC.

Convenções

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 usuários a largura de banda adicional por encomenda com a capacidade para rachar e para recombine pacotes através de uma tubulação lógica (pacote) essa os links múltiplos formam.

Isto reduz a latência da transmissão através dos enlaces de WAN lentos, e igualmente fornece um método para aumentar o Maximum Receive Unit.

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.

Cisco apoia o MP aos sistemas finais autônomos, isto é, os links múltiplos MP do mesmo cliente podem terminar no servidor de acesso. Contudo, os ISP, por exemplo, preferem atribuir convenientemente um único número giratório aos pris múltiplo através dos servidores de acesso múltiplo, e fazem seu server estruturar escalável e flexível às necessidades de negócio.

No Software Release 11.2 de Cisco IOS� Cisco fornece tal funcionalidade, de modo que os links múltiplos MP do mesmo cliente possam terminar em servidores de acesso diferentes. Quando os links individuais MP do mesmo pacote puderem realmente terminar em servidores de acesso diferentes, tanto quanto o cliente MP, este é similar à terminação em um único servidor de acesso.

A fim conseguir este objetivo, o MP usa o multichassis MP.

Visão geral funcional

Figura 1 ilustra o uso do MP em um único Cisco access server apoiar esta característica.

Figura 1 – MP em um único Cisco access server

/image/gif/paws/14942/figure1-mmp.gif

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.

A fim apoiar um ambiente empilhado, além do que o MP, estes três subcomponents adicionais são necessários:

  • SGBP

  • Vtemplate

  • L2F

As próximas seções deste documento explicam estes componentes em detalhe.

SGBP

Em um ambiente de servidor de acesso múltiplo, o administrador de rede pode designar um grupo de servidores de acesso para pertencer a um grupo de pilhas.

Supõe que um grupo de pilhas consiste no sistema A e no sistema B. Um cliente remoto MP chamado userx manda o primeiro link MP terminar 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 momento, um outro componente — L2F — projeta o segundo link MP do systemb ao systema. O link MP projetado unirá o pacote no sistema.

O SGBP encontra assim o lugar do pacote de um membro de 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 estiver recebido no systema, systema e systemb (e todos membros restantes do grupo de pilhas) oferecidos realmente para a criação de pacote. A oferta do systema é mais alta (porque aceitou o primeiro link), assim que o SGBP designa-o para a criação de pacote.

Esta descrição do processo de oferta SGBP é um tanto simplista. Na prática, um SGBP oferecido de um membro de pilha é uma função da localidade, uma métrica tornada mais pesada configuráveis pelo usuário, tipo de CPU, número de MP empacota, e assim por diante. Este processo de leilão permite a criação de pacote em um sistema designado — mesmo um que não tem nenhuma interfaces de acesso. Por exemplo, um ambiente empilhado pode consistir em sistemas do servidor de acesso 10 e em dois 4500s — um grupo de pilhas de 12 membros de pilha.

Nota: Quando as disputas são iguais, como entre dois 4500s, o SGBP designa um como vencedor da disputa. Você pode configurar o 4500s de modo que dê mais sempre os outros membros de pilha. Os 4500s tornam-se assim offload os server do multichassis MP especializados em fragmenters e em reassemblers dos pacotes MP — uma tarefa serida para sua potência de CPU mais alta relativo aos servidores de acesso.

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

Interfaces de acesso virtual

Links de PPP projetados do saque das interfaces de acesso virtual como o pacote conecta (vê figuras 1 e figura 2) e (veja figura 2). Estas relações dinamicamente são criadas e retornadas ao sistema por encomenda.

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 o origem de configuração de que clonar uma interface de acesso virtual se torna aparente no Multilink de Multichassi PPP (MMP) (parte 2).

L2F

O L2F prevê a projeção real do link de PPP a 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 de autenticação ou a falha final são executados assim no membro de pilha de destino.

A interface física original que aceitou a chamada recebida seriam o L2F enviada. A interface correspondente que o L2F cria dinamicamente (quando a autenticação de PPP sucede) é uma interface de acesso virtual projetada.

Nota: A interface de acesso virtual projetada é clonada igualmente da relação virtual do molde (se definido).

Figura 2 descreve um stackq do grupo de pilhas que consiste no systema, no systemb, e no systemc.

Figura 2 – Cliente que chama em uma pilha

figure2-mmp.gif

  1. Atendimentos do userx do cliente. O primeiro link no systema recebe o atendimento. O SGBP tenta localizar qualquer pacote pelo userx existente entre os membros do grupo de pilha. Se não há nenhuns, e porque o MP está negociado no PPP, um bundle interface é criado no systema.

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

  3. o systemc recebe o terceiro atendimento do 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.

Nota: Um bundle interface representa o pacote no systema. 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. Refira a especificação funcionalleavingcisco.com do molde virtual para detalhes.

SGBP

  1. <name> do grupo do sgbp

    Este comando global define um grupo de pilhas, atribui um nome ao grupo, e faz ao sistema um membro desse grupo de pilhas.

    Nota: Você pode definir somente um grupo de pilhas globalmente.

    Defina um grupo de pilha chamado stackq:

    systema(config)#sgbp group stackq
    

    Nota: O desafio do PPP CHAP ou o pedido PPP PAP do systema carregam agora o stackq do nome. Quando você define o nome de grupo de pilha no servidor de acesso, o nome substitui geralmente o hostname definido para o mesmo sistema.

  2. <peer-IP-address> do <peer-name> do membro do sgbp

    Este comando global especifica pares no grupo de pilhas. Neste comando, o <peer-name> é o nome de host e o <peer-IP-address> é o endereço IP de Um ou Mais Servidores Cisco ICM NT do membro de pilha remoto. Portanto, é necessário definir uma entrada para cada membro de grupo da pilha exceto você. um Domain Name Server (DNS) pode resolver os nomes do par. Se você tem um DNS, você não precisa de incorporar o endereço IP de Um ou Mais Servidores Cisco ICM NT.

    systema(config)#sgbp member systemb 1.1.1.2
    	
       systema(config)#sgbp member systemc 1.1.1.3 
  3. semente-oferta do sgbp {padrão | offload | dianteiro-somente | <0-9999>}

    O peso configurável que o membro de pilha oferece com 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 define uma semente-oferta do sgbp, o padrão está usado.

    Se offload é definido, ele envia a por-plataforma precalibrated oferecida que aproxima a potência de CPU, menos a carga de pacote.

    Se < 0-9999 > são configurados, a oferta mandada é o valor configurado por usuário menos a carga de pacote.

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

    1. Quando você tem o equivalent stack members stacked para receber atendimentos em um grupo giratório através dos pris múltiplo, emita o comando sgbp seed-bid default across 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ê tem uma alto-potência CPU disponível como um membro de pilha relativo aos outros membros de pilha, você pode querer leverage a potência mais alta relativa desse membro de pilha sobre o resto (por exemplo, uns ou vários CPU alto-postos disponíveis como um membro de pilha relativo aos outros membros de pilha similares; por exemplo, um 4500 e quatro AS5200s).You podem ajustar o membro de pilha de alta potência designado como o servidor de descarga com o comando sgbp seed-bid offload. Neste caso, o servidor de descarga hospeda o pacote mestre. Todos os atendimentos de outros membros de pilha são projetados a este membro de pilha. Realmente, uns ou vários servidores de descarga podem ser definidos; se as Plataformas são as mesmas (equivalente), as ofertas são iguais. O mecanismo tie-breaking do SGBP quebra o vínculo e designa uma das plataformas como vencedora.

      Nota: Se você designa duas plataformas diferentes como servidores de descarga, esse com a potência de CPU mais alta ganha a oferta.

    3. Se você classificou ou exatamente as mesmos Plataformas e você querem designar umas ou várias Plataformas como servidores de descarga, você pode manualmente ajustar o valor de oferta para ser significativamente mais alto do que o resto com o comando sgbp seed-bid 9999. Por exemplo, um 4700 (designado pela semente-oferta a mais alta), dois 4000s, e um 7000. Para determinar o valor de oferta inicial associou com suas plataformas particular, usam o sgbp da mostra.

    4. Em um ambiente multibase aonde os membros de empilhamento front-end offload sempre a uns ou vários servidores de descarga, há os casos onde o membro de empilhamento front-end não pode realmente offload, como quando o conjunto multilink é formado localmente. Esse problema poderá ocorrer, por exemplo, quando todos os servidores de descarga estiverem inativos. Se o administrador de rede prefere a chamada recebida pendurar acima pelo contrário, emita o comando sgbp seed-bid forward-only.

  4. sgbp PPP-dianteiro

    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. mostre o sgbp

    Esse comando mostra o estado dos membros do grupo de pilhas. Os estados podem ser ACTIVE, CONNECTING, WAITINFO ou IDLE. O ACTIVE em cada membro de grupo de pilhas é o melhor estado. A CONEXÃO e o WAITINFO são estados transitórios e você deve somente vê-la quando na transição ao ACTIVE. IDLE indica que o grupo de pilhas systema não pode detectar o membro da pilha remota systemd. Se o systemd é derrubado para a manutenção, por exemplo, não há nenhum motivo de preocupação. Se não, olhe algumas questões de roteamento ou outros problemas entre estes membro de 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. virtual-molde <1-9> do multilink

    Esse é o número de modelos virtuais pelo qual a interface de pacotes MP clona os parâmetros da interface. Está aqui um exemplo para como um MP associa com um molde virtual. Uma relação virtual do molde deve igualmente 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

    Este comando indica a informação de 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 conjunto tem seu feixe de interface definido como Virtual-Access4. Duas interfaces de membros são associadas a esta interface de conjunto. O primeiro é um canal local PRI e o segundo é uma relação projetada do systemb do membro de grupo de pilhas.

Exemplos

Refira o Multilink de Multichassi PPP (MMP) (parte 2) para ver estes exemplos:

E igualmente refira as seções sobre:

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 14942