WAN : Point-to-Point Protocol (PPP)

Multilink de Multichassi PPP (MMP) (parte 2)

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


Índice


Introdução

Este documento continua a descrever o apoio para o multilink ppp (MP) em uma “pilha” ou no ambiente multibase (chamado às vezes MMP, para o Multilink de Multichassi PPP), nas plataformas de servidor de acesso de Cisco Systems.

Este documento é a parte dois de um documento bipartido. Refira a parte uma deste documento para mais informação.

Pré-requisitos

As condições prévias para este documento são dadas na parte uma deste documento.

Exemplos

AS5200 em uma pilha (com discadores)

Quando os discadores são configurados nas interfaces física, não há nenhuma necessidade de especificar a relação virtual do molde de todo. A interface de acesso virtual atua como uma interface passiva, suportada entre a interface do discador e as interfaces física associadas com a interface do discador.

Em curto, você precisa somente de definir o nome de grupo de pilha, a senha comum, e os membros de grupo de pilhas através de todos os membros de pilha. Nenhuma relação virtual do molde é definida, segundo as indicações do exemplo seguinte:

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 seguinte é 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 o bundle interface é criado, está clonado com somente os comandos PPP da interface do discador. Os links de PPP projetados subsequentes são clonados igualmente com os comandos PPP da interface do discador. Figura 3 mostra como a interface do discador se senta sobre o bundle interface. Compare-a com figura 2, em que não há nenhuma interface do discador.

Os PRI e os BRI são à revelia interfaces do discador; um PRI configurado sem um discador explícito (através do comando dialer rotary) é ainda uma interface do discador em Serial0:23, como mostrado pelo exemplo seguinte:

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink
Figura 3: Um grupo de pilhas – stackq – consistindo no systema, no systemb, e no systemc. o link do systema é configurado na interface do discador.

/image/gif/paws/14945/figure3-mmp.gif

Utilizando um servidor de offload

