Automação Paragon, Versão 24.1

Destaques de software

• Suporte para RHEL 8.10
• Capacidade para usuários não-root executarem comandos no utilitário CLI paragon
• Capacidade de provisionar políticas de roteamento por segmentos em dispositivos Cisco IOS XR usando NETCONF

Introdução

O Juniper® Paragon Automation é uma solução pronta para a nuvem para planejamento, configuração, provisionamento, engenharia de tráfego, monitoramento e gerenciamento do ciclo de vida de rede que traz recursos avançados de visualização e análise para gerenciamento e monitoramento de rede. Você pode implantar o Paragon Automation como um aplicativo local (gerenciado pelo cliente).
A Paragon Automation opera em uma arquitetura baseada em microsserviços e emprega APIs REST, APIs gRPC e comunicações de barramento de mensagens comuns. A Paragon Automation fornece recursos básicos de plataforma, como suporte para Juniper Networks e dispositivos de terceiros (Cisco IOS XR, Nokia), provisionamento zerotouch, gerenciamento de usuários e controle de acesso baseado em função (RBAC).
Além de fornecer recursos básicos de plataforma, a Paragon Automation oferece um conjunto de aplicativos baseados em microsserviços: Juniper® Paragon Insights (anteriormente HealthBot), Juniper® Paragon Planner (anteriormente NorthStar Planner) e Juniper® Paragon Pathfinder (anteriormente NorthStar Controller).
Quando você adiciona qualquer um desses aplicativos ao Paragon Automation, o conjunto de API do aplicativo se integra ao Paragon Automation para permitir uma comunicação perfeita entre serviços novos e existentes. Nestas notas de versão, descrevemos os novos recursos da plataforma base, Paragon Pathfinder, Paragon Planner (aplicativo de desktop) e módulos Paragon Insights que estão disponíveis nesta versão. Para obter mais informações sobre recursos relacionados a esses aplicativos, consulte Guia do usuário do Paragon Automation.
Use estas notas de versão para encontrar recursos novos e atualizados, limitações de software e problemas em aberto no Paragon Automation versão 24.1.

Instruções de instalação e atualização

Para obter informações sobre procedimento de instalação, procedimento de atualização e requisitos (software e
hardware), consulte o Guia de instalação do Paragon Automation.

OBSERVAÇÃO:
Você pode atualizar diretamente apenas da versão 23.2 do Paragon Automation para a versão 24.1. Se a sua versão for anterior à Versão 23.2, você deverá instalar a Versão 24.1 novamente. No entanto, para migrar a configuração da versão atual para a versão 24.1, você pode usar a funcionalidade de backup e restauração. Para obter mais informações sobre atualização, consulte Atualizar para o Paragon Automation versão 24.1.

Licenciamento

No Paragon Insights, apresentamos os seguintes níveis de licença e suas licenças de dispositivos relacionadas:

• Paragon Insights Advanced (PIN avançado)
• Padrão Paragon Insights (padrão PIN)

Atualmente, as licenças de nível são rigorosamente aplicadas. Ou seja, você não poderá executar a operação de implementação a menos que adicione as licenças.
As licenças de dispositivo são aplicadas de forma suave. Ou seja, você receberá um alerta de fora de conformidade na GUI do Paragon Automation se tentar implantar mais dispositivos do que o número para o qual você obteve licenças.
No entanto, você pode continuar a usar a funcionalidade existente.
Você pode view seu status de conformidade de licença na página Administração > Gerenciamento de licenças na GUI.
No Paragon Pathfinder, aplicamos rigorosamente os seguintes níveis de licença:

• Padrão Pathfinder
• Desbravador Avançado
• Desbravador Premium

Para obter informações sobre licenciamento, consulte o Guia de Licenciamento.
Se você tiver uma chave de licença gerada para uma versão do Paragon Automation anterior à Release
22.1, você precisará atualizar o formato da chave de licença para o novo formato antes de poder instalá-lo no Paragon Automaton versão 24.1. Você pode gerar uma nova chave de licença usando o portal Juniper Agile Licensing. Para obter mais informações sobre como gerar uma nova chave de licença, consulte View, Adicionar ou Excluir licenças.

Recursos novos e alterados

Esta seção descreve os recursos de cada módulo do Juniper Paragon Automation versão 24.1.
Instalação e atualização do Paragon

• Red Hat Enterprise Linux (RHEL) 8.10 — Paragon Automation Release 24.1 está qualificado para funcionar com RHEL 8.10.
  [Ver Pré-requisitos de instalação no Red Hat Enterprise Linux.]
• Execute comandos do utilitário CLI paragon como um usuário não root — A partir do Paragon Automation versão 24.1, um usuário não root com privilégios de superusuário (sudo) pode executar os comandos do utilitário CLI paragon para analisar, consultar e depurar a configuração do Paragon Automation.
  [Ver Solucionar problemas usando o utilitário CLI paragon.]

