IP : Serviços de endereçamento IP

Troubleshooting de Problemas de DHCP em Redes a Cabo com uso de Cisco Network Registrar Debugs

29 Julho 2013 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (26 Outubro 2005) | Feedback


Índice


Introdução

O mandato do Data-over-Cable Service Interface Specifications (DOCSIS) que o Modems a cabo negocia seus endereços IP de Um ou Mais Servidores Cisco ICM NT com o DHCP. O Cisco Network Registrar (CNR) fornece o Domain Name System (DNS) e a funcionalidade administrativa do DHCP detalhados. O CNR igualmente fornece a funcionalidade de servidor de TFTP.

A negociação do DHCP é um problema comum nos ambientes de rede do cabo que transportam dados IP. Você pode permitir debuga no CNR para pesquisar defeitos a negociação do DHCP. Este documento começa com uma explicação da funcionalidade de CNR, a seguir explica como permitir debuga. Finalmente, fornece os exemplos comuns de situações aonde o Modems a cabo não vem em linha ou onde o Customer Premises Equipment (CPE) atrás do Modems a cabo não pode conectar ao Internet.

Pré-requisitos

Requisitos

Este documento aplica-se ao CNR5.0.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Sistemas UNIX

    • Solaris

    • HP/UX

    • AIX

  • Windows NT

  • Windows 2000

Nota: A interface GUI para sistemas UNIX está disponível somente em Solaris.

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.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Estrutura de diretórios no CNR

Sistemas UNIX

A estrutura do diretório para UNIX começa neste diretório:

/opt/nwreg2

O diretório contem estes sub-directórios:

skyshark# ls -l

total 18
drwxr-xr-x   2 root     bin         1024 Mar 28 18:34 bin/
drwxr-xr-x   2 root     bin          512 Mar 28 18:35 conf/
drwxr-xr-x   3 root     bin          512 Mar 28 18:33 docs/
drwxr-xr-x   3 root     bin          512 Mar 28 18:31 examples/
drwxr-xr-x   3 root     bin          512 Mar 28 18:31 extensions/
drwxr-xr-x   3 root     bin         1024 Mar 28 18:35 lib/
drwxr-xr-x   2 root     bin          512 Mar 28 18:33 misc/
drwxr-xr-x   2 root     bin          512 Apr  2 18:39 usrbin/
drwxr-xr-x   5 root     bin          512 Mar 28 18:31 WebUI/

Os sub-directórios contêm estes componentes:

  • escaninho — Programas executáveis.

  • conf — Arquivos de configuração.

  • liberal — Bibliotecas usadas por arquivos executáveis.

  • usrbin — O sub-directório em que você lança o GUI ou o nrcmd (comando network registrar, o [CLI] da interface da linha de comando CNR).

Para lançar o GUI, ntwkreg da edição. Para lançar o CLI, nrcmd da edição.

O diretório de /opt/nwreg2/usrbin contem estes arquivos:

skyshark# pwd

/opt/nwreg2/usrbin

skyshark# ls -l

total 11422
-r-xr-xr-x   1 root     bin          980 Mar 28 18:35 aicstatus*
-r-xr-xr-x   1 root     bin          365 Mar 28 18:34 cnrFailoverConfig*
-r-xr-xr-x   1 root     bin          179 Mar 28 18:34 mcdadmin*
-r-xr-xr-x   1 root     bin          180 Mar 28 18:35 mcdshadow*
-r-xr-xr-x   1 root     bin          385 Mar 28 18:34 nrcmd*
-r-xr-xr-x   1 root     bin         1986 Mar 28 18:35 ntwkreg*

As bases de dados e os registros estão no diretório de /var/nwreg2. Esses arquivos devem ter acesso de gravação.

/var/nwreg2

skyshark# ls -l

total 6
drwxr-xr-x   9 root     other        512 Mar 28 18:36 data/
drwxrwxrwt   3 root     other        512 APR 16 09:07 logs/
drwxr-xr-x   2 root     other        512 Mar 28 18:42 temp/

