Long Reach Ethernet (LRE) e Digital Subscriber Line (xDSL) : LRE/VDSL (Ethernet de longo alcance/DSL de alta velocidade)

Pesquise defeitos o VDSL

18 Junho 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (21 Abril 2016) | Feedback

Introdução

Este documento descreve como configurar seu roteador do equipamento da premissa do cliente do digital subscriber line (DSL) de Cisco (CPE) para o serviço muito alto da linha de assinante digital da taxa de bits (VDSL). Explica como pesquisar defeitos problemas relacionados VDSL no Cisco 880 Series, no 890 Series, no 860 Series, e no WAN Interface Card de alta velocidade aumentado do Asynchronous Digital Subscriber Line VDSL/(ADSL) (EHWICs). Este documento é muito específico ao serviço VDSL, embora você pode ter o serviço ADSL ou VDSL no Roteadores e nos módulos acima mencionados. Há três camadas em que a falha pode ocorrer:

  • Layer 1 - Conectividade física DSL ao multiplexador de acesso de linha de assinante digital do seu ISP (DSLAM)
  • 2.1 da camada - Conectividade de ponta a ponta dos Ethernet
  • Camada 2.2 - Point-to-Point Protocol sobre Ethernet (PPPoE), IP sobre Ethernet (IPoE), RFC1483 que constrói uma ponte sobre, ou distribuição do RFC1483
  • Camada 3 - IP

Contribuído pelo C de Sunil, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Edições do Layer 1

É a luz do Carrier Detect (CD) no painel dianteiro do roteador Cisco DSL de ligar/desligar?

Se a luz do CD está ligada, vá à seção das edições da camada 2 deste documento.

Se a luz do CD está, continue com a pergunta seguinte.

Seu ISP usa um DSLAM que apoie o chipset de Broadcom?

Verifique a informação de seu ISP. Verifique a Interoperabilidade DSLAM para ver se há o modelo do roteador ou o cartão que refere a folha de dados.

A porta DSL na parte de trás do roteador Cisco DSL é obstruída na tomada de parede DSL?

Se a porta DSL não é obstruída na tomada de parede DSL, conecte a porta à parede com o a reto-através do cabo RJ-11. Este é um cabo de telefone padrão. As linhas uso VDSL fixam 3 e 4.

Que é o status de controle, o modo operacional, e o modo da cobertura da transmissão (TC)?

Veja este exemplo de saída:

Router#show controller vdsl 0/1/0

!--- Make sure the controller is in UP state. In case you see it in down state,
it indicates a Layer 1 issue (Hardware issue, Line issue, Interoperability
issue with DSLAM etc.)

Controller VDSL 0/1/0 is UP

Daemon Status:         Up

!--- XTU-R and XTU-C shows local (Cisco Router) and remote (DSLAM) DSL related
details like chipset vendor, Vendor ID etc.

            XTU-R (DS)        XTU-C (US)
Chip Vendor ID:        'BDCM'             'BDCM'
Chip Vendor Specific:   0x0000             0xA1AA
Chip Vendor Country:    0xB500             0xB500
Modem Vendor ID:     'CSCO'             '    '
Modem Vendor Specific:  0x4602             0x0000
Modem Vendor Country:   0xB500             0x0000
Serial Number Near:     FOC15163V2Q 2911/K9 15.5(1)T
Serial Number Far:     
Modem Version Near:     15.5(1)T
Modem Version Far:      0xa1aa

Modem Status:         TC Sync (Showtime!)

!--- Below shows the configured DSL operating mode, trained mode and TC mode.

DSL Config Mode:     AUTO
Trained Mode:    G.993.2 (VDSL2) Profile 17a
TC Mode:         PTM
Selftest Result:     0x00
DELT configuration:  disabled
DELT state:         not running

Full inits:        1
Failed full inits:   0
Short inits:        0
Failed short inits:  0

!--- DSL firmware related details

Firmware    Source        File Name
--------    ------        ----------
VDSL        embedded       VDSL_LINUX_DEV_01212008