Desbravador exemplar

• Provisionar políticas de roteamento por segmentos em dispositivos Cisco IOS XR — A partir do Paragon Automation versão 24.1, você pode provisionar políticas de roteamento por segmentos em dispositivos Cisco IOS XR usando NETCONF como método de provisionamento.

Plataforma básica
Não adicionamos nenhum novo recurso relacionado à plataforma base no Paragon Automation versão 24.1.
Insights exemplares
Não adicionamos nenhum novo recurso relacionado ao Paragon Insights no Paragon Automation versão 24.1.
Planejador exemplar
Não adicionamos nenhum novo recurso relacionado ao Paragon Planner no Paragon Automation versão 24.1.
OBSERVAÇÃO: Planejador exemplar Web O aplicativo é um recurso beta do Paragon Automation versão 24.1.

Recursos obsoletos

Esta seção lista os recursos que estão obsoletos ou para os quais o suporte foi retirado do Paragon
Versão do Autômato 24.1.
• IU Grafana
Você não pode acessar a UI do Grafana no Paragon Automation. Para acessar a UI do Grafana, você deve:

1. Instale o Grafana.
   Ver Documentação Grafana para maiores informações.
2. Exponha a porta TSDB executando o comando /var/local/healthbot/healthbot tsdb start-services.

OBSERVAÇÃO: No Paragon Automation, a porta TSDB não é exposta por padrão. Para usar ferramentas externas como Grafana, você precisa executar uma consulta diretamente ao TSDB (e não por meio de APIs) para expor a porta TSDB.

Para mais informações, consulte Faça backup e restaure o TSDB.
• Gráficos

Problemas conhecidos

Esta seção lista os problemas conhecidos no Juniper Paragon Automation versão 24.1

Instalação

• Ao provisionar máquinas virtuais (VMs) em servidores VMware ESXi, se você adicionar o disco de armazenamento em bloco antes de adicionar o disco com o sistema operacional base, o Ceph às vezes identifica incorretamente as unidades e cria o cluster usando a unidade incorreta, resultando no sistema operacional base sendo destruído.
  Solução alternativa: adicione o primeiro disco como sistema operacional base (unidade maior) e, em seguida, adicione o disco de armazenamento em bloco menor.
• Na ausência de uma replicação HA de banco de dados de série temporal (TSDB), se um nó de trabalho do Kubernetes que executa um pod TSDB ficar inativo, mesmo que haja capacidade no pod, o serviço TSDB não será ativado em um novo nó. Isso ocorre porque um grande volume de dados precisaria ser transferido para o novo nó.
  Solução alternativa: no caso de falha do servidor ou armazenamento que hospeda uma instância TSDB, você pode reconstruir o servidor ou componente danificado.

Se o fator de replicação for definido como 1, os dados TSDB dessa instância serão perdidos. Nesse caso, você precisa remover o nó TSDB com falha do Paragon Automation. Para remover o nó TSDB com falha:

1. Na GUI do Paragon Automation, selecione Configuração > Configurações do Insights.
   A página Configurações do Insights é exibida.
2. Clique na guia TSDB para view a página com a guia Configurações do TSDB.
3. Para excluir o nó com falha, na página com guia Configurações do TSDB, clique no X ao lado do nome do nó do TSDB com falha.
   OBSERVAÇÃO: Recomendamos que você exclua nós TSDB durante uma janela de manutenção, pois alguns serviços serão reiniciados e a GUI do Paragon Automation não responderá enquanto o trabalho do TSDB for executado.
4. Clique em Salvar e implementar.
5. Se as alterações não forem implementadas e você encontrar um erro durante a implementação, ative o botão de alternância Forçar e confirme as alterações clicando em Salvar e Implementar. Ao fazer isso, o sistema ignora o erro encontrado ao ajustar as configurações do TSDB.

• Se você desinstalar completamente o Paragon Automation, também deverá garantir que o diretório /var/lib/rook seja removido de todos os nós e que todos os dispositivos de bloco do Ceph sejam apagados.
  Solução alternativa: consulte o Solução de problemas do Ceph e Rook > Reparar um disco com falha seção no Guia de instalação do Paragon Automation.
• Ao instalar o Paragon Automation usando o método air-gap, ocorre o seguinte erro:

Solução alternativa: edite as seguintes variáveis ​​de configuração em config-dir/config.yml file e, em seguida, instale o Paragon Automation usando o método air-gap:

Em geral