Os sub-directórios contêm estes componentes:

  • dados — Lugar dos dados e dos arquivos de backup da base de dados:

    • DB — A base de dados ativa.

    • db.bak — Uma cópia da base de dados. Esta cópia é feita cada noite em 11:45 PM (tempo de servidor).

    • dns — O arquivo de cache e o campo de zona competente atual que está sendo lido pelo server e passado aos secondaries em transferência de zona.

  • registros — Este diretório contem os arquivos de registro. Um erro comum é olhar no sub-directório de /opt/. A maneira a mais fácil de recordar é que os registros estão escritos por um server e, devem consequentemente estar em um diretório com acesso de gravação. Os registros são usados frequentemente pesquisar defeitos, e são o que você usa o a maioria neste documento.

  • temp — Arquivos temporário fechados que são usados para executar o agente do servidor AIC.

Em UNIX, há diversos processos relativos a executar o CNR. Para verificar o estado, emita este comando:

skyshark# /opt/nwreg2/usrbin/aicstatus

Server Agent running     (pid: 112)
MCD lock manager running (pid: 118)
MCD server running       (pid: 116)
DNS server running       (pid: 119)
DHCP server running      (pid: 120)

Execute somente um exemplo de cada agente do servidor.

Para parar e começar o processo, emita estes comandos:

skyshark# /etc/init.d/aicservagt stop

skyshark# /etc/init.d/aicservagt start

# Starting AIC Server Agent for Network Registrar

Sistemas Windows

Para o Windows NT e o Windows 2000, a estrutura é similar. Se você instalou o CNR no C: conduza, isto é o diretório de instalação:

C:\Program Files\Network Registrar\

Esse diretório contem estes arquivos e sub-directórios:

C:\Program Files\Network Registrar> dir

 Volume in drive C is W2K
 Volume Serial Number is D439-C697

 Directory of C:\Program Files\Network Registrar

01/24/2001  03:22p      <DIR>          .
01/24/2001  03:22p      <DIR>          ..
01/24/2001  03:22p      <DIR>          BIN
04/14/2001  11:46p      <DIR>          DATA
01/24/2001  03:23p              15,037 DeIsL1.isu
01/24/2001  03:22p      <DIR>          DOCS
01/24/2001  03:22p      <DIR>          EXAMPLES
01/24/2001  03:21p      <DIR>          EXTENSIONS
01/24/2001  03:22p      <DIR>          lib
04/09/2001  08:38a      <DIR>          LOGS
01/24/2001  03:22p      <DIR>          MISC
12/25/2000  05:12p               2,083 README.TXT
01/24/2001  03:21p      <DIR>          TEMP
12/25/2000  10:12p              58,880 unregistrar.dll
01/24/2001  03:21p      <DIR>          WebUI
               3 File(s)         76,000 bytes
              12 Dir(s)   1,426,918,400 bytes free

A estrutura do diretório em NT é diferente do que em Unix. NT é mais flexível porque todos os arquivos são ficados situados em um diretório e os arquivos de leitura apenas específicos são embandeirados.

Em Windows, há somente um processo que está sendo executado: Agente do servidor AIC 2,0. No indicador NT, escolha o > serviços do começo > dos ajustes > do Control Panel para controlá-lo.

Monitor de status de servidor

Você pode monitorar o estado do DNS, do DHCP, e dos servidores TFTP no CNR com o monitor de status de servidor. Este monitor indica os aspetos da saúde do server especificado.

