Paragon Automation, verze 24.1

Nejdůležitější body softwaru

• Podpora pro RHEL 8.10
• Možnost pro uživatele bez oprávnění root spouštět příkazy v obslužném programu paragon CLI
• Schopnost poskytovat zásady směrování segmentů na zařízeních Cisco IOS XR pomocí NETCONF

Zavedení

Juniper® Paragon Automation je cloudové řešení pro plánování, konfiguraci, zřizování, řízení provozu, monitorování a správu životního cyklu sítě, které přináší pokročilé možnosti vizualizace a analýzy do správy a monitorování sítě. Paragon Automation můžete nasadit jako místní aplikaci (spravovanou zákazníkem).
Paragon Automation funguje na architektuře založené na mikroslužbách a využívá REST API, gRPC API a běžné komunikační sběrnice pro zasílání zpráv. Paragon Automation poskytuje funkce základní platformy, jako je podpora pro Juniper Networks a zařízení třetích stran (Cisco IOS XR, Nokia), zerotouch provisioning, správa uživatelů a řízení přístupu na základě rolí (RBAC).
Kromě poskytování funkcí základní platformy nabízí Paragon Automation sadu aplikací založených na mikroslužbách – Juniper® Paragon Insights (dříve HealthBot), Juniper® Paragon Planner (dříve NorthStar Planner) a Juniper® Paragon Pathfinder (dříve NorthStar Controller).
Když do Paragon Automation přidáte kteroukoli z těchto aplikací, sada API aplikace se integruje s Paragon Automation a umožní bezproblémovou komunikaci mezi novými a stávajícími službami. V těchto poznámkách k vydání nastíníme nové funkce základní platformy, modulů Paragon Pathfinder, Paragon Planner (desktopová aplikace) a Paragon Insights, které jsou dostupné v tomto vydání. Další informace o funkcích souvisejících s těmito aplikacemi naleznete v Uživatelské příručce Paragon Automation.
Pomocí těchto poznámek k vydání najdete nové a aktualizované funkce, softwarová omezení a otevřené problémy v Paragon Automation Release 24.1.

Pokyny k instalaci a upgradu

Informace o postupu instalace, postupu upgradu a požadavcích (software a
hardware), viz Průvodce instalací Paragon Automation.

POZNÁMKA:
Můžete přímo upgradovat pouze z verze Paragon Automation 23.2 na verzi 24.1. Pokud je vaše vydání starší než verze 23.2, musíte verzi 24.1 nainstalovat znovu. Chcete-li však migrovat konfiguraci aktuálního vydání na verzi 24.1, můžete použít funkci zálohování a obnovení. Další informace o upgradu najdete v Upgrade na Paragon Automation Release 24.1.

Licencování

V Paragon Insights jsme zavedli následující úrovně licencí a související licence zařízení:

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

V současné době jsou úrovňové licence tvrdě vynucovány. To znamená, že nemůžete provést operaci nasazení, dokud nepřidáte licence.
Licence zařízení jsou vynuceny soft-vynucené. To znamená, že pokud se pokusíte nasadit více zařízení, než je počet, pro který jste získali licence, obdržíte upozornění na nesoulad v GUI Paragon Automation.
Můžete však nadále používat stávající funkce.
Můžete view stav shody s licencí na stránce Administrace > Správa licencí v GUI.
V Paragon Pathfinder jsme tvrdě prosadili následující úrovně licencí:

• Pathfinder Standard
• Pathfinder Advanced
• Pathfinder Premium

Informace o licencování viz Průvodce licencí.
Pokud máte licenční klíč, který byl vygenerován pro verzi Paragon Automation dříve než Release
22.1 budete muset upgradovat formát licenčního klíče na nový formát, než jej budete moci nainstalovat v Paragon Automaton Release 24.1. Nový licenční klíč můžete vygenerovat pomocí portálu Juniper Agile Licensing. Další informace o generování nového licenčního klíče viz View, Přidat nebo Smazat licence.

Nové a změněné funkce

Tato část popisuje funkce jednotlivých modulů Juniper Paragon Automation Release 24.1.
Instalace a upgrade Paragon

• Red Hat Enterprise Linux (RHEL) 8.10 – Paragon Automation Release 24.1 je kvalifikován pro práci s RHEL 8.10.
  [Vidět Předpoklady instalace na Red Hat Enterprise Linux.]
• Spouštění příkazů obslužného programu Paragon CLI jako uživatel bez oprávnění root – Počínaje verzí Paragon Automation 24.1 může uživatel bez oprávnění root s oprávněními superuser (sudo) spouštět příkazy obslužného programu Paragon CLI k analýze, dotazování a ladění nastavení Paragon Automation.
  [Vidět Odstraňování problémů s použitím paragon CLI Utility.]

Paragon Pathfinder

