Paragon Automation, versione 24.1

Caratteristiche principali del software

• Supporto per RHEL 8.10
• Possibilità per gli utenti non root di eseguire comandi nell'utilità CLI paragon
• Possibilità di fornire policy di routing dei segmenti sui dispositivi Cisco IOS XR utilizzando NETCONF

Introduzione

Juniper® Paragon Automation è una soluzione pronta per il cloud per la pianificazione, la configurazione, il provisioning, l'ingegneria del traffico, il monitoraggio e la gestione del ciclo di vita della rete che offre capacità di visualizzazione e analisi avanzate alla gestione e al monitoraggio della rete. Puoi distribuire Paragon Automation come un'applicazione locale (gestita dal cliente).
Paragon Automation opera su un'architettura basata su microservizi e impiega API REST, API gRPC e comunicazioni bus di messaggistica comuni. Paragon Automation fornisce funzionalità della piattaforma di base come supporto per dispositivi Juniper Networks e di terze parti (Cisco IOS XR, Nokia), provisioning zerotouch, gestione degli utenti e controllo degli accessi basato sui ruoli (RBAC).
Oltre a fornire funzionalità della piattaforma di base, Paragon Automation offre una suite di applicazioni basate su microservizi: Juniper® Paragon Insights (in precedenza HealthBot), Juniper® Paragon Planner (in precedenza NorthStar Planner) e Juniper® Paragon Pathfinder (in precedenza NorthStar Controller).
Quando aggiungi una di queste applicazioni a Paragon Automation, la suite API dell'applicazione si integra con Paragon Automation per consentire una comunicazione continua tra i servizi nuovi ed esistenti. In queste note sulla versione, descriviamo le nuove funzionalità della piattaforma di base, dei moduli Paragon Pathfinder, Paragon Planner (applicazione desktop) e Paragon Insights disponibili in questa versione. Per ulteriori informazioni sulle funzionalità relative a queste applicazioni, consultare la Guida per l'utente di Paragon Automation.
Utilizzare queste note sulla versione per trovare funzionalità nuove e aggiornate, limitazioni del software e problemi aperti in Paragon Automation Release 24.1.

Istruzioni per l'installazione e l'aggiornamento

Per informazioni sulla procedura di installazione, sulla procedura di aggiornamento e sui requisiti (software e
hardware), consultare la Guida all'installazione di Paragon Automation.

NOTA:
È possibile aggiornare direttamente solo dalla versione 23.2 di Paragon Automation alla versione 24.1. Se la tua versione è precedente alla versione 23.2, devi installare nuovamente la versione 24.1. Tuttavia, per migrare la configurazione della versione corrente alla Versione 24.1, è possibile utilizzare la funzionalità di backup e ripristino. Per ulteriori informazioni sull'aggiornamento, vedere Aggiornamento a Paragon Automation Release 24.1.

Licenza

In Paragon Insights abbiamo introdotto i seguenti livelli di licenza e le relative licenze per dispositivo:

• Paragon Insights Advanced (PIN avanzato)
• Paragon Insights Standard (standard PIN)

Attualmente, le licenze di livello sono applicate in modo rigido. Cioè, non è possibile eseguire l'operazione di distribuzione a meno che non si aggiungano le licenze.
Le licenze del dispositivo vengono applicate in modo soft. Ovvero, riceverai un avviso di non conformità nella GUI di Paragon Automation se provi a distribuire più dispositivi rispetto al numero per il quale hai ottenuto le licenze.
Tuttavia, puoi continuare a utilizzare la funzionalità esistente.
Puoi view lo stato di conformità della licenza nella pagina Amministrazione > Gestione licenze nella GUI.
In Paragon Pathfinder, abbiamo applicato in modo rigido i seguenti livelli di licenza:

• Standard dell'Esploratore
• Pathfinder Avanzato
• Pathfinder Premium

Per informazioni sulla licenza, vedere Guida alle licenze.
Se si dispone di una chiave di licenza generata per una versione di Paragon Automation precedente alla Release
22.1 sarà necessario aggiornare il formato della chiave di licenza al nuovo formato prima di poterlo installare in Paragon Automaton Release 24.1. È possibile generare una nuova chiave di licenza utilizzando il portale licenze Juniper Agile. Per ulteriori informazioni sulla generazione di una nuova chiave di licenza, vedere View, Aggiungi o Elimina licenze.

Funzionalità nuove e modificate

Questa sezione descrive le funzionalità di ciascun modulo di Juniper Paragon Automation Release 24.1.
Installazione e aggiornamento di Paragon

• Red Hat Enterprise Linux (RHEL) 8.10—Paragon Automation Release 24.1 è qualificato per funzionare con RHEL 8.10.
  [Vedere Prerequisiti di installazione su Red Hat Enterprise Linux.]