Para adicionar server ao monitor de status de servidor, use este procedimento para arrastar e deixar cair server no monitoramento de status:

  1. Lance o CNR GUI:

    1. No sistema operacional UNIX, lance o xterm e siga este procedimento:

      1. Emita o comando xhost +.

      2. Telnet ao sistema Unix que hospeda o servidor de CNR.

      3. Execute estes comandos:

        • xterm do TERMO do setenv

        • INDICADOR your-local-ip-address:0.0 do setenv

      4. Emita este comando lançar o GUI:

        • /opt/nwreg2/usrbin/ntwkreg &

          Nota:  & permite que você use esse indicador para outros comandos.

    2. No sistema operacional de Windows, escolha o Start > Programs > o registro de rede.

  2. Uma vez que você lança o GUI, o sistema pede-o o nome de usuário e senha. Quando o CNR é instalado primeiramente, usa o admin de nome de usuário e a senha changeme.

    cuidado Cuidado: Mude esta senha.

  3. Clique + sinal ao lado do conjunto que você quer monitorar.

    Você vê agora uma tela similar para figurar 1.

    Figura 1 – Janela do gerenciador do servidor para CNR 5.0.1

    /image/gif/paws/12192/cnr_debug_1.gif

  4. Clicar com o botão direito o server que você quer monitorar e para escolher adicionar ao monitoramento de status. Faça isto para cada server que você quer monitorar.

    O indicador do monitoramento de status mostra uma luz verde ao lado dos server que estão sendo executado. Figura 2 mostra que o DNS e os servidores DHCP para o conjunto 172.16.30.3 são ativos, quando o servidor TFTP para o mesmo conjunto não for (mostra uma luz vermelha).

    Figura 2 – Indicador do monitoramento de status para CNR 5.0.1

    /image/gif/paws/12192/cnr_debug_2.gif

    Nota: Se você quer remover um server do indicador do monitoramento de status, clicar com o botão direito o server e o escolher remova.

Configurações de depurações de DHCP

Você para ter bastante informação no debuga ajustes para pesquisar defeitos um problema de DHCP. A informação salvar nos arquivos de registro. Você pode usar o GUI e o CLI (nrcmd) a ajustar-se debuga no CNR.

Usando o GUI para ajustar-se debuga para o DHCP

Para usar o GUI para ajustar-se debuga para o DHCP, usam este procedimento:

  1. Do gerenciador do servidor, selecione o server para que você quer ajustar a opção debugar.

  2. Clique propriedades da mostra.

  3. Clique o guia avançada na caixa de diálogo das propriedades.

  4. O clique debuga os ajustes (indicados pela seta vermelha em figura 3).

    Figura 3 – Diálogo para ajustar os níveis de debug para o DHCP

    /image/gif/paws/12192/cnr_debug_3.gif

  5. Nos ajustes caixa de diálogo debugar, a verificação Enable debuga.

  6. No campo da categoria, incorpore um do ajuste da tabela 1.

    Tabela 1 – Os ajustes, os níveis, e a descrição para o DHCP debugam ajustes

    Categoria de Servidor (DHCP) Nível Descrição
    VX= 1 Rastreamento de pacotes detalhado recebido e enviado.
    KP= 1-9 Rastreamento de pacotes e detalhes completos dos DN Dinâmicos em todas as mensagens a e do Lightweight Directory Access Protocol (LDAP), incluindo atributos do valor.
    Q= 1-9 Traço do Classe de serviço (CoS).
    Y= 1 A configuração de registro do log-failover-detail.
    Y= 2 Detalhe moderado no Failover.
    Y= 3 Pacotes de comutação formatados. Não inclui pacotes da votação. Isto dá a mesma saída que o VX=1, mas somente para pacotes de comutação.
    Y= 4 Pacotes de comutação formatados, votações incluídas.
    A-LZ-Z= 9 Todo o logging DHCP.

  7. Clique o botão de rádio MLOG, que envia a saída ao arquivo de registro apropriado.

  8. APROVAÇÃO do clique na caixa de diálogo dos ajustes debugar e então na caixa de diálogo das propriedades.

Usando o CLI para ajustar-se debuga para o DHCP

Você pode igualmente ajustar-se debuga ajustes com o CLI (nrcmd).

Este é o formato do comando que você emite:

nrcmd> server server-type setDebug categories=level

  • tipo de servidor — O server na pergunta; no exemplo para esta seção, é DHCP.

  • categorias — Corresponda à coluna do Server Category (DHCP) da tabela 1.

  • nível — Um dos valores numéricos, da coluna nivelada da tabela 1, que corresponde às categorias.

Se você não especifica todos os argumentos requerido (variáveis), a seguir você verá esta mensagem:

nrcmd> dhcp setDebug

310 Too few arguments - usage: server <server> setDebug <categories>=<level>..