• A saída do comando deploy-federated-exchange exibe que a instalação falhou quando você configura a recuperação de desastres em uma implementação de cluster duplo. Você pode ignorar a mensagem de falha, mas deve executar o seguinte comando em todos os nós primários de ambos os clusters:Solução alternativa: nenhuma.
• Quando uma falha afeta ambos os pares diversos de LSPs, o Path Computation Server (PCS) não roteará os LSPs ao longo do caminho de menor nível de diversidade ou ao longo do caminho não diverso. Os LSPs não são roteados até que o PCS encontre um caminho que corresponda ao nível de diversidade configurado.
  Solução alternativa: nenhuma
• Quando uma falha afeta ambos os pares diversos de LSPs, o Path Computation Server (PCS) não roteará os LSPs ao longo do caminho não diverso. Os LSPs não são roteados até que o PCS encontre um caminho que corresponda ao nível de diversidade configurado.
  Solução alternativa: remova e reaplique o grupo de diversidade.
• O valor mínimo do limite de variação nas configurações de dimensionamento de largura de banda de um subLSP de contêiner é mostrado como 0, apesar de configurá-lo no contêiner. Sob condições normais, não há impacto no dimensionamento da largura de banda do subLSP, pois a tarefa de dimensionamento de largura de banda busca esse valor no contêiner em vez do subLSP. No entanto, em certos cenários, é possível que o subLSP seja redimensionado para um novo valor de largura de banda quando o limite mínimo de variação configurado não tiver sido violado.
  Para obter mais detalhes sobre esse problema, entre em contato com o Centro de Assistência Técnica da Juniper Networks (JTAC).
• Durante o dimensionamento da largura de banda, um LSP secundário ativo que tenha o dimensionamento de largura de banda habilitado pode não ser redimensionado. Quando esse problema ocorre, a utilização de RSVP dos links no caminho secundário pode ser atualizada incorretamente.
  Solução alternativa: nenhuma.
• Fazer alterações nas configurações do Paragon Pathfinder (Configuração > Configurações de rede) usando a UI pode exigir mais de uma tentativa para que a modificação entre em vigor. Talvez seja necessário clicar em Salvar mais de uma vez.
  Solução alternativa: as mesmas alterações podem ser feitas usando a CLI cMGD, que pode ser acessada a partir do nó mestre que executa o comando pf-cmgd.
• Sob certas condições durante a normalização do contêiner, um ou mais subLSPs de contêiner que deveriam ser removidos continuarão a permanecer. Esses subLSPs de contêiner permanecerão na rede como LSPs independentes não associados ao contêiner. Uma incompatibilidade no número de subLSPs de um contêiner indicado na coluna subLSPs na guia Container LSP e no número real de LSPs com o nome do contêiner como prefixo na guia Tunnel pode ser considerada uma indicação desse problema.
  Para obter mais detalhes sobre esse problema, entre em contato com o Centro de Assistência Técnica da Juniper Networks (JTAC).
• O Container LSP pode ser configurado com configurações de dimensionamento de largura de banda que são herdadas por seus subLSPs. Sob certas circunstâncias, quando um usuário desabilita a opção de dimensionamento de largura de banda no contêiner depois de tê-la habilitado no passado, ela não é desabilitada nos subLSPs existentes.
  Solução alternativa: nenhuma.
• O reprovisionamento manual de um subLSP de contêiner levaria à adição de dados ao objeto LSP. Como resultado, os seguintes problemas podem ocorrer:
• Se o contêiner estiver habilitado para dimensionamento de largura de banda e um limite de variação mínimo diferente de zero estiver configurado, o subLSP específico poderá ser redimensionado apesar do tráfego através do subLSP não exceder sua largura de banda sinalizada em pelo menos o valor mínimo do limite de variação.
• O subLSP poderá ter configurações de dimensionamento de largura de banda diferentes das do contêiner se as configurações de dimensionamento de largura de banda do contêiner forem modificadas posteriormente.
• Falha na remoção do subLSP durante a normalização do contêiner quando a largura de banda cai abaixo da largura de banda mesclada.
  Para obter mais detalhes sobre esse problema e obter instruções para remover os dados adicionais adicionados ao estado interno, entre em contato com o Centro de Assistência Técnica da Juniper Networks (JTAC).
• Em determinados cenários, como falha na normalização do contêiner por falta de caminhos disponíveis, um estado interno adicional seria adicionado aos objetos subLSP do contêiner, o que poderia levar aos seguintes problemas:
• Se o contêiner estiver habilitado para dimensionamento de largura de banda e um limite de variação mínimo diferente de zero estiver configurado, o subLSP específico poderá ser redimensionado apesar do tráfego através do subLSP não exceder sua largura de banda sinalizada em pelo menos o valor mínimo do limite de variação.
• O subLSP poderá ter configurações de dimensionamento de largura de banda diferentes das do contêiner se as configurações de dimensionamento de largura de banda do contêiner forem modificadas posteriormente.
• Falha na remoção do subLSP durante a normalização do contêiner quando a largura de banda cai abaixo da largura de banda mesclada.