• Esegui i comandi dell'utilità CLI paragon come utente non root: a partire da Paragon Automation Release 24.1, un utente non root con privilegi di superutente (sudo) può eseguire i comandi dell'utilità CLI paragon per analizzare, eseguire query ed eseguire il debug della configurazione di Paragon Automation.
  [Vedere Risolvere i problemi utilizzando l'utilità CLI paragon.]

Esploratore d'eccellenza

• Fornire policy di routing del segmento sui dispositivi Cisco IOS XR: a partire da Paragon Automation Release 24.1, è possibile eseguire il provisioning delle policy di routing del segmento sui dispositivi Cisco IOS XR utilizzando NETCONF come metodo di provisioning.

Piattaforma di base
Non abbiamo aggiunto nuove funzionalità relative alla piattaforma di base in Paragon Automation Release 24.1.
Approfondimenti sul modello
Non abbiamo aggiunto nuove funzionalità relative a Paragon Insights in Paragon Automation Release 24.1.
Pianificatore Paragon
Non abbiamo aggiunto nuove funzionalità relative a Paragon Planner nella versione 24.1 di Paragon Automation.
NOTA: Pianificatore Paragon Web L'applicazione è una funzionalità beta di Paragon Automation Release 24.1.

Funzionalità obsolete

Questa sezione elenca le funzionalità deprecate o per le quali è stato ritirato il supporto da Paragon
Versione dell'automa 24.1.
• Interfaccia utente Grafana
Non è possibile accedere all'interfaccia utente di Grafana da Paragon Automation. Per accedere all'interfaccia utente di Grafana, è necessario:

1. Installa Grafana.
   Vedere Documentazione Grafana per ulteriori informazioni.
2. Esporre la porta TSDB eseguendo il comando /var/local/healthbot/healthbot tsdb start-services.

NOTA: In Paragon Automation, la porta TSDB non è esposta per impostazione predefinita. Per utilizzare strumenti esterni come Grafana, è necessario eseguire una query direttamente su TSDB (e non tramite API) per esporre la porta TSDB.

Per ulteriori informazioni, vedere Eseguire il backup e ripristinare il TSDB.
• Grafici

Problemi noti

Questa sezione elenca i problemi noti di Juniper Paragon Automation Release 24.1

Installazione

• Quando si effettua il provisioning di macchine virtuali (VM) su server VMware ESXi, se si aggiunge il disco di storage a blocchi prima di aggiungere il disco con il sistema operativo di base, Ceph a volte identifica erroneamente le unità e crea il cluster utilizzando l'unità errata, con il risultato che il sistema operativo di base viene distrutto.
  Soluzione alternativa: aggiungere il primo disco come sistema operativo di base (unità più grande), quindi aggiungere il disco di archiviazione a blocchi più piccolo.
• In assenza di una replica HA del database delle serie temporali (TSDB), se un nodo di lavoro Kubernetes che esegue un pod TSDB si interrompe, anche se c'è capacità nel pod, il servizio TSDB non viene avviato su un nuovo nodo. Questo perché un enorme volume di dati dovrebbe essere trasferito al nuovo nodo.
  Soluzione alternativa: in caso di guasto del server o dello storage che ospita un'istanza TSDB, è possibile ricostruire il server o il componente danneggiato.

Se il fattore di replica è impostato su 1, i dati TSDB per quell'istanza andranno persi. In tal caso, è necessario rimuovere il nodo TSDB con errori da Paragon Automation. Per rimuovere il nodo TSDB guasto:

1. Nella GUI di Paragon Automation, selezionare Configurazione > Impostazioni Insights.
   Viene visualizzata la pagina Impostazioni approfondimenti.
2. Fare clic sulla scheda TSDB per view la pagina a schede Impostazioni TSDB.
3. Per eliminare il nodo guasto, nella pagina a schede Impostazioni TSDB, fare clic sulla X accanto al nome del nodo TSDB guasto.
   NOTA: Si consiglia di eliminare i nodi TSDB durante una finestra di manutenzione poiché alcuni servizi verranno riavviati e la GUI di Paragon Automation non risponderà mentre viene eseguito il lavoro di TSDB.
4. Fare clic su Salva e distribuisci.
5. Se le modifiche non vengono distribuite e se si verifica un errore durante la distribuzione, abilitare il pulsante di attivazione/disattivazione Forza e confermare le modifiche facendo clic su Salva e distribuisci. In questo modo, il sistema ignora l'errore riscontrato durante la regolazione delle impostazioni TSDB.

• Se disinstalli completamente Paragon Automation, devi anche assicurarti che la directory /var/lib/rook venga rimossa su tutti i nodi e che tutti i dispositivi a blocchi Ceph vengano cancellati.
  Soluzione alternativa: vedere il Risoluzione dei problemi di Ceph e Rook > Ripara un disco guasto sezione nella Guida all'installazione di Paragon Automation.
• Durante l'installazione di Paragon Automation utilizzando il metodo air-gap, si verifica il seguente errore:

Soluzione alternativa: modificare le seguenti variabili di configurazione in config-dir/config.yml file e quindi installare Paragon Automation utilizzando il metodo air-gap:

Generale

• L'output del comando deploy-federated-exchange indica che l'installazione non è riuscita quando si configura il ripristino di emergenza in una distribuzione a doppio cluster. Puoi ignorare il messaggio di errore ma devi eseguire il seguente comando su tutti i nodi primari di entrambi i cluster:Soluzione alternativa: nessuna.
• Quando un guasto colpisce entrambe le diverse coppie di LSP, il Path Computation Server (PCS) non instraderà gli LSP lungo il percorso del livello di diversità minore o lungo il percorso non diversificato. Gli LSP non vengono instradati finché il PCS non trova un percorso corrispondente al livello di diversità configurato.
  Soluzione alternativa: nessuna
• Quando un guasto colpisce entrambe le diverse coppie di LSP, il Path Computation Server (PCS) non instraderà gli LSP lungo il percorso non diversificato. Gli LSP non vengono instradati finché il PCS non trova un percorso corrispondente al livello di diversità configurato.
  Soluzione alternativa: rimuovere e riapplicare il gruppo di diversità.
• Il valore della soglia di variazione minima nelle impostazioni di dimensionamento della larghezza di banda di un subLSP del contenitore viene visualizzato come 0 nonostante sia stato configurato nel contenitore. In condizioni normali, non vi è alcun impatto sul dimensionamento della larghezza di banda del subLSP poiché l'attività di dimensionamento della larghezza di banda recupera questo valore dal contenitore anziché dal subLSP. Tuttavia, in alcuni scenari, è possibile che il subLSP possa essere ridimensionato al nuovo valore di larghezza di banda quando la soglia di variazione minima configurata non è stata superata.
  Per ulteriori dettagli su questo problema, contattare il Centro di assistenza tecnica Juniper Networks (JTAC).
• Durante il dimensionamento della larghezza di banda, un LSP secondario attivo con il dimensionamento della larghezza di banda abilitato potrebbe non essere ridimensionato. Quando si verifica questo problema, l'utilizzo RSVP dei collegamenti nel percorso secondario potrebbe essere aggiornato in modo errato.
  Soluzione alternativa: nessuna.
• Apportare modifiche alle impostazioni di Paragon Pathfinder (Configurazione > Impostazioni di rete) utilizzando l'interfaccia utente potrebbe richiedere più di un tentativo affinché la modifica abbia effetto. Potrebbe essere necessario fare clic su Salva più di una volta.
  Soluzione alternativa: le stesse modifiche potrebbero essere apportate utilizzando la CLI cMGD accessibile dal nodo master che esegue il comando pf-cmgd.
• In determinate condizioni durante la normalizzazione del contenitore, uno o più subLSP del contenitore che avrebbero dovuto essere rimossi continueranno a rimanere. Questi subLSP del contenitore rimarranno nella rete come LSP indipendenti non associati al contenitore. Una mancata corrispondenza nel numero di subLSP di un contenitore indicato nella colonna subLSP nella scheda Container LSP e nel numero effettivo di LSP aventi il ​​nome del contenitore come prefisso nella scheda Tunnel, potrebbe essere considerata un'indicazione di questo problema.
  Per ulteriori dettagli su questo problema, contattare il Centro di assistenza tecnica Juniper Networks (JTAC).
• Il contenitore LSP può essere configurato con impostazioni di dimensionamento della larghezza di banda ereditate dai suoi subLSP. In determinate circostanze, quando un utente disabilita l'opzione di dimensionamento della larghezza di banda nel contenitore dopo averla abilitata in passato, questa non viene disabilitata nei subLSP esistenti.
  Soluzione alternativa: nessuna.
• Il riapprovvigionamento manuale di un subLSP del contenitore comporterebbe l'aggiunta di dati all'oggetto LSP. Di conseguenza, potrebbero verificarsi i seguenti problemi:
• Se il contenitore è abilitato al dimensionamento della larghezza di banda ed è configurata una soglia di variazione minima diversa da zero, il subLSP specifico potrebbe essere ridimensionato nonostante il traffico attraverso il subLSP non superi la larghezza di banda segnalata almeno del valore di soglia di variazione minima.
• Il subLSP potrebbe avere impostazioni di dimensionamento della larghezza di banda diverse rispetto al contenitore se le impostazioni di dimensionamento della larghezza di banda del contenitore vengono modificate successivamente.
• Errore nella rimozione del subLSP durante la normalizzazione del contenitore quando la larghezza di banda scende al di sotto della larghezza di banda di fusione.
  Per ulteriori dettagli su questo problema e sulle istruzioni per rimuovere i dati aggiuntivi che vengono aggiunti allo stato interno, contattare il Centro di assistenza tecnica di Juniper Networks (JTAC).
• In determinati scenari, ad esempio un errore di normalizzazione del contenitore per mancanza di percorsi disponibili, uno stato interno aggiuntivo verrebbe aggiunto agli oggetti subLSP del contenitore che potrebbero portare ai seguenti problemi:
• Se il contenitore è abilitato al dimensionamento della larghezza di banda ed è configurata una soglia di variazione minima diversa da zero, il subLSP specifico potrebbe essere ridimensionato nonostante il traffico attraverso il subLSP non superi la larghezza di banda segnalata almeno del valore di soglia di variazione minima.
• Il subLSP potrebbe avere impostazioni di dimensionamento della larghezza di banda diverse rispetto al contenitore se le impostazioni di dimensionamento della larghezza di banda del contenitore vengono modificate successivamente.
• Errore nella rimozione del subLSP durante la normalizzazione del contenitore quando la larghezza di banda scende al di sotto della larghezza di banda di fusione.

Per ulteriori dettagli su questo problema e sulle istruzioni per rimuovere i dati aggiuntivi che vengono aggiunti allo stato interno, contattare il Centro di assistenza tecnica di Juniper Networks (JTAC).

• Quando uno o più nodi in un cluster Kubernetes funzionante non sono disponibili, potrebbe verificarsi il seguente comportamento imprevisto:
• Lo stato PCEP di tutti i nodi viene visualizzato come inattivo anche se lo stato della connessione PCEP è attivo sul router.
• Topologia di rete non visualizzata nell'interfaccia utente.
  Per ulteriori dettagli su questo problema, contattare il Centro di assistenza tecnica Juniper Networks (JTAC).
• Paragon Pathfinder potrebbe calcolare un percorso che viola il vincolo di hop massimo configurato nel tunnel. Questi scenari spiegano come viene annullato il vincolo di hop massimo:
• Quando il Path Computation Server (PCS) si riavvia, viene effettuato il provisioning dell'LSP inattivo senza considerare il vincolo di hop massimo.
• Durante un guasto della rete, l'LSP viene reindirizzato senza considerare il vincolo massimo dell'hop.
• Durante l'ottimizzazione del percorso, l'LSP viene ottimizzato senza considerare il vincolo di hop massimo.
  Soluzione alternativa: utilizzare l'opzione di nuovo provisioning se è disponibile un percorso alternativo che non viola il vincolo configurato.
• Il percorso calcolato da Paragon Pathfinder per un LSP in standby con vincolo di hop massimo potrebbe violare il vincolo configurato.
  Soluzione alternativa: nessuna.
• Esiste la possibilità che il PCS non riesca a trovare LSP con diversità di collegamento in una topologia che ha più collegamenti paralleli tra i nodi.
  Soluzione alternativa: nessuna.
• Quando la sessione PCEP è disabilitata, lo stato operativo dell'LSP passerà allo stato sconosciuto dopo l'esecuzione della raccolta dei dispositivi.
  Soluzione alternativa: nessuna.
• Un collegamento potrebbe scomparire durante la creazione di un'attività di archivio di rete.
  Soluzione alternativa: creare una nuova attività di archiviazione di rete.
• Impossibile instradare la richiesta VPN a causa di problemi nella rete.
  Soluzione alternativa: nessuna.
• Gli allarmi non rispondono quando i dispositivi Cisco sono inizialmente configurati con NETCONF sulla porta 22.
  Soluzione alternativa: modificare la porta NETCONF sul dispositivo Cisco in e assicurati che le modifiche vengano salvate. Successivamente, ripristinare le impostazioni della porta sulla porta 22.
• Quando aggiungi richieste multicast nella GUI, il campo del nodo Z è vuoto.
  Soluzione alternativa: nessuna.
• Quando aggiungi più nuovi tunnel, vengono visualizzati i valori del traffico dei tunnel precedentemente eliminati (che erano memorizzati nella cache).
  Soluzione alternativa: nessuna.
• Quando aggiungi nuovi tunnel diversi, a volte vengono visualizzati i valori del traffico dei tunnel precedentemente eliminati (che erano memorizzati nella cache).
  Soluzione alternativa: nessuna.
• Il Toposerver non cancella né aggiorna la topologia dopo aver perso la connessione al pod BMP.
  Soluzione alternativa: nessuna.
• Quando un collegamento è inattivo, Paragon Pathfinder non reindirizza un LSP SR delegato con il metodo di routing Explicit Route Object (ERO) e Route By Device preferito.
  Soluzione alternativa: utilizzare il metodo di routing predefinito.
• Se si esegue una simulazione direttamente dopo aver eseguito un Diverse Multicast Tree Design, il report in Tunnel Traffic on Links (Tunnel Layer Simulation Report > Peak Network Statistics) non è corretto.
  Soluzione alternativa: salvare la rete dopo aver eseguito Diverse Multicast Tree Design e chiuderla. Riaprire la rete ed eseguire la simulazione.
• Durante la simulazione di scenari di guasto (Strumenti > Opzioni > Simulazione guasti), se si esegue prima una simulazione di guasti multipli e poi si esegue una simulazione di guasto singolo, il report in Traffico tunnel sui collegamenti (Report Simulazione layer tunnel > Statistiche di rete di picco) non è corretto. Il report visualizza più valori di simulazione del guasto anziché un singolo guasto.
  Soluzione alternativa: deselezionare tutte le opzioni nella scheda Errori multipli prima di simulare un singolo scenario di errore.
• Il report di simulazione dell'utilizzo del collegamento potrebbe mostrare valori negativi durante lo scenario di doppio errore.
  Soluzione alternativa: nessuna.
• Quando il nome host di un dispositivo viene modificato, la modifica non si riflette su tutti i database.

Soluzione alternativa: eseguire i passaggi seguenti in modo che il nuovo nome host del dispositivo venga riflesso in tutti i database e componenti.

1. Prima di modificare il nome host, rimuovi il dispositivo da tutti i gruppi di dispositivi (controller o altri playbook).
2. Assicurarsi che i riferimenti al dispositivo vengano eliminati da tutti i diversi componenti di Paragon Automation. Passare alla pagina Configurazione > Dispositivi.
   UN. Seleziona il dispositivo.
   B. Fare clic sull'icona del cestino per eliminare il dispositivo. Viene visualizzata la pagina Elimina dispositivo.
   C. Seleziona Forza eliminazione e fai clic su Sì.
3. Effettuare nuovamente l'onboarding del dispositivo utilizzando il flusso di lavoro di onboarding del dispositivo dalla pagina Configurazione > Dispositivi.
   Il dispositivo dovrebbe ora essere integrato con il nuovo nome host. Dovrebbero essere aggiornate anche le proprietà del dispositivo, in particolare system-id (importante per ricevere i flussi JTI).
4. Aggiungi nuovamente il dispositivo con il nuovo nome host ai gruppi di dispositivi.
5. (Facoltativo) Verifica tutte le statistiche del dispositivo in Influxdb utilizzando Grafana o sulla CLI del dispositivo. Il database dovrebbe essere aggiornato con il nuovo nome host.

• Il metodo di provisioning Network Configuration Protocol (NETCONF) per LSP punto-multipunto (P2MP) non è supportato nei router Cisco IOS-XR.
• Sui router Cisco IOS-XR, lo stato LSP secondario P2MP non è supportato nello stato di configurazione per gli LSP P2MP con provisioning CLI.
  Soluzione alternativa: nessuna.
• Junos OS versione 22.4R1 e successive presentano una limitazione con gli LSP SR-TE.
  Per stabilire le sessioni PCEP, è necessario disabilitare la funzionalità multipath utilizzando il seguente comando: set protocols pcep Disable-multipath-capability Il percorso secondario non è supportato.
•  I vecchi messaggi in coda verranno elaborati dopo il ripristino del collegamento alla federazione.
  Soluzione alternativa: impostare il tempo di scadenza della coda del collegamento della federazione vicino al tempo di rilevamento dell'errore del collegamento della federazione Toposerver (l'impostazione predefinita è 3*5 s).