• Poskytování zásad směrování segmentů na zařízeních Cisco IOS XR – Počínaje verzí Paragon Automation 24.1 můžete na zařízeních Cisco IOS XR poskytovat zásady směrování segmentů pomocí NETCONF jako metody zřizování.

Základní platforma
Do Paragon Automation Release 24.1 jsme nepřidali žádné nové funkce související se základní platformou.
Paragon Insights
Do Paragon Automation Release 24.1 jsme nepřidali žádné nové funkce související s Paragon Insights.
Paragon Planner
Do Paragon Automation Release 24.1 jsme nepřidali žádné nové funkce související s Paragon Plannerem.
POZNÁMKA: Paragon Planner Web Aplikace je beta funkce v Paragon Automation Release 24.1.

Zastaralé funkce

V této části jsou uvedeny funkce, které jsou zastaralé nebo pro které byla z Paragonu stažena podpora
Vydání automatu 24.1.
• Uživatelské rozhraní Grafana
Z Paragon Automation nemáte přístup k uživatelskému rozhraní Grafana. Pro přístup k uživatelskému rozhraní Grafana musíte:

1. Nainstalujte Grafana.
   Vidět Dokumentace Grafana pro více informací.
2. Odhalte port TSDB spuštěním příkazu /var/local/healthbot/healthbot tsdb start-services.

POZNÁMKA: V Paragon Automation není port TSDB ve výchozím nastavení vystaven. Chcete-li použít externí nástroje, jako je Grafana, musíte spustit dotaz na TSDB přímo (a ne prostřednictvím rozhraní API), abyste odhalili port TSDB.

Více informací viz Zálohujte a obnovte TSDB.
• Grafy

Známé problémy

Tato část uvádí známé problémy v Juniper Paragon Automation Release 24.1

Instalace

• Když poskytujete virtuální stroje (VM) na serverech VMware ESXi a přidáte blokový úložný disk před přidáním disku se základním OS, Ceph někdy nesprávně identifikuje jednotky a vytvoří cluster pomocí nesprávné jednotky, což má za následek, že základní OS bude zničeno.
  Řešení: Přidejte první disk jako základní OS (větší jednotku) a poté přidejte menší blokový úložný disk.
• Při absenci replikace HA databáze časových řad (TSDB) a pracovní uzel Kubernetes, na kterém běží pod TSDB, selže, i když je v podu kapacita, služba TSDB se na novém uzlu neroztočí. Do nového uzlu by totiž bylo potřeba přenést obrovský objem dat.
  Řešení: V případě selhání serveru nebo úložiště hostujícího instanci TSDB můžete server nebo poškozenou komponentu znovu sestavit.

Pokud je faktor replikace nastaven na 1, data TSDB pro danou instanci budou ztracena. V takovém případě musíte z Paragon Automation odebrat neúspěšný uzel TSDB. Odebrání neúspěšného uzlu TSDB:

1. V rozhraní Paragon Automation GUI vyberte Configuration > Insights Settings.
   Zobrazí se stránka Nastavení statistik.
2. Klepněte na kartu TSDB view stránku s kartami Nastavení TSDB.
3. Chcete-li odstranit neúspěšný uzel, na kartě Nastavení TSDB klikněte na X vedle názvu neúspěšného uzlu TSDB.
   POZNÁMKA: Doporučujeme odstranit uzly TSDB během okna údržby, protože některé služby budou restartovány a grafické uživatelské rozhraní Paragon Automation přestane během práce TSDB reagovat.
4. Klikněte na Uložit a nasadit.
5. Pokud změny nejsou nasazeny a pokud při nasazování dojde k chybě, povolte přepínací tlačítko Vynutit a potvrďte změny kliknutím na Uložit a nasadit. Tím systém ignoruje chybu, ke které došlo při úpravě nastavení TSDB.

• Pokud úplně odinstalujete Paragon Automation, musíte také zajistit, aby byl adresář /var/lib/rook odstraněn ze všech uzlů a všechna bloková zařízení Ceph byla vymazána.
  Řešení: Viz Odstraňování problémů Ceph a Rook > Opravit vadný disk části v Průvodci instalací Paragon Automation.
• Při instalaci Paragon Automation pomocí metody vzduchové mezery dojde k následující chybě:

Řešení: Upravte následující konfigurační proměnné v souboru config-dir/config.yml file a poté nainstalujte Paragon Automation pomocí metody vzduchové mezery:

Generál

• Výstup příkazu deploy-federated-exchange zobrazuje, že instalace selhala, když nakonfigurujete zotavení po havárii v nasazení duálního klastru. Chybovou zprávu můžete ignorovat, ale musíte provést následující příkaz na všech primárních uzlech obou klastrů:Řešení: Žádné.
• Pokud selhání zasáhne oba různé páry LSP, Path Computation Server (PCS) nebude směrovat LSP po cestě nižší úrovně diverzity nebo po nerůzné cestě. LSP nejsou směrovány, dokud PCS nenajde cestu odpovídající nakonfigurované úrovni diverzity.
  Řešení: Žádné