Para obter mais detalhes sobre esse problema e obter instruções para remover os dados adicionais adicionados ao estado interno, entre em contato com o Centro de Assistência Técnica da Juniper Networks (JTAC).

• Quando um ou mais nós em um cluster Kubernetes em funcionamento não estão disponíveis, isso pode resultar no seguinte comportamento inesperado:
• O status PCEP de todos os nós é mostrado como inativo, embora o status da conexão PCEP esteja ativo no roteador.
• Topologia de rede não exibida na UI.
  Para obter mais detalhes sobre esse problema, entre em contato com o Centro de Assistência Técnica da Juniper Networks (JTAC).
• O Paragon Pathfinder pode calcular um caminho que viola a restrição máxima de salto configurada no túnel. Estes cenários explicam como a restrição máxima de salto é violada:
• Quando o Path Computation Server (PCS) é reiniciado, o LSP inativo é provisionado sem considerar a restrição máxima de salto.
• Durante uma falha na rede, o LSP é redirecionado sem considerar a restrição máxima de salto.
• Durante a otimização do caminho, o LSP é otimizado sem considerar a restrição máxima de salto.
  Solução alternativa: use a opção de reprovisionamento se um caminho alternativo que não viole a restrição configurada estiver disponível.
• O caminho calculado pelo Paragon Pathfinder para um LSP de espera com restrição máxima de salto pode violar a restrição configurada.
  Solução alternativa: nenhuma.
• Existe a possibilidade de o PCS não conseguir encontrar LSP com diversidade de enlaces em uma topologia que possui múltiplos enlaces paralelos entre nós.
  Solução alternativa: nenhuma.
• Quando a sessão PCEP estiver desabilitada, o status operacional do LSP passará para um estado desconhecido após a execução da coleta de dispositivos.
  Solução alternativa: nenhuma.
• Um link pode desaparecer ao criar uma tarefa de arquivamento de rede.
  Solução alternativa: crie uma nova tarefa de arquivamento de rede.
• Não foi possível rotear a demanda de VPN devido a problemas na rede.
  Solução alternativa: nenhuma.
• Os alarmes não respondem quando os dispositivos Cisco são configurados inicialmente com NETCONF na porta 22.
  Solução alternativa: modifique a porta NETCONF no seu dispositivo Cisco para e certifique-se de que as alterações sejam salvas. Depois disso, reverta as configurações da porta para a porta 22.
• Ao adicionar demandas multicast na GUI, o campo do nó Z fica vazio.
  Solução alternativa: nenhuma.
• Quando você adiciona vários novos túneis, os valores de tráfego dos túneis excluídos anteriormente (que foram armazenados em cache) são exibidos.
  Solução alternativa: nenhuma.
• Quando você adiciona novos túneis diversos, às vezes os valores de tráfego de túneis excluídos anteriormente (que foram armazenados em cache) são exibidos.
  Solução alternativa: nenhuma.
• O Toposerver não limpa nem atualiza a topologia após perder a conexão com o pod BMP.
  Solução alternativa: nenhuma.
• Quando um link está inativo, o Paragon Pathfinder não redireciona um LSP SR delegado com o método de roteamento preferido Explicit Route Object (ERO) e Route By Device.
  Solução alternativa: use o método de roteamento padrão.
• Se você executar uma simulação diretamente após executar um projeto de árvore multicast diverso, o relatório em Tráfego de túnel em links (Relatório de simulação de camada de túnel > Estatísticas de pico de rede) estará incorreto.
  Solução alternativa: salve a rede depois de executar um Diverse Multicast Tree Design e feche-a. Reabra a rede e execute a simulação.
• Ao simular cenários de falha (Ferramentas > Opções > Simulação de falha), se você executar uma simulação de falha múltipla primeiro e depois executar uma simulação de falha única, o relatório em Tráfego de túnel em links (Relatório de simulação de camada de túnel > Estatísticas de pico de rede) estará incorreto. O relatório exibe vários valores de simulação de falha em vez de falha única.
  Solução alternativa: desmarque todas as opções na guia Falha Múltipla antes de simular um cenário de falha única.
• O relatório de simulação de utilização do link pode mostrar valores negativos durante o cenário de falha dupla.
  Solução alternativa: nenhuma.
• Quando um nome de host de dispositivo é alterado, a alteração não é refletida em todos os bancos de dados.

Solução alternativa: execute as etapas a seguir para que o novo nome de host do dispositivo seja refletido em todos os bancos de dados e componentes.

1. Antes da alteração do nome do host, remova o dispositivo de todos os grupos de dispositivos (controlador ou outros manuais).
2. Certifique-se de que as referências do dispositivo sejam excluídas de todos os diferentes componentes do Paragon Automation. Navegue até a página Configuração > Dispositivos.
   um. Selecione o dispositivo.
   b. Clique no ícone da lixeira para excluir o dispositivo. A página Excluir dispositivo é exibida.
   c. Selecione Forçar exclusão e clique em Sim.