Modem FW  Version:    130205_1433-4.02L.03.B2pvC035j.d23j
Modem PHY Version:    B2pvC035j.d23j
Trellis:         ON              ON
SRA:              disabled         disabled
 SRA count:          0             0
Bit swap:          enabled         enabled
 Bit swap count:     0             0
!--- Attenuation and Noise margin are two important parameters which points to
the line quality and intern the stability of the DSL connection
Line Attenuation:      0.0 dB          0.0 dB
Signal Attenuation:      0.0 dB          0.0 dB
Noise Margin:         11.1 dB          6.0 dB
Attainable Rate:    40440 kbits/s   3280 kbits/s
Actual Power:         14.5 dBm          4.9 dBm
Per Band Status:       D1     D2     D3     U0     U1     U2     U3
Line Attenuation(dB):   20.0    48.3    73.7    9.4    37.9   56.2   N/A    
Signal Attenuation(dB): 20.0    48.3    N/A    10.2    36.2   53.3   N/A    
Noise Margin(dB):       10.9    11.3    N/A    5.9    6.0    6.0    N/A    
Total FECC:        97252         0
Total ES:        7             0
Total SES:         0             0
Total LOSS:        0             0
Total UAS:        24             24
Total LPRS:        0             0
Total LOFS:        0             0
Total LOLS:        0             0

!--- DSL trained speed can be found below

DSChannel1   DSChannel0    US Channel1   US Channel0
Speed (kbps):              0           25087             0            3192
SRA Previous Speed:        0               0             0               0
Previous Speed:            0               0             0               0
Reed-Solomon EC:           0           97252             0               0
CRC Errors:               0              15             0               0
Header Errors:             0              62             0               0
Interleave (ms):        0.00            8.00          0.00            8.00
Actual INP:           0.00            3.01          0.00            2.00

Training Log :    Stopped
Training Log Filename :    flash:vdsllog.bin

Router#

Verifique para ver se há estes no comando show controller output:

  • O status de controle está “ACIMA DE”. Se está no “para baixo” indique, ele indica uma edição do Layer 1 (o problema de hardware, alinha a edição, ou a questão de interoperabilidade com DSLAM). Continue com o Layer 1 que pesquisa defeitos neste caso.
  • Verifique o modo operacional, o modo treinado, e o modo TC. Certifique-se de você ter o modo operacional correto configurado sob o controlador. Cisco recomenda que você usa o automóvel do modo operacional DSL se você não é certo que tecnologia do Discrete Multi-Tone (DMT) seu ISP usa. Estes são os comandos configurar o autodetection do modo operacional:
    Router#configure terminal

    Enter configuration commands, one per line. End with CNTL/Z.

    Router(config)#controller vdsl 0

    Router(config-controller)#operating-mode auto

    Router(config-controller)#end

    Router#write memory

    Olhe o modo treinado e certifique-se de você ter o modo correto negociado com o ISP. Um outro parâmetro importante a olhar é o modo TC. Caso que o modo de treinamento é VDSL2 ou VDSL2+, o modo TC será o modo de transferência de pacote de informação (PTM). Neste caso, você precisa de ver a interface Ethernet PTM no “acima” do estado e todos os parâmetros da camada superior tais como o PPP, IP, e assim por diante devem ser configurados sob a interface Ethernet. Se o modo treinado é ADSL, ADSL2, ou ADSL2+, o modo TC deve ser ATM e todos os parâmetros da camada superior devem ser configurados sob os Circuitos Virtuais Permanentes (PVC) ATM neste caso. Se você muda o modo operacional entre o ADSL e o VDSL, você não pôde precisar de recarregar o roteador a fim ativar os Ethernet ou as interfaces ATM correspondentes.