o systema é designado um servidor de descarga (que usa o comando sgbp seed-bid). Todos membros de grupo de pilhas restantes devem ser definidos com o comando default da semente-oferta do sgbp (ou, se você não define o comando da semente-oferta do thesgbp, opta 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
Figura 4: systema como um servidor de descarga.

/image/gif/paws/14945/figure4-mmp.gif

Servidor de offload com interfaces físicas

Se o servidor de descarga designado igualmente tem as interfaces física (por exemplo, PRI) desejando servir o mesmo grupo de buscas do telco que os outros membros de pilha, você pode configurar-lo para fazer assim combinando as configurações mostradas nas seções deste documento intitulado AS5200 em uma pilha (com discadores) e usando um servidor de descarga.

Um link de PPP projetado offloaded e suas relações do pacote confiam em moldes virtuais para um origem de configuração. Uma conexão que tenha o primeiro link chega em um dispositivo físico conectado a uma interface do discador, e no origem de configuração para o bundle interface e todos os links de PPP projetados subsequentes é a configuração da interface do discador. Daqui, estas variações coexistem, dependente do membro de pilha em que o primeiro link chega.

Esta configuração não é recomendado devido à complexidade das configurações exigidas no discador e nas relações virtuais do molde.

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

Quando você puder configurar assíncrono e dispositivos serial como interfaces do discador (neste caso reverte ao AS5200 em uma pilha (com discadores), segundo as indicações dessa seção deste documento), você pode escolher apoiar o multichassis MP sem nenhuma configuração do discador para assíncrono, de série, e outras interfaces do não-discador. A fonte de toda a configuração é definida então na relação virtual do molde, 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 de multichassi não apoia a discagem, porque o protocolo da transmissão da camada 2 (L2F) não apoia a discagem.

Consequentemente, não há nenhuma maneira para o servidor de descarga (onde uma rota é falsificado, em um perfil do discador, e assim por diante) de iniciar um seletor no membro de empilhamento front-end no mesmo grupo de pilhas. Todas as rotas falsificado devem ser instaladas o nos membros de empilhamento front-end, porque estes são esses com as conexões de discagem físicas (tais como o PRI).

Algumas ações alternativas são como segue:

  • Quando o comando sgbp ppp-forward é emitido no membro de empilhamento front-end, este significa que todos os atendimentos PPP e de multilink de PPP estão enviados automaticamente ao vencedor oferecido do protocolo stack group bidding (SGBP), tal como um servidor de descarga.

    Você tem que confiar no servidor do acesso de rede (NAS) que disca para fora e deixe a convergência de Roteamento IP (para o IP somente) tomam seu curso. Por exemplo, para discar 1.1.1.1, põe este endereço na instrução de mapa de discador sobre o NAS e põe uma rota estática sobre o NAS, como segue:

      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 o seletor conecta ao peer remoto, a conexão PPP está formada entre o peer remoto e o servidor de descarga. O membro de empilhamento front-end é contorneado completamente. O PPP no servidor de descarga instala então uma rota do host ao par — 1.1.1.1. Neste momento, o protocolo de IP Routing convirge à rota do host no servidor de descarga porque a métrica de roteamento gravita a rota lá.

    Nota: Distribuindo resultados da convergência na latência.

  • Quando o comando sgbp ppp-forward não é definido no membro de empilhamento front-end, este significa que somente os atendimentos do multilink de PPP estão enviados automaticamente ao vencedor de lance de SGBP, tal como um servidor de descarga. Assim, um discador do membro de empilhamento front-end a um peer remoto mede a conexão PPP entre a parte frontal e o peer remoto — o mesmo comportamento como se o NAS não era parte de um grupo de pilhas.

    Nota: Isto acontece enquanto a conexão é PPP reto (e não multilink de PPP).

Discando para um multibase

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

Impeça instalar uma rota conectada no lado do cliente

Configurar o cliente 1.1.1.2 onde 1.1.1.2 é o endereço do NAS (o quadro-remetente transparente), como mostrado abaixo.

  int bri0

  dialer map 1.1.1.2 ....

Se você tem o EIGRP, por exemplo, ser executado entre o cliente e o servidor de descarga, a tabela de roteamento no servidor de descarga indica que aquela obter a 1.1.1.2 a rota deve atravessar a interface de acesso virtual. Isto é porque o protocolo ppp ip control (IPCP) no lado do cliente instala uma rota conectada 1.1.1.2 à interface BRI. O EIGRP anuncia então esta rota ao servidor de descarga sobre a sessão de PPP (sobre o L2F). O EIGRP no servidor de descarga indica assim aquele para obter a 1.1.1.2, ele deve distribuir ao cliente — a rota 1.1.1.1 do cliente é à interface de acesso virtual.

Agora, você tem um pacote destinado para o cliente 1.1.1.1. Roteamento IP envia o pacote à interface de acesso virtual. A interface de acesso virtual encapsula o protocolo dos dados IP/User (o encapsulamento UDP)/L2F/PPP e envia o pacote ao L2F NAS — 1.1.1.2. Tudo é normal neste momento. Então, em vez de enviar o pacote para fora através (por exemplo) da interface Ethernet, Roteamento IP envia-a através da interface de acesso virtual outra vez. Isto é porque a tabela de roteamento indica aquela para obter ao NAS, ele deve dirigir o cliente. Isto cria um loop de roteamento e desabilita eficazmente a entrada e saída sobre o túnel L2F.

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

Nota: Isto pertence somente quando você tem algum protocolo de IP Routing que é executado entre o cliente e o Home Gateway de Cisco.

A configuração de cliente é como segue:

  int bri0

  no peer neighbor-route

Mapas de discagem no cliente

Quando o cliente está discando a um ambiente multibase, defina sempre os discadores a cada ganhador potencial do conjunto multilink. Por exemplo, se há quatro servidores de descarga na pilha do multichassis, lá deve estar quatro Mapas de discagem 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 para rotas de 1.1.1.2 ao BRI, e o discador discam o destino porque há um fósforo do mapa de discadores. O servidor de descarga 1.1.1.4 ganha realmente a oferta e a sessão de PPP é projetada lá. O EIGRP é trocado entre o cliente e o servidor de descarga. A tabela de IP Routing no cliente é enchida com uma rota 1.1.1.4 (servidor de descarga) ao BRI0. Agora, no cliente, um pacote destinado para 1.1.1.4 é distribuído ao BRI0. O discador, contudo, não pode discar porque não há nenhum fósforo do discador.

Nota: Defina sempre Mapas de discagem para todos os potenciais vencedores de bid SGBP em clientes sempre que alcançar os servidores de descarga é uma exigência dos clientes.

Configuração e restrições

  • A j-imagem da empresa é exigida para o multichassis MP.

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

  • Os links MACILENTOS da Alta latência entre os membros de pilha, causando a remontagem MP atrasam, podem fazer com que o multichassis MP seja incapaz.

  • As relações são apoiadas para o PRI, o [M] BRI, a série, e os dispositivos assíncronos.

  • A discagem não é apoiada.

Configurações da interface por protocolo

Para todos os efeitos práticos, não configurar um endereço de protocolo específico no molde virtual.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

A relação virtual do molde serve como um molde de que todo o número de interfaces de acesso virtual é clonado dinamicamente. Você não deve especificar um endereço do específico de protocolo da interface per. à relação virtual do molde. Porque um endereço IP de Um ou Mais Servidores Cisco ICM NT deve ser original para cada interface de rede, especificar um endereço IP exclusivo na relação virtual do molde é errônea. Em lugar de, faça o seguinte:

  interface virtual-template 1

  ip unnum e0

  :

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

Um cliente que disque em um único roteador de acesso e espere o servidor de acesso ter um endereço global original (tal como o DECNet) agora disca realmente ao grupo de pilhas do Multilink de Multichassi que consiste em diversos servidores de acesso. Neste tipo de situação, termine o grupo de pilhas deterministically em um único servidor de acesso. Para fazer isso, para emitir o comando sgbp seed-bid offload no servidor de acesso designado (ou para especificar a oferta a mais alta).

Troubleshooting

A primeira coisa a fazer se você tem problemas é ir para trás a um único membro de pilha, desabilitando todos membros de pilha restantes. Então teste suas conexões multilink de PPP e atravesse a autenticação e a configuração da interface usuais do protocolo de autenticação de cumprimento do desafio (RACHADURA) para erros na configuração e assim por diante. Quando você é satisfeito trabalha, permite os outros membros de pilha, a seguir continua como segue:

  1. Certifique-se que o SGBP é em serviço.

  2. Debugar o multilink de PPP.

  3. Debugar o VPN e o L2F.

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

Emita o comando show sgbp certificar-se de que todos os estados de membro são ATIVOS. Se não, olhe para fora para a QUIETUDE, o AUTHOK, ou estados ATIVOS. Como mencionado previamente, a QUIETUDE é um estado válido para todos os membros de pilha remotos que são intencionalmente inativos.

Se você encontra um problema como descrito acima, gire sobre o debug sgbp hellos e o comando debug sgbp error. A autenticação entre dois membros de pilha, por exemplo entre o systema e o systemb, deve ser como segue (no systema):

  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 systema envia um desafio do Rachadura-estilo e recebe uma resposta do systemb. Similarmente, o systemb manda um desafio e recebe uma resposta do systema.

Se a autenticação falha, você vê:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Isto significa que a senha de sistema b remoto para o stackq não combina a senha definida no systema.

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

Isto significa que o systema não tem um username ou uma senha definido localmente ou com o TACACS+.

Geralmente, defina um segredo comum através de todos os membros de pilha para o stackq do grupo de pilhas. Você pode defini-los localmente ou com o TACACS+.

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

  username stackq password blah

Este segredo comum é facilitar o arbitragem e faturamento SGBP de membro de pilha.

Refira a seção do multilink de PPP da eliminação de erros deste documento para um exame da autenticação do link de PPP quando um cliente remoto disca dentro aos membros de pilha.

No caso da fiação ou dos problemas de roteamento, um erro comum está tendo o endereço IP de origem do membro de pilha (que é recebido realmente na mensagem dos hellos de SGBP) diferente do endereço IP de Um ou Mais Servidores Cisco ICM NT localmente definido para o mesmo membro de 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

Isto significa que o endereço IP de origem dos hellos de SGBP recebidos do systemb não combina o endereço IP de Um ou Mais Servidores Cisco ICM NT configurado localmente para o systemb (através do comando sgbp member). Corrija isto indo ao systemb e verificando para ver se há interfaces múltiplas por que os hellos de SGBP podem transmitir a mensagem.

Uma outra causa comum para erros é:

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

Isto significa que você não tem o systemk definido localmente, mas um outro membro de pilha faz.

Depurando o multilink PPP

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

Este exemplo demonstra a autenticação chap, porque é mais involvido. Como um exemplo familiar, usa uma plataforma Cisco como um cliente junto com nomes de usuário locais (o protocolo tacacs+ (TACACS+) é apoiado igualmente, mas não é mostrado aqui).

Userx do cliente Cada membro do stackq da pilha
#config

username stackq password blah
#config

username userx password blah

Nenhumas interfaces do discador envolvidas

Desde que não há nenhuma interface do discador no servidor de descarga, precisa de estar uma outra fonte de configuração da interface das interfaces de acesso virtual. A resposta é relações virtuais do molde.

  1. Certifique-se primeiramente que o número do template virtual global do multilink está definido em cada membro de pilha.

      #config
      Multilink virtual-template 1
    
  2. Se você não configurou nenhuma interfaces do discador para as interfaces física na pergunta (tal como o PRI, o BRI, o assíncrono, e serial síncrona), você pode definir:

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

    Nota: Você não define um endereço IP de Um ou Mais Servidores Cisco ICM NT específico no molde virtual. Isto é porque as interfaces de acesso virtual projetadas são clonadas sempre da relação virtual do molde. Se um link de PPP subsequente igualmente obtém projetado a um membro de pilha com uma interface de acesso virtual já clonada e ativa, você tem o endereço IP idêntico nas duas interfaces virtuais, fazendo com que o IP distribua erroneamente entre elas.

Interfaces do discador envolvidas

Quando os discadores são configurados nas interfaces física, não há nenhuma necessidade de especificar uma relação virtual do molde, porque a configuração da interface reside na interface do discador. Neste caso, a interface de acesso virtual atua como uma interface passiva, suportada entre a interface do discador e as interfaces membro associadas com a interface do discador.

Nota: A interface do discador, Discador1, é indicada na sessão de multilink PPP como segue:

  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 NCP

Os estados LCP em todas as interfaces membro devem estar ACIMA. O IPCP, o ATCP, e outros NCP devem estar acima somente no bundle interface.

A saída int da mostra do bundle interface Virtual-Access4 deve ler como segue:

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

Todas interfaces membro restantes devem ter a seguinte mostra int output:

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

Depurando o VPN/L2F

Gire sobre o seguinte:

  debug vpn event
  debug vpn error

Quando a interface física aceita a chamada recebida e é enviada agora ao membro de pilha de destino, você vê o seguinte:

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

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

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

Verifique então sua definição de sua relação virtual do molde. Geralmente, a relação virtual do molde deve combinar os parâmetros de interface PPP da interface física que aceitou uma chamada recebida.

Recorde a configuração mínima (que usa a RACHADURA como um 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ê vê a mensagem acima, significa que o L2F projetou com sucesso o link de PPP do membro de pilha que tomou primeiramente a chamada recebida ao membro de pilha onde o bundle interface para o mesmo cliente reside (ou criará, como na encenação do offload).

Um erro comum falha definir o username para o nome comum da pilha (stackq) ou a harmonização da senha da pilha em todos os membros de pilha.

Emita o seguinte comando:

  debug vpdn l2f-error

Os resultados do seguinte mensagem:

  L2F Tunnel authentication failed for stackq

Corrija o fósforo do nome de usuário e senha em cada membro de pilha neste caso.


Informações Relacionadas


Document ID: 14945