3. Integre o dispositivo novamente, usando o fluxo de trabalho de integração do dispositivo na página Configuração > Dispositivos.
   O dispositivo agora deve estar integrado com o novo nome de host. As propriedades do dispositivo, especialmente o ID do sistema (importante para receber os fluxos JTI), também devem ser atualizadas.
4. Adicione o dispositivo com o novo nome de host novamente aos grupos de dispositivos.
5. (Opcional) Verifique todas as estatísticas do dispositivo no Influxdb usando Grafana ou na CLI do dispositivo. O banco de dados deve ser atualizado com o novo nome de host.

• O método de provisionamento do Network Configuration Protocol (NETCONF) para LSPs ponto a multiponto (P2MP) não é suportado em roteadores Cisco IOS-XR.
• Em roteadores Cisco IOS-XR, o status sub-LSP P2MP não é suportado no estado de configuração para LSPs P2MP provisionados por CLI.
  Solução alternativa: nenhuma.
• O Junos OS versão 22.4R1 e posterior tem uma limitação com LSPs SR-TE.
  Para que as sessões PCEP sejam estabelecidas, você deve desabilitar o recurso multipath usando o seguinte comando: set protocols pcep disable-multipath-capability O caminho secundário não é suportado.
•  Mensagens antigas na fila estão sendo processadas após a recuperação do link de federação.
  Solução alternativa: Defina o tempo de expiração da fila do link de federação próximo ao tempo de detecção de falha do link de federação Toposerver (o padrão é 3*5s).
• Você não pode usar os métodos NETCONF e Path Computation Element Protocol (PCEP) para provisionar LSPs P2MP para roteadores Cisco IOS-XR usando a UI do Paragon Automation.
  Gambiarra. Provisione os LSPs P2MP usando a CLI. Depois que a configuração for analisada, execute uma tarefa de coleta de dispositivos para view os PSL.
•  Você não pode desabilitar o sinalizador da fonte da verdade quando a implantação estiver no modo de segurança.
  Solução alternativa: reinicie o pod toposerver para desativar o sinalizador de fonte da verdade durante o modo de segurança.
• Quando você seleciona vários caminhos comutados por rótulos delegados (LSPs) pertencentes a um único roteador de entrada e clica em Retornar delegação ao PCC, apenas um dos LSPs se torna controlado pelo dispositivo. Um problema no Junos causa esse cenário.
  Solução alternativa: selecione um LSP por vez e clique em Retornar delegação ao PCC individualmente para cada LSP.
• O status operacional de um LSP SR-TE delegado permanece inativo após seu nó de destino ser redescoberto.
  Solução alternativa: você deve sincronizar o modelo de rede depois que o nó de destino LSP SR-TE delegado for redescoberto.
• O servidor PCE não consegue se reconectar ao RabbitMQ após o RabbitMQ ser reiniciado.
  Solução alternativa: reinicie o pod ns-pceserver.
• Você não pode modificar a configuração use-federated-exchange da API/UI REST.
  Solução alternativa: modifique a configuração use-federated-exchange diretamente da CLI cMGD e reinicie o toposerver para que a mudança entre em vigor.
• O Paragon Insights mapeia o campo Nome (nome do host ou endereço IP) para o campo ID do dispositivo. No entanto, o nome do dispositivo não é mais exclusivo pelos seguintes motivos:
• Em um dispositivo Dual Routing Engine, “-reX” é anexado ao nome do dispositivo.
• Aplicativos de terceiros, como Anuta Atom, acrescentam o nome de domínio ao nome do dispositivo.
  Além disso, mapear um dispositivo por seu identificador exclusivo universal (UUID) e não pelo nome do host pode causar problemas com as informações exibidas pela GUI.
  Solução alternativa: configure um endereço IP adicional para a interface Ethernet de gerenciamento no dispositivo incluindo a instrução master-only no nível [edit groups] da hierarquia. Você deve então usar esse endereço IP adicional para integrar o dispositivo. Para obter mais informações, consulte Interfaces Ethernet de gerenciamento.
• Se você dedicou um nó para TSDB, alguns serviços (por exemploample, AtomDB, ZooKeeper e assim por diante) no namespace comum que tem PersistentVolumeClaim definido podem ser afetados se os pods relevantes estiverem em execução no nó dedicado. Ou seja, o status dos pods em execução no nó TSDB é sempre exibido como Pendente.
  Solução alternativa: para evitar essa situação, ao dedicar um nó para TSDB, certifique-se de que o nó não tenha pods para serviços dedicados que usam PersistentVolumeClaim.
• Quando você cancela a delegação de um LSP delegado, a largura de banda planejada do LSP é baseada na largura de banda relatada pelo dispositivo, em vez do valor de entrada do usuário.
  Solução alternativa: nenhuma.