Para desativar tudo debugar ajustes, emitem o comando unsetDebug:

nrcmd> server dhcp unsetDebug

100 OK

Exemplo 1

Para ajustar os ajustes debugar para o servidor DHCP ao rastreamento de pacotes detalhado recebido e enviado (VX=1), emita este comando:

nrcmd> server dhcp setDebug VX=1

100 OK

Nota: A mensagem de 100 APROVAÇÕES indica que o comando está aceitado. Se você faz um erro, você vê uma mensagem similar a esta:

nrcmd> server dhcp setDebug= vx=1

306 Unknown command - dhcp method 'setDebugs='

Nesse erro, um extra, incorreto = sinal foi entrado após o setDebug.

Exemplo 2

Para ajustar o ajuste debugar para o servidor DHCP para o logging DHCP o mais detalhado, emita este comando:

nrcmd> server dhcp setDebug A-LN-Z=9

100 OK

Às vezes o CLI aceita números de mais alto nível do que aqueles que são especificadas na tabela 1, na tabela 2, ou na tabela 3. Tais níveis de debug mais altos não fornecem mais informação detalhada do que aqueles especificados nestas tabelas.

Neste exemplo, o nível é ajustado a 100, e o comando é aceitado; mas os detalhes que estão indo ser enviados aos registros são os mesmos que aqueles para o nível 9:

nrcmd> dhcp setDebug A-LN-Z=100

100 OK

Configurações da depuração DNS

Você pode usar o DNS debuga ajustes para pesquisar defeitos problemas de DNS. Você pode usar o GUI e o CLI para ajustar os níveis de debug para o DNS.

Utilizando GUI para definir as depurações para DNS

Para usar o GUI para ajustar-se debuga para o DNS, usam este procedimento:

  1. Do gerenciador do servidor, selecione o server para que você quer ajustar a opção debugar.

  2. Clique propriedades da mostra.

  3. Clique o guia avançada na caixa de diálogo das propriedades.

  4. O clique debuga os ajustes (indicados pela seta vermelha em figura 4).

    Figura 4 – Diálogo para ajustar os níveis de debug para o DHCP

    /image/gif/paws/12192/cnr_debug_4.gif

  5. Nos ajustes caixa de diálogo debugar, a verificação Enable debuga.

  6. No campo da categoria, incorpore um do ajuste da tabela 2.

    Tabela 2 – Os ajustes, os níveis, e a descrição para o DHCP debugam ajustes

    Categoria do Servidor (DNS) Nível Descrição
    D   Traçado básico DNS
      1 Falhas, erros, singularidades de configuração, alguns detalhes de configuração.
    2 Erros menos significativos. Erros de formato nas respostas, para a frente, re-para a frente.
    3 Falhas recuperáveis, Nome do servidor ilegal, modo slave da configuração ou mudanças de estado do major do cliente de transferência (XFER).
    4 Server de transferência incremental (IXFR) que embala índices de cada registro, de zona IXFR ou de transferência (AXFR) e transferências de zona.
    5 conclusão do Por-nome do carregamento de zona de funda.
    6 Programação e conclusão do aparamento da história da zona. Registo do cliente do pacote per. XFER.
    U   Rastreamento de atualização dinâmica
      1 Erros, falhas, respostas do NON-sucesso.
    2 Fonte do pacote per., zona, ld, prereq, e contagens de registro de recurso de registo da actualização.
    3 Registo do pacote de entrada do pacote per., pacote ou erros de validação do pedido.
    4 Registo básico do pacote externo do pacote per.
    5 Duplicatas de entrada na zona, pedidos de entrada novos na zona, reação de cliente XFER notificar pedidos na zona.
    P   Pacotes
      1 pacote da Por-pergunta após a validação de pacote básico.
    2 pacote Por-de entrada, logging de pré-validação.
    3 pacote Por-de partida, log de dados da resposta.
    DNUP   Todo o registo DNS
    A-Z 10 Todo o de entrada e pacotes externos, pedidos, encaminharam mensagens, atualizações dinâmica, notificam mensagens, transferências de zona incrementais e completas, e muitos mensagens de informação verbosos, função-específicos da árvore de decisão para todo o servidor interno de DNS, base de dados, e subsistemas da biblioteca.

  7. Clique o botão de rádio MLOG, que envia a saída ao arquivo de registro apropriado.

  8. APROVAÇÃO do clique na caixa de diálogo dos ajustes debugar e então na caixa de diálogo das propriedades.