Verifique a margem de ruído e a atenuação. A margem de ruído é a potência relativa do Signal to Noise Ratio DSL. Mais alto o número o melhor para esta medida:

  • 6dB ou abaixo é ruim e não experimentará nenhum sincronização ou problema intermitente da sincronização
  • o 7dB-10dB é justo, mas não sae de muita sala para variações nas circunstâncias
  • 11dB-20dB é bom com pouco ou nenhum problemas da sincronização
  • 20dB-28dB é excelente
  • 29dB ou é acima proeminente

A atenuação é uma medida de quanto o sinal degradou entre o DSLAM e o modem. Esta é pela maior parte uma função da distância da troca. Mais baixo o DB o melhor para esta medida.

  • 20dB e é abaixo proeminente
  • 20dB-30dB é excelente
  • 30dB-40dB é muito bom
  • 40dB-50dB é bom
  • 50dB-60dB é deficiente e pôde experimentar problemas de conectividade
  • 60dB ou acima é ruim e experimentará problemas de conectividade

Certifique-se de você ter uma das versões as mais atrasadas do firmware VDSL. O firmware mais recente tem um reparo para a maioria das questões de interoperabilidade conhecidas. Você pode transferir o firmware mais recente do CCO.

Verifique que o DSL é em sincronia com velocidades apropriadas do fluxo acima e fluxo abaixo.

Você tem o modelo do roteador correto?

Note que o Roteadores ADSL/VDSL vem em duas versões; 1) DSL sobre o serviço de telefonia velho liso (Annex-a) e 2) DSL sobre o Integrated Services Digital Network (Annex-b). Em alguns países, os ISP fornecem uma conexão do Annex-b, quando em na maioria de outro for Annex-a. Um roteador DSL ou um cartão do Annex-a não sincronização com uma linha do Annex-b e vice-versa. Daqui você precisa de certificar-se de que você tem o modelo do roteador direito no lugar. Veja a folha de dados do roteador para mais informação.

É o circuito testado/fornecida corretamente?

Obtenha esta informação de sua ISP ou companhia telefônica.

Mergulhe 2 edições

É o PTM Ethernet acima?

Uma vez que se verifica que o modo treinado é VDSL, certifique-se que a interface Ethernet está no “acima” do estado.

Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Embedded-Service-Engine0/0 unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/0         unassigned      YES NVRAM  up                    up      
GigabitEthernet0/0.1       unassigned      YES unset  up                    up           
GigabitEthernet0/1         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/2         192.168.22.1    YES NVRAM  up                    up      
ISM0/1                     unassigned      YES unset  up                    up      
ATM0/1/0                   unassigned      YES NVRAM  administratively down down    
!--- Verify that the Ethernet interface is in up state
Ethernet0/1/0              unassigned      YES NVRAM  up                    up

O fornecedor espera o tráfego rotulado? Se sim, que é o identificador do LAN virtual (ID de VLAN)?

A maioria dos fornecedores esperam o tráfego rotulado do equipamento da premissa do cliente (CPE). Você pode configurar o VLAN que etiqueta como mostrado aqui depois que você obtém o ID de VLAN de seu ISP.

Router(config)#interface Ethernet0.835

Router(config-subif)#encapsulation dot1Q 835

Router(config-subif)#end

Router#

A entrada do Address Resolution Protocol (ARP) é povoada?

Determine se o MAC address do telecontrole está na saída do comando show arp.

Você recebe dados de seu ISP?

Se você tem o ID de VLAN correto, a próxima etapa é verificar sua tentativa de negociar o protocolo ponto-a-ponto (PPP) com seu ISP. A fim fazer isto, inscreva o comando show interface ethernet0 e verifique os pacotes de entrada e saída.

Router#show interface ethernet0
Ethernet0/1/0 is up, line protocol is up
  Hardware is VDSL_ETHERNET, address is 30f7.0d7e.3408 (bia 30f7.0d7e.3408)
  MTU 1500 bytes, BW 3261 Kbit/sec, DLY 3000 usec,
     reliability 255/255, txload 19/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:19, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/1024 (size/max)
  5 minute input rate 23000 bits/sec, 19 packets/sec
  5 minute output rate 244000 bits/sec, 29 packets/sec
     3096276 packets input, 3672318911 bytes, 0 no buffer
     Received 0 broadcasts (1517324 IP multicasts)
     0 runts, 0 giants, 1 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     1287646 packets output, 240862302 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out