• Ao adicionar um dispositivo, se você especificar um endereço IP de origem que já seja usado em uma rede, talvez não seja possível adicionar o dispositivo a um grupo de dispositivos, implantar um playbook, encontrar erros relacionados à ingestão de funções e assim por diante.
  Solução alternativa: corrija o endereço IP de origem conflitante. Clique no ícone Status de implementação e confirme as alterações.
• Se você selecionar uma consulta salva na página Alarmes, os alarmes serão filtrados com base na consulta salva. Porém, o gráfico e a data não são atualizados.
  Solução alternativa: nenhuma.
• Se você adicionar um dispositivo não gerenciado na página Dispositivo e posteriormente editar o nome do host do dispositivo não gerenciado, o nome do host não será refletido no grupo de dispositivos e no painel Dispositivos no Painel.
  Solução alternativa: você pode adicionar um dispositivo não gerenciado usando o nome do host ou o endereço IP de um dispositivo.
  Se você adicionou um dispositivo não gerenciado usando o nome de host, excluir o dispositivo existente e adicionar o dispositivo com um novo nome de host resolverá o problema.
  Se você adicionou um dispositivo não gerenciado usando o endereço IP, no grupo de dispositivos e no painel Dispositivos no Painel, você precisará identificar os dispositivos não gerenciados com base no endereço IP e não no nome do host.
• Por padrão, o filtro de topologia está desabilitado. Você não pode ativar o filtro de topologia usando a GUI do Paragon Automation.
  Solução alternativa: para obter o procedimento para ativar o filtro de topologia, consulte o tópico Ativar o serviço de filtro de topologia.
• Para dispositivos Cisco IOS XR, você não pode restaurar uma configuração de dispositivo na página Dispositivos. Você só pode fazer backup da configuração do dispositivo.
  Solução alternativa: para restaurar a configuração dos seus dispositivos Cisco IOS XR:
  1. Na página Configuração > Dispositivos, selecione o dispositivo Cisco XR e clique em Mais > Versão de configuração.
  2. Copie a versão de configuração que deseja restaurar.
  3. Restaure a configuração usando a CLI.
• Se você tiver habilitado o SSH de saída em nível de grupo de dispositivos, não poderá desabilitar o SSH de saída para um dos dispositivos do grupo de dispositivos.
  Solução alternativa: você pode ativar ou desativar o SSH de saída no dispositivo usando MGD CLI ou APIs Rest. Para desabilitar o SSH de saída, você deve definir o sinalizador de desabilitação como verdadeiro. Execute o seguinte comando no dispositivo para desabilitar o SSH de saída usando a CLI do MGD: set healthbot DeviceName outbound-ssh disable true
• Você não pode fazer download de todos os logs de serviço da GUI do Paragon Automation.
  Solução alternativa: você pode view todos os logs de serviço no Elastic Search Database (ESDB) e no Grafana. Para efetuar login no Grafana ou ESDB, você deve configurar uma senha no campo grafana_admin_password no config.yml file antes da instalação.
• Se você modificar um LSP existente ou usar um ID de fatia como um dos critérios de roteamento, o caminho pré-definidoview pode não aparecer corretamente.
  Solução alternativa: depois de provisionar o caminho, ele respeitará as restrições de ID de fatia e aparecerá corretamente no caminho pré-definido.view.
• Se você provisionar um LSP roteado por segmentos usando PCEP, a funcionalidade de cores não funcionará.
  Esse problema ocorre se o roteador estiver em execução no Junos OS Release 20.1R1.
  Solução alternativa: atualize o Junos OS para a versão 21.4R1.
• Os microsserviços não conseguem se conectar ao PostgresSQL porque o PostgresSQL não aceita nenhuma conexão durante a alternância de função primária. Este é um estado transitório.
  Solução alternativa: certifique-se de que os microsserviços se conectem ao PostgresSQL após a conclusão da alternância da função primária.
  • O banco de dados Postgres deixa de funcionar em alguns sistemas, o que leva à falha de conexão.
  Solução alternativa: execute o seguinte comando no nó primário: for pod in atom-db-{0..2}; fazer
  kubectl exec -n common $pod — chmod 750 /home/postgres/pgdata/pgroot/data concluído
• A descoberta de dispositivos para dispositivos Cisco IOS XR falha.
  Solução alternativa: Aumente o limite de taxa do servidor SSH para o dispositivo Cisco IOS XR. Faça login no dispositivo no modo de configuração e execute o seguinte comando:
  RP/0/RP0/CPU0:ios-xr(config)#ssh server rate-limit 600
• Se você usar BGP-LS para obter informações sobre o atraso do link e a variação do atraso do link, não será possível view os dados históricos de atraso do link.
  Solução alternativa: nenhuma.