• Non è possibile utilizzare i metodi NETCONF e PCEP (Path Computation Element Protocol) per eseguire il provisioning di LSP P2MP per i router Cisco IOS-XR utilizzando l'interfaccia utente di Paragon Automation.
  Soluzione alternativa. Fornire gli LSP P2MP utilizzando la CLI. Una volta analizzata la configurazione, eseguire un'attività di raccolta dispositivi su view gli LSP.
•  Non è possibile disabilitare il flag dell'origine della verità quando la distribuzione è in modalità provvisoria.
  Soluzione alternativa: riavviare il pod toposerver per disabilitare il flag dell'origine della verità durante la modalità provvisoria.
• Quando si selezionano più percorsi delegati con commutazione di etichetta (LSP) appartenenti a un singolo router di ingresso e si fa clic su Restituisci delega a PCC, solo uno degli LSP diventa controllato dal dispositivo. Un problema in Junos causa questo scenario.
  Soluzione alternativa: selezionare un LSP alla volta e fare clic su Restituisci delega a PCC individualmente per ciascun LSP.
• Lo stato operativo di un LSP SR-TE delegato rimane inattivo dopo il riscoperto del nodo di destinazione.
  Soluzione alternativa: è necessario sincronizzare il modello di rete dopo il riscoperto del nodo di destinazione LSP SR-TE delegato.