Router#show controller vdsl 0 datapath
ptm0            Link encap:Ethernet  HWaddr 02:10:18:01:00:02  
                UP BROADCAST RUNNING MULTICAST  MTU:1600  Metric:1
                RX packets:3111732 errors:0 dropped:0 overruns:0 frame:0
                TX packets:1311107 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000
                RX bytes:3677814427 (3.4 GiB)  TX bytes:265796876 (253.4 MiB)

atm/ptm interface statistics for port 0
in octets                   4983267
out octets                  27636440
in packets                  16376
out packets                 26024
in OAM cells                0
out OAM cells               0
in ASM cells                0
out ASM cells               0
in packet errors            0
in cell errors              0

Se os contadores de pacote de informação incrementam, você deve receber pacotes de negociação PPP de seu ISP. Se tal não for o caso, chame seu ISP.

Se os contadores encadernados da saída incrementam, você deve enviar pacotes de negociação PPP. Se tal não for o caso, verifique a configuração no roteador. Se o PPP é configurado corretamente, os pacotes de negociação PPP estão mandados continuamente a relação do ethernet0.

O PPP negocia corretamente?

Se o Layer 1 é ascendente e você tem o ID de VLAN correto, a próxima etapa é certificar-se que o PPP vem acima corretamente. A fim realizar isto, você precisa de executar uma série de comandos debug no roteador Cisco DSL e de interpretar a saída. O comando debug que preliminar você se usa é debuga a negociação ppp. Esta saída do comando é um exemplo de uma negociação de PPP bem-sucedida:

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

Router#
2w3d: Vi1 PPP: No remote authentication for call-out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 10.10.10.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 10.10.10.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 10.10.10.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 10.1.1.1
2w3d: Di1 IPCP: Install route to 10.10.10.1
Router#

Há quatro pontos principais da falha em uma negociação de PPP:

  • Nenhuma resposta do dispositivo remoto (seu ISP)
  • Protocolo de controle de link (LCP) não aberto
  • Falha de autenticação
  • Falha do protocolo de controle de IP (IPCP)

Nenhuma resposta de seu ISP

Se seu ISP não responde, este não deve ser um problema desde que você já verificou que os pacotes incrementam na relação do ethernet0 na direção de entrada. Contudo, se os pacotes incrementam no ethernet0 na direção de entrada, e você receba isto quando você é executado debuga a negociação ppp, contacta seu ISP a fim verificar que os pacotes estão enviados ao roteador Cisco DSL.

Router#debug ppp negotiation
*Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout
*Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10

!--- "O" specifies an outbound packet

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10

!--- "O" specifies an outbound packet

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10
*Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10
*Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10
*Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10
*Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10

!--- "O" specifies an outbound packet

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
Router#undebug all

Nesta saída há somente os pacotes O, que são pacotes externos. A fim negociar com sucesso o PPP, deve haver um pacote de entrada I de seu ISP para cada pacote O enviado. Se os pacotes incrementam de entrada, mas você não vê pacotes I, contacte seu ISP a fim verificar os pacotes que são enviados ao roteador Cisco DSL.

LCP não aberto

Se o LCP não está aberto, este está causado geralmente por uma má combinação nas opções de PPP. Esta má combinação ocorre quando o roteador Cisco DSL tem um parâmetro PPP configurado que seu ISP não apoia, ou quando seu ISP tem um parâmetro configurado que o roteador Cisco DSL não apoia. Esta saída mostra um exemplo de uma má combinação da opção de PPP:

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

Se é um I ou um pacote O, um Configurar-Negativo-reconhecimento (CONFNAK) é indicativo de uma má combinação da configuração de PPP. O que este os meios são que um lado da conexão PPP pede uma opção de PPP que o outro lado é incapaz ou não configurado de executar. Se o roteador Cisco DSL envia o CONFNAK (indicado por “O CONFNAK”), o roteador Cisco DSL não pode executar nem não está configurado para a opção que o ISP envia. Se o CONFNAK está enviado por seu ISP (indicado pelo “mim CONFNAK”), você configurou uma opção no roteador Cisco DSL que seu ISP não quer executar.