• Em cenários raros (por ex.ampPor exemplo, quando o Redis trava e é reiniciado automaticamente pelo Kubernetes, ou você precisa reiniciar o servidor Redis), algumas informações de interfaces são perdidas e as interfaces não são listadas na guia Interface da tabela de informações de rede. No entanto, esse problema não afeta o cálculo do caminho, as estatísticas ou o provisionamento de LSP.
  Solução alternativa: para restaurar interfaces no modelo de rede ativa, execute novamente a tarefa de coleta de dispositivos.
• Na guia Tarefas das páginas Adicionar novo fluxo de trabalho e Editar fluxo de trabalho:
• Mesmo que você clique na opção Cancelar, as alterações feitas durante a edição de uma tarefa serão salvas.
• Você não pode reutilizar o nome de uma etapa que já excluiu.
• Uma mensagem de erro não será exibida mesmo quando você adicionar uma etapa com entradas vazias e clicar em Salvar e implementar.
  Solução alternativa: nenhuma.
• Atualização de alguns dos dispositivos PTX de baixo custo com o modo Dual RE (por exemploamparquivo, PTX5000 e PTX300) não é suportado no Paragon Automation. Isso ocorre porque os dispositivos PTX de baixo custo com o modo Dual RE não suportam a configuração de ponte ou domínio de ponte.
  Solução alternativa: nenhuma.
• A API POST /traffic-engineering/api/topology/v2/1/rpc/diverseTreeDesign não funciona.
  Solução alternativa: Recomendamos que você use a API POST /NorthStar/API/v2/tenant/1/topology/1/rpc/diverseTreeDesign.
• A Paragon Automation não mostra alarmes para dispositivos Nokia.
  Solução alternativa: nenhuma.
• Ao configurar um LSP SRv6 com o método de roteamento como routeByDevice, você deve especificar um valor para o objeto de rota explícita de roteamento por segmentos (SR-ERO); caso contrário, você não poderá usar o LSP SRv6 para transportar tráfego.
  Solução alternativa: ao adicionar um túnel, na guia Caminho, adicione saltos para especificar o tipo de roteamento necessário ou preferencial.
• Se um LSP SRv6 controlado por dispositivo for descoberto na rede, o caminho destacado para esse LSP estará incorreto, independentemente de você especificar ou não um objeto de rota explícita (ERO) para a rota.
  Solução alternativa: nenhuma.
• Às vezes, talvez você não consiga excluir LSPs de roteamento por segmentos em massa.
  Solução alternativa: você pode forçar a exclusão dos LSPs que não foram excluídos durante o processo de exclusão em massa.
•  Na GUI do Paragon Automation, na guia Tarefas das páginas Adicionar novo fluxo de trabalho e Editar fluxo de trabalho, a seguinte mensagem de erro é exibida quando você tenta editar e salvar uma etapa existente sem fazer nenhuma alteração:
  O nome já existe
  Solução alternativa: se você clicou erroneamente na opção Editar, certifique-se de alterar pelo menos o nome da etapa.
• A sessão PCEP às vezes é exibida como Inativa se você reiniciar todos os pods no namespace northstar.
  Solução alternativa: reinicie o servidor de topologia usando kubectl delete pods ns-toposerver- -n comando estrela do norte.
• Na página Administração > Gerenciamento de licenças, você não pode view o nome SKU de uma licença ao selecionar a licença e, em seguida, selecione Mais > Detalhes.
  Solução alternativa: nenhuma.
• O gráfico na página Alarmes não reflete os dados mais recentes. Ou seja, o gráfico não é atualizado depois que um alarme deixa de estar ativo.
  Solução alternativa: nenhuma.
• Ao configurar o SSH de saída para o iAgent, os dados da regra configurada não serão gerados.
  Solução alternativa: nenhuma.
• Um valor de zero por cento de perda de pacotes será exibido entre os links se você tiver configurado o Two-Way Active Management Protocol (TWAMP). Isso está incorreto porque TWAMP não oferece suporte à exportação de perda de pacotes para engenharia de tráfego IS-IS.
  Solução alternativa: nenhuma.
• Se você estiver usando um dispositivo com placas de linha MPC10+ e se o dispositivo estiver em execução em uma versão Junos OS diferente da versão 21.3R2-S2 ou versão 21.4R2-S1, as estatísticas para interfaces lógicas não serão coletadas. Contudo, as estatísticas para interfaces físicas e LSPs são coletadas.
  Solução alternativa: atualize a versão do Junos OS para a versão 21.3R2-S2 ou 21.4R2-S1. Além disso, certifique-se de ter atualizado o Paragon Automation para a versão 23.1.
• Quando você cancela a delegação de um LSP, o status do LSP é exibido como delegado. Ao tentar cancelar a delegação do LSP novamente, a configuração do roteador poderá ser modificada para adicionar objetos de rota explícitos (ERO).
  Solução alternativa: atualize a guia Tunnel antes de cancelar a delegação do LSP novamente.