• Pokud selhání zasáhne oba různé páry LSP, Path Computation Server (PCS) nebude směrovat LSP po nerůzné cestě. LSP nejsou směrovány, dokud PCS nenajde cestu odpovídající nakonfigurované úrovni diverzity.
  Řešení: Odstraňte a znovu použijte skupinu pro diverzitu.
• Minimální prahová hodnota variace pod nastavením velikosti šířky pásma kontejneru subLSP je zobrazena jako 0, přestože je konfigurován v kontejneru. Za normálních podmínek nemá žádný vliv na dimenzování šířky pásma subLSP, protože úloha dimenzování šířky pásma načítá tuto hodnotu z kontejneru namísto subLSP. V určitých scénářích je však možné, že velikost subLSP by mohla být změněna na novou hodnotu šířky pásma, když nebyl překročen nakonfigurovaný minimální práh variace.
  Pro více podrobností o tomto problému kontaktujte Juniper Networks Technical Assistance Center (JTAC).
• Během určování velikosti šířky pásma se nemusí změnit velikost aktivního sekundárního LSP, který má povolenou velikost šířky pásma. Když nastane tento problém, může být nesprávně aktualizováno využití RSVP odkazů v sekundární cestě.
  Řešení: Žádné.
• Provádění změn nastavení Paragon Pathfinder (Konfigurace > Nastavení sítě) pomocí uživatelského rozhraní může vyžadovat více než jeden pokus, aby se změna projevila. Možná budete muset kliknout na Uložit více než jednou.
  Řešení: Stejné změny lze provést pomocí cMGD CLI, které je přístupné z hlavního uzlu spouštějícího příkaz pf-cmgd.
• Za určitých podmínek během normalizace kontejneru zůstane jeden nebo více kontejnerových subLSP, které měly být odstraněny, nadále. Tyto subLSP kontejneru zůstanou v síti jako nezávislé LSP, které nejsou spojeny s kontejnerem. Nesoulad v počtu subLSP kontejneru uvedeného ve sloupci subLSP na kartě Container LSP a skutečný počet LSP, které mají název kontejneru jako předponu na kartě Tunnel, lze považovat za indikátor tohoto problému.
  Pro více podrobností o tomto problému kontaktujte Juniper Networks Technical Assistance Center (JTAC).
• Kontejnerový LSP lze konfigurovat s nastavením velikosti šířky pásma, které zdědí jeho subLSP. Za určitých okolností, když uživatel zakáže možnost dimenzování šířky pásma v kontejneru poté, co ji v minulosti povolil, nebude deaktivována ve stávajících subLSP.
  Řešení: Žádné.
• Ruční reprovisioning subLSP kontejneru by vedlo k přidání dat do LSP objektu. V důsledku toho mohou nastat následující problémy:
• Pokud má kontejner povoleno dimenzování šířky pásma a je nakonfigurován nenulový minimální práh variace, může být velikost specifického subLSP změněna navzdory tomu, že provoz přes subLSP nepřekračuje jeho signalizovanou šířku pásma o alespoň minimální prahovou hodnotu variace.
• SubLSP by mohl mít jiné nastavení velikosti šířky pásma než kontejner, pokud se později změní nastavení velikosti šířky pásma kontejneru.
• Selhání při odstraňování subLSP během normalizace kontejneru, když šířka pásma klesne pod slučovací šířku pásma.
  Další podrobnosti o tomto problému a pokyny k odstranění dalších dat, která se přidávají do interního stavu, získáte od centra technické pomoci Juniper Networks (JTAC).
• V určitých scénářích, jako je selhání normalizace kontejneru při nedostatku dostupných cest, by se do objektů subLSP kontejneru přidal další interní stav, což by mohlo vést k následujícím problémům:
• Pokud má kontejner povoleno dimenzování šířky pásma a je nakonfigurován nenulový minimální práh variace, může být velikost specifického subLSP změněna navzdory tomu, že provoz přes subLSP nepřekračuje jeho signalizovanou šířku pásma o alespoň minimální prahovou hodnotu variace.
• SubLSP by mohl mít jiné nastavení velikosti šířky pásma než kontejner, pokud se později změní nastavení velikosti šířky pásma kontejneru.
• Selhání při odstraňování subLSP během normalizace kontejneru, když šířka pásma klesne pod slučovací šířku pásma.

Další podrobnosti o tomto problému a pokyny k odstranění dalších dat, která se přidávají do interního stavu, získáte od centra technické pomoci Juniper Networks (JTAC).