• Il server PCE non è in grado di riconnettersi a coniglimq dopo il riavvio di coniglimq.
  Soluzione alternativa: riavviare il pod ns-pceserver.
• Non è possibile modificare l'impostazione use-federated-exchange dall'API/interfaccia utente REST.
  Soluzione alternativa: modificare l'impostazione use-federated-exchange direttamente dalla CLI cMGD e riavviare il toposerver affinché la modifica abbia effetto.
• Paragon Insights mappa il campo Nome (nome host o indirizzo IP) al campo ID dispositivo. Tuttavia, il nome del dispositivo non è più univoco per i seguenti motivi:
• In un dispositivo con doppio motore di routing, al nome del dispositivo viene aggiunto "-reX".
• Applicazioni di terze parti come Anuta Atom aggiungono il nome di dominio al nome del dispositivo.
  Inoltre, la mappatura di un dispositivo tramite il suo identificatore univoco universale (UUID) e non tramite il nome host potrebbe causare problemi con le informazioni visualizzate dalla GUI.
  Soluzione alternativa: configurare un indirizzo IP aggiuntivo per l'interfaccia Ethernet di gestione sul dispositivo includendo l'istruzione solo master al livello gerarchico [modifica gruppi]. È quindi necessario utilizzare questo indirizzo IP aggiuntivo per l'onboarding del dispositivo. Per ulteriori informazioni, vedere Interfacce Ethernet di gestione.