Utilizando CLI para definir as depurações para DNS

Você pode ajustar-se debuga ajustes com o CLI (nrcmd).

Este é o formato do comando que você emite:

nrcmd> server server-type setDebug categories=level

  • tipo de servidor — O server na pergunta; neste exemplo para a seção, é dns.

  • categorias — Corresponda à coluna do Server Category (DNS) da tabela 2.

  • nível — Um dos valores numéricos, da coluna nivelada da tabela 2, que corresponde às categorias.

Para desativar tudo debugar ajustes, emitem o comando unsetDebug. Desativa todos os ajustes.

nrcmd> server dns unsetDebug

100 OK

Exemplo

nrcmd> server dns setDebug D=5

100 OK

nrcmd> server dns setDebug AZ=10

100 OK

Configurações de depuração de TFTP

Quando você está tendo problemas com o servidor TFTP, use o CLI para ajustar os níveis de debug. Não é possível usar por esse motivo o GUI. A tabela 3 mostra que debuga os níveis que podem ser ajustados no CNR para o servidor TFTP.

Tabela 3 – Os ajustes, os níveis, e a descrição para o servidor TFTP debugam ajustes

Categoria do Servidor (TFTP) Nível Descrição
C 1-3 Configuração do servidor.
D 1-3 Estatísticas.
E 1-3 Objeto da extensão CSCR.
F 1-3 Manipulação do arquivo.
P 1-3 Manipulação do pacote.
S 1-3 Manipulação da sessão de TFTP.
T 1-3 Manipulação do temporizador.

Os níveis acima correspondem a estes debugam tipos:

  • 1 — Circunstâncias inesperadas.

  • 2 — Mais informação detalhada.

  • 3 — Cada possível debuga.

Exemplo

Para ajustar o ajuste debugar para o servidor de CNR TFTP para a configuração do servidor a mais detalhada que registra, emita este comando:

nrcmd> server tftp setDebug C=3

100 OK

Nota: Se você não vê a mensagem de 100 APROVAÇÕES, a seguir o CNR não aceitou o comando.

Para desativar tudo debugar ajustes, emitem o comando unsetDebug:

nrcmd> server tftp unsetDebug

100 OK

Problemas de configuração: O cliente não consegue obter um endereço IP

Um dos problemas mais comuns com o uso do servidor DHCP do CNR nos ambientes do cabo é que os clientes — Modems a cabo e o CPE atrás deles — não recebem um endereço IP de Um ou Mais Servidores Cisco ICM NT. Se este é o caso, o Modems a cabo obtem colado no init (d) estado. Para detalhes nesta situação, refira pesquisando defeitos o Online de vinda do Modems a cabo do uBR. Há diversas causas possíveis deste problema. O resto deste documento discute cada um das razões.

O pacote DHCP DISCOVER está atingindo o CNR?

Registros CNR, mesmo a nível padrão, mostra bastante informação para determinar se o CNR recebeu o pacote. Você pode verificar se o MAC address do identificador de cliente do cliente (CID) aparece em um pacote de descoberta DHCP. O byte leftmost do CID indica o htype=1 para Ethernet, assim que o endereço MAC real é os seis bytes direitos-mais. Com o nível de registro da opção, você vê este como uma parcela do name_dhcp_1_log (no escrivão de C:\Program Files\Network \ entra o Windows NT):


!--- Output suppressed.

08/24/2000 17:40:09 name/dhcp/1 Activity Server 0 04619 Server received
                    a DHCPDISCOVER packet 'R1' from:
                    Host: 'dell-port-pc' CID: 01:00:10:a4:ff:61:8e
                    with IP source address: 0.0.0.0 via: Interface 10.200.68.200,
                    1 in use.