• Když jeden nebo více uzlů ve funkčním clusteru Kubernetes není k dispozici, může to vést k následujícímu neočekávanému chování:
• Stav PCEP všech uzlů je zobrazen jako dolů, ačkoli stav připojení PCEP je na routeru nahoře.
• Topologie sítě není zobrazena v uživatelském rozhraní.
  Pro více podrobností o tomto problému kontaktujte Juniper Networks Technical Assistance Center (JTAC).
• Paragon Pathfinder by mohl vypočítat cestu, která porušuje omezení maximálního skoku, které je nakonfigurováno v tunelu. Tyto scénáře vysvětlují, jak je porušeno omezení maximálního skoku:
• Když se Path Computation Server (PCS) restartuje, je zřízena down LSP bez ohledu na maximální omezení skoku.
• Během selhání sítě je LSP přesměrováno bez ohledu na maximální omezení skoku.
• Během optimalizace cesty je LSP optimalizována bez ohledu na maximální omezení skoku.
  Řešení: Použijte volbu reprovision, pokud je k dispozici alternativní cesta, která neporušuje nakonfigurované omezení.
• Cesta vypočítaná pomocí Paragon Pathfinder pro pohotovostní LSP s maximálním omezením skoku by mohla narušit nakonfigurované omezení.
  Řešení: Žádné.
• Existuje možnost, že PCS není schopen najít LSP s diverzitou spojů v topologii, která má více paralelních spojů mezi uzly.
  Řešení: Žádné.
• Když je relace PCEP zakázána, provozní stav LSP se po spuštění sběru zařízení přesune do neznámého stavu.
  Řešení: Žádné.
• Při vytváření úlohy síťového archivu může odkaz chybět.
  Řešení: Vytvořte novou úlohu síťového archivu.
• Nelze směrovat požadavky VPN kvůli problémům v síti.
  Řešení: Žádné.
• Alarmy nereagují, když jsou zařízení Cisco zpočátku nakonfigurována pomocí NETCONF na portu 22.
  Řešení: Upravte port NETCONF na zařízení Cisco na a ujistěte se, že se změny uloží. Poté vraťte nastavení portu zpět na port 22.
• Když do GUI přidáte požadavky vícesměrového vysílání, pole uzlu Z je prázdné.
  Řešení: Žádné.
• Když přidáte více nových tunelů, zobrazí se hodnoty provozu z dříve odstraněných tunelů (které byly uloženy v mezipaměti).
  Řešení: Žádné.
• Když přidáte nové různé tunely, někdy se zobrazí hodnoty provozu z dříve odstraněných tunelů (které byly uloženy v mezipaměti).
  Řešení: Žádné.
• Toposerver nevymaže ani neaktualizuje topologii po ztrátě spojení s BMP pod.
  Řešení: Žádné.
• Když je linka nefunkční, Paragon Pathfinder nepřesměruje delegovanou SR LSP s preferovanou metodou směrování Explicit Route Object (ERO) a Route By Device.
  Řešení: Použijte výchozí metodu směrování.
• Pokud spustíte simulaci přímo poté, co provedete návrh stromu rozmanitého vícesměrového vysílání, sestava v části Provoz tunelu na odkazech (Zpráva simulace vrstvy tunelu > Statistika špičkové sítě) je nesprávná.
  Alternativní řešení: Po provedení návrhu stromu Diverse Multicast Tree uložte síť a zavřete ji. Znovu otevřete síť a poté spusťte simulaci.
• Pokud při simulaci scénářů selhání (Nástroje > Možnosti > Simulace selhání) nejprve spustíte simulaci vícenásobného selhání a poté spustíte simulaci jediné poruchy, bude zpráva v části Provoz tunelu na spojích (Zpráva simulace vrstvy tunelu > Statistika špičkové sítě) nesprávná. Zpráva zobrazuje více hodnot simulace selhání namísto jedné poruchy.
  Řešení: Před simulací scénáře jednoho selhání zrušte výběr všech možností na kartě Vícenásobné selhání.
• Zpráva o simulaci využití propojení může během scénáře dvojitého selhání vykazovat záporné hodnoty.
  Řešení: Žádné.
• Když se změní název hostitele zařízení, změna se neprojeví ve všech databázích.

Řešení: Proveďte následující kroky, aby se nový název hostitele zařízení projevil ve všech databázích a komponentách.

1. Před změnou názvu hostitele odeberte zařízení ze všech skupin zařízení (ovladač nebo jiné příručky).
2. Ujistěte se, že jsou odkazy na zařízení odstraněny ze všech různých komponent Paragon Automation. Přejděte na stránku Konfigurace > Zařízení.
   A. Vyberte zařízení.
   b. Klepnutím na ikonu koše zařízení smažete. Zobrazí se stránka Odstranit zařízení.
   C. Vyberte Vynutit odstranění a klikněte na Ano.