• Se hai dedicato un nodo per TSDB, alcuni servizi (ad esample, AtomDB, ZooKeeper e così via) nello spazio dei nomi comune con PersistentVolumeClaim impostato può essere influenzato se i pod pertinenti sono in esecuzione sul nodo dedicato. Cioè, lo stato dei pod in esecuzione sul nodo TSDB viene sempre visualizzato come In sospeso.
  Soluzione alternativa: per evitare questa situazione, mentre dedichi un nodo per TSDB, assicurati che il nodo non disponga di pod per servizi dedicati che utilizzano PersistentVolumeClaim.
• Quando si annulla la delega di un LSP delegato, la larghezza di banda pianificata dell'LSP si basa sulla larghezza di banda segnalata dal dispositivo anziché sul valore immesso dall'utente.
  Soluzione alternativa: nessuna.
• Durante l'aggiunta di un dispositivo, se specifichi un indirizzo IP di origine già utilizzato in una rete, potresti non essere in grado di aggiungere il dispositivo a un gruppo di dispositivi, distribuire un playbook, riscontrare errori relativi all'acquisizione di funzioni e così via.
  Soluzione alternativa: correggere l'indirizzo IP di origine in conflitto. Fare clic sull'icona Stato distribuzione e confermare le modifiche.
• Se selezioni una query salvata nella pagina Allarmi, gli allarmi vengono filtrati in base alla query salvata. Ma il grafico e la data non vengono aggiornati.
  Soluzione alternativa: nessuna.