A linha depois que o CONFNAK descreve a opção que está rejeitada. Nestas saídas de exemplo, a opção é protocolo de autenticação de cumprimento do desafio (RACHADURA), mas poderia ser toda a opção. O único lugar no roteador Cisco DSL onde as opções de PPP podem ser configuradas é o discador 1. da relação incorpora o interface dialer 1 do comando show run a fim ver sua configuração do interface dialer 1.

Se seu ISP envia o I CONFNAK, procure os comandos sob o interface dialer 1 que combinam a linha após o CONFNAK e os removem. Se o roteador Cisco DSL envia o O CONFNAK, adicionar um comando ao interface dialer 1 a fim negociar corretamente o PPP com seu ISP. No caso em que o roteador enviasse pacotes, você pôde precisar de chamar Cisco apoia a fim determinar que comandos precisam de ser permitidos no roteador Cisco DSL.

Falha de autenticação

Uma falha de autenticação ocorre quando seu ISP é incapaz de autenticar sua username PPP ou senha. Há duas encenações em que este pode ocorrer. A primeira encenação é uma má combinação do tipo do autenticação, que seja causada quando você não configura corretamente o roteador. Todas as configurações de autenticação alistadas neste documento esclarecem tipos do protocolo password authentication (PAP) e da autenticação chap. Para a flexibilidade de configuração, você deve ter a RACHADURA e o PAP configurados. Se você não tem ambos configurados, você pôde ver a saída de um comando debug ppp negotiation como este exemplo:

Router#debug ppp negotiation
00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)

!--- Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8
Router#undebug all

A fim corrigir ambos os problemas de incompatibilidade da autenticação, você precisa de reconfigurar o protocolo de autenticação a esse pedido pelo ISP no pacote de entrada CONFREQ.

Como eu sei se meus nome de usuário de PAP e senha estão corretos?

Depois que você confirmou que seu ISP usa o PAP, inscreva o comando debug ppp negotiation a fim confirmar que seus nome de usuário de PAP e senha estão corretos.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco"

!--- "cisco" is the PAP username configured on this DSL Router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

Você precisa de contactar seu ISP e de conseguir as credenciais corretas a fim fixar isto. Você pode reconfigurar as credenciais PAP com estes comandos:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username <username> password <password>
Router(config-if)#end
Router#write memory

Como eu sei se meu nome de usuário e senha da RACHADURA está correto?

Depois que você confirmou que seus usos ISP RACHAM, inscreva o comando debug ppp negotiation a fim confirmar que seu nome de usuário e senha da RACHADURA está correto.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL Router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

Você precisa de contactar seu ISP e de conseguir as credenciais corretas a fim fixar isto. Você pode reconfigurar as credenciais da RACHADURA com estes comandos:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname <username>
Router(config-if)#ppp chap password <password>
Router(config-if)#end
Router#write memory

Como eu sei quando a autenticação de PPP é bem sucedida?

Este exemplo mostra uma negociação bem sucedida da RACHADURA.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4

!--- CHAP negotiation was a success.

*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load]
<... snipped ...>
Router#undebug all
This example shows a successful PAP negotiation.
Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load]

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all

Problemas de desempenho sobre o PPPoE

Esta seção é específica às conexões PPPoE. Espera-se ver edições com taxa de transferência, consultação lenta, e assim por diante com conexões PPPoE quando você usa o tamanho da unidade de transmissão máxima (MTU) do padrão na interface do discador. Você precisa de ajustar o MTU no discador PPPoE a 1492 a fim tomar esclarece os oito bytes usados pelo cabeçalho PPPoE. Incorpore estes comandos a fim configurar o MTU apropriado:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#mtu 1492

  


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 119009