Gerenciamento e automatização de redes : Cisco Network Registrar

Configurações e gerenciamento de CNR recomendados

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Esse artigo tem dois objetivos. Em primeiro lugar, contém recomendações sobre como configurar o Cisco Network Registrar (CNR) para desempenho ideal e estabilidade e sobre como monitorar a instalação do CNR. Em segundo lugar, contém recomendações sobre como você deve reagir se um problema efetivamente ocorrer. Em uma situação ideal, você lerá este artigo e seguirá as recomendações de configuração e monitoramento antes que algum problema ocorra. Com isso, você evitará problemas. Se você está lendo este artigo pela primeira vez porque você tem um problema com CNR, vá imediatamente às ações imediatas ao enfrentar uma seção de problema. Para uma explicação mais adicional das recomendações, refira por favor os Guias do Usuário e referências de comandos CNR.

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.

Convenções

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

Configuração padrão

As recomendações de configuração oferecidas aqui representam um ponto de início. Se o seu sistema estiver com uma configuração diferente, revise as suas configurações. Sua configuração pode ter se desenvolvido de versões anteriores do CNR. O CNR 5.0 e as versões posteriores proporcionam um desempenho muito melhor, em comparação com as versões anteriores, mas devem ser feitas alterações de parâmetro para se obter o máximo de benefício. O foco deste documento é em amplos ambientes de provedores de serviços, mas muitas das recomendações aplicam-se também a outros ambientes de CNR. Este documento supõe aquele:

  • Você é um provedor de serviços executando uma rede de banda larga com 10.000 ou mais assinantes.

  • Você está usando CNR 5.0.3 ou mais atrasado.

  • Você está usando o protocolo LDAP (Lightweight Directory Access Protocol). O CNR é executado sem LDAP, mas muitos provedores de serviços usam o LDAP.

  • Sua rede tem a saturação média do endereço IP de Um ou Mais Servidores Cisco ICM NT.

  • Você executa CNR em servidores UNIX. A maioria das recomendações aplicam-se ingualmente ao Windows NT, mas a maioria de provedores de serviços executam o CNR em servidores Unix, assim que onde UNIX e NT diferem, o exemplo Unix é usado.

  • Você tem conexões de upstream com outros sistemas (como cobrança, atendimento ao cliente ou configuração) que estão sendo executados em outros servidores.

  • O Domain Name System dinâmico (DDNS) não é ativo em seu local (a maioria de provedores de serviços não usam o DDNS).

Recomendações de configuração e instalação

Planejamento e configuração iniciais

  • Alocação de endereço IP do plano e do documento.

  • Operações disco-intensivas separadas: põe seu servidor DHCP preliminar sobre uma máquina diferente do que seus servidor ldap e servidor de DNS principal.

  • Documente sua configuração de cable modem termination system (CMTS); certifique-se de que as configurações de CMTS e CNR sejam compatíveis.

  • Preparar planos de recuperação de desastre.

  • Documente sua topologia de rede.

  • Note as versões de software de Cisco IOS� dos CMTS.

As etapas as mais eficazes à saúde a longo prazo de sua rede são: a) planeia sua configuração, b) registro aqueles planos, e c) registro as mudanças quando as mudanças são planeadas e feitas. Documentar as razões das escolhas pode ser útil em sessões futuras de planejamento.

Configuração geral do sistema

  • Use failover seguro. O failover simples, onde um server é principal para todos os espaços, e o outro server são alternativos para todos os espaços (ao contrário do Failover simétrico, onde ambos os server são principais e alternativo ao mesmo tempo, segundo o escopo individual), é altamente recomendado, porque simplifica extremamente as tarefas da administração.

  • Gire sobre armadilhas de Protocolo de Gerenciamento de Rede Simples (SNMP). Estes exemplos são para a ilustração:

    nrcmd> trap enable address-conflict
    nrcmd> trap enable dhcp-failover-config-mismatch
    nrcmd> trap enable other-server-not-responding
    nrcmd> trap set free-address-low-threshold=15%
    nrcmd> trap set free-address-high-threshold=30%
    nrcmd> trap enable free-address-low
    
  • Seja certo que você tem RAM adequado (512 MB ou maior).

  • Seja certo que a separação dos dados é grande bastante (2.5 GB ou maiores).

  • Use partições separadas para logs e dados.

  • Assegure de alta velocidade, conexões da latência baixa entre server; verifique as configurações da interface.

Os desvios de SNMP permitem monitorar o servidor DHCP a partir de um monitor de rede. Não se esqueça de configurar os desvios no servidor DHCP, configurar o monitor para recebê-los e exibi-los e, obviamente, não deixe de prestar atenção no monitor.

Configurar um sistema da produção exige o comércio-offs de custar contra a efetividade de sistema. Nós sugerimos estes valores que supomos aproximadamente 100,000 assinantes na falha de execução de sistemas E250-class. O uso de muitas políticas, classes de cliente, espaços, bufferes do pedido e da resposta, extensões de DHCP, e outras complicações afeta necessidades da memória e o desempenho.

A partição de registro (/var/nwreg2) deverá ser aumentada se o número e o tamanho dos registros aumentarem.

Configuração DHCP

  • Defina os buffers de solicitação e resposta para o ritmo de transferência ideal. Observe que estas recomendações mudaram no CNR 5.0.

    nrcmd> DHCP set max-dhcp-requests=500
    nrcmd> DHCP set max-dhcp-responses=2000
    
  • Lease Time do modem a cabo = 604800 (dias 7) ou mais.

  • Lease Time do Customer Premises Equipment (CPE): todo o tempo possível (veja a nota para o comércio-offs).

  • Aumente tamanhos do log DHCP e TFTP:

    nrcmd> server DHCP serverLogs nlogs=15 logsize=10M
    nrcmd> server DNS serverLogs nlogs=15 logsize=10M
    nrcmd> server TFTP serverLogs nlogs=10 logsize=10M
    
  • Configurar as configurações de registro que fornecem bastante detalhe para identificar problemas, mas não gere o detalhe excessivo (que faz difícil distinguir problemas e põe a carga desnecessária sobre o server). Estas são as configurações recomendadas que são geralmente aplicáveis. Ajuste as configurações, caso seja necessário lidar com questões na sua rede:

    • Activity-summary

    • Padrão

    • Não há atividade de failover

    • Enable defer-lease-extensions

    • Ajuste a último-transação-tempo-granularidade = intervalo do aluguer de 1/2

    • Desabilite a permitir-cliente-aluguer-ultrapassagem para as políticas que oferecem alugueres da produção.

    • Permita queda-para trás-à-local; quando o LDAP é não disponível, o CNR usa dados locais:

      nrcmd> session set visibility=3
      nrcmd> dhcp enable fallback-to-local-client-data
      nrcmd> session set visibility=5
      
  • Se usando o CNR 5.5 ou mais atrasado, configura a capacidade do cache de cliente de reduzir as perguntas LDAP pela metade.

    nrcmd> dhcp set client-cache-count=2000
    nrcmd> dhcp set client-cache-ttl=5
    

Para usar o recurso de transferência de CNRs da forma mais eficiente, deve haver uma quantidade de buffers de resposta de três a quatro vezes maior do que a quantidade de buffers de requisições. O sistema usa somente tantos como bufferes enquanto precisa. Enquanto os tempos do aluguer se tornam mais curtos, mais bufferes da resposta estão exigidos.

Nota: Tempos de concessão devem ser coerentes em termos de duração e praticidade. Os arrendamentos de modem a cabo são originários de um espaço de endereço privado (em geral, net-10), e os modems raramente movem-se para locais diferentes na rede. Essas concessões devem ser feitas por uma semana ou mais. Os alugueres CPE, por outro lado, vindos do espaço de endereço público, e dos CPE (em particular, portáteis) movem-se ao redor. Aqui a duração de aluguel deve ser ajustada para combinar os hábitos de sua população de usuário. Concessões mais longas reduzem a carga no servidor DHCP. Ao usar concessões curtas (menos de 8 horas), aumente os buffers de resposta para 2500.

Desabilite a permitir-cliente-aluguer-ultrapassagem para assegurar-se de que os clientes adiram aos tempos do aluguer especificados em sua configuração de CNR — alguns clientes tentam cancelar o ajuste especificado.

Habilite fall-back-to-local para manter o sistema operacional em caso de falha no servidor de LDAP. Com este ajuste, o servidor DHCP continua a satisfazer pedidos do aluguer mesmo que o servidor ldap não esteja respondendo. O servidor não terá acesso às informações de cliente específicas armazenadas no servidor de LDAP; por isso, ele atenderá a cada requisição com uma configuração padrão. Você deve configurar um padrão que seja razoável para sua rede.

Finalmente, a característica do cache de cliente mantém-se na memória que os dados do cliente recuperaram do LDAP, de modo que o servidor DHCP precise de perguntar o LDAP somente uma vez durante o ciclo descoberta-oferta-pedido-ACK, acelerando o desempenho do servidor DHCP.

Configuração DNS

  1. Habilite o recurso de transferência incremental:

    nrcmd> dns enable ixfr-enable
    
  2. Enable notifica. Refira as referências do comando CLI CNR para os argumentos que você precisa de permitir notifica.

  3. Põe servidores de DNS principais e secundários sobre segmentos de rede separados.

  4. Configurar clientes para perguntar um servidor de DNS secundário.

Os servidores de DNS secundários recebem seus dados do servidor primário um de duas maneiras: a) “transferência de zona completa,” ou b) “notifica/ixfr” (transferência incremental). Usar-se notifica/ixfr reduz o número de registro que deve ser transferido do preliminar aos servidores secundários. Isto é crítico quando o espaço de nome é relativamente dinâmico.

Configuração de TFTP

  • Ajuste o Initial-packet-timeout a 2:

    nrcmd> tftp set initial-packet-timeout = 2
    
  • Se usando o CNR 5.5 ou mais atrasado, permite o arquivo TFTP que põe em esconderijo para melhorar o desempenho:

    nrcmd> tftp set home-directory=/var/nwreg2/data/tftp
    nrcmd> tftp set file-cache-directory=CacheDir
    nrcmd> tftp set file-cache-max-memory-size=32000
    nrcmd> tftp enable file-cache
    nrcmd> tftp reload
    

Pôr em esconderijo do arquivo TFTP mantém os arquivos de configuração do Cable Modem armazenados na memória, evitando lê ao disco cada vez que um modem a cabo pede um arquivo de configuração. Um diretório cache do arquivo precisa de ser criado no disco rígido (CacheDir no exemplo acima), e um tamanho máximo é atribuído. Escolha o tamanho que leva em consideração a quantidade total de RAM em seu sistema e no número de arquivos de configuração diferentes necessários.

O protocolo TFTP não exige o cliente enviar um pacote do reconhecimento final (ACK) no recibo de um arquivo. Se nenhum ACK é recebido, o server deve guardar a conexão de cliente para o período de timeout, que limita sua capacidade prestar serviços de manutenção a pedidos novos. Se seu servidor TFTP tem a capacidade de recurso, você pode igualmente aumentar o valor do Max-tftp-packets para apoiar um número maior de conexões de cliente. O valor padrão deste parâmetro é 512. O valor máximo é 1000.

Configuração LDAP de CNR

Essas definições mostram uma configuração em que o CNR está gravando atualizações de concessão no LDAP. Se for possível, projete sua rede para que isso não seja necessário. Mostra-se aqui para fornecer recomendações se você deve escrever atualizações do aluguer. Aperfeiçoe conexões ldap usando objetos separadamente ajustáveis do READ/WRITE LDAP. (Cada objeto obtém seu próprio grupo de linhas).

# Create and Configure a New LDAP Create/Update object
     ldap LDAP-Write create csrc-ldap
     ldap LDAP-Write set password=changeme
     ldap LDAP-Write set port=389
     ldap LDAP-Write set preference=1
     ldap LDAP-Write setEntry query-dictionary csrcclientclass=client-class-name
     ldap LDAP-Write set reactivate-interval=60s
     ldap LDAP-Write set search-filter=
     (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem)))
     ldap LDAP-Write set search-path=csrcprogramname=csrc,o=NetscapeRoot
     ldap LDAP-Write set username=
     "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot"
     ldap LDAP-Write set can-query=disabled
     ldap LDAP-Write set can-create=enabled
     ldap LDAP-Write set can-update=enabled
     ldap LDAP-Write set connections=2
     ldap LDAP-Write set limit-requests=enabled
     ldap LDAP-Write set max-requests=8
     ldap LDAP-Write set timeout=30s

### Create and Configure a New LDAP Read object
     ldap LDAP-Read create csrc-ldap
     ldap LDAP-Read set password=changeme
     ldap LDAP-Read set port=389
     ldap LDAP-Read set preference=1
     ldap LDAP-Read setEntry query-dictionary csrcclientclass=client-class-name
     ldap LDAP-Read set reactivate-interval=60s
     ldap LDAP-Read set search-filter=
     (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem)))
     ldap LDAP-Read set search-path=csrcprogramname=csrc,o=NetscapeRoot
     ldap LDAP-Read set username=
     "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot"
     ldap LDAP-Read set can-query=enabled
     ldap LDAP-Read set can-create=disabled
     ldap LDAP-Read set can-update=disabled
     ldap LDAP-Read set connections=3
     ldap LDAP-Read set limit-requests=enabled
     ldap LDAP-Read set max-requests=12
     ldap LDAP-Read set timeout=3s

A configuração mostrada inclui fazer com que o CNR grave atualizações de aluguel no LDAP. É possível que você queira fazer isso para permitir que os aplicativos consultem o LDAP sobre informações de uso atuais, mas você deve tentar evitar estruturar o aplicativo de modo que isso seja necessário. Se você precisar disponibilizar informações sobre o estado do arrendamento para um endereço IP, poderá usar o comando de arrendamento de NRCMD para obter o endereço MAC, a expiração e outras informações sobre o status atual do arrendamento.

Os diretórios LDAP são projetados para serem lidos de forma rápida e eficiente, mas gravar para um diretório LDAP é ineficiente. Se você configura o CNR para redigir a informação de lease ao LDAP, o LDAP transforma-se um gargalo ao desempenho de sistema total. Se tiver que configurar gravações de uso do LDAP, use as configurações recomendadas. Observe que o acesso CNR ao LDAP foi otimizado por meio do uso de objetos de “leitura” e “atualizar LDAP” em separado. Observe também o tempo limite de escrita de 30 segundos. Com um intervalo de parada mais curto, é possível correr o risco do LDAP gravar o intervalo de parada quando o LDAP Depois, o CNR faz uma nova tentativa de gravação, o que adiciona carga extra ao LDAP.

O número total de conexões com o servidor LDAP não deve exceder o número máximo de segmentos disponíveis. Se seu servidor ldap apoia linhas múltiplas pela conexão, o número ótimo de conexões é o número total de linhas divididas pelo número de linhas pela conexão.

Parâmetros de ajuste de servidor de LDAP

  • Crie deslocamentos predeterminados para campos da consulta.

  • Configure o tamanho do cache para aumentar o número de entradas no cache de memória, embora o cache não deva exceder um terço da memória disponível.

  • Configurar os segmentos máximos para aumentar o número de conexões simultâneas que podem ser suportadas, embora esse número não possa exceder metade dos recursos disponíveis.

  • Configurar as configurações de registro que fornecem bastante detalhe para identificar problemas mas não gere o detalhe excessivo (que faz difícil distinguir problemas e põe a carga desnecessária sobre o server).

  • Use partições separadas para logs e dados.

As aplicações de servidor ldap específicas variam. Refira sua documentação de servidor para executar estas sugestões.

Procedimentos de rotina

  • Suporte regularmente os bancos de dados de CNR. Refira os Guias do Usuário para instruções. Você deve suportar os bancos de dados de CNR pelo menos uma vez por dia. Mantenha os arquivos de backup por pelo menos duas semanas.

  • Suporte regularmente o LDAP.

  • Regularmente apoio e log de arquivo.

  • Depois que as mudanças são feitas ao CNR, assegure-se de que a configuração dos servidores principal e de backup e os servidores de backup em um cenário de failover permaneçam consistentes. Use o cnrFailoverConfig - compare a ferramenta nas versões de CNR 5.5 e mais adiantado, ou compare as configurações usando o WebUI em CNR 6.0 e mais atrasado.

  • Quando alterações na topologia da rede forem planejadas, defina os tempos de renovação e liberação para valores pequenos.

  • Monitore o uso do endereço IP de Um ou Mais Servidores Cisco ICM NT (SNMP traps do uso).

  • Monitore a utilização de sistema (memória, disco, CPU, e troca). A parte superior de serviço público é útil por esse motivo.

  • Periodicamente, revise os registros para ficar familiarizado com os casos normais. Compreender logs normais deixa-o segurar mais rapidamente problemas.

  • Periodicamente logs da revisão para exceções: grep para o “erro”, “advirta”, ou " conectar " (por exemplo, em UNIX, grep do uso - eu advirto o name_dhcp_1_log).

DHCP Safe-failover exige que os ajustes de configuração de um escopo sejam idênticos nos servidores principal e de backup para esse escopo. Seja certo, quando você faz uma mudança a um ajuste, que você faz a mudança em ambos os server. Periodicamente cnrFailoverConfig do uso - compare ou o WebUI em CNR 6.0 e para verificar acima para certificar-se lá não é nenhuma diferença.

As mudanças das alterações de topologia de rede ou da alocação de endereço IP podem fazê-lo necessário para que os clientes obtenham um endereço diferente. Deve ser feito um plano para um período em que alguns clientes de uma sub-rede têm um endereço da faixa antiga e alguns clientes foram renovados e obtiveram um endereço da nova faixa. É possível reduzir a quantidade de tempo durante o qual os dois conjuntos de endereços estão ativos reduzindo a duração das concessões antes de fazer a alteração de modo que todos os clientes tenham concessões de curta duração. Isto assegura-se de que devam renovar seus alugueres frequentemente e consequentemente para escolher acima logo um aluguer da escala nova depois que você faz a mudança. Seja certo não ajustar o Lease Time tão curto que os alugueres executados para fora quando você parar e ligar o server fazer a mudança. Depois que você fez a mudança, seja certo restaurar o período do aluguel original de modo que você não aumente a carga no server.

A abordagem mais efetiva para solucionar problemas é evitá-los. Depois das recomendações esboçadas acima mantém seus administradores em harmonia com sua operação e permite-o de evitar problemas graves. Quando os problemas aparecerem (como aumentos ou utilização de memória do tempo de espera I/O aumenta para nenhuma razão conhecida), continue com os logs. Revise as recentes alterações do ambiente físico ou da configuração do CNR para ver se essa pode ser a origem dos problemas.

Os logs CNR são seus amigos. Ao iniciar o uso do CNR, ou ao fazer a atualização do CNR, ou quando alterar a configuração do CNR, use o comando grep descrito, para verificar os logs de qualquer emissão. Trabalhe então para trás no log para compreender quando e como a edição elevarou, e fixe o problema.