• Se aggiungi un dispositivo non gestito nella pagina Dispositivo e successivamente modifichi il nome host del dispositivo non gestito, il nome host non si riflette nel gruppo di dispositivi e nel dashlet Dispositivi sulla dashboard.
  Soluzione alternativa: è possibile aggiungere un dispositivo non gestito utilizzando il nome host o l'indirizzo IP di un dispositivo.
  Se hai aggiunto un dispositivo non gestito utilizzando il nome host, l'eliminazione del dispositivo esistente e l'aggiunta del dispositivo con un nuovo nome host risolve il problema.
  Se hai aggiunto un dispositivo non gestito utilizzando l'indirizzo IP, nel gruppo di dispositivi e nel dashlet Dispositivi sulla dashboard devi identificare i dispositivi non gestiti in base all'indirizzo IP e non al nome host.
• Per impostazione predefinita, il filtro della topologia è disabilitato. Non è possibile abilitare il filtro della topologia utilizzando la GUI di Paragon Automation.
  Soluzione alternativa: per la procedura per abilitare il filtro della topologia, vedere l'argomento Abilitare il servizio filtro della topologia.
• Per i dispositivi Cisco IOS XR, non è possibile ripristinare la configurazione di un dispositivo dalla pagina Dispositivi. È possibile eseguire solo il backup della configurazione del dispositivo.
  Soluzione alternativa: per ripristinare la configurazione dei dispositivi Cisco IOS XR:
  1. Nella pagina Configurazione > Dispositivi, selezionare il dispositivo Cisco XR e fare clic su Altro > Versione configurazione.
  2. Copia la versione della configurazione che desideri ripristinare.
  3. Ripristinare la configurazione utilizzando la CLI.
• Se hai abilitato SSH in uscita a livello di gruppo di dispositivi, non puoi disabilitare SSH in uscita per uno dei dispositivi nel gruppo di dispositivi.
  Soluzione alternativa: è possibile abilitare o disabilitare l'SSH in uscita sul dispositivo utilizzando la CLI MGD o le API Rest. Per disabilitare l'SSH in uscita è necessario impostare il flag di disabilitazione su true. Esegui il comando seguente sul dispositivo per disabilitare l'SSH in uscita utilizzando la CLI MGD: set Healthbot DeviceName outbound-ssh Disable true
• Non è possibile scaricare tutti i registri di servizio dalla GUI di Paragon Automation.
  Soluzione alternativa: puoi view tutti i log del servizio in Elastic Search Database (ESDB) e Grafana. Per accedere a Grafana o ESDB, è necessario configurare una password nel campo grafana_admin_password nel config.yml file prima dell'installazione.
• Se si modifica un LSP esistente o si utilizza un ID di sezione come uno dei criteri di instradamento, il percorso preview potrebbe non apparire correttamente.
  Soluzione alternativa: una volta eseguito il provisioning del percorso, il percorso rispetta i vincoli dell'ID sezione e viene visualizzato correttamente nel percorso preview.
• Se esegui il provisioning di un LSP con instradamento di segmenti utilizzando PCEP, la funzionalità del colore non funziona.
  Questo problema si verifica se il router è in esecuzione sulla versione 20.1R1 del sistema operativo Junos.
  Soluzione alternativa: aggiornare il sistema operativo Junos alla versione 21.4R1.
• I microservizi non riescono a connettersi a PostgresSQL poiché PostgresSQL non accetta alcuna connessione durante il passaggio del ruolo primario. Questo è uno stato transitorio.
  Soluzione alternativa: assicurarsi che i microservizi si connettano a PostgresSQL dopo il completamento del passaggio del ruolo primario.
  • Il database Postgres diventa non operativo in alcuni sistemi, il che porta a un errore di connessione.
  Soluzione alternativa: eseguire il comando seguente nel nodo primario: for pod in atom-db-{0..2}; Fare
  kubectl exec -n common $pod — chmod 750 /home/postgres/pgdata/pgroot/data done
• Il rilevamento dei dispositivi Cisco IOS XR non riesce.
  Soluzione alternativa: aumentare il limite di velocità del server SSH per il dispositivo Cisco IOS XR. Accedi al dispositivo in modalità di configurazione ed esegui il comando seguente:
  RP/0/RP0/CPU0:ios-xr(config)#ssh limite di velocità del server 600
• Se si utilizza BGP-LS per ottenere informazioni sul ritardo del collegamento e sulla variazione del ritardo del collegamento, non è possibile view i dati storici sul ritardo del collegamento.
  Soluzione alternativa: nessuna.
