PPP Multilink Multichassis (MMP) (Parte 2)

Introduction

Este documento continua a descrever o suporte para PPP Multilink (MP) em um ambiente de "pilha" ou multichassi (às vezes chamado de MMP, para PPP Multilink Multichassis), em plataformas de servidor de acesso da Cisco Systems.

Este documento é a Parte Dois de um documento em duas partes. Consulte a Parte Um deste documento para obter mais informações.

Prerequisites

Os pré-requisitos para este documento são fornecidos na Parte Um deste documento.

Examples

AS5200 em uma pilha (com discadores)

Quando os discadores são configurados nas interfaces físicas, não há necessidade de especificar a interface de modelo virtual. A interface de acesso virtual atua como uma interface passiva, reforçada entre a interface do discador e as interfaces físicas associadas à interface do discador.

Resumindo, você só precisa definir o nome do grupo de pilha, a senha comum e os membros do grupo de pilha em todos os membros da pilha. Nenhuma interface de modelo virtual é definida, como mostrado no exemplo a seguir:

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

O exemplo a seguir é de um controlador E1:

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

Depois que a interface do pacote é criada, ela é clonada somente com os comandos PPP da interface do discador. Os links de PPP projetados subsequentes também são clonados com os comandos PPP da interface do discador. A Figura 3 mostra como a interface do discador está no topo da interface do pacote. Compare-a com a Figura 2, na qual não há interface de discador.

Por padrão, as PRIs e BRIs são interfaces de discador; uma PRI configurada sem um discador explícito (através do comando dialer rotary) ainda é uma interface de discador na Serial0:23, como mostrado pelo seguinte exemplo:

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

Utilizando um servidor de offload

o sistema é designado um servidor de descarga (usando o comando sgbp seed-bid). Todos os outros membros do grupo de pilha devem ser definidos com o comando sgbp seed-bid default (ou, se você não definir o comando gbp seed-bid, o padrão será este).

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

Servidor de offload com interfaces físicas

Se o servidor de descarga designado também tiver interfaces físicas (por exemplo, PRI) que desejam servir o mesmo grupo de busca da telco como os outros membros da pilha, você poderá configurá-lo para fazer isso combinando configurações mostradas nas seções deste documento intitulado AS5200 em uma pilha (com discadores) e usando um servidor de descarga.

Um link PPP projetado descarregado e suas interfaces de pacote dependem de modelos virtuais para uma fonte de configuração. Uma conexão que tem o primeiro link chega a um dispositivo físico conectado a uma interface de discador, e a origem da configuração para a interface do pacote e todos os links PPP projetados subsequentes é a configuração da interface do discador. Assim, essas variações coexistem, dependentes do membro da pilha em que o primeiro link chega.

Essa configuração não é recomendada devido à complexidade das configurações necessárias nas interfaces do discador e do modelo virtual.

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

Embora você possa configurar dispositivos assíncronos e seriais como interfaces de discador (nesse caso, ele é revertido para AS5200 em uma pilha (com discadores), como mostrado nessa seção deste documento), você pode optar por suportar MP multichassis sem qualquer configuração de discador para interfaces assíncronas, seriais e outras não discadoras. A origem de toda a configuração é então definida na interface de modelo virtual, como mostrado abaixo.

#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

Discagem a partir de um multichassi

Atualmente, a configuração multichassi não suporta dialout, porque o protocolo L2F (Layer 2 Forwarding) não suporta dialout.

Consequentemente, não há como o servidor de descarga (onde uma rota é falsificada, em um perfil de discador e assim por diante) iniciar uma discagem no membro da pilha de front-end no mesmo grupo de pilha. Todas as rotas falsificadas devem ser instaladas nos membros da pilha de front-end, pois são essas as conexões de discagem física (como PRI).

Algumas soluções alternativas são as seguintes:

