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.
Os pré-requisitos para este documento são fornecidos na Parte Um deste documento.
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:
Figura 3: Uma pilha de grupo de pilha constituída de sistema, system e systemc. o link do sistema é configurado na interface do discador.interface Serial0:23 ip unnum e0 dialer map ..... encap ppp ppp authen chap dialer-group 1 dialer rot 1 ppp multilink
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).
Figura 4: sistema como um servidor de descarga.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
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.
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
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).
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:
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
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.
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.
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 :
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).
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:
Verifique se o SGBP está em operação.
Depurar multilink PPP.
Depurar VPN e L2F.
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.
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).
Cliente userx | Cada membro da pilha stackq |
---|---|
#config username stackq password blah |
#config username userx password blah |
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.
Primeiro, verifique se o número de modelo virtual global multilink está definido em cada membro da pilha.
#config Multilink virtual-template 1
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.
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)
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
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.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
09-Sep-2005 |
Versão inicial |