Este documento descreve a arquitetura geral de aplicativos PPP de Acesso Virtual no Cisco IOS®. Para obter mais informações sobre um recurso específico, consulte os documentos listados no final do Glossário.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Não existem requisitos específicos para este documento.
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.
Estes são os termos que aparecerão neste documento.
Servidor de acesso: Plataformas de Servidor de Acesso Cisco, inclusive ISDN e as interface assíncronas para fornecer acesso remoto.
L2F: Protocolo de Encaminhamento da Camada 2 (Esboço experimental RFC). É a tecnologia em nível de link subjacente para Multichassis MP e Virtual Private Networks (VPNs).
Link: Um ponto de conexão fornecido por um sistema. Pode ser uma interface de hardware dedicada (como uma interface async) ou um canal de uma interface de hardware multi-canais (como PRI ou BRI).
MP: Protocolo Multilink PPP (consulte RFC 1717).
MP Multichassi: MP + SGBP + L2F + Vtemplate.
PPP: Point-to-Point Protocol (consulte RFC 1331).
Grupo rotativo: Um grupo de interfaces físicas alocadas para chamadas enviadas ou recebidas. O grupo age como um conjunto do qual qualquer enlace pode ser usado para fazer ou receber chamadas.
SGBP: Protocolo SGBP
Grupo de Pilhas: Uma coleção de dois ou mais sistemas que serão configurados para funcionar como um grupo e oferecerá suporte aos pacotes MP com enlaces em sistemas diferentes.
VPDN: Virtual Private Dialup Network. O encaminhamento de links PPP de um Provedor de Internet (ISP, Internet Service Provider) para um Gateway Doméstico.
Vtemplate: Interface de Modelo Virtual.
Observação: para obter informações sobre os RFCs mencionados neste documento, consulte RFCs suportados no Cisco IOS versão 11.2, um boletim de produto; ou Obtenção de RFCs e Outros Documentos de Padrões para obter um link direto com InterNIC.
No Cisco IOS Release 11.2F, a Cisco oferece suporte a estes recursos do acesso de dial-up: VPDN, multilink de multichassi, VP, conversão de protocolo utilizando acesso virtual e PPP/ATM. Esses recursos utilizam interfaces virtuais para carregar PPP em suas máquinas-alvo.
Uma Interface de Acesso Virtual é uma interface Cisco IOS, assim como interfaces físicas como uma Serial Interface. Uma configuração de interface serial reside na configuração de interface serial.
#config int s0 ip unnumbered e0 encap ppp :
As interfaces físicas têm configurações fixas e estáticas. No entanto, as interfaces de Aceso Virtual são criadas de forma dinâmica, sob demanda (os vários usos são discutidos na próxima seção deste documento). Elas também são liberadas quando deixam de ser necessárias. Portanto, a origem da configuração de interfaces de acesso virtual deve ser ancorada por outros meios.
Os vários métodos pelos quais um acesso virtual obtém sua configuração são pela interface de modelo virtual e/ou registros RADIUS e TACAC+ que residem em um servidor de autenticação. Esse último método é chamado perfis virtuais por usuário. Como as interfaces de acesso virtual podem ser configuradas usando um Modelo virtual global, as interfaces de acesso virtual de vários usuários podem herdar configurações idênticas de uma interface de Modelo virtual. Por exemplo, o administrador de rede pode optar por definir um método de autenticação PPP comum (CHAP) para todos os usuários do Acesso Virtual do sistema. Para configurações personalizadas para um usuário específico, o administrador de rede pode definir configurações da interface - como a autenticação PAP - específica do usuário no Perfil Virtual. Em resumo, o esquema de configuração geral para específico disponível para as interfaces de acesso virtual permite que o administrador da rede adapte configurações de interface comuns a todos os usuários e/ou individualmente a cada usuário.
A Figura 1 acima ilustra duas das interfaces de Acesso Virtual para userA e userB. A operação 1 denota a aplicação da configuração da interface de uma interface do Modelo Virtual global às duas interfaces de Acesso Virtual. A operação 2 denota a aplicação das configurações de interface por usuário dos Perfis Virtuais diferentes às duas interfaces de Acesso Virtual.
Esta seção descreve as várias maneiras como o Cisco IOS utiliza as interfaces de Acesso Virtual.
Você observará um tema recorrente de cada aplicação - elas permitem um Modelo Virtual geral específico na aplicação (Operação 1). Perfis virtuais por usuário são aplicados por usuário (Operação 2)
O Multilink PPP utiliza a interface de Acesso Virtual como uma interface de conjunto para remontar pacotes recebidos e enviados em enlaces individuais. A interface conjunta obtém sua configuração do Modelo Virtual específico do Multilink PPP. Se o administrador de rede optar por ativar perfis virtuais, a configuração da interface de perfil virtual por nome de usuário será aplicada à interface de pacotes desse usuário.
A Figura 2 representa o uso de Multilink PPP de interfaces seriais. Como não há interface de discador, uma interface de molde virtual é definida por:
multilink virtual-template 1 int virtual-template 1 ip unnum e0 encap ppp ppp chap authen
Dessa forma, uma configuração opcional de Perfil Virtual por nome de usuário é aplicada à interface em pacote. Quando a interface do discador é envolvida, a interface conjunta é uma interface passiva - nenhuma interface de modelo Virtual é obrigatória.
Por exemplo, a Figura 3 exibe um PRI se0:23 configurado para oferecer suporte a multilink PPP
Observe que se o perfil virtual estiver ativado, o esquema reverterá o mostrado na Figura 2. Ou seja, se uma chamada recebida for recebida em uma interface de discador e o perfil virtual estiver ativado, a origem da configuração não será mais do discador. Em vez disso, o feixe de interface (veja a Figura 2) é a interface "ativa" em que todos os protocolos serão lidos ou gravados. O origem de configuração é primeiro a interface Modelo Virtual e só então o Perfil Virtual de um usuário particular.
O encaminhamento da camada 2 de nível de enlace, ou L2F, permite que o PPP seja encerrado em um destino remoto. Normalmente, sem L2F, o PPP está entre o cliente discado e o NAS que atendeu a chamada recebida. Com L2F, o PPP é projetado para um nó de destino. No que diz respeito ao cliente, ele "pensa" que está conectado ao nó de destino via PPP. O NAS, na verdade, se torna um encaminhador de estrutura PPP simples. Na terminologia de L2F, o nó de destino é denominado Home Gateway.
No Home-Gateway, a interface de acesso virtual é utilizada para terminar o enlace PPP. Além disso, um Modelo Virtual é utilizado como a origem de configuração. Se o Perfil Virtual for definido, a configuração da interface por usuário será aplicada à interface de Acesso Virtual.
O túnel L2F é propagado atualmente no UDP/IP.
A tecnologia de tunelamento L2F é usada atualmente em dois recursos do Cisco IOS 11.2: VPDN (Rede dialup privada virtual) e MMP (Multilink de multibase PPP).
O VPDN permite que as redes privadas se estendam do cliente diretamente ao home gateway de escolha. Por exemplo, usuários móveis (vendas, por exemplo) de HP desejam poder sempre conectar-se ao HP Home Gateway de sua escolha a qualquer hora, em qualquer lugar. A HP contrataria ISPs que suportassem PDN. Esses ISPs seriam configurados de tal forma que se jsmith@hp.com discasse para qualquer um dos números fornecidos pelo ISP, o NAS encaminharia automaticamente para o HP Home-Gateway. Assim, o ISP fica livre de administrar os endereços IP de usuários HP, o roteamento e outras funções ligadas à base de usuários HP. A administração ISP HP é reduzida para questões de conectividade IP do gateway local HP.
NAS: isp
vpdn outgoing hp.com isp ip 1.1.1.2
Home-Gateway: hp-gateway
int virtual-template 1 ip unnum e0 encap ppp ppp chap authen vpdn incoming isp hp-gateway virtual-template 1
O multilink PPP fornece a usuários largura de banda adicional sob demanda, com a possibilidade 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 da WAN lenta e fornece um método para aumentar a unidade máxima de recepção. O multilink é suportado em um ambiente de um único servidor de acesso.
ISPs, por exemplo, gostariam de alocar convenientemente um único número giratório para multiplicar PRIs em vários Access Servers, escaláveis e flexíveis para suas necessidades comerciais.
Com o Multichassis Multilink, vários links Multilink a partir do mesmo cliente podem terminar em Servidores de Acesso diferentes. Embora os links de MP individuais do mesmo conjunto possam, na realidade, terminar em diferentes Servidores de Acesso, à medida que o cliente MP é envolvido, pressupõe-se que eles estejam terminando em um único servidor de acesso. Quando componentes são comparados aos do VPDN, multichassis mostram diferença apenas em um Protocolo de oferta de grupo empilhado (SGBP) adicional que facilita a oferta e arbitração de conjuntos multilink. Como o endereço IP de destino do grupo empilhado vencedor é decidido sobre SGBP, multibase usa L2F para projetar do NAS para outro NAS, que é aquele com o grupo empilhado vencedor.
Por exemplo em Grupo de Pilhas. chamada stackq de dois NASes: nasa e nasb.
nasa:
username stackq password hello multilink virtual-template 1 int virtual-template 1 ip unnum e0 encap ppp ppp authen chap sgbp stack stackq sgbp member nasb 1.1.1.2
nasb:
username stackq password hello multilink virtual-template 1 int virtual-template 1 ip unnum e0 encap ppp ppp authen chap sgbp stack stackq sgbp member nasb 1.1.1.2
Tradução de Protocolo permite tráfego encapsulado PPP em um Gateway - como X.25/TCP - terminar como uma interface de Acesso Virtual (tradução em duas etapas). A interface de acesso virtual também é suportada na conversão de apenas um passo.
Exemplo de conversão de protocolo em duas etapas:
int virtual-template 1 ip unnum e0 encap ppp ppp authen chap vty-async virtual-template 1
Exemplo de conversão de protocolo em etapa única:
int virtual-template 1 ip unnum e0 encap ppp ppp authen chap translate tcp 1.1.1.1 virtual-template 1
Esse recurso oferece suporte à terminação de várias conexões PPP em uma interface de roteador ATM quando os dados são formatados de acordo com o encapsulamento (StrataCom) Frame Forwarding da Cisco. O protocolo PPP é encerrado no roteador como se fosse recebido de uma interface serial PPP típica. Cada conexão PPP será encapsulada em um VC ATM separado. VCs usando outros tipos de encapsulamento também podem ser configurados na mesma interface.
interface Virtual-Template1 ip unnumbered e0/0 ppp authentication chap interface ATM2/0.2 point-to-point atm pvc 34 34 34 aal5ppp virtual-template 1
Perfis Virtuais é um aplicativo exclusivo de PPP que define a aplica informações de configuração por usuário para usuários que discam em um roteador Os Perfis Virtuais permitem que as informações de configuração específicas do usuário sejam aplicadas independente da mídia utilizada para a chamada de discagem de entrada. As informações de configuração para perfis virtuais pode surgir a partir de um molde de interface virtual, para cada informação de configuração de usuário armazenada em um servidor AAA (ou em ambos), dependendo de como o roteador e o servidor AAA estão configurados. A aplicação de perfis virtuais pode ser um ambiente de caixa única, em um gateway local VPDN ou em um ambiente multibase.
Para definir um Modelo virtual como fonte de configuração de Perfil virtual:
virtual-profile virtual-template 1 int virtual-template 1 ip unnum e0 encap ppp ppp authen chap :
Para definir AAA como uma origem da configuração do perfil virtual:
virtual-profile aaa
Neste exemplo, o administrador de sistema decide filtrar rotas que estão sendo anunciadas para John e aplicar listas de acesso a conexões de discagem de Rick. Quando John ou Rick faz uma discagem através da interface S1 ou BRI 0 e faz uma autenticação, um perfil virtual é criado: filtros da rota são aplicados a John e as listas de acessos são aplicadas a Rick.
Configuração de AAA para usuários John e Rick:
john Password = ``welcome'' User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = ``ip:rte-fltr-out#0=router igrp 60'', cisco-avpair = ``ip:rte-fltr-out#3=deny 171.0.0.0 0.255.255.255'', cisco-avpair = ``ip:rte-fltr-out#4=deny 172.0.0.0 0.255.255.255'', cisco-avpair = ``ip:rte-fltr-out#5=permit any'' rick Password = ``emoclew'' User-Service-Type = Framed-User, Framed-Protocol = PPP, cisco-avpair = ``ip:inacl#3=permit ip any any precedence immediate'', cisco-avpair = ``ip:inacl#4=deny igrp 0.0.1.2 255.255.0.0 any'', cisco-avpair = ``ip:outacl#2=permit ip any any precedence immediate'', cisco-avpair = ``ip:outacl#3=deny igrp 0.0.9.10 255.255.0.0 any''
Em resumo, os cisco-avpairs AAA contêm os comandos Cisco IOS por interface a serem aplicados para um usuário em particular.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
22-Oct-2018 |
Versão inicial |