Este documento apresenta um exemplo de configuração no qual o tunelamento de protocolo da camada 2 (L2TP) da VPDN (Rede Virtual Privada de Dialup) é configurado para chamadas de discagem ISDN e analógicas. Não há servidor de autenticação, autorização e contabilidade (AAA) envolvido nessa configuração.
O L2TP é um padrão da Internet Engineering Task Force (IETF) que combina os melhores recursos de dois protocolos de tunelamento existentes:
Cisco Layer 2 Forwarding (L2F)
Protocolo de Encapsulamento Ponto a Ponto da Microsoft (PPTP - Point-to-Point Tunneling Protocol)
Nesta configuração, usamos L2TP adicionando o protocolo de comando L2TP. L2F é o padrão.
A Cisco recomenda que você use o comando vpdn-group, introduzido no Cisco IOS® Software Release 12.0(1)T, para definir os parâmetros da VPDN no L2TP Access Concentrator (LAC) e no L2TP Network Server (LNS). No entanto, se deseja usar os comandos vpdn incoming e vpdn outgoing, consulte Configuring Virtual Private Dialup Networks (Configurando Redes de Discagem Privada Virtual).
As principais características dessa configuração são as seguintes:
O LAC:
identifica um cliente VPDN com base no nome de domínio recebido na resposta de autenticação (nesta instalação, Challenge Handshake Authentication Protocol [CHAP]).
utiliza seus parâmetros de VPDN local para ativar o túnel e a sessão com o LNS.
O LNS:
Use seus parâmetros VPDN locais para aceitar a sessão e o túnel VPDN do LAC.
autentica o usuário remoto localmente.
atribui um endereço IP do conjunto local para o cliente.
Esta configuração foi desenvolvida e testada utilizando as versões de software e hardware abaixo.
Linha principal do Software Cisco IOS versão 12.2. O recurso IP+ é necessário para VPDN.
Um Cisco AS5300 (o LAC) com uma placa E1 e uma placa Mica. Ele pode aceitar chamadas ISDN e analógicas.
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Nesta seção, você encontrará informações para configurar os recursos descritos neste documento.
Nota:Use a Command Lookup Tool (somente clientes registrados) para obter mais informações sobre os comandos usados neste documento.
Este documento utiliza a seguinte configuração de rede:
LAC |
---|
version 12.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname LAC ! spe 2/0 2/9 firmware location system:/ucode/mica_port_firmware ! ! modem country mica belgium ! vpdn enable ! -- Enables VPDN. ! vpdn search-order domain ! -- VPDN tunnel authorization is based on the domain name ! -- (the default is DNIS). ! vpdn-group GroupCisco request-dialin protocol l2tp ! -- L2TP is used instead of the default (L2F). domain cisco.com ! -- The domain name cisco.com is used to identify a VPDN user when ! -- receiving the CHAP response from the user. initiate-to ip 10.48.74.35 ! -- The tunnel and session are initialized to the ethernet ip address of the ! -- LNS 10.48.74.35. l2tp tunnel password cisco ! -- for tunnel authentication ! isdn switch-type primary-net5 ! controller E1 0 clock source line primary pri-group timeslots 1-31 ! interface Ethernet0 ip address 10.48.75.7 255.255.254.0 ! interface Serial0:15 no ip address encapsulation ppp dialer rotary-group 1 isdn switch-type primary-net5 isdn incoming-voice modem ! interface Group-Async1 no ip address encapsulation ppp async mode dedicated ppp authentication chap pap group-range 1 120 ! interface Dialer1 no ip address encapsulation ppp ppp authentication chap pap ! ip classless ip route 0.0.0.0 0.0.0.0 10.48.74.1 ! line con 0 exec-timeout 0 0 line 1 120 modem InOut transport input all line aux 0 line vty 0 4 exec-timeout 0 0 password cisco login ! |
LNS |
---|
version 12.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname LNS ! username UserISDN@cisco.com password 0 cisco username UserAnalog@cisco.com password 0 cisco ! -- The LNS authenticates the remote users locally. ! vpdn enable ! -- Enables VPDN. ! vpdn-group VPDN accept-dialin ! -- Enables the LNS to accept VPDN request. protocol l2tp !-- L2TP is used instead of the L2F (default). virtual-template 1 ! -- For each user, the virtual-template 1 is used to terminate the PPP session. terminate-from hostname LAC ! -- The LNS accepts VPDN request from router LAC. l2tp tunnel password cisco ! -- for tunnel authentication ! ! ! ! interface Loopback1 ip address 12.12.12.1 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Ethernet0 ip address 10.48.74.35 255.255.254.0 no ip route-cache no ip mroute-cache no cdp enable ! interface Virtual-Template1 ! -- The PPP session is terminated in the virtual-access cloned from this ! -- virtual-template ip unnumbered Loopback1 peer default ip address pool GroupCisco ppp authentication chap pap ! ip local pool GroupCisco 12.12.12.2 12.12.12.50 ! -- The LNS assigns an ip address to the remote user ip classless ip route 0.0.0.0 0.0.0.0 10.48.74.1 |
Observação: nas configurações acima, configuramos as interfaces dialer 1 e group-async1 com as opções mínimas de Point to Point Protocol (PPP).
Para permitir mais funcionalidades em PPP (ppp multilink, compressão, etc.), você precisa adicionar estas funcionalidades nessas interfaces e no modelo virtual 1 do LNS.
Importante: A regra é que todas as opções PPP definidas nas interfaces do discador 1 e do grupo assíncrono1 devem ser configuradas no modelo virtual 1 do LNS.
O molde virtual 1 recebe uma "cópia" de opções LCP negociadas entre o LAC e o cliente. Se uma opção que foi negociada entre o LAC e o cliente não estiver configurada no molde virtual 1, o LNS limpará a sessão VPDN. No entanto, para permitir que o LNS renegocie o LCP com o cliente, defina os comandos lcp renegotiation always ou lcp renegotiation on-mismatch no grupo VPDN.
Observação: por padrão, o LAC e o LNS usam seu nome de host nos pacotes de troca L2TP. Para modificar esse comportamento, defina o nome local do comando no grupo vpdn. Vamos ver um exemplo de uma configuração de LNS:
vpdn-group VPDN accept-dialin protocol l2tp virtual-template 1 terminate-from hostname LAC local name LNS-cental
Esta seção fornece informações que você pode usar para confirmar se sua configuração está funcionando adequadamente.
A Output Interpreter Tool ( somente clientes registrados) (OIT) oferece suporte a determinados comandos show. Use a OIT para exibir uma análise da saída do comando show.
show vpdn tunnel — Exibe informações sobre todos os túneis L2F e L2TP ativos no formato de estilo de resumo.
show caller ip — Exibe um resumo das informações do chamador para o endereço IP fornecido.
Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.
Note: Consulte Informações Importantes sobre Comandos de Depuração antes de usar comandos debug.
No LAC:
debug vpdn event — Exibe erros e eventos L2TP que fazem parte do estabelecimento ou encerramento normal de túnel para VPDNs.
debug vpdn l2x-event — Exibe mensagens sobre eventos que fazem parte do estabelecimento ou encerramento normal de túneis para 12x.
debug vpdn l2x-error—Exibe os erros do protocolo L2x que impedem seu estabelecimento ou sua operação normal.
debug ppp negotiation — faz o comando debug ppp exibir pacotes PPP transmitidos durante a inicialização PPP, em que as opções PPP são negociadas.
debug isdn q931 — exibe informações sobre configuração de chamada e subdivisão de conexões de rede ISDN (Camada 3) entre o roteador local (lado do usuário) e a rede.
debug modem—Exibe a atividade da linha do modem em um servidor de acesso.
No LNS:
debug vpdn event
debug vpdn l2x-event
debug vpdn l2x-error
debug vtemplate — exibe informações de clonagem para uma interface de acesso virtual a partir do tempo em que elas são clonadas de um molde virtual até o tempo em que a interface de acesso virtual cai, quando a ligação termina.
negociação de debug ppp
Abaixo está uma chamada ISDN do cliente UserISDN@cisco.com.
debug Comandos no LAC
O LAC recebe uma chamada ISDN do número 8101.
LAC# *Feb 1 14:45:09.684: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x3D03 *Feb 1 14:45:09.688: Sending Complete *Feb 1 14:45:09.688: Bearer Capability i = 0x8890 *Feb 1 14:45:09.688: Channel ID i = 0xA18387 *Feb 1 14:45:09.688: Calling Party Number i = 0xA1, '8101', Plan:ISDN, Type:National *Feb 1 14:45:09.688: Called Party Number i = 0x81, '214', Plan:ISDN, Type:Unknown *Feb 1 14:45:09.692: %LINK-3-UPDOWN: Interface Serial0:6, changed state to up *Feb 1 14:45:09.692: Se0:6 PPP: Treating connection as a callin *Feb 1 14:45:09.692: Se0:6 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] *Feb 1 14:45:09.692: Se0:6 LCP: State is Listen *Feb 1 14:45:09.696: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0xBD03 *Feb 1 14:45:09.696: Channel ID i = 0xA98387 *Feb 1 14:45:09.696: ISDN Se0:15: TX -> CONNECT pd = 8 callref = 0xBD03 *Feb 1 14:45:09.696: Channel ID i = 0xA98387 ! -- The ISDN phase is finished and the B channel is up ! -- as soon as the LAC receives RX <- CONNECT_ACK. *Feb 1 14:45:09.752: ISDN Se0:15: RX <- CONNECT_ACK pd = 8 callref = 0x3D03 *Feb 1 14:45:09.752: ISDN Se0:15: CALL_PROGRESS: CALL_CONNECTED call id 0x90, bchan 6, dsl 0 ! -- PPP starts with LCP phase : authentication protocol and other LCP ! -- options (compression, multilink, and so on) are negotiated. ! -- In the debug below, only chap is negotiated. *Feb 1 14:45:09.844: Se0:6 LCP: I CONFREQ [Listen] id 179 len 10 *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Feb 1 14:45:09.844: Se0:6 LCP: O CONFREQ [Listen] id 1 len 15 *Feb 1 14:45:09.844: Se0:6 LCP: AuthProto CHAP (0x0305C22305) *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Feb 1 14:45:09.844: Se0:6 LCP: O CONFACK [Listen] id 179 len 10 *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Feb 1 14:45:09.876: Se0:6 LCP: I CONFACK [ACKsent] id 1 len 15 *Feb 1 14:45:09.876: Se0:6 LCP: AuthProto CHAP (0x0305C22305) *Feb 1 14:45:09.876: Se0:6 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Feb 1 14:45:09.876: Se0:6 LCP: State is Open *Feb 1 14:45:09.876: Se0:6 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load] ! -- The LAC sends the client a CHAP challenge. *Feb 1 14:45:09.876: Se0:6 CHAP: O CHALLENGE id 1 len 24 from "LAC". ! -- The LAC receives the CHAP response from the client with username ! -- UserISDN@cisco.com. *Feb 1 14:45:09.924: Se0:6 CHAP: I RESPONSE id 1 len 39 from "UserISDN@cisco.com" ! -- The LAC checks out if UserISDN@cisco.com is a VPDN client or not. ! -- Because the domain cisco.com is configured in the vpdn-group ! -- GroupCisco, UserISDN@cisco.com is a VPDN client. The LAC takes ! -- the VPDN parameters in the vpdn-group where the domain name ! -- cisco.com is located. *Feb 1 14:45:09.924: Se0:6 PPP: Phase is FORWARDING [0 sess, 0 load] *Feb 1 14:45:09.924: Se0:6 VPDN: Got DNIS string 214 *Feb 1 14:45:09.924: Se0:6 VPDN: Looking for tunnel -- cisco.com -- *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: Got tunnel info for cisco.com *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: LAC *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: l2tp-busy-disconnect yes *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: IP 10.48.74.35 *Feb 1 14:45:09.928: Se0:6 VPDN/GroupCisco: curlvl 1 Address 0: 10.48.74.35, priority 1 *Feb 1 14:45:09.928: Se0:6 VPDN/GroupCisco: Select non-active address 10.48.74.35, priority 1 *Feb 1 14:45:09.928: Se0:6 VPDN: Find LNS process created *Feb 1 14:45:09.928: Tnl 2027 L2TP: SM State idle ! -- In order to bring up the tunnel, the LAC sends SCCRQ (Start Control ! -- Connection Request) to the LNS. ! -- A CHAP challenge is included in the packet. *Feb 1 14:45:09.928: Tnl 2027 L2TP: O SCCRQ *Feb 1 14:45:09.928: Tnl 2027 L2TP: Tunnel state change from idle to wait-ctl-reply *Feb 1 14:45:09.928: Tnl 2027 L2TP: SM State wait-ctl-reply *Feb 1 14:45:09.928: Se0:6 VPDN: Forward to address 10.48.74.35 *Feb 1 14:45:09.928: Se0:6 VPDN: Pending *Feb 1 14:45:09.932: Se0:6 VPDN: Process created ! -- The LAC receives from the LNS SCCRP (Start Control Connection Reply). ! -- The response to its own chalenge and another chap chalenge from the LNS ! -- are included in the packet. *Feb 1 14:45:09.956: Tnl 2027 L2TP: I SCCRP from LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Got a challenge from remote peer, LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Got a response from remote peer, LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Tunnel Authentication success *Feb 1 14:45:09.956: Tnl 2027 L2TP: Tunnel state change from wait-ctl-reply to established ! -- The LAC sends to the LNS SCCCN (Start Control Connection Connected). ! -- The response to LNS's challenge is included in the packet. *Feb 1 14:45:09.956: Tnl 2027 L2TP: O SCCCN to LNS tnlid 11514 *Feb 1 14:45:09.956: Tnl 2027 L2TP: SM State established *Feb 1 14:45:09.956: Se0:6 VPDN: Forwarding... *Feb 1 14:45:09.956: Se0:6 VPDN: Bind interface direction=1 *Feb 1 14:45:09.956: Tnl/Cl 2027/18 L2TP: Session FS enabled *Feb 1 14:45:09.956: Tnl/Cl 2027/18 L2TP: Session state change from idle to wait-for-tunnel *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: Create session *Feb 1 14:45:09.960: Tnl 2027 L2TP: SM State established ! -- The Tunnel is up. The LAC brings up the session for the user ! -- UserISDN@cisco.com. For that, it sends ICRQ (Incoming Call ReQuest). *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: O ICRQ to LNS 11514/0 *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: Session state change from wait-for-tunnel to wait-reply *Feb 1 14:45:09.960: Se0:6 VPDN: UserISDN@cisco.com is forwarded ! -- After receiving ICRP (Incoming Call Reply, we don't see it in the debug) ! -- the LAC sends ICCN Incoming Call Connected. The VPDN session is up . ! -- Then the LAC forwards to the LNS what it has negotiated with the client ! -- (LCP options) along with the username and chap password of the client. *Feb 1 14:45:10.008: Se0:6 Tnl/Cl 2027/18 L2TP: O ICCN to LNS 11514/6 *Feb 1 14:45:10.008: Se0:6 Tnl/Cl 2027/18 L2TP: Session state change from wait-reply to established *Feb 1 14:45:10.960: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:6, changed state to up *Feb 1 14:45:15.692: %ISDN-6-CONNECT: Interface Serial0:6 is now connected to 8101 UserISDN@cisco.com LAC#
debug Comandos no LNS
O LNS recebe SCCRQ de LAC.
LNS# *Mar 1 02:13:06.499: L2TP: I SCCRQ from LAC tnl 2027 *Mar 1 02:13:06.507: Tnl 11514 L2TP: Got a challenge in SCCRQ, LAC *Mar 1 02:13:06.511: Tnl 11514 L2TP: New tunnel created for remote LAC, address 10.48.75.7 ! -- The LNS replies with SCCRP which includes the CHAP response to LAC's ! -- challenge and a CHAP challenge. *Mar 1 02:13:06.515: Tnl 11514 L2TP: O SCCRP to LAC tnlid 2027 *Mar 1 02:13:06.523: Tnl 11514 L2TP: Tunnel state change from idle to wait-ctl-reply ! -- The LNS receives SCCCN. *Mar 1 02:13:06.535: Tnl 11514 L2TP: I SCCCN from LAC tnl 2027 *Mar 1 02:13:06.539: Tnl 11514 L2TP: Got a Challenge Response in SCCCN from LAC *Mar 1 02:13:06.543: Tnl 11514 L2TP: Tunnel Authentication success *Mar 1 02:13:06.543: Tnl 11514 L2TP: Tunnel state change from wait-ctl-reply to established *Mar 1 02:13:06.547: Tnl 11514 L2TP: SM State established ! -- The tunnel is up. The LNS receives ICRQ to bring up the session. *Mar 1 02:13:06.555: Tnl 11514 L2TP: I ICRQ from LAC tnl 2027 *Mar 1 02:13:06.559: Tnl/Cl 11514/6 L2TP: Session FS enabled *Mar 1 02:13:06.563: Tnl/Cl 11514/6 L2TP: Session state change from idle to wait-connect *Mar 1 02:13:06.567: Tnl/Cl 11514/6 L2TP: New session created ! -- The LNS replies with ICRP (Incoming Call Reply). *Mar 1 02:13:06.567: Tnl/Cl 11514/6 L2TP: O ICRP to LAC 2027/18 ! -- The LNS receives ICCN (Incoming Call coNnected). The VPDN sesion is up, ! -- then the LNS receives the LCP layer along with the username ! -- and chap password of the client. ! -- A virtual-access is cloned from the virtual-template 1. *Mar 1 02:13:06.583: Tnl/Cl 11514/6 L2TP: I ICCN from LAC tnl 2027, cl 18 *Mar 1 02:13:06.591: Tnl/Cl 11514/6 L2TP: Session state change from wait-connect to established *Mar 1 02:13:06.591: Vt1 VTEMPLATE: Unable to create and clone vaccess *Mar 1 02:13:06.595: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 1 *Mar 1 02:13:06.595: Vi1 VTEMPLATE: Hardware address 0000.0c4a.4314 *Mar 1 02:13:06.599: Vi1 VPDN: Virtual interface created for UserISDN@cisco.com *Mar 1 02:13:06.603: Vi1 PPP: Phase is DOWN, Setup [0 sess, 0 load] *Mar 1 02:13:06.603: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking *Mar 1 02:13:06.607: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vtemplate *Mar 1 02:13:06.611: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ***************** *Mar 1 02:13:06.615: Vi1 VTEMPLATE: Clone from Virtual-Template1 interface Virtual-Access1 default ip address no ip address encap ppp ip unnumbered Loopback1 end *Mar 1 02:13:07.095: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Mar 1 02:13:07.099: Vi1 PPP: Using set call direction *Mar 1 02:13:07.103: Vi1 PPP: Treating connection as a callin *Mar 1 02:13:07.103: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] *Mar 1 02:13:07.107: Vi1 LCP: State is Listen *Mar 1 02:13:07.111: Vi1 VPDN: Bind interface direction=2 *Mar 1 02:13:07.111: Vi1 LCP: I FORCED CONFREQ len 11 *Mar 1 02:13:07.115: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 02:13:07.119: Vi1 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Mar 1 02:13:07.119: Vi1 VPDN: PPP LCP accepted rcv CONFACK *Mar 1 02:13:07.123: Vi1 LCP: I FORCED CONFACK len 6 *Mar 1 02:13:07.127: Vi1 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Mar 1 02:13:07.131: Vi1 VPDN: PPP LCP accepted sent CONFACK ! -- The LNS authenticates the user. It doesn't send a new CHAP challenge ! -- (the debug may be confusing) since it has received the CHAP challenge ! -- and response from the LAC. *Mar 1 02:13:07.131: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load] *Mar 1 02:13:07.135: Vi1 CHAP: O CHALLENGE id 2 len 24 from "LNS" *Mar 1 02:13:07.143: Vi1 CHAP: I RESPONSE id 1 len 39 from "UserISDN@cisco.com" *Mar 1 02:13:07.151: Vi1 CHAP: O SUCCESS id 1 len 4 *Mar 1 02:13:07.155: Vi1 PPP: Phase is UP [0 sess, 0 load] ! -- The IPCP phase starts. ! -- The IP address 12.12.12.2 is assigned to the client. *Mar 1 02:13:07.159: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 *Mar 1 02:13:07.163: Vi1 IPCP: Address 12.12.12.1 (0x03060C0C0C01) *Mar 1 02:13:07.215: Vi1 IPCP: I CONFREQ [REQsent] id 34 len 10 *Mar 1 02:13:07.219: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 02:13:07.223: Vi1 IPCP: Pool returned 12.12.12.2 *Mar 1 02:13:07.227: Vi1 IPCP: O CONFNAK [REQsent] id 34 len 10 *Mar 1 02:13:07.231: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.235: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 *Mar 1 02:13:07.239: Vi1 IPCP: Address 12.12.12.1 (0x03060C0C0C01) *Mar 1 02:13:07.271: Vi1 IPCP: I CONFREQ [ACKrcvd] id 35 len 10 *Mar 1 02:13:07.275: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.279: Vi1 IPCP: O CONFACK [ACKrcvd] id 35 len 10 *Mar 1 02:13:07.283: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.287: Vi1 IPCP: State is Open *Mar 1 02:13:07.295: Vi1 IPCP: Install route to 12.12.12.2 ! -- The virtual-access is up. *Mar 1 02:13:08.159: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up LNS#
show Comandos
LAC#show vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 36556 45655 LNS est 10.48.74.35 1701 1 %No active L2F tunnels %No active PPTP tunnels %No active PPPoE tunnels LAC#
LNS#show vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 45655 36556 LAC est 10.48.75.7 1701 1 %No active L2F tunnels %No active PPTP tunnels %No active
LNS#show caller ip Line User IP Address Local Number Remote Number <-> Vi1 UserISDN@cisco.com \ 12.12.12.2 214 8101 in LNS#
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
09-Sep-2005 |
Versão inicial |