• Quando o comando sgbp ppp-forward é emitido no membro da pilha front-end, isso significa que todas as chamadas PPP e PPP multilink são encaminhadas automaticamente para o vencedor da oferta do Stack Group Bidding Protocol (SGBP), como um servidor de descarga.

  Você precisa confiar na discagem do NAS (Network Access Server, servidor de acesso à rede) e permitir que a convergência do roteamento IP (somente para IP) faça seu curso. Por exemplo, para discar 1.1.1.1, coloque esse endereço na instrução dialer map no NAS e coloque uma rota estática no NAS, como a seguir:

    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
  

  Quando a discagem se conecta ao peer remoto, a conexão PPP é formada entre o peer remoto e o servidor de descarga. O membro da pilha de front-end é completamente ignorado. O PPP no servidor de descarga e, em seguida, instala uma rota de host para o peer—1.1.1.1. Neste ponto, o protocolo de roteamento IP converge de para a rota do host no servidor de descarga porque a métrica de roteamento gravita a rota lá.

  Observação: a convergência de roteamento resulta em latência.

• Quando o comando sgbp ppp-forward não é definido no membro da pilha front-end, isso significa que somente as chamadas multilink PPP são encaminhadas automaticamente para o vencedor da oferta SGBP, como um servidor de descarga. Assim, um discador do membro da pilha front-end para um peer remoto abrange a conexão PPP entre o front-end e o peer remoto — o mesmo comportamento como se o NAS não fizesse parte de um grupo de pilha.

  Observação: isso acontece desde que a conexão seja PPP direto (e não multilink PPP).

Discando para um multibase