Esta saída mostra que o pacote de descoberta DHCP estêve recebido.

Esta é a mesma saída com um registo mais detalhado; O VX=1 é o nível de debug que é ajustado:

08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -----  RECEIVED -- R1 -----
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  port = 68 received from  = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  packet length = 300
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  op = 1 request
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  htype = 1 ethernet 	hlen = 6
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  hops =   0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	xid = 0xec9e secs = 0 flags = 0x0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	ciaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	yiaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	siaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	giaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	chaddr = 0:10:a4:ff:61:8e
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->     dhcp-message-type = 1 discover
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    -> 	   dhcp-client-identifier =1 0 16 164 255 97 142
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->     ethernet? = 0:10:a4:ff:61:8e
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->     dhcp-requested-address = 10.200.68.100
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->     host-name = "dell-port-PC"
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->     end
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  sname = ""
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ->  file  = ""
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
                    ----- END OF RECEIVED -- R1 -----

Como você pode ver nesta saída, você obtem a mesma informação sobre o DHCPDISCOVER; mas, com o nível de debug ajustado ao VX=1, mais informação detalhada sobre o pacote própria é fornecida.

O CNR tem um escopo adequado para o cliente?

O DHCP não compreende o conceito da máscara de sub-rede do IP. Quando o CNR recebe um DHCPDISCOVER, olha o campo GIADDR ou o campo de saltos: se são vazios ou iguais a 0, a seguir o CNR supor que o pedido vem da rede local. Olha o endereço IP de Um ou Mais Servidores Cisco ICM NT da relação em que recebeu o pacote, e usa esse para selecionar um espaço. Se o campo GIADDR não está vazio, a seguir o DHCPDISCOVER estêve enviado por um agente de transmissão de DHCP. O agente de transmissão de DHCP é configurado geralmente em roteadores Cisco com o comando ip helper-address. Neste caso, o CNR usa o endereço IP de Um ou Mais Servidores Cisco ICM NT no campo GIADDR para selecionar um espaço. Esse endereço IP de Um ou Mais Servidores Cisco ICM NT era da interface do roteador que recebeu a requisição de transmissão do cliente. Em ambos os casos, porque não há nenhuma informação da máscara de sub-rede no pedido, o CNR faz um melhor fósforo em todos os espaços configurados para selecionar bom.

Supor no CNR que você configura 10.0.0.0/8: isto será bom para um pedido que vem de 10.200.68.200. Se há mais específico, como 10.200.0.0/16 ou 10.200.68.0/24, a seguir esse com a máscara a mais longa está escolhido. É melhor criar espaços com a mesma máscara de sub-rede da rede onde são atribuídos. Isto é porque a máscara de sub-rede do espaço é a máscara de sub-rede que é atribuída aos clientes e, em um segmento de rede, todos os anfitriões devem compartilhar da mesma máscara de sub-rede. É possível atribuir aos clientes uma máscara de sub-rede que seja diferente de essa que é definida no espaço com a GET-TARGET570_0_-máscara--política da opção de DHCP. Neste exemplo, o CNR não tem um espaço, assim que rejeita o pedido:

08/24/2000 17:45:19 name/dhcp/1 Warning Protocol 0 04663
                    Received DHCPDISCOVER packet but found no Scopes
                    for source network = '10.200.68.200'. Dropping packet.

O exemplo de saída seguinte mostra um pacote que seja enviado por um agente de transmissão. Observe os saltos e os valores do campo GIADDR, e compare-os aos valores no exemplo de saída precedente. O resultado é o mesmo porque o CNR não tem um espaço esse ternos 10.200.71.1.