3. Znovu připojte zařízení pomocí pracovního postupu pro zavedení zařízení ze stránky Konfigurace > Zařízení.
   Zařízení by nyní mělo být připojeno s novým názvem hostitele. Vlastnosti zařízení, zejména system-id (důležité pro příjem toků JTI), by měly být také aktualizovány.
4. Přidejte zařízení s novým názvem hostitele zpět do skupin zařízení.
5. (Volitelné) Ověřte všechny statistiky zařízení v Influxdb pomocí Grafany nebo v CLI zařízení. Databáze by měla být aktualizována novým názvem hostitele.

• Metoda poskytování protokolu NETCONF (Network Configuration Protocol) pro LSP typu point-to-multipoint (P2MP) není podporována ve směrovačích Cisco IOS-XR.
• Na směrovačích Cisco IOS-XR není stav P2MP sub-LSP podporován ve stavu konfigurace pro CLIprovisioned P2MP LSP.
  Řešení: Žádné.
• Junos OS Release 22.4R1 a novější mají omezení s SR-TE LSP.
  Chcete-li navázat relace PCEP, musíte zakázat funkci více cest pomocí následujícího příkazu: set protocols pcep disable-multipath-capability Sekundární cesta není podporována.
•  Po obnovení spojení federace se zpracovávají staré zprávy ve frontě.
  Alternativní řešení: Nastavte čas vypršení fronty federačního propojení blízko času detekce selhání federačního odkazu Toposerer (výchozí je 3*5s).
• Metody NETCONF a PCEP (Path Computation Element Protocol) nelze použít k poskytování P2MP LSP pro směrovače Cisco IOS-XR pomocí uživatelského rozhraní Paragon Automation.
  Řešení. Poskytujte P2MP LSP pomocí CLI. Po analýze konfigurace spusťte úlohu kolekce zařízení view LSP.
•  Pokud je nasazení v nouzovém režimu, nemůžete zakázat příznak source-of-truth.
  Řešení: Restartujte modul toposerer, abyste v nouzovém režimu zakázali příznak zdroje pravdy.
• Když vyberete více delegovaných cest s přepínáním návěští (LSP) patřících k jednomu příchozímu směrovači a kliknete na Return Delegation to PCC, bude zařízení řízeno pouze jedno z LSP. Tento scénář způsobuje problém v Junos.
  Řešení: Vyberte vždy jednu LSP a klikněte na Return Delegation to PCC jednotlivě pro každou LSP.
• Provozní stav delegovaného SR-TE LSP zůstává mimo provoz poté, co je znovu objeven jeho cílový uzel.
  Řešení: Po opětovném nalezení delegovaného cílového uzlu SR-TE LSP musíte model sítě synchronizovat.
• PCE server se nemůže znovu připojit k rabbitmq po restartování rabbitmq.
  Řešení: Restartujte modul ns-pceserver.
• Nastavení use-federated-exchange nemůžete upravit z rozhraní REST API/UI.
  Řešení: Upravte nastavení use-federated-exchange přímo z cMGD CLI a restartujte toposerver, aby se změna projevila.
• Paragon Insights mapuje pole Název (název hostitele nebo IP adresa) na pole ID zařízení. Název zařízení však již není jedinečný z následujících důvodů:
• V duálním zařízení Routing Engine je k názvu zařízení připojeno „-reX“.
• Aplikace třetích stran, jako je Anuta Atom, připojují k názvu zařízení název domény.
  Také mapování zařízení podle jeho univerzálního jedinečného identifikátoru (UUID) a nikoli podle názvu hostitele může způsobit problémy s informacemi, které GUI zobrazuje.
  Řešení: Nakonfigurujte další IP adresu pro rozhraní Ethernet pro správu na zařízení zahrnutím příkazu pouze pro master na úrovni hierarchie [upravit skupiny]. Tuto další IP adresu pak musíte použít pro připojení zařízení. Více informací viz Správa rozhraní Ethernet.
• Pokud jste vyhradili uzel pro TSDB, některé služby (napřample, AtomDB, ZooKeeper a tak dále) ve společném jmenném prostoru, které mají nastaveno PersistentVolumeClaim, mohou být ovlivněny, pokud příslušné pody běží na vyhrazeném uzlu. To znamená, že stav modulů spuštěných na uzlu TSDB je vždy zobrazen jako Nevyřízený.
  Řešení: Chcete-li se této situaci vyhnout, při vyhrazení uzlu pro TSDB se ujistěte, že uzel nemá žádné pody pro vyhrazené služby, které používají PersistentVolumeClaim.
• Když zrušíte delegování delegovaného LSP, bude plánovaná šířka pásma LSP založena na šířce pásma hlášené zařízením namísto hodnoty vstupu uživatele.
  Řešení: Žádné.