• In rari casi (ad esample, quando Redis si arresta in modo anomalo e viene riavviato automaticamente da Kubernetes oppure è necessario riavviare il server Redis), alcune informazioni sulle interfacce vengono perse e le interfacce non sono elencate nella scheda Interfaccia della tabella delle informazioni di rete. Tuttavia, questo problema non influisce sul calcolo del percorso, sulle statistiche o sul provisioning dell'LSP.
  Soluzione alternativa: per ripristinare le interfacce nel modello di rete attiva, eseguire nuovamente l'attività di raccolta dei dispositivi.
• Nella scheda Attività delle pagine Aggiungi nuovo flusso di lavoro e Modifica flusso di lavoro:
• Anche se fai clic sull'opzione Annulla, le modifiche apportate durante la modifica di un'attività verranno salvate.
• Non puoi riutilizzare il nome di un passaggio che hai già eliminato.
• Non verrà visualizzato un messaggio di errore anche quando si aggiunge un passaggio con voci vuote e si fa clic su Salva e distribuisci.
  Soluzione alternativa: nessuna.
• Aggiornamento di alcuni dispositivi PTX di fascia bassa con la modalità Dual RE (ad esample, PTX5000 e PTX300) non è supportato in Paragon Automation. Questo perché i dispositivi PTX di fascia bassa con modalità Dual RE non supportano la configurazione bridging o bridge domain.
  Soluzione alternativa: nessuna.
• L'API POST /traffic-engineering/api/topology/v2/1/rpc/diverseTreeDesign non funziona.
  Soluzione alternativa: ti consigliamo di utilizzare l'API POST /NorthStar/API/v2/tenant/1/topology/1/rpc/ diverseTreeDesign.
• Paragon Automation non mostra gli allarmi per i dispositivi Nokia.
  Soluzione alternativa: nessuna.
• Durante la configurazione di un LSP SRv6 con il metodo di routing come routeByDevice, è necessario specificare un valore per l'oggetto routing-Explicit Route del segmento (SR-ERO); in caso contrario, non è possibile utilizzare l'LSP SRv6 per trasportare il traffico.
  Soluzione alternativa: durante l'aggiunta di un tunnel, nella scheda Percorso, aggiungere hop per specificare il tipo di instradamento richiesto o preferito.
• Se dalla rete viene rilevato un LSP SRv6 controllato dal dispositivo, il percorso evidenziato per questo LSP sarà errato indipendentemente dal fatto che si specifichi o meno un oggetto di instradamento esplicito (ERO) per l'instradamento.
  Soluzione alternativa: nessuna.
• A volte, potresti non essere in grado di eliminare in blocco gli LSP di instradamento dei segmenti.
  Soluzione alternativa: è possibile forzare l'eliminazione degli LSP che non vengono eliminati durante il processo di eliminazione in blocco.
•  Nella GUI di Paragon Automation, nella scheda Attività delle pagine Aggiungi nuovo flusso di lavoro e Modifica flusso di lavoro, viene visualizzato il seguente messaggio di errore quando si tenta di modificare e salvare un passaggio esistente senza apportare modifiche:
  Il nome esiste già
  Soluzione alternativa: se hai erroneamente fatto clic sull'opzione Modifica, assicurati di modificare almeno il nome del passaggio.
• La sessione PCEP a volte viene visualizzata come Inattiva se riavvii tutti i pod nello spazio dei nomi northstar.
  Soluzione alternativa: riavviare il server della topologia utilizzando kubectl delete pods ns-toposerver- -n comando stella polare.
• Nella pagina Amministrazione > Gestione licenze non è possibile view il nome SKU di una licenza quando si seleziona la licenza e quindi si seleziona Altro > Dettagli.
  Soluzione alternativa: nessuna.
• Il grafico nella pagina Allarmi non riflette i dati più recenti. Cioè, il grafico non viene aggiornato dopo che un allarme non è più attivo.
  Soluzione alternativa: nessuna.
• Quando si configura l'SSH in uscita per iAgent, i dati per la regola configurata non verranno generati.
  Soluzione alternativa: nessuna.
• Se è stato configurato il protocollo Two-Way Active Management Protocol (TWAMP). Questo non è corretto perché TWAMP non supporta l'esportazione della perdita di pacchetti per l'ingegneria del traffico IS-IS.
  Soluzione alternativa: nessuna.
• Se si utilizza un dispositivo con schede di linea MPC10+ e se il dispositivo è in esecuzione su una versione del sistema operativo Junos diversa dalla versione 21.3R2-S2 o dalla versione 21.4R2-S1, le statistiche per le interfacce logiche non vengono raccolte. Tuttavia, vengono raccolte le statistiche per le interfacce fisiche e gli LSP.
  Soluzione alternativa: aggiornare la versione del sistema operativo Junos alla versione 21.3R2-S2 o 21.4R2-S1. Inoltre, assicurati di aver aggiornato Paragon Automation alla versione 23.1.
• Quando si annulla la delega di un LSP, lo stato dell'LSP viene visualizzato come delegato. Quando si tenta di annullare nuovamente la delega dell'LSP, la configurazione del router potrebbe essere modificata per aggiungere oggetti di percorso espliciti (ERO).
  Soluzione alternativa: aggiornare la scheda Tunnel prima di annullare nuovamente la delega dell'LSP.
• Paragon Pathfinder non disattiva un LSP SR delegato quando l'LSP SR non soddisfa i vincoli di sezione se lo stato dell'LSP SR è instradato localmente.
• Se crei un gruppo di topologia con ID di sezione maggiore o uguale a 2**32, l'ID del gruppo di topologia non corrisponderà all'ID di sezione.
• Il cluster Paragon Automation Kubernetes utilizza certificati gestiti da kubeadm generati automaticamente.
  Questi certificati scadono dopo un anno dalla distribuzione, a meno che la versione Kubernetes non venga aggiornata o i certificati non vengano rinnovati manualmente. Se i certificati scadono, i pod non vengono attivati ​​e visualizzano errori di certificati errati nel log.
  Soluzione alternativa: rinnovare manualmente i certificati. Eseguire i seguenti passaggi per rinnovare i certificati:

1. Controlla la data di scadenza dei certificati correnti utilizzando il comando kubeadm certs check-expiration su ogni nodo primario del tuo cluster.
2. Per rinnovare i certificati, utilizza il comando kubeadm certs renew all su ogni nodo primario del tuo cluster Kubernetes.
3. Ricontrolla la data di scadenza utilizzando il comando kubeadm certs check-expiration su ciascun nodo primario del cluster.
4. Riavvia i seguenti pod da uno qualsiasi dei nodi primari per utilizzare i nuovi certificati.

Problemi risolti

Questa sezione elenca i problemi risolti in Juniper Paragon Automation Release 24.1

• Gli LSP a coppia simmetrica potrebbero non essere instradati simmetricamente al momento del reindirizzamento che attraversa la soglia.
  Soluzione alternativa: nessuna.
• I grafici del traffico sono ora supportati per i dispositivi con doppi motori di routing onboarded con re0 o re1 come suffisso ai relativi nomi host. Tuttavia, i grafici sono supportati solo se i suffissi del nome host sono in minuscolo e nel formato -re0 o -re1. Per esampfile: vmx101-re0 o vmx101-re1
  Soluzione alternativa: nessuna
• I siti controller non sono inclusi nell'archivio di rete per Paragon Planner.
  Soluzione alternativa: nessuna.
• Lo stato della modalità provvisoria è sempre falso quando ns-web il pod si avvia.
  Soluzione alternativa: nessuna.
• Viene visualizzato uno stato di modalità provvisoria non corretto dopo aver modificato il flag dell'origine della verità durante la modalità provvisoria.
  Soluzione alternativa: nessuna.
• A volte i dispositivi con NETCONF disabilitato vengono visualizzati con lo stato NETCONF Su.
  Soluzione alternativa: modificare il dispositivo Profile senza alcuna modifica per attivare il ricaricamento del dispositivo profile.
• Il colore per gli LSP SR-TE provenienti da dispositivi Cisco IOS-XR è visibile solo se l'LSP viene inizialmente rilevato dalla raccolta dei dispositivi.
  Soluzione alternativa: nessuna.
• Il gruppo di amministrazione di un LSP SR-TE appreso da PCEP scompare dopo la sincronizzazione della topologia, se l'LSP ha configurato lo stato.
  Soluzione alternativa: modificare SR-TE LSP per rendere persistente il gruppo di amministratori appreso da PCEP.
• Gli LSP sul percorso ottimale potrebbero ricevere aggiornamenti PCEP non necessari durante l'ottimizzazione PCS.
  Soluzione alternativa: nessuna.
• Un errore nella funzionalità di diagnostica (Configurazione > Acquisizione dati > Diagnostica > Applicazione) causa il fallimento dei test dell'applicazione.
  Soluzione alternativa: nessuna.
• Nella scheda Rete > Topologia > Tunnel, quando passi il mouse sull'icona Filtro (imbuto) e selezioni Aggiungi filtro, viene visualizzata la pagina Aggiungi criteri. Se si seleziona Colore nell'elenco Campo, il valore del campo viene visualizzato come PlannedProperties anziché Colore.
  Soluzione alternativa: nessuna.
• Il report di analisi del percorso è vuoto.

Soluzione alternativa: eseguire un'attività di raccolta dispositivi prima di eseguire l'analisi del percorso. Tieni presente che il report di analisi del percorso può essere vuoto se gli LSP si trovano già sul percorso ottimale.

Juniper Networks, il logo Juniper Networks, Juniper e Junos sono marchi registrati di Juniper Networks, Inc. negli Stati Uniti e in altri paesi. Tutti gli altri marchi, marchi di servizio, marchi registrati o marchi di servizio registrati sono di proprietà dei rispettivi proprietari. Juniper Networks non si assume alcuna responsabilità per eventuali inesattezze presenti nel presente documento. Juniper Networks si riserva il diritto di cambiare, modificare, trasferire o altrimenti rivedere questa pubblicazione senza preavviso. Copyright © 2024 Juniper Networks, Inc. Tutti i diritti riservati.

Documenti / Risorse

RETI Juniper Paragon Software di automazione [pdf] Guida utente Software di automazione Paragon, software di automazione, software

Riferimenti

• Manuale d'uso