NESTA PÁGINA
Problemas abertos
Saiba mais sobre problemas abertos nesta versão para a Série PTX.
Para obter as informações mais completas e mais recentes sobre os defeitos conhecidos do Junos OS, use o aplicativo de pesquisa de relatório de problemas junos on-line da Juniper Networks.
Roteamento geral
-
Em roteadores e switches que executam o Junos OS, com o Link Aggregation Control Protocol (LACP) habilitado, a desativação de um link remoto de membro da Ethernet agregada (AE) faz com que o link de membro local se mova para o estado separado do LACP e cause quedas de tráfego naquele link de membro. O mesmo cenário aplicado quando um novo link de membro é adicionado onde a outra extremidade desse link ainda não está configurada com LACP. PR1423707
-
A configuração sem suporte está sendo tentada pelo script que então atinge o limite máximo para a plataforma PTX5000. PR1555159
-
Nas plataformas PTX, quando o Jflow inline é configurado e a alta taxa de amostragem (mais de 4000 por segundo) é definida, uma alta utilização de CPU pode ser observada e isso pode resultar em impactos relevantes na análise e faturamento do tráfego. PR1569229
-
Em PTX10002-60C/QFX10002-60C, após a reinicialização do sistema, o alarme "Erros maiores do FPC 0" pode ser visto devido a um raro problema de temporização. O problema pode fazer com que o tráfego do caminho do host seja descartado. É um problema raro e nem sempre acontece durante o reboot. Tente realizar "solicitar reinicialização do vmhost" para a recuperação. PR1613229
-
Em plataformas dual-RE, se certos FPCs baseados em Linux PTX3000/5000 (FPC3-SFF-PTX-1X,FPC3-SFF-PTX-2X,FPC-P1,FPC-P2) forem instalados, quando o TNP (Protocolo de Rede Trivial) estiver em direção a flaps de backup RE continuamente, o FPC pode reiniciar após o GRES devido ao problema do vizinho TNP. PR1630393
-
A rota padrão V6 não será adicionada após a ligação bem-sucedida do cliente dhcpv6 no roteador PTX1000 durante o ztp. PR1649576
-
A presença de recursos consistentes de hash/resiliência na configuração em execução faz com que o sistema demorou muito mais para convergir em caso de churn. PR1652750
-
ZTP: DHCPACK não é recebido no ztp-server após zeroize do dispositivo (cliente). PR1658287
-
Ao assinar caminhos de sensores "/junos/system/linecard/packet/usage/", "/junos/services/label-switched-path/usage/" ou outros caminhos de sensor de placa de linha (PFE) no modo de assinatura gNMI, as quedas de pacotes podem ser vistas no comando CLI "mostrar estatísticas de agentes de rede gnmi detalhadas". A saída do coletor também pode conter números de sequência ausentes. Por exemplo, a saída de número de sequência pode ser 0, 3, 6, 9, 12 etc. em vez de 0, 1, 2, 3, 4, etc. PR1703418
-
No Chassisd, a thread Jvision leva mais tempo no streaming de pacotes jvision devido ao volume de dados e número de sensores envolvidos com este daemon. A rosca Jvision engajada por mais tempo para processar eventos de streaming fez com que a thread principal do Chassisd perdesse mensagens de recebimento/envio de mensagens keepalive para/de outras RE, o que acabou causando a transferência automática de RE na maioria dos casos. Para evitar isso, faça a correção para exportar pacotes jvision de carga pequena (formação que leva menos tempo) e adiar a rosca jvision mais em um intervalo, para permitir que o thread mestre do chassi processe mensagens olá/keep-alive de alta prioridade. Isso significa que agora, mais pacotes são enviados em um intervalo de relatórios e com maior disseminação (anteriormente, a mesma quantidade de dados foi enviada com 2 ou 3 pacotes de maior tamanho de carga, e 100ms de tempo de adiamento para thread jvision. Esse comportamento está aumentando o KPI-2, mas diminuindo o KPI-1 (tamanho da carga). Não é possível apoiar as mudanças feitas para resolver o problema de perda de mensagem continuamente vivo. Por isso, teremos que manter o Chassisd como exceção, quando medirmos/reportarmos os valores do KPI-2. A Jvision in Chassisd precisa dar mais prioridade/tempo para processar mensagens de manter a vida viva do que o envio de pacotes jvision. Por isso, o atraso entre os pacotes jvision são mais. PR1706300
Protocolos de roteamento
-
Quaisquer plataformas com Micro BFD configurada em links de membros da interface LAG/ae, o estado de sessão de BFD no RE permanece como UP sempre, embora o dispositivo PEER tenha deixado de ser. PR1675921