08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ----- RECEIVED -- R61 -----
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  port = 67    received from = 10.200.71.1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  packet length = 296
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  op =  1 request
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  htype = 1  ethernet    hlen = 6
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  hops = 1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  xid = 0x2127  secs = 0  flags = 0x8000  broadcast
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  ciaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  yiaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  siaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  giaddr = 10.200.71.1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->  chaddr = 0:1:96:59:47:c1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-message-type = 1 discover
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-max-message-size = 1152
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-client-identifier = 1 0 1 150 89 71 193
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    ethernet? = 0:1:96:59:47:c1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-parameter-request-list = 20
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        1    subnet-mask
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        2    time-offset
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        4    time-servers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        66   tftp-server
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        128  mcns-sec-server
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        3    routers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        7    log-servers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->        67   boot-file
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-class-identifier = "docsis1.0"
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    dhcp-option-overload = 3
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->    relay-agent-info = 1 4 128 6 0 9 2 6 0 1 150 89 71 193
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                    ->
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
                     ----- END OF RECEIVED -- R61 -----
08/24/2000 18:11:23 name/dhcp/1 Warning Protocol 0 04663
                    Received DHCPDISCOVER packet but found no Scopes
                    for source network = '10.200.71.1'. Dropping packet.

Os endereços livres estão no escopo?

É possível que o escopo esteja configurado de tal forma que o pool de endereços seja muito pequeno. Nesses casos, você pode geralmente ser executado fora dos endereços no pool. Este exemplo de saída mostra as mensagens debugar quando um cliente está tentando obter um endereço IP de Um ou Mais Servidores Cisco ICM NT mas o espaço já usa todos seus endereços no pool:

08/24/2000 19:14:26 name/dhcp/1 Warning Server 0 04440
                    No more leases are AVAILABLE, unable to respond
                    to DHCP DISCOVER Request: R9 = from Client: Host:
                    dell-port-PC CID: 01:00:10:a4:ff:61:8e in Network:
                    10.200.68.0-255.255.255.0 via: Interface 10.200.68.200

A oferta alcança o cliente?

  • Uma vez que o CNR seleciona um espaço e cria um pacote da oferta, a informação deve ser transmitida ao cliente.

    Nota: Quando o pacote é destinado a um agente de transmissão, assegure-se de que a máquina CNR tenha uma rota ao GIADDR.

  • No caso destes exemplos, assegure-se de que você possa sibilar da máquina CNR 10.200.71.1.

  • Recorde que, depois que um aluguer é oferecido, há algumas outras etapas antes que se transforme um endereço IP real na rede.

  • Você deve ver, do mesmo cliente, de uns ou vários DHCPREQUEST e de uns ou vários DHCPOFFER do server ao cliente. Estes são usados para pedir e obter opções de DHCP.

  • Você deve ver um DHCPACK final do server ao cliente, que termina o processo DHCP.

  • Se você não vê somente DHCPOFFER mas nada mais, assegure-se de que os pacotes alcancem o cliente e que o DHCPREQUEST subsequente vem para trás ao server.

Esta é uma entrada de registro que mostre que um aluguer estêve concedido (esta informação fornece o MAC address do cliente, o endereço IP de Um ou Mais Servidores Cisco ICM NT que é atribuído, e a data de expiração do aluguer):

08/24/2000 13:13:15 name/dhcp/1 Activity Protocol 0 04994 10.200.68.200
                    Lease granted to Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e
                    packet 'R207' until Thu, 31 Aug 2000 13:13:15  +0200. 320 ms.

Há outro servidor na mesma rede com o mesmo escopo configurado?

Em tal caso, ambos os server recebem um DHCPDISCOVER e fazem sua oferta, mas o cliente escolhe somente um. Indica, no dhcp-server-identifier, que do server aceita uma oferta. Se o outro server vê o DHCPREQUEST para o mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT que lhe ofereceu — mas o dhcp-server-identifier aponta a um outro server — então desativa o aluguer, para impedir endereços duplicados possíveis.

A última linha neste exemplo de saída mostra esta desactivação:

09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ----- RECEIVED -- R7 -----
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   port = 68 received from = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   packet length = 300
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   op = 1 request
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   htype = 1 ethernet hlen =3D 6
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   hops =  0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   xid =0xddaadeaa   secs = 0 flags = 0x0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   ciaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   yiaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   siaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   giaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   chaddr = 0:10:a4:ff:61:8e
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     dhcp-message-type = 3 request
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     dhcp-client-identifier = 1 0 16 164 255 97 142
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     ethernet? = 0:10:a4:ff:61:8e
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     dhcp-requested-address = 10.200.68.201
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     dhcp-server-identifier = 10.200.68.17
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     hostname = "dell-port-PC"
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->     dhcp-parameter-request-list = 20
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         1   subnet-mask
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         3   routers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         15  domain-name
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         6   domain-name-servers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         44  netbios-name-servers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         46  netbios-node-type
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->         47  netbios-scope
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   vendor-encapsulated-options = 55 2 0 0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   end
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   sname = ""
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ->   file = ""
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
                    ----- END OF RECEIVED -- R7 -----
09/01/2000 12:21:05 name/dhcp/1 Activity Protocol 0 04993 10.200.68.201
                    Lease offered to Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e
                    packet 'R5' until Fri, 01 Sep 2000 12:23:05 +0200. 150 ms.
09/01/2000 12:21:05 name/dhcp/1 Error Protocol 0  04684 Client:
                    'Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e ' sent a 
                    REQUEST for Lease: '10.200.68.201' to Server: '10.200.68.17'
                    instead of us. Marking Lease UNAVAILABLE

Se o server vê um DHCPREQUEST para um endereço IP de Um ou Mais Servidores Cisco ICM NT diferente, registra-o simplesmente. Neste exemplo de saída, o outro server (10.200.68.17) ofereceu 10.200.68.201:

09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ----- RECEIVED -- R3 -----
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  port = 68    received from = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  packet length = 300
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  op = 1 request
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  htype = 1  ethernet    hlen = 6
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  hops = 0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  xid = 0x8a7d8b7d  secs = 0  flags = 0x0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  ciaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  yiaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  siaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  giaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->  chaddr = 0:10:a4:ff:61:8e
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     dhcp-message-type =  3 request
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     dhcp-client-identifier = 1 0 16 164 255 97 142
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     ethernet? = 0:10:a4:ff:61:8e
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     dhcp-requested-address = 10.200.68.201
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     dhcp-server-identifier = 10.200.68.17
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     hostname = "dell-port-PC"
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->     dhcp-parameter-request-list = 20
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         1    subnet-mask
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         3    routers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         15   domain-name
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         6    domain-name-servers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         44   netbios-name-servers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         46   netbios-node-type
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->         47   netbios-scope
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->    vendor-encapsulated-options = 55 2 0 0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->    end
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->    sname = ""
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ->    file = ""
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
                    ----- END OF RECEIVED -- R3 -----
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 05005 10.200.68.202
                    Offer to Host: dell-port-PC CID: 1:00:10:a4:ff:61:8e packet
                    'R3' was rejected in favor of an offer from another server.

Há outro host na mesma rede já configurado com o endereço IP que será oferecido ao cliente?

Antes que ofereça um aluguer, o CNR pode executar um sibilo ao endereço IP de Um ou Mais Servidores Cisco ICM NT que está a ponto de oferecer. Se recebe uma resposta positiva, a seguir desativa esse aluguer e escolhe um endereço IP de Um ou Mais Servidores Cisco ICM NT novo oferecer, para evitar endereços duplicados na rede. À revelia, este comportamento é desabilitado, mas você pode permiti-lo em uma base do por-espaço do GUI.

Escolha o espaço > as propriedades e clique o guia avançada; verifique então o endereço do sibilo antes de oferecer-lhe a caixa de seleção:

Figura 5 – Caixa de diálogo do espaço

cnr_debug_5.gif

Inversamente, você pode emitir este comando do CLI:

nrcmd>  scope name enable ping-clients

Exemplo

Se, no espaço UBR7246_C4_0, você quer sibilar um endereço antes que estiver oferecido, a seguir para emitir este comando:

nrcmd> scope UBR7246_C4_0 enable ping-clients

100 OK
ping-clients=enabled

Este exemplo de saída mostra que debuga nesta situação:

09/01/2000 12:52:26 name/dhcp/1 Warning Protocol 0 0467
                    Unexpected ping reply received for AVAILABLE lease
                    '10.200.68.201' - it is being marked  UNAVAILABLE

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.


Informações Relacionadas


Document ID: 12192