• Pokud při přidávání zařízení zadáte zdrojovou IP adresu, která se již v síti používá, možná nebudete moci přidat zařízení do skupiny zařízení, nasadit playbook, setkat se s chybami souvisejícími se zpracováním funkcí a tak dále.
  Řešení: Opravte konfliktní zdrojovou IP adresu. Klepněte na ikonu Stav nasazení a potvrďte změny.
• Pokud na stránce Alarmy vyberete uložený dotaz, budou alarmy filtrovány na základě uloženého dotazu. Graf a datum se však neaktualizují.
  Řešení: Žádné.
• Pokud na stránce Zařízení přidáte nespravované zařízení a později upravíte název hostitele nespravovaného zařízení, název hostitele se neprojeví ve skupině zařízení a v řídicím panelu Zařízení na řídicím panelu.
  Řešení: Můžete přidat nespravované zařízení pomocí názvu hostitele nebo IP adresy zařízení.
  Pokud jste pomocí názvu hostitele přidali nespravované zařízení, problém vyřeší odstranění stávajícího zařízení a přidání zařízení s novým názvem hostitele.
  Pokud jste přidali nespravované zařízení pomocí adresy IP, musíte ve skupině zařízení a dashletu Zařízení na řídicím panelu identifikovat nespravovaná zařízení na základě adresy IP, nikoli názvu hostitele.
• Ve výchozím nastavení je filtr topologie zakázán. Filtr topologie nelze povolit pomocí grafického uživatelského rozhraní Paragon Automation.
  Řešení: Postup povolení filtru topologie naleznete v tématu Povolení služby filtru topologie.
• U zařízení Cisco IOS XR nelze obnovit konfiguraci zařízení ze stránky Zařízení. Zálohovat lze pouze konfiguraci zařízení.
  Řešení: Chcete-li obnovit konfiguraci zařízení vašich zařízení Cisco IOS XR:
  1. Na stránce Konfigurace > Zařízení vyberte zařízení Cisco XR a klikněte na Více > Verze konfigurace.
  2. Zkopírujte verzi konfigurace, kterou chcete obnovit.
  3. Obnovte konfiguraci pomocí CLI.
• Pokud jste povolili odchozí SSH na úrovni skupiny zařízení, nemůžete zakázat odchozí SSH pro jedno ze zařízení ve skupině zařízení.
  Řešení: Odchozí SSH na zařízení můžete povolit nebo zakázat pomocí rozhraní MGD CLI nebo Rest API. Chcete-li zakázat odchozí SSH, musíte nastavit příznak zakázání na hodnotu true. Spuštěním následujícího příkazu na zařízení zakažte odchozí SSH pomocí MGD CLI: set healthbot DeviceName outbound-ssh disable true
• Z grafického uživatelského rozhraní Paragon Automation nelze stáhnout všechny protokoly služeb.
  Řešení: Můžete view všechny protokoly služeb v databázi Elastic Search (ESDB) a Grafana. Chcete-li se přihlásit do Grafana nebo ESDB, musíte nakonfigurovat heslo v poli grafana_admin_password v souboru config.yml file před instalací.
• Pokud upravíte existující LSP nebo použijete ID řezu jako jedno z kritérií směrování, pak cesta předview se nemusí zobrazit správně.
  Alternativní řešení: Jakmile vytvoříte cestu, bude cesta respektovat omezení ID řezu a cesta se zobrazí správně v předběžnémview.
• Pokud zřídíte LSP se směrováním segmentů pomocí PCEP, funkce barev nebude fungovat.
  K tomuto problému dochází, pokud router běží na Junos OS Release 20.1R1.
  Řešení: Upgradujte Junos OS na verzi 21.4R1.
• Mikroslužbám se nedaří připojit k PostgresSQL, protože PostgresSQL nepřijímá žádná připojení během přepínání primární role. Toto je přechodný stav.
  Řešení: Ujistěte se, že se mikroslužby připojí k PostgresSQL po dokončení přepnutí primární role.
  • Databáze Postgres se v některých systémech stane nefunkční, což vede k selhání připojení.
  Řešení: Spusťte následující příkaz v primárním uzlu: for pod in atom-db-{0..2}; dělat
  kubectl exec -n common $pod — chmod 750 /home/postgres/pgdata/pgroot/data hotovo
• Zjištění zařízení pro zařízení Cisco IOS XR se nezdaří.
  Řešení: Zvyšte limit rychlosti serveru SSH pro zařízení Cisco IOS XR. Přihlaste se k zařízení v konfiguračním režimu a spusťte následující příkaz:
  RP/0/RP0/CPU0:ios-xr(config)#ssh server rate-limit 600
• Pokud používáte BGP-LS k získání informací o zpoždění spojení a odchylce zpoždění spojení, nemůžete view historická data zpoždění spojení.
  Řešení: Žádné.