Se você tiver roteamento IP (como Enhanced Interior Gateway Routing Protocol (EIGRP) e Open Shortest Path First (OSPF) fluindo entre o cliente e o membro da pilha que eventualmente ganha a oferta (como o servidor de descarga), aqui estão algumas dicas a seguir:

Impedir a instalação de uma rota conectada no lado do cliente

Configure o cliente 1.1.1.2, onde 1.1.1.2 é o endereço do NAS (o encaminhador de quadros transparente), como mostrado abaixo.

  int bri0

  dialer map 1.1.1.2 ....

Se você tiver o EIGRP, por exemplo, sendo executado entre o cliente e o servidor de descarga, a tabela de roteamento no servidor de descarga indica que, para chegar a 1.1.1.2, a rota deve passar pela interface de acesso virtual. Isso ocorre porque o PPP IP Control Protocol (IPCP) no lado do cliente instala uma rota 1.1.1.2 conectada à interface BRI. Em seguida, o EIGRP anuncia essa rota ao servidor de descarga na sessão PPP (sobre L2F). O EIGRP no servidor de descarga indica, portanto, que para chegar a 1.1.1.2, ele deve rotear para o cliente—a rota 1.1.1.1 do cliente é para a interface de acesso virtual.

Agora, você tem um pacote destinado ao cliente 1.1.1.1. O roteamento IP envia o pacote para a interface de acesso virtual. A interface de acesso virtual encapsula o encapsulamento IP/User Data Protocol (UDP)/L2F/PPP e envia o pacote para o L2F NAS—1.1.1.2. Tudo é normal neste momento. Em seguida, em vez de enviar o pacote através (por exemplo) da interface Ethernet, o roteamento IP o envia através da interface de acesso virtual novamente. Isso porque a tabela de roteamento indica que, para chegar ao NAS, ele deve passar pelo cliente. Isso cria um loop de roteamento e efetivamente desabilita a entrada e a saída pelo túnel L2F.

Para evitar isso, não permita que o IPCP instale uma rota conectada no lado do cliente.

Observação: isso só ocorre quando você tem algum protocolo de roteamento IP sendo executado entre o cliente e o Cisco Home Gateway.

A configuração do cliente é a seguinte:

  int bri0

  no peer neighbor-route

Mapas de discador no cliente

Quando o cliente estiver discando para um ambiente multichassi, sempre defina os discadores para cada possível vencedor do pacote multilink. Por exemplo, se houver quatro servidores de descarga na pilha multichassis, deve haver quatro mapas de discadores definidos no lado do cliente.

Por exemplo:

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

Neste exemplo, 1.1.1.3 é apenas um servidor de descarga.

Um pacote destinado às rotas 1.1.1.2 para a BRI e o discador disca para o destino porque há uma correspondência de mapa de discador. O servidor de descarga 1.1.1.4 realmente ganha a oferta e a sessão PPP é projetada ali. O EIGRP é trocado entre o cliente e o servidor de descarga. A tabela de roteamento IP no cliente é preenchida com uma rota 1.1.1.4 (servidor de descarga) para BRI0. Agora, no cliente, um pacote destinado a 1.1.1.4 é roteado para BRI0. O discador, no entanto, não pode discar porque não há correspondência de discador.

Observação: sempre defina mapas de discadores para todos os possíveis vencedores de ofertas SGBP em clientes sempre que acessar os servidores de descarga for um requisito dos clientes.

Configuração e restrições

• A j-image corporativa é necessária para MP multichassis.

• Somente um grupo de pilha pode ser definido para cada servidor de acesso.

• Os links de WAN de alta latência entre os membros da pilha, causando atrasos na remontagem do MP, podem fazer com que o MP multichassi seja ineficiente.

• As interfaces são suportadas para dispositivos PRI, [M]BRI, seriais e assíncronos.

• Não há suporte para discagem.

Configurações da interface por protocolo

Para todos os fins práticos, não configure um endereço de protocolo específico no modelo virtual.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

A interface de modelo virtual serve como um modelo a partir do qual qualquer número de interfaces de acesso virtual é clonado dinamicamente. Você não deve especificar um endereço específico de protocolo por interface para a interface de modelo virtual. Como um endereço IP deve ser exclusivo para cada interface de rede, especificar um endereço IP exclusivo na interface de modelo virtual é errado. Em vez disso, faça o seguinte:

  interface virtual-template 1

  ip unnum e0

  :

Configuração das configurações do protocolo global

Um cliente que disca para um único roteador de acesso e espera que o servidor de acesso tenha um endereço global exclusivo (como DECnet) agora realmente disca para o grupo de pilha multilink multichassi que consiste em vários servidores de acesso. Nesse tipo de situação, termine deterministicamente o grupo de pilhas em um único servidor de acesso. Para fazer isso, emita o comando sgbp seed-bid offload no servidor de acesso designado (ou especifique a oferta mais alta).

Troubleshooting

A primeira coisa a fazer se você tiver problemas é voltar para um único membro da pilha, desativando todos os outros membros da pilha. Em seguida, teste as conexões multilink PPP e passe pela autenticação CHAP (Challenge Handshake Authentication Protocol Protocolo de Autenticação de Handshake de Desafio) e pela configuração da interface para verificar se há erros na configuração e assim por diante. Quando estiver satisfeito que funciona, ative os outros membros da pilha e, em seguida, proceda da seguinte forma:

1. Verifique se o SGBP está em operação.

2. Depurar multilink PPP.

3. Depurar VPN e L2F.

Certificando-se de que o SGBP está ativo e executando corretamente

Emita o comando show sgbp para verificar se todos os estados membros estão ATIVOS. Caso contrário, procure os estados IDLE, AUTHOK ou ATIVE. Como mencionado anteriormente, IDLE é um estado válido para todos os membros da pilha remota que estão intencionalmente inativos.

Se encontrar um problema conforme descrito acima, ative o comando debug sgbp hellos e debug sgbp error. A autenticação entre dois membros da pilha, por exemplo, entre o sistema e a sistem, deve ser a seguinte (no sistema):

  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

o sistema envia um desafio no estilo CHAP e recebe uma resposta do sistema. Da mesma forma, o sistema envia um desafio e recebe uma resposta do sistema.

Se a autenticação falhar, você verá:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Isso significa que a senha de sistema remoto para stackq não corresponde à senha definida no sistema.

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

Isso significa que o sistema não tem um nome de usuário ou senha definidos localmente ou por meio do TACACS+.

Em geral, defina um segredo comum entre todos os membros da pilha para o grupo de pilha stackq. Você pode defini-los localmente ou por meio do TACACS+.

Um nome de usuário local definido em cada membro da pilha é:

  username stackq password blah

Esse segredo comum é facilitar a licitação e a arbitragem de SGBP do membro da pilha.

Consulte a seção Debugging PPP Multilink deste documento para uma discussão sobre autenticação de link PPP quando um cliente remoto disca para os membros da pilha.

No caso de problemas de cabeamento ou roteamento, um erro comum é ter o endereço IP origem do membro da pilha (que é realmente recebido na mensagem de saudação SGBP) diferente do endereço IP definido localmente para o mesmo membro da pilha.

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

Isso significa que o endereço IP de origem do hello SGBP recebido do sistema não corresponde ao endereço IP configurado localmente para system (através do comando sgbp member). Corrija isso indo para system e verificando se há várias interfaces pelas quais o hello de SGBP pode transmitir a mensagem.

Outra causa comum de erros é:

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

Isso significa que você não tem o sistema definido localmente, mas outro membro da pilha o tem.

Depurando o multilink PPP

A primeira coisa a verificar é se o cliente e o membro da pilha foram autenticados no PPP corretamente.

Este exemplo demonstra a autenticação CHAP, pois está mais envolvida. Como um exemplo familiar, ele usa uma plataforma Cisco como um cliente juntamente com nomes de usuário locais (o Terminal Access Controller Access Control System Plus (TACACS+) também é suportado, mas não é mostrado aqui).

#config

username stackq password blah

#config

username userx password blah

Nenhuma interface de discador envolvida

Como não há interface de discador no servidor de descarga, precisa haver outra fonte de configuração de interface das interfaces de acesso virtual. A resposta são interfaces de modelo virtual.

1. Primeiro, verifique se o número de modelo virtual global multilink está definido em cada membro da pilha.

     #config
     Multilink virtual-template 1
   

2. Se você não configurou nenhuma interface de discador para as interfaces físicas em questão (como PRI, BRI, serial assíncrona e síncrona), poderá definir:

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

   Observação: você não define um endereço IP específico no modelo virtual. Isso ocorre porque as interfaces de acesso virtual projetadas são sempre clonadas na interface de modelo virtual. Se um link PPP subsequente também for projetado para um membro da pilha com uma interface de acesso virtual já clonada e ativa, você terá endereços IP idênticos nas duas interfaces virtuais, fazendo com que o IP roteie erroneamente entre elas.

Interfaces do discador envolvidas

Quando os discadores são configurados nas interfaces físicas, não há necessidade de especificar uma interface de modelo virtual, pois a configuração da interface reside na interface do discador. Nesse caso, a interface de acesso virtual atua como uma interface passiva, dividida entre a interface do discador e as interfaces de membro associadas à interface do discador.

Observação: a interface do discador, Discador 1, é exibida na sessão multilink do PPP da seguinte maneira:

  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 e NCPs

Os estados do LCP em todas as interfaces membro devem estar UP. IPCP, ATCP e outros NCPs devem estar ativados apenas na interface do pacote.

A saída do Virtual-Access4 show int da interface do pacote deve ler-se como se segue:

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

Todas as outras interfaces membro devem ter a seguinte saída show int:

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

Depurando o VPN/L2F

Ative o seguinte:

  debug vpn event
  debug vpn error

Quando a interface física aceitar a chamada recebida e for encaminhada para o membro da pilha de destino, você verá o seguinte:

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

No membro da pilha de destino, se você vir o seguinte:

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

Em seguida, verifique sua definição de interface de modelo virtual. Geralmente, a interface do modelo virtual deve corresponder aos parâmetros da interface PPP da interface física que aceitou uma chamada de entrada.

Lembre-se da configuração mínima (usando o CHAP como exemplo):

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

Você pode ver o seguinte:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Se você vir a mensagem acima, significa que L2F projetou com êxito o link PPP do membro da pilha que primeiro recebeu a chamada para o membro da pilha onde reside a interface do pacote para o mesmo cliente (ou criará, como no cenário de descarga).

Um erro comum é não definir o nome de usuário para o nome da pilha comum (stackq) ou não corresponder à senha da pilha em todos os membros da pilha.

Emita o seguinte comando:

  debug vpdn l2f-error

Os seguintes resultados da mensagem:

  L2F Tunnel authentication failed for stackq

Corrija a correspondência de nome de usuário e senha em cada membro da pilha nesse caso.

Informações Relacionadas

• Parte 1 deste documento
• Recursos de PPP de acesso virtual no software Cisco IOS
• Entendendo o VPDN
• Suporte Técnico - Cisco Systems

Histórico de revisões