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 escalonamento, porque ambos os mecanismos usam uma infraestrutura separada para transferir registros para o coletor.

Um alto número de eventos nat pode causar considerações de escalabilidade devido à estrutura de monitoramento de fluxo também exigindo processos do 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 pequeno 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 do 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 endereços para alocação do pool 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 do NAT, como "Fora das portas", "Fora de endereços" e "Cota Excedida" são limitados por taxa. O limite de taxa 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, que é um protocolo não confiável.

Essa funcionalidade é suportada em roteadores da Série MX com pacotes Junos OS Extension-Provider instalados e configurados no dispositivo, e em MS-MPCs, MS-PICs e MX-SPC3s. Ele não é suportado em 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 dos serviços não criptografam. Presume-se que o transporte de logs e o posicionamento do coletor de logs estejam 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 de modelo de 0 a 255 estão reservados para conjuntos de modelos e o número máximo de modelos suportados para registrar eventos em formato de monitoramento de fluxo é 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 associado ao modelo), o modelo específico é desregistrado e reregistrado. No entanto, a infraestrutura de monitoramento de fluxo requer 10 minutos por padrão, conforme o período de atraso para que os IDs do modelo sejam liberados. Como resultado, se você modificar muitas vezes as configurações de perfil de modelo dentro do período de 10 minutos, o limite máximo de IDs de modelo de 255 é excedido e outros modelos não são registrados. Nesse caso, quando os modelos não estão 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 modelo, ele denota que os modelos são registrados com sucesso.

Em um cenário em que a capacidade de registrar eventos NAT em formato de monitoramento de fluxo é habilitada em nível de conjunto de serviços e, se o PIC inicializar, os modelos de log de monitoramento de fluxo são registrados com o 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 do PIC no roteador ou podem não ser transmitidos para fora do roteador, porque a interface pode não estar acima da perspectiva do Mecanismo de Encaminhamento de Pacotes. Após a expiração 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 do tempo de inicialização do PIC, os registros do modelo serão enviados corretamente ao coletor.

Caso não ocorram problemas na transmissão de mensagens de registro de monitoramento de fluxo para o coletor a partir do PIC, o campo Enviado será 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 valor na Dropped seção da saída do show services service-sets statistics jflow-log service-set service-set-name comando for incrementado ou não for incrementado, você deve examinar as estatísticas e contadores de depuração para determinar se existe algum problema na rede para a transmissão das mensagens de log de monitoramento de fluxo.