• O Paragon Pathfinder não derruba um SR LSP delegado quando o SR LSP não atende às restrições de fatia se o status do SR LSP for roteado localmente.
• Se você criar um grupo de topologia com ID de fatia maior ou igual a 2**32, o ID do grupo de topologia não corresponderá ao ID de fatia.
• O cluster Paragon Automation Kubernetes usa certificados gerenciados por kubeadm autogerados.
  Esses certificados expiram um ano após a implantação, a menos que a versão do Kubernetes seja atualizada ou os certificados sejam renovados manualmente. Se os certificados expirarem, os pods não aparecerão e exibirão erros de certificado inválidos no log.
  Solução alternativa: renove os certificados manualmente. Execute as seguintes etapas para renovar certificados:

1. Verifique a data atual de expiração dos certificados usando o comando kubeadm certs check-expiration em cada nó primário do seu cluster.
2. Para renovar os certificados, use o comando kubeadm certs restart all em cada nó primário do cluster Kubernetes.
3. Verifique novamente a data de expiração usando o comando kubeadm certs check-expiration em cada nó primário do seu cluster.
4. Reinicie os seguintes pods de qualquer um dos nós primários para usar os novos certificados.

Problemas resolvidos

Esta seção lista os problemas resolvidos no Juniper Paragon Automation versão 24.1

• LSPs de pares simétricos podem não ser roteados simetricamente após o reencaminhamento de cruzamento de limite.
  Solução alternativa: nenhuma.
• Os gráficos de tráfego agora são suportados para dispositivos com mecanismos de roteamento duplos integrados com re0 ou re1 com sufixo em seus nomes de host. No entanto, os gráficos só serão suportados se os sufixos do nome do host estiverem em letras minúsculas e no formato -re0 ou -re1. Para examparquivo: vmx101-re0 ou vmx101-re1
  Solução alternativa: nenhuma
• Os sites do controlador não estão incluídos no arquivo de rede do Paragon Planner.
  Solução alternativa: nenhuma.
• O status do modo de segurança é sempre falso quando ns-web o pod é iniciado.
  Solução alternativa: nenhuma.
• Você obtém um status de modo de segurança incorreto após modificar o sinalizador da fonte da verdade durante o modo de segurança.
  Solução alternativa: nenhuma.
• Às vezes, dispositivos com NETCONF desativado aparecem com status NETCONF ativo.
  Solução alternativa: edite o dispositivo profissionalfile sem quaisquer alterações para acionar o recarregamento do dispositivo profile.
• A cor para LSPs SR-TE originados de dispositivos Cisco IOS-XR será visível somente se o LSP for descoberto inicialmente na coleção de dispositivos.
  Solução alternativa: nenhuma.
• O grupo de administradores de um LSP SR-TE aprendido com PCEP desaparece após a sincronização da topologia, se o LSP tiver configurado o estado.
  Solução alternativa: modifique o SR-TE LSP para persistir o grupo de administração aprendido com o PCEP.
• Os LSPs no caminho ideal podem receber atualizações desnecessárias do PCEP durante a otimização do PCS.
  Solução alternativa: nenhuma.
• Um erro no recurso de diagnóstico (Configuração > Ingestão de dados > Diagnóstico > Aplicativo) faz com que os testes do aplicativo falhem.
  Solução alternativa: nenhuma.
• Na guia Rede > Topologia > Túnel, quando você passa o mouse sobre o ícone Filtro (funil) e seleciona Adicionar Filtro, a página Adicionar Critérios é exibida. Se você selecionar Cor na lista Campo, o valor do campo será exibido como PlannedProperties em vez de Cor.
  Solução alternativa: nenhuma.
• O relatório de análise de caminho está vazio.

Solução alternativa: execute uma tarefa de coleta de dispositivos antes de realizar a análise de caminho. Observe que o relatório de análise de caminho pode estar vazio se os LSPs já estiverem no caminho ideal.

Juniper Networks, o logotipo da Juniper Networks, Juniper e Junos são marcas registradas da Juniper Networks, Inc. nos Estados Unidos e em outros países. Todas as outras marcas comerciais, marcas de serviço, marcas registradas ou marcas de serviço registradas são propriedade de seus respectivos proprietários. A Juniper Networks não assume nenhuma responsabilidade por quaisquer imprecisões neste documento. A Juniper Networks reserva-se o direito de alterar, modificar, transferir ou revisar esta publicação sem aviso prévio. Copyright © 2024 Juniper Networks, Inc. Todos os direitos reservados.

Documentos / Recursos

Software de automação Juniper NETWORKS Paragon [pdf] Guia do Usuário Software de automação Paragon, Software de automação, Software

Referências

• Manual do usuário