• Ve vzácných případech (napřampPokud Redis selže a je automaticky restartován Kubernetes nebo musíte restartovat server Redis), některé informace o rozhraní se ztratí a rozhraní nejsou uvedena na kartě Rozhraní v tabulce informací o síti. Tento problém však neovlivňuje výpočet cesty, statistiky ani poskytování LSP.
  Řešení: Chcete-li obnovit rozhraní v modelu živé sítě, spusťte znovu úlohu shromažďování zařízení.
• Na kartě Úlohy na stránkách Přidat nový pracovní postup a Upravit pracovní postup:
• I když klepnete na možnost Storno, změny, které jste provedli při úpravě úkolu, se uloží.
• Nemůžete znovu použít název kroku, který jste již odstranili.
• Chybová zpráva se nezobrazí, ani když přidáte krok s prázdnými položkami a kliknete na Uložit a nasadit.
  Řešení: Žádné.
• Upgrade některých zařízení PTX nižší třídy s režimem Dual RE (napřample, PTX5000 a PTX300) není podporován v Paragon Automation. Důvodem je to, že zařízení PTX nižší třídy s režimem Dual RE nepodporují konfiguraci přemostění nebo přemostění domény.
  Řešení: Žádné.
• Rozhraní POST /traffic-engineering/api/topology/v2/1/rpc/diverseTreeDesign API nefunguje.
  Řešení: Doporučujeme použít rozhraní POST /NorthStar/API/v2/tenant/1/topology/1/rpc/ DifferentTreeDesign API.
• Paragon Automation nezobrazuje alarmy pro zařízení Nokia.
  Řešení: Žádné.
• Při konfiguraci LSP SRv6 s metodou směrování jako routeByDevice musíte zadat hodnotu pro objekt směrování segmentu-Explicitní cesta (SR-ERO); jinak nemůžete použít SRv6 LSP k přenášení provozu.
  Řešení: Při přidávání tunelu na kartě Cesta přidáním přeskoků určete požadovaný nebo preferovaný typ směrování.
• Pokud je ze sítě objevena zařízení SRv6 LSP, cesta zvýrazněná pro tuto LSP bude nesprávná bez ohledu na to, zda pro trasu zadáte objekt Explicit Route (ERO) či nikoli.
  Řešení: Žádné.
• Někdy se může stát, že nebudete moci hromadně odstranit LSP směrování segmentů.
  Řešení: Můžete vynutit odstranění LSP, které nebyly odstraněny během procesu hromadného odstranění.
•  V uživatelském rozhraní Paragon Automation na kartě Úlohy na stránkách Přidat nový pracovní postup a Upravit pracovní postup se při pokusu o úpravu a uložení existujícího kroku bez provedení jakýchkoli změn zobrazí následující chybová zpráva:
  Název již existuje
  Řešení: Pokud jste omylem klikli na možnost Upravit, ujistěte se, že jste změnili alespoň název kroku.
• Relace PCEP se někdy zobrazí jako Down, pokud restartujete všechny moduly v oboru názvů northstar.
  Řešení: Restartujte topologický server pomocí kubectl delete pods ns-toposerver- -n příkaz northstar.
• Na stránce Administrace > Správa licencí nemůžete view název SKU licence, když vyberete licenci a poté vyberte Více > Podrobnosti.
  Řešení: Žádné.
• Graf na stránce Alarmy neodráží nejnovější data. To znamená, že graf není aktualizován poté, co alarm již není aktivní.
  Řešení: Žádné.
• Když nakonfigurujete odchozí SSH pro iAgent, nebudou se generovat data pro nakonfigurované pravidlo.
  Řešení: Žádné.
• Pokud jste nakonfigurovali Two-Way Active Management Protocol (TWAMP). To je nesprávné, protože TWAMP nepodporuje export ztráty paketů pro provozní inženýrství IS-IS.
  Řešení: Žádné.
• Pokud používáte zařízení s linkovými kartami MPC10+ a pokud zařízení běží na jiném vydání Junos OS než vydání 21.3R2-S2 nebo vydání 21.4R2-S1, pak se statistiky pro logická rozhraní neshromažďují. Shromažďují se však statistiky fyzických rozhraní a LSP.
  Řešení: Upgradujte vydání Junos OS na vydání 21.3R2-S2 nebo 21.4R2-S1. Také se ujistěte, že jste upgradovali Paragon Automation na verzi 23.1.
• Když zrušíte delegování LSP, stav LSP se zobrazí jako delegovaný. Když se znovu pokusíte zrušit delegování LSP, konfigurace směrovače může být upravena tak, aby byly přidány objekty explicitní trasy (ERO).
  Alternativní řešení: Než znovu zrušíte delegování LSP, obnovte kartu Tunnel.
• Paragon Pathfinder nesníží delegovaný SR LSP, když SR LSP nesplňuje omezení segmentu, pokud je stav SR LSP lokálně směrován.
• Pokud vytvoříte skupinu topologie s ID řezu větším nebo rovným 2**32, ID skupiny topologie se nebude shodovat s ID řezu.
• Cluster Paragon Automation Kubernetes používá samostatně generované certifikáty spravované kubeadm.
  Platnost těchto certifikátů vyprší jeden rok po nasazení, pokud není upgradována verze Kubernetes nebo pokud certifikáty nejsou ručně obnoveny. Pokud platnost certifikátů vyprší, pody se neobjeví a v protokolu se zobrazí chybné chyby certifikátu.
  Řešení: Obnovte certifikáty ručně. Chcete-li obnovit certifikáty, proveďte následující kroky:

1. Zkontrolujte aktuální datum vypršení platnosti certifikátů pomocí příkazu kubeadm certs check-expiration na každém primárním uzlu vašeho klastru.
2. Chcete-li obnovit certifikáty, použijte příkaz kubeadm certs renew all na každém primárním uzlu vašeho clusteru Kubernetes.
3. Znovu zkontrolujte datum vypršení platnosti pomocí příkazu kubeadm certs check-expiration na každém primárním uzlu vašeho klastru.
4. Chcete-li použít nové certifikáty, restartujte následující moduly z libovolného z primárních uzlů.

Vyřešené problémy

Tato část obsahuje seznam vyřešených problémů v Juniper Paragon Automation Release 24.1

• Symetrické párové LSP nemusí být směrovány symetricky při přesměrování překročení prahu.
  Řešení: Žádné.
• Grafy provozu jsou nyní podporovány pro zařízení s duálními směrovacími moduly, která jsou integrována s příponou re0 nebo re1 k názvu hostitele. Grafy jsou však podporovány pouze v případě, že jsou přípony názvu hostitele malými písmeny a ve formátu -re0 nebo -re1. Napřample: vmx101-re0 nebo vmx101-re1
  Řešení: Žádné
• Místa kontroléru nejsou součástí síťového archivu pro Paragon Planner.
  Řešení: Žádné.
• Stav nouzového režimu je vždy nepravdivý, když ns-web pod začíná.
  Řešení: Žádné.
• Po změně příznaku zdroje pravdy v nouzovém režimu získáte nesprávný stav nouzového režimu.
  Řešení: Žádné.
• Někdy se u zařízení s deaktivovaným NETCONF zobrazí stav NETCONF Up.
  Řešení: Upravte profesionální zařízenífile bez jakýchkoli změn, které by spustily opětovné načtení zařízení profile.
• Barva pro SR-TE LSP pocházející ze zařízení Cisco IOS-XR je viditelná pouze v případě, že je LSP původně objeven z kolekce zařízení.
  Řešení: Žádné.
• Pokud má LSP nakonfigurovaný stav, po synchronizaci topologie zmizí skupina Admin SR-TE LSP naučená z PCEP.
  Alternativní řešení: Upravte SR-TE LSP tak, aby byla zachována skupina správců naučená z PCEP.
• LSP na optimální cestě mohou během optimalizace PCS obdržet zbytečnou aktualizaci PCEP.
  Řešení: Žádné.
• Chyba ve funkci diagnostiky (Konfigurace > Zpracování dat > Diagnostika > Aplikace) způsobí selhání testů aplikace.
  Řešení: Žádné.
• Když na kartě Síť > Topologie > Tunel umístíte ukazatel myši na ikonu Filtr (cesta) a vyberete Přidat filtr, zobrazí se stránka Přidat kritéria. Pokud v seznamu Pole vyberete Barva, hodnota pole se zobrazí jako plánovanéVlastnosti místo Barva.
  Řešení: Žádné.
• Zpráva analýzy trasy je prázdná.

Řešení: Před provedením analýzy cesty spusťte úlohu shromažďování zařízení. Všimněte si, že sestava analýzy cesty může být prázdná, pokud jsou LSP již na optimální cestě.

Juniper Networks, logo Juniper Networks, Juniper a Junos jsou registrované ochranné známky společnosti Juniper Networks, Inc. ve Spojených státech a dalších zemích. Všechny ostatní ochranné známky, servisní známky, registrované známky nebo registrované servisní známky jsou majetkem příslušných vlastníků. Juniper Networks nepřebírá žádnou odpovědnost za jakékoli nepřesnosti v tomto dokumentu. Juniper Networks si vyhrazuje právo změnit, upravit, převést nebo jinak revidovat tuto publikaci bez upozornění. Copyright © 2024 Juniper Networks, Inc. Všechna práva vyhrazena.

Dokumenty / zdroje

Juniper NETWORKS Paragon Automation Software [pdfUživatelská příručka Paragon Automation Software, Automatizační software, Software

Reference

• Uživatelská příručka