Ações imediatas ao enfrentar um problema

  • Não recarregue o CMTS a menos que pedido para fazer assim pelo grupo de suporte Cisco (se aplica aos ambientes do cabo somente).

  • Não reinicie o CNR, a menos se solicitado pela equipe de suporte da Cisco.

  • Não desabilite o failover seguro, a menos que isso seja solicitado pela equipe de suporte Cisco.

  • Não recarregue, reinicie, ou interrompa o CNR em toda a maneira com o resynchronization do failover seguro em andamento.

  • Copie os arquivos de registro para um diretório em que não sejam sobrescritos. Se o CNR travou, copie o arquivo central em um diretório em que não seja substituído.

  • Use:

    nrcmd> server dhcp getRelatedServers
    

    para isolar o misconfiguration do failover seguro.

  • Procure exceções nos registros. Verifique particularmente a sequência start-up (isto pode estar em um log velho): grep para o “erro”, “advirta”, ou " conectar " (por exemplo erro name_dhcp_1_log* do grep-eu).

Quando você enfrenta um problema, é crucial que você não causa nenhum dano mais adicional ao isolar e ao fixar o problema inicial. Recarregar um CMTS ou reiniciar o CNR criam pontos imediatos da carga durante uma época em que o sistema for já frágil. O objetivo é ter o sistema plenamente funcional novamente no menor período de tempo. O tempo transcorrido até suas últimas contagens da ação; o tempo a sua primeira ação não conta. Ou seja não tome a ação rápida apenas para a ação rápida. Pense antes de agir.

Comece um log de todas as etapas tomadas e de todas as mudanças feitas em qualquer lugar no sistema: DHCP, DNS, ou servidores TFTP, e mudanças feitas a algum CMTS ou modem a cabo. Descreva o problema e registre, em detalhes, apenas o comportamento que pode ser observado.

Analisar arquivos de log

Recolha os logs (/var/nwreg2/logs). Analise isso procurando erros ou avisos. Use um editor de texto para analisar mais erros do interesse. Começando do erro para trás, procure no registro todas as entradas relativas ao endereço MAC, ao endereço IP ou ao nome de domínio associados ao erro.

Talvez seja necessário ativar o registro adicionar para diagnosticar problemas de DHCP. O servidor DHCP apoia um intervalo extensivo das potencialidades de registro. Refira as referências do comando CLI CNR para uma lista de opções de registro e uma explicação de cada um. Tenha cuidado, pois cada mensagem de registro coloca carga no servidor. Você deve fazer umas trocas entre a quantidade de informação que você pede que o CNR registrem e o desempenho de servidor.

Verificar problemas de LDAP

O problema pode ser com o servidor do LDAP. O CNR constrói uma fila dos pedidos ao servidor ldap. Se o servidor ldap não pode prosseguir com a carga, a fila acumula-se. Olhe no diretório de /var/nwreg2/data/dhcpeventstore. Os arquivos da loja do evento são fixados em tamanho, assim que se a fila se está acumulando, o CNR cria mais arquivos. Se há mais de um arquivo no diretório, este indica que a fila está suportando. A mesma fila é usada para enfileirar pedidos ao servidor DNS, assim que se a fila está suportando, e você está usando o DDNS, ele poderia encher-se com os pedidos ao servidor DNS. Para determinar se o problema é com LDAP, gire sobre o registo adicional da interface ldap CNR. Habilite os flags de log ldap-create-detail, ldap-query-detail e ldap-update-detail. O mensagem de registro inclui selos de tempo que a ajuda você determina se o LDAP é o gargalo do sistema.

Verifique os banco de dados internos de CNR

Se você suspeita o problema pode ser que uns ou vários dos bancos de dados internos do CNR perderam a integridade, refere os Guias do Usuário CNR para aprender como executar as utilidades da verificação de validade do banco de dados. Se uma destas utilidades indica um problema, continue a seguir os sentidos nos Guias do Usuário para resolvê-lo.

Verifique dados DNS com o nslookup

A consulta ns de utilitário é incluída com sistemas Unix e com Windows NT. Pode ser usado para interrogar um servidor DNS e, por isso, é útil na verificação dos dados armazenados pelo servidor. A documentação para o seu sistema operacional fornece informações detalhadas sobre os seus recursos.

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: 13390