Configuração da geração de log de eventos NAT em formato de registro de monitoramento de fluxo em um roteador da Série MX ou NFX250

Habilitar recursos de syslog e Jflow ao mesmo tempo pode resultar em impactos de escala, pois ambos esses mecanismos usam uma infraestrutura separada para transferir registros para o coletor.

Um alto número de eventos de NAT pode causar considerações de escalabilidade devido à estrutura de monitoramento de fluxo também exigindo processos de sistema.

A infraestrutura de log de monitoramento de fluxo usa CPUs de dados para enviar os logs para o servidor de fluxo externo, o que pode causar um leve impacto no desempenho.

Um limite máximo explícito e separado no número de mensagens de monitoramento de fluxo geradas para eventos de erro de NAT é implementado. Você pode controlar o número máximo de eventos de erro de NAT para os quais os logs no formato de monitoramento de fluxo devem ser registrados, incluindo a opção message-rate-limit messages-per-second no nível de [edit interfaces interface-name services-options jflow-log] hierarquia. Esses registros de eventos de erro de NAT são gerados quando os endereços para alocação do grupo NAT não estão disponíveis, quando as portas para alocação a um assinante não estão disponíveis ou quando a cota alocada é excedida para eventos NAT (mais do que o número configurado de portas é solicitado). Além disso, você pode configurar a opção message-rate-limit que anteriormente existia no nível de [edit interfaces interface-name services-options syslog] hierarquia para especificar o número máximo de mensagens de log do sistema por segundo que podem ser enviadas do PIC para o Mecanismo de Roteamento (local) ou para um servidor externo (remoto).

Eventos de erro de NAT, como "Fora de portas", "Fora de endereços" e "Cota excedida" são limitados por taxa. O limite de taxa de padrão é de 10.000 eventos por segundo. Essa configuração também é configurável no nível PIC.

O modelo para registro de eventos NAT está de acordo com o IETF como Elementos de informações de IPFIX para registrar eventos NAT — draft-ietf-behave-ipfix-nat-logging-02.

Apenas o registro baseado em UDP é suportado, o que é um protocolo não confiável.

Essa funcionalidade é suportada em roteadores da Série MX com pacotes de provedores de extensão Junos OS instalados e configurados no dispositivo, e em MS-MPCs, MS-PICs e MX-SPC3s. Não é compatível com MS-DPCs com roteadores da Série MX.

A transmissão de logs ocorre em formato de texto claro, semelhante a outras mensagens de log que os PICs de serviços não criptografam. Assume-se que o transporte de logs e o posicionamento do coletor de log estão dentro de um reino seguro. Como as mensagens não contêm detalhes sensíveis, como nome de usuário ou senhas, as mensagens não causam riscos de segurança ou confiabilidade.

Os IDs modelo 0 a 255 estão reservados para conjuntos de modelos e o número máximo de templates suportados para eventos de registro em formato de monitoramento de fluxo é de 255. Quando você modifica uma configuração de perfil de modelo (alterações no coletor ou versão, ou uma desativação e ativação do conjunto de serviços associados ao modelo), o modelo específico é desregistrado e reregistrado. No entanto, a infraestrutura de monitoramento de fluxo requer 10 minutos por padrão, pois o período de atraso para que as IDs do modelo sejam liberadas. Como resultado, se você modificar as configurações do perfil do modelo muitas vezes dentro do período de 10 minutos, o limite máximo de IDs de modelo de 255 é excedido e outros modelos não serão registrados. Nesse caso, quando os modelos não estiverem sendo registrados, você deve esperar até o período de atraso para excluir um modelo desregistrado de 10 minutos antes de realizar mais alterações de configuração para ter modelos registrados no aplicativo de monitoramento de fluxo. Para examinar se um modelo foi registrado, você pode usar o show services service-sets statistics jflow-log comando. Se o campo Enviado exibir um valor não zero para registros de modelos, ele denota que os modelos serão registrados com sucesso.

Em um cenário em que a capacidade de registrar eventos NAT no formato de monitoramento de fluxo é habilitada no nível de conjunto de serviços e, se o PIC inicializar, os modelos de log de monitoramento de fluxo são registrados no aplicativo de monitoramento de fluxo. Durante o processo de registro, um primeiro conjunto de 12 registros de modelos são enviados ao coletor. No entanto, todos os registros do modelo podem não chegar ao coletor a partir do PIC no roteador ou podem não ser transmitidos para fora do roteador porque a interface pode não estar sob a perspectiva do Mecanismo de encaminhamento de pacotes. Após o término do tempo de atualização de um modelo, o próximo conjunto de registros de modelos é enviado ao coletor. Por exemplo, se o tempo de atualização do modelo for de 60 segundos, somente após 60 segundos a partir do tempo de inicialização do PIC, os registros de modelos são enviados corretamente ao coletor.

Se nenhum problema ocorrer na transmissão de mensagens de log de monitoramento de fluxo para o coletor a partir do PIC, o campo Enviado é incrementado para indicar eventos NAT sendo registrados para cada evento. Além disso, o utilitário tcpdump no endereço IP de destino do coletor denota a recepção de pacotes UDP. Se o processamento de NAT ocorrer e o Dropped valor na seção da saída do show services service-sets statistics jflow-log service-set service-set-name comando for incrementado ou não, você deve examinar as estatísticas e contadores de depuração para determinar se existe algum problema na rede para transmissão das mensagens de log de monitoramento de fluxo.