Paragon Automation, გამოშვება 24.1

პროგრამული უზრუნველყოფის მაჩვენებლები

• RHEL 8.10-ის მხარდაჭერა
• არა-root მომხმარებლებისთვის ბრძანებების გაშვების შესაძლებლობა პარაგონ CLI უტილიტაში
• სეგმენტის მარშრუტიზაციის პოლიტიკის მიწოდების შესაძლებლობა Cisco IOS XR მოწყობილობებზე NETCONF-ის გამოყენებით

შესავალი

Juniper® Paragon Automation არის ღრუბლოვანი გადაწყვეტა ქსელის დაგეგმვის, კონფიგურაციის, უზრუნველყოფის, ტრაფიკის ინჟინერიის, მონიტორინგისა და სასიცოცხლო ციკლის მენეჯმენტისთვის, რომელიც ანიჭებს გაფართოებულ ვიზუალიზაციის შესაძლებლობებს და ანალიტიკას ქსელის მენეჯმენტსა და მონიტორინგში. თქვენ შეგიძლიათ განათავსოთ Paragon Automation, როგორც შიდა (მომხმარებლის მიერ მართული) აპლიკაცია.
Paragon Automation მუშაობს მიკროსერვისებზე დაფუძნებულ არქიტექტურაზე და იყენებს REST API-ებს, gRPC API-ებს და ჩვეულებრივი შეტყობინებების ავტობუსის კომუნიკაციებს. Paragon Automation უზრუნველყოფს საბაზისო პლატფორმის შესაძლებლობებს, როგორიცაა Juniper Networks და მესამე მხარის (Cisco IOS XR, Nokia) მოწყობილობების მხარდაჭერა, zerotouch უზრუნველყოფა, მომხმარებლის მართვა და როლებზე დაფუძნებული წვდომის კონტროლი (RBAC).
გარდა საბაზისო პლატფორმის შესაძლებლობებისა, Paragon Automation გთავაზობთ მიკროსერვისებზე დაფუძნებულ აპლიკაციების კომპლექტს - Juniper® Paragon Insights (ყოფილი HealthBot), Juniper® Paragon Planner (ყოფილი NorthStar Planner) და Juniper® Paragon Pathfinder (ყოფილი NorthStar Controller).
როდესაც ამ აპლიკაციებიდან რომელიმეს ამატებთ Paragon Automation-ს, აპლიკაციის API კომპლექტი ინტეგრირდება Paragon Automation-თან, რათა დაუშვას უწყვეტი კომუნიკაცია ახალ და არსებულ სერვისებს შორის. ამ გამოშვების შენიშვნებში ჩვენ გამოვყოფთ საბაზისო პლატფორმის, Paragon Pathfinder, Paragon Planner (Desktop Application) და Paragon Insights მოდულების ახალ ფუნქციებს, რომლებიც ხელმისაწვდომია ამ გამოშვებაში. ამ აპლიკაციებთან დაკავშირებული ფუნქციების შესახებ დამატებითი ინფორმაციისთვის იხილეთ Paragon Automation მომხმარებლის სახელმძღვანელო.
გამოიყენეთ ეს გამოშვების შენიშვნები, რათა იპოვოთ ახალი და განახლებული ფუნქციები, პროგრამული უზრუნველყოფის შეზღუდვები და გახსნილი საკითხები Paragon Automation Release 24.1-ში.

ინსტალაციისა და განახლების ინსტრუქციები

ინსტალაციის პროცედურის, განახლების პროცედურისა და მოთხოვნების შესახებ ინფორმაციისთვის (პროგრამული უზრუნველყოფა და
აპარატურა), იხილეთ Paragon Automation ინსტალაციის სახელმძღვანელო.

შენიშვნა:
თქვენ შეგიძლიათ პირდაპირ განაახლოთ მხოლოდ Paragon Automation Release 23.2-დან Release 24.1-მდე. თუ თქვენი გამოშვება უფრო ადრეა, ვიდრე გამოშვება 23.2, თქვენ უნდა დააინსტალიროთ გამოშვება 24.1 თავიდან. თუმცა, თქვენი მიმდინარე გამოშვების კონფიგურაციის Release 24.1-ზე გადასატანად, შეგიძლიათ გამოიყენოთ სარეზერვო ასლის შექმნა და ფუნქციონირების აღდგენა. განახლების შესახებ დამატებითი ინფორმაციისთვის იხილეთ Paragon Automation Release 24.1-ის განახლება.

ლიცენზირება

Paragon Insights-ში ჩვენ წარმოვადგინეთ შემდეგი ლიცენზიის დონეები და მათთან დაკავშირებული მოწყობილობის ლიცენზიები:

• Paragon Insights Advanced (PIN-Advanced)
• Paragon Insights Standard (PIN-სტანდარტი)

ამჟამად, დონის ლიცენზიები რთულად აღსრულებულია. ანუ, თქვენ ვერ შეასრულებთ განლაგების ოპერაციას, თუ არ დაამატებთ ლიცენზიებს.
მოწყობილობის ლიცენზიები რბილია. ანუ, თქვენ მიიღებთ შესაბამისობის შეუსაბამობის გაფრთხილებას Paragon Automation GUI-ში, თუ ცდილობთ უფრო მეტი მოწყობილობის დაყენებას, ვიდრე ნომერი, რომლისთვისაც მიიღეთ ლიცენზია.
თუმცა, შეგიძლიათ გააგრძელოთ არსებული ფუნქციების გამოყენება.
შეგიძლია view თქვენი ლიცენზიის შესაბამისობის სტატუსი GUI-ში ადმინისტრაცია > ლიცენზიის მენეჯმენტის გვერდზე.
Paragon Pathfinder-ში ჩვენ მტკიცედ დავამყარეთ შემდეგი ლიცენზიის დონეები:

• Pathfinder Standard
• Pathfinder Advanced
• Pathfinder Premium

ლიცენზირების შესახებ ინფორმაციისთვის იხილეთ ლიცენზირების გზამკვლევი.
თუ თქვენ გაქვთ ლიცენზიის გასაღები, რომელიც შეიქმნა Paragon Automation-ის ვერსიისთვის უფრო ადრე, ვიდრე Release
22.1 თქვენ უნდა განაახლოთ ლიცენზიის გასაღების ფორმატი ახალ ფორმატზე, სანამ დააინსტალირებთ Paragon Automaton Release 24.1-ში. თქვენ შეგიძლიათ შექმნათ ახალი ლიცენზიის გასაღები Juniper Agile Licensing პორტალის გამოყენებით. ახალი ლიცენზიის გასაღების გენერირების შესახებ დამატებითი ინფორმაციისთვის იხ Viewლიცენზიების დამატება ან წაშლა.

ახალი და შეცვლილი ფუნქციები

ეს განყოფილება აღწერს Juniper Paragon Automation Release 24.1-ის თითოეულ მოდულის ფუნქციებს.
პარაგონის ინსტალაცია და განახლება

• Red Hat Enterprise Linux (RHEL) 8.10—Paragon Automation Release 24.1 კვალიფიცირებულია RHEL 8.10–თან მუშაობისთვის.
  [იხ ინსტალაციის წინაპირობები Red Hat Enterprise Linux-ზე.]
• Paragon CLI utility ბრძანებების გაშვება, როგორც არა-root მომხმარებელი - პარაგონის ავტომატიზაციის გამოშვებიდან 24.1 დაწყებული, არა-root მომხმარებელს სუპერმომხმარებლის (sudo) პრივილეგიებით შეუძლია პარაგონ CLI utility ბრძანებების გაშვება Paragon Automation-ის დაყენების გასაანალიზებლად, მოთხოვნისა და გამართვის მიზნით.
  [იხ პრობლემების მოგვარება პარაგონის CLI Utility-ის გამოყენებით.]

Paragon Pathfinder

• უზრუნველყოფის სეგმენტის მარშრუტიზაციის პოლიტიკა Cisco IOS XR მოწყობილობებზე - პარაგონის ავტომატიზაციის გამოშვებიდან 24.1 დაწყებული, შეგიძლიათ მიაწოდოთ სეგმენტის მარშრუტიზაციის პოლიტიკა Cisco IOS XR მოწყობილობებზე NETCONF, როგორც უზრუნველყოფის მეთოდის გამოყენებით.

ბაზის პლატფორმა
ჩვენ არ დავამატეთ რაიმე ახალი ფუნქცია, რომელიც დაკავშირებულია საბაზო პლატფორმასთან Paragon Automation Release 24.1-ში.
Paragon Insights
ჩვენ არ დავამატეთ რაიმე ახალი ფუნქცია Paragon Insights-თან Paragon Automation Release 24.1-ში.
პარაგონის დამგეგმავი
ჩვენ არ დავამატეთ Paragon Planner-თან დაკავშირებული ახალი ფუნქციები Paragon Automation Release 24.1-ში.
შენიშვნა: პარაგონის დამგეგმავი Web აპლიკაცია არის ბეტა ფუნქცია Paragon Automation Release 24.1-ში.

მოძველებული თვისებები

ამ განყოფილებაში ჩამოთვლილია ფუნქციები, რომლებიც მოძველებულია ან რომელთა მხარდაჭერა ამოღებულია Paragon-ისგან
ავტომატური გამოშვება 24.1.
• Grafana UI
თქვენ არ შეგიძლიათ წვდომა Grafana UI-ზე Paragon Automation-დან. Grafana UI-ზე წვდომისთვის თქვენ უნდა:

1. დააინსტალირეთ Grafana.
   იხ გრაფანას დოკუმენტაცია დამატებითი ინფორმაციისთვის.
2. გამოავლინეთ TSDB პორტი /var/local/healthbot/healthbot tsdb start-services ბრძანების გაშვებით.

შენიშვნა: Paragon Automation-ში TSDB პორტი ნაგულისხმევად არ არის გამოვლენილი. გარე ინსტრუმენტების გამოსაყენებლად, როგორიცაა Grafana, თქვენ უნდა გაუშვათ შეკითხვა TSDB-ზე პირდაპირ (და არა API-ების მეშვეობით), რათა გამოაშკარავოთ TSDB პორტი.

დამატებითი ინფორმაციისთვის იხ სარეზერვო და აღდგენა TSDB.
• სქემები

ცნობილი საკითხები

ამ განყოფილებაში ჩამოთვლილია ცნობილი საკითხები Juniper Paragon Automation Release 24.1-ში

ინსტალაცია

• როდესაც თქვენ უზრუნველვყოფთ ვირტუალურ მანქანებს (VM) VMware ESXi სერვერებზე, თუ დაამატებთ ბლოკის შენახვის დისკს დისკის საბაზო OS-ით დამატებამდე, Ceph ზოგჯერ არასწორად ამოიცნობს დისკებს და ქმნის კლასტერს არასწორი დისკის გამოყენებით, რის შედეგადაც საბაზო OS ხდება. განადგურდა.
  გამოსავალი: დაამატეთ პირველი დისკი, როგორც ძირითადი OS (უფრო დიდი დისკი) და შემდეგ დაამატეთ პატარა ბლოკის შენახვის დისკი.
• დროის სერიების მონაცემთა ბაზის (TSDB) HA რეპლიკაციის არარსებობის შემთხვევაში, თუ Kubernetes-ის მუშა კვანძი, რომელიც მუშაობს TSDB პოდზე, გაქრება, მიუხედავად იმისა, რომ პოდში არის ტევადობა, TSDB სერვისი არ დატრიალდება ახალ კვანძზე. ეს იმიტომ ხდება, რომ მონაცემთა დიდი მოცულობის ახალ კვანძში გადატანა დასჭირდება.
  გამოსავალი: სერვერის ან მეხსიერების წარუმატებლობის შემთხვევაში, რომელიც მასპინძლობს TSDB ინსტანციას, შეგიძლიათ აღადგინოთ სერვერი ან დაზიანებული კომპონენტი.

თუ რეპლიკაციის ფაქტორი დაყენებულია 1-ზე, მაშინ ამ მაგალითისთვის TSDB მონაცემები იკარგება. ამ შემთხვევაში, თქვენ უნდა ამოიღოთ წარუმატებელი TSDB კვანძი Paragon Automation-დან. წარუმატებელი TSDB კვანძის მოსაშორებლად:

1. Paragon Automation GUI-ში აირჩიეთ Configuration > Insights Settings.
   გამოჩნდება Insights პარამეტრების გვერდი.
2. დააჭირეთ TSDB ჩანართს view TSDB პარამეტრების ჩანართის გვერდი.
3. წარუმატებელი კვანძის წასაშლელად, TSDB პარამეტრების ჩანართის გვერდზე დააწკაპუნეთ X წარუმატებელი TSDB კვანძის სახელის გვერდით.
   შენიშვნა: ჩვენ გირჩევთ, წაშალოთ TSDB კვანძები ტექნიკური ფანჯრის დროს, რადგან ზოგიერთი სერვისი გადაიტვირთება და Paragon Automation GUI არ პასუხობს TSDB სამუშაოს შესრულებისას.
4. დააჭირეთ Save and Deploy.
5. თუ ცვლილებები არ არის განლაგებული და თუ შეცდომას წააწყდებით განლაგებისას, ჩართეთ იძულებითი გადართვის ღილაკი და განახორციელეთ ცვლილებები Save and Deploy-ზე დაწკაპუნებით. ამით სისტემა უგულებელყოფს TSDB პარამეტრების რეგულირებისას წარმოქმნილ შეცდომას.

• თუ მთლიანად წაშალეთ Paragon Automation, თქვენ ასევე უნდა დარწმუნდეთ, რომ /var/lib/rook დირექტორია წაშლილია ყველა კვანძიდან და ყველა Ceph ბლოკის მოწყობილობა წაშლილია.
  გამოსავალი: იხილეთ Ceph and Rook-ის პრობლემების მოგვარება > წარუმატებელი დისკის შეკეთება პარაგონის ავტომატიზაციის ინსტალაციის სახელმძღვანელოს განყოფილებაში.
• Paragon Automation-ის ჰაერის უფსკრული მეთოდის გამოყენებით ინსტალაციისას ჩნდება შემდეგი შეცდომა:

გამოსავალი: შეცვალეთ შემდეგი კონფიგურაციის ცვლადები config-dir/config.yml-ში file და შემდეგ დააინსტალირეთ Paragon Automation საჰაერო უფსკრული მეთოდის გამოყენებით:

გენერალი

• deploy-federated-exchange ბრძანება გამომავალი აჩვენებს, რომ ინსტალაცია ვერ მოხერხდა, როდესაც თქვენ დააკონფიგურირებთ კატასტროფის აღდგენის ორმაგ კლასტერში. თქვენ შეგიძლიათ უგულებელყოთ წარუმატებლობის შეტყობინება, მაგრამ თქვენ უნდა შეასრულოთ შემდეგი ბრძანება ორივე კლასტერის ყველა ძირითად კვანძზე:გამოსავალი: არცერთი.
• როდესაც წარუმატებლობა გავლენას მოახდენს LSP-ების ორივე მრავალფეროვან წყვილზე, ბილიკების გამოთვლის სერვერი (PCS) არ გაატარებს LSP-ებს მცირე მრავალფეროვნების დონის გზაზე ან არამრავალფეროვნების ბილიკზე. LSP-ების მარშრუტირება არ ხდება მანამ, სანამ PCS არ იპოვის გზას, რომელიც შეესაბამება კონფიგურირებული მრავალფეროვნების დონეს.
  გამოსავალი: არცერთი
• როდესაც წარუმატებლობა გავლენას მოახდენს LSP-ების ორივე მრავალფეროვან წყვილზე, ბილიკის გამოთვლის სერვერი (PCS) არ განათავსებს LSP-ებს არამრავალფეროვან გზაზე. LSP-ების მარშრუტირება არ ხდება მანამ, სანამ PCS არ იპოვის გზას, რომელიც შეესაბამება კონფიგურირებული მრავალფეროვნების დონეს.
  გამოსავალი: ამოიღეთ და ხელახლა გამოიყენეთ მრავალფეროვნების ჯგუფი.
• მინიმალური ცვალებადობის ზღურბლის მნიშვნელობა კონტეინერის subLSP-ის გამტარუნარიანობის ზომის პარამეტრებში ნაჩვენებია როგორც 0 კონტეინერში მისი კონფიგურაციის მიუხედავად. ნორმალურ პირობებში, subLSP-ის გამტარუნარიანობის ზომაზე გავლენას არ მოახდენს, რადგან გამტარუნარიანობის გაზომვის ამოცანა ამ მნიშვნელობას იღებს კონტეინერიდან subLSP-ის ნაცვლად. თუმცა, გარკვეულ სცენარებში, შესაძლებელია, რომ subLSP-ის ზომა შეიცვალოს გამტარუნარიანობის ახალ მნიშვნელობამდე, როდესაც კონფიგურირებული მინიმალური ცვალებადობის ზღვარი არ დაირღვა.
  ამ საკითხთან დაკავშირებით დამატებითი ინფორმაციისთვის დაუკავშირდით Juniper Networks ტექნიკური დახმარების ცენტრს (JTAC).
• გამტარუნარიანობის ზომის განსაზღვრისას, აქტიური მეორადი LSP, რომელსაც ჩართული აქვს სიჩქარის ზომა, შეიძლება არ შეიცვალოს ზომა. როდესაც ეს პრობლემა წარმოიქმნება, მეორად გზაზე ბმულების RSVP გამოყენება შეიძლება არასწორად განახლდეს.
  გამოსავალი: არცერთი.
• UI-ის გამოყენებით Paragon Pathfinder-ის პარამეტრებში (კონფიგურაცია > ქსელის პარამეტრები) ცვლილებების შეტანას შესაძლოა დასჭირდეს ერთზე მეტი მცდელობა, რომ ცვლილება ძალაში შევიდეს. შეიძლება დაგჭირდეთ შენახვაზე დაწკაპუნება არაერთხელ.
  გამოსავალი: იგივე ცვლილებები შეიძლება განხორციელდეს cMGD CLI გამოყენებით, რომელიც ხელმისაწვდომია ძირითადი კვანძიდან, რომელიც მუშაობს pf-cmgd ბრძანებით.
• კონტეინერის ნორმალიზების დროს გარკვეულ პირობებში, ერთი ან მეტი კონტეინერის subLSP, რომელიც უნდა მოიხსნას, დარჩება. ეს კონტეინერის subLSP დარჩება ქსელში, როგორც დამოუკიდებელი LSP, რომელიც არ არის დაკავშირებული კონტეინერთან. კონტეინერის subLSP-ების რაოდენობის შეუსაბამობა, რომელიც მითითებულია subLSPs სვეტში კონტეინერის LSP ჩანართის ქვეშ და LSP-ების ფაქტობრივი რაოდენობა, რომლებსაც აქვთ კონტეინერის სახელი, როგორც პრეფიქსი გვირაბის ჩანართის ქვეშ, შეიძლება ჩაითვალოს ამ პრობლემის მითითებად.
  ამ საკითხთან დაკავშირებით დამატებითი ინფორმაციისთვის დაუკავშირდით Juniper Networks ტექნიკური დახმარების ცენტრს (JTAC).
• კონტეინერის LSP შეიძლება კონფიგურირებული იყოს გამტარუნარიანობის ზომის პარამეტრებით, რომლებიც მემკვიდრეობით მიიღება მისი subLSP-ების მიერ. გარკვეულ პირობებში, როდესაც მომხმარებელი თიშავს გამტარუნარიანობის ზომის ვარიანტს კონტეინერში წარსულში ჩართვის შემდეგ, ის არ ითიშება არსებულ subLSP-ებში.
  გამოსავალი: არცერთი.
• კონტეინერის subLSP-ის ხელით ხელახალი გადამუშავება გამოიწვევს მონაცემთა დამატებას LSP ობიექტში. შედეგად, შეიძლება მოხდეს შემდეგი პრობლემები:
• თუ კონტეინერში ჩართულია სიჩქარის ზომა და კონფიგურირებულია არანულოვანი მინიმალური ცვალებადობის ზღურბლი, კონკრეტული subLSP შეიძლება შეიცვალოს ზომა, მიუხედავად იმისა, რომ subLSP ტრაფიკი არ აღემატება მის სიგნალიზებულ სიჩქარეს მინიმუმ მინიმალური ცვალებადობის ზღვრული მნიშვნელობით.
• subLSP-ს შეიძლება ჰქონდეს სიჩქარის ზომის განსხვავებული პარამეტრები, ვიდრე კონტეინერი, თუ კონტეინერის გამტარუნარიანობის ზომის პარამეტრები მოგვიანებით შეიცვლება.
• subLSP-ის მოცილება ვერ მოხერხდა კონტეინერის ნორმალიზების დროს, როდესაც გამტარუნარიანობა ეცემა გაერთიანების სიჩქარეს.
  დამატებითი ინფორმაციისთვის ამ საკითხთან დაკავშირებით და ინსტრუქციების შესახებ დამატებითი მონაცემების ამოღების შესახებ, რომლებიც ემატება შიდა მდგომარეობას, დაუკავშირდით Juniper Networks Technical Assistance Center (JTAC).
• გარკვეულ სცენარებში, როგორიცაა კონტეინერის ნორმალიზაციის წარუმატებლობა ხელმისაწვდომი ბილიკების ნაკლებობის გამო, დამატებითი შიდა მდგომარეობა დაემატება კონტეინერის subLSP ობიექტებს, რამაც შეიძლება გამოიწვიოს შემდეგი პრობლემები:
• თუ კონტეინერში ჩართულია სიჩქარის ზომა და კონფიგურირებულია არანულოვანი მინიმალური ცვალებადობის ზღურბლი, კონკრეტული subLSP შეიძლება შეიცვალოს ზომა, მიუხედავად იმისა, რომ subLSP ტრაფიკი არ აღემატება მის სიგნალიზებულ სიჩქარეს მინიმუმ მინიმალური ცვალებადობის ზღვრული მნიშვნელობით.
• subLSP-ს შეიძლება ჰქონდეს სიჩქარის ზომის განსხვავებული პარამეტრები, ვიდრე კონტეინერი, თუ კონტეინერის გამტარუნარიანობის ზომის პარამეტრები მოგვიანებით შეიცვლება.
• subLSP-ის მოცილება ვერ მოხერხდა კონტეინერის ნორმალიზების დროს, როდესაც გამტარუნარიანობა ეცემა გაერთიანების სიჩქარეს.

დამატებითი ინფორმაციისთვის ამ საკითხთან დაკავშირებით და ინსტრუქციების შესახებ დამატებითი მონაცემების ამოღების შესახებ, რომლებიც ემატება შიდა მდგომარეობას, დაუკავშირდით Juniper Networks Technical Assistance Center (JTAC).

• როდესაც მუშა Kubernetes კლასტერში ერთი ან მეტი კვანძი მიუწვდომელია, ამან შეიძლება გამოიწვიოს შემდეგი მოულოდნელი ქცევა:
• ყველა კვანძის PCEP სტატუსი ნაჩვენებია ქვემოთ, თუმცა PCEP კავშირის სტატუსი როუტერზე მაღლაა.
• ქსელის ტოპოლოგია არ არის ნაჩვენები ინტერფეისში.
  ამ საკითხთან დაკავშირებით დამატებითი ინფორმაციისთვის დაუკავშირდით Juniper Networks ტექნიკური დახმარების ცენტრს (JTAC).
• Paragon Pathfinder-ს შეუძლია გამოთვალოს ბილიკი, რომელიც არღვევს სპექტაკლის მაქსიმალურ შეზღუდვას, რომელიც კონფიგურირებულია გვირაბში. ეს სცენარები ხსნის, თუ როგორ ხდება მაქსიმალური ჰოპ შეზღუდვის გაუქმება:
• როდესაც Path Computation Server (PCS) გადაიტვირთება, ქვემოთ LSP უზრუნველყოფილია მაქსიმალური hop შეზღუდვის გათვალისწინების გარეშე.
• ქსელის უკმარისობის დროს, LSP-ის გადამისამართება ხდება მაქსიმალური hop შეზღუდვის გათვალისწინების გარეშე.
• ბილიკის ოპტიმიზაციის დროს, LSP ოპტიმიზებულია მაქსიმალური hop შეზღუდვის გათვალისწინების გარეშე.
  გამოსავალი: გამოიყენეთ ხელახალი უზრუნველყოფის ვარიანტი, თუ ხელმისაწვდომია ალტერნატიული გზა, რომელიც არ არღვევს კონფიგურირებულ შეზღუდვას.
• Paragon Pathfinder-ის მიერ გამოთვლილი ბილიკი ლოდინის LSP-სთვის მაქსიმალური hop შეზღუდვით შეიძლება დაარღვიოს კონფიგურირებული შეზღუდვა.
  გამოსავალი: არცერთი.
• არსებობს შესაძლებლობა, რომ PCS-მა ვერ იპოვნოს LSP ბმულის მრავალფეროვნებით ტოპოლოგიაში, რომელსაც აქვს მრავალი პარალელური ბმული კვანძებს შორის.
  გამოსავალი: არცერთი.
• როდესაც PCEP სესია გამორთულია, LSP ოპერაციული სტატუსი გადავა უცნობ მდგომარეობაში მოწყობილობის შეგროვების გაშვების შემდეგ.
  გამოსავალი: არცერთი.
• ბმული შეიძლება გაქრეს ქსელის არქივის ამოცანის შექმნისას.
  გამოსავალი: შექმენით ახალი ქსელის არქივის ამოცანა.
• VPN მოთხოვნის მარშრუტი ვერ ხერხდება ქსელში არსებული პრობლემების გამო.
  გამოსავალი: არცერთი.
• სიგნალიზაცია არ პასუხობს, როდესაც Cisco მოწყობილობები თავდაპირველად კონფიგურირებულია NETCONF-ით 22-ე პორტზე.
  გამოსავალი: შეცვალეთ NETCONF პორტი თქვენს Cisco მოწყობილობაზე და დარწმუნდით, რომ ცვლილებები შენახულია. ამის შემდეგ, დააბრუნეთ პორტის პარამეტრები 22-ე პორტზე.
• როდესაც თქვენ დაამატებთ multicast მოთხოვნას GUI-ში, კვანძის Z ველი ცარიელია.
  გამოსავალი: არცერთი.
• როდესაც დაამატებთ რამდენიმე ახალ გვირაბს, ნაჩვენებია ტრაფიკის მნიშვნელობები ადრე წაშლილი გვირაბებიდან (რომლებიც ქეშირებული იყო).
  გამოსავალი: არცერთი.
• როდესაც თქვენ დაამატებთ ახალ მრავალფეროვან გვირაბებს, ზოგჯერ ნაჩვენებია ტრაფიკის მნიშვნელობები ადრე წაშლილი გვირაბებიდან (რომლებიც ქეშირებული იყო).
  გამოსავალი: არცერთი.
• ტოპოსერვერი არ ასუფთავებს და არ განაახლებს ტოპოლოგიას BMP პოდთან კავშირის დაკარგვის შემდეგ.
  გამოსავალი: არცერთი.
• როდესაც ბმული გათიშულია, Paragon Pathfinder არ ახდენს დელეგირებული SR LSP-ის მარშრუტიზაციას სასურველი ექსპლიციტური მარშრუტის ობიექტით (ERO) და მარშრუტის მიხედვით მოწყობილობით მარშრუტიზაციის მეთოდით.
  გამოსავალი: გამოიყენეთ ნაგულისხმევი მარშრუტიზაციის მეთოდი.
• თუ თქვენ აწარმოებთ სიმულაციას პირდაპირ მას შემდეგ, რაც შეასრულებთ მრავალმხრივი ხის დიზაინის შესრულებას, ანგარიში გვირაბის ტრაფიკში ბმულებზე (გვირაბის ფენის სიმულაციის ანგარიში > ქსელის პიკის სტატისტიკა) არასწორია.
  გამოსავალი: შეინახეთ ქსელი მას შემდეგ, რაც შეასრულებთ მრავალმხრივი ხის დიზაინს და დახურავთ მას. ხელახლა გახსენით ქსელი და შემდეგ გაუშვით სიმულაცია.
• წარუმატებლობის სცენარების სიმულაციისას (ინსტრუმენტები > ოფციები > წარუმატებლობის სიმულაცია), თუ ჯერ აწარმოებთ მრავალჯერადი მარცხის სიმულაციას და შემდეგ აწარმოებთ ერთი ავარიის სიმულაციას, ანგარიში გვირაბის ტრაფიკში ბმულებზე (გვირაბის ფენის სიმულაციის ანგარიში > ქსელის პიკის სტატისტიკა) არასწორია. მოხსენება აჩვენებს წარუმატებლობის სიმულაციური მნიშვნელობების ერთჯერადი შეცდომის ნაცვლად.
  გამოსავალი: გააუქმეთ ყველა ვარიანტი მრავალჯერადი წარუმატებლობის ჩანართზე ერთი მარცხის სცენარის სიმულაციამდე.
• ბმულის გამოყენების სიმულაციური ანგარიში შეიძლება აჩვენოს უარყოფითი მნიშვნელობები ორმაგი წარუმატებლობის სცენარის დროს.
  გამოსავალი: არცერთი.
• როდესაც მოწყობილობის ჰოსტის სახელი იცვლება, ცვლილება არ აისახება ყველა მონაცემთა ბაზაში.

გამოსავალი: შეასრულეთ შემდეგი ნაბიჯები ისე, რომ ახალი მოწყობილობის ჰოსტის სახელი აისახოს ყველა მონაცემთა ბაზაში და კომპონენტში.

1. ჰოსტის სახელის შეცვლამდე, ამოიღეთ მოწყობილობა მოწყობილობის ყველა ჯგუფიდან (კონტროლერი ან სხვა სათამაშო წიგნები).
2. დარწმუნდით, რომ მოწყობილობის მითითებები წაშლილია Paragon Automation-ის ყველა სხვადასხვა კომპონენტიდან. გადადით კონფიგურაციის > მოწყობილობების გვერდზე.
   ა. აირჩიეთ მოწყობილობა.
   ბ. დააწკაპუნეთ ნაგვის ურნის ხატულაზე მოწყობილობის წასაშლელად. ჩნდება მოწყობილობის წაშლის გვერდი.
   გ. აირჩიეთ იძულებითი წაშლა და დააჭირეთ დიახ.
3. ხელახლა ჩასვით მოწყობილობაზე, მოწყობილობის ჩართვის სამუშაო პროცესის გამოყენებით კონფიგურაციის > მოწყობილობების გვერდიდან.
   მოწყობილობა ახლა უნდა იყოს ჩართული ახალი ჰოსტის სახელით. ასევე უნდა განახლდეს მოწყობილობის თვისებები, განსაკუთრებით system-id (მნიშვნელოვანია JTI ნაკადების მისაღებად).
4. დაამატეთ მოწყობილობა ახალი ჰოსტის სახელით მოწყობილობის ჯგუფებში.
5. (სურვილისამებრ) გადაამოწმეთ ყველა მოწყობილობის სტატისტიკა Influxdb-ში Grafana-ს ან მოწყობილობაზე CLI-ის გამოყენებით. მონაცემთა ბაზა უნდა განახლდეს ახალი ჰოსტის სახელით.

• ქსელის კონფიგურაციის პროტოკოლის (NETCONF) უზრუნველყოფის მეთოდი წერტილიდან მრავალწერტილამდე (P2MP) LSP-ებისთვის არ არის მხარდაჭერილი Cisco IOS-XR მარშრუტიზატორებში.
• Cisco IOS-XR მარშრუტიზატორებზე, P2MP sub-LSP სტატუსი არ არის მხარდაჭერილი კონფიგურაციის მდგომარეობაში CLI-ის მოწოდებული P2MP LSP-ებისთვის.
  გამოსავალი: არცერთი.
• Junos OS Release 22.4R1 და მოგვიანებით აქვს შეზღუდვა SR-TE LSP-ებთან.
  PCEP სესიების დასამყარებლად, თქვენ უნდა გამორთოთ მრავალმხრივი ფუნქცია შემდეგი ბრძანების გამოყენებით: დააყენეთ პროტოკოლები pcep disable-multipath-capability მეორადი გზა არ არის მხარდაჭერილი.
•  რიგში მყოფი ძველი შეტყობინებები მუშავდება ფედერაციის ბმულის აღდგენის შემდეგ.
  გამოსავალი: დააყენეთ ფედერაციის ბმულის რიგის ვადის გასვლის დრო Toposerver-ის ფედერაციის ბმულის გაუმართაობის გამოვლენის დროთან ახლოს (ნაგულისხმევი არის 3*5 წმ).
• თქვენ არ შეგიძლიათ გამოიყენოთ NETCONF და Path Computation Element Protocol (PCEP) მეთოდები P2MP LSP-ების უზრუნველსაყოფად Cisco IOS-XR მარშრუტიზატორებისთვის Paragon Automation UI-ის გამოყენებით.
  Გარშემო მუშაობა. მიაწოდეთ P2MP LSP-ები CLI-ის გამოყენებით. კონფიგურაციის გაანალიზების შემდეგ, გაუშვით Device Collection დავალება view LSP-ები.
•  თქვენ არ შეგიძლიათ გამორთოთ სიმართლის წყაროს დროშა, როდესაც განლაგება უსაფრთხო რეჟიმშია.
  გამოსავალი: გადატვირთეთ ტოპოსერვერის პოდი, რათა გამორთოთ სიმართლის წყაროს დროშა უსაფრთხო რეჟიმში.
• როდესაც ირჩევთ რამდენიმე დელეგირებულ ეტიკეტზე გადართვის ბილიკებს (LSP), რომლებიც მიეკუთვნება ერთ შემოსასვლელ როუტერს და დააწკაპუნეთ PCC-ზე დელეგაციის დაბრუნებაზე, მხოლოდ ერთი LSP ხდება მოწყობილობის კონტროლირებადი. Junos-ის პრობლემა იწვევს ამ სცენარს.
  გამოსავალი: აირჩიეთ თითო LSP და დააწკაპუნეთ PCC-ში დელეგაციის დაბრუნებაზე ინდივიდუალურად თითოეული LSP-ისთვის.
• დელეგირებული SR-TE LSP-ის ოპერაციული სტატუსი შენარჩუნებულია მისი დანიშნულების კვანძის ხელახლა აღმოჩენის შემდეგ.
  გამოსავალი: თქვენ უნდა მოახდინოთ ქსელის მოდელის სინქრონიზაცია დელეგირებული SR-TE LSP დანიშნულების კვანძის ხელახლა აღმოჩენის შემდეგ.
• PCE სერვერს არ შეუძლია ხელახლა დაკავშირება rabbitmq-თან rabbitmq გადატვირთვის შემდეგ.
  გამოსავალი: გადატვირთეთ ns-pceserver pod.
• თქვენ არ შეგიძლიათ შეცვალოთ use-federated-exchange პარამეტრი REST API/UI-დან.
  გამოსავალი: შეცვალეთ use-federated-exchange პარამეტრი პირდაპირ cMGD CLI-დან და გადატვირთეთ ტოპოსერვერი, რომ ცვლილება ძალაში შევიდეს.
• Paragon Insights ასახავს სახელის (ჰოსტის სახელი ან IP მისამართი) ველს Device ID ველში. თუმცა, მოწყობილობის სახელი აღარ არის უნიკალური შემდეგი მიზეზების გამო:
• ორმაგი მარშრუტიზაციის ძრავის მოწყობილობაში „-reX“ დართულია მოწყობილობის სახელს.
• მესამე მხარის აპლიკაციები, როგორიცაა Anuta Atom, ანიჭებენ დომენის სახელს მოწყობილობის სახელს.
  ასევე, მოწყობილობის რუკების დახატვამ მისი უნივერსალური უნიკალური იდენტიფიკატორის (UUID) და არა ჰოსტის სახელის მიხედვით, შეიძლება გამოიწვიოს პრობლემები GUI-ში გამოსახულ ინფორმაციასთან დაკავშირებით.
  გამოსავალი: დააკონფიგურირეთ დამატებითი IP მისამართი Ethernet-ის მართვის ინტერფეისისთვის მოწყობილობაზე, იერარქიის დონეზე [რედაქტირების ჯგუფების] მხოლოდ ძირითადი განცხადების ჩათვლით. ამის შემდეგ თქვენ უნდა გამოიყენოთ ეს დამატებითი IP მისამართი მოწყობილობის ჩასართავად. დამატებითი ინფორმაციისთვის იხ მენეჯმენტი Ethernet ინტერფეისები.
• თუ თქვენ გაქვთ გამოყოფილი კვანძი TSDB-სთვის, ზოგიერთი სერვისი (მაგample, AtomDB, ZooKeeper და ა.შ.) საერთო სახელთა სივრცეში, რომელსაც აქვს PersistentVolumeClaim კომპლექტი, შეიძლება გავლენა იქონიოს, თუ შესაბამისი pods მუშაობს გამოყოფილ კვანძზე. ანუ, TSDB კვანძზე გაშვებული pod-ების სტატუსი ყოველთვის ნაჩვენებია როგორც მომლოდინე.
  გამოსავალი: ამ სიტუაციის თავიდან ასაცილებლად, TSDB-სთვის კვანძის გამოყოფისას, დარწმუნდით, რომ კვანძს არ ჰქონდეს კვანძები გამოყოფილი სერვისებისთვის, რომლებიც იყენებენ PersistentVolumeClaim-ს.
• დელეგირებული LSP-ის დელეგაციის გაუქმებისას, LSP-ის დაგეგმილი გამტარუნარიანობა ეფუძნება მოწყობილობის მიერ მოხსენებულ სიჩქარეს მომხმარებლის შეყვანის მნიშვნელობის ნაცვლად.
  გამოსავალი: არცერთი.
• მოწყობილობის დამატებისას, თუ მიუთითებთ წყაროს IP მისამართს, რომელიც უკვე გამოიყენება ქსელში, შეიძლება ვერ შეძლოთ მოწყობილობის დამატება მოწყობილობების ჯგუფში, განათავსოთ სათამაშო წიგნი, შეხვდეთ ფუნქციის შეყვანასთან დაკავშირებულ შეცდომებს და ა.შ.
  გამოსავალი: შეასწორეთ კონფლიქტური წყაროს IP მისამართი. დააწკაპუნეთ განლაგების სტატუსის ხატულაზე და განახორციელეთ ცვლილებები.
• თუ თქვენ აირჩევთ შენახულ მოთხოვნას სიგნალიზაციის გვერდზე, სიგნალიზაცია იფილტრება შენახული მოთხოვნის საფუძველზე. მაგრამ, გრაფიკი და თარიღი არ განახლებულია.
  გამოსავალი: არცერთი.
• თუ დაამატებთ უმართავ მოწყობილობას მოწყობილობის გვერდზე და მოგვიანებით შეცვლით უმართავი მოწყობილობის ჰოსტის სახელს, ჰოსტის სახელი არ აისახება მოწყობილობების ჯგუფში და მოწყობილობების დაფაზე დაფაზე.
  გამოსავალი: შეგიძლიათ დაამატოთ უმართავი მოწყობილობა ჰოსტის სახელის ან მოწყობილობის IP მისამართის გამოყენებით.
  თუ თქვენ დაამატეთ უმართავი მოწყობილობა ჰოსტის სახელის გამოყენებით, არსებული მოწყობილობის წაშლა და მოწყობილობის ახალი ჰოსტის სახელით დამატება პრობლემას გადაჭრის.
  თუ თქვენ დაამატეთ უმართავი მოწყობილობა IP მისამართის გამოყენებით, მაშინ მოწყობილობების ჯგუფში და Devices dashlet-ში Dashboard-ზე, თქვენ უნდა ამოიცნოთ უმართავი მოწყობილობები IP მისამართის და არა ჰოსტის სახელის საფუძველზე.
• ნაგულისხმევად, ტოპოლოგიის ფილტრი გამორთულია. თქვენ არ შეგიძლიათ ჩართოთ ტოპოლოგიის ფილტრი Paragon Automation GUI-ის გამოყენებით.
  გამოსავალი: ტოპოლოგიის ფილტრის ჩართვის პროცედურისთვის იხილეთ თემა ტოპოლოგიის ფილტრის სერვისის ჩართვა.
• Cisco IOS XR მოწყობილობებისთვის, თქვენ არ შეგიძლიათ მოწყობილობის კონფიგურაციის აღდგენა მოწყობილობების გვერდიდან. თქვენ შეგიძლიათ მხოლოდ მოწყობილობის კონფიგურაციის სარეზერვო ასლის შექმნა.
  გამოსავალი: თქვენი Cisco IOS XR მოწყობილობების მოწყობილობის კონფიგურაციის აღსადგენად:
  1. კონფიგურაციის > მოწყობილობების გვერდზე აირჩიეთ Cisco XR მოწყობილობა და დააწკაპუნეთ მეტი > კონფიგურაციის ვერსია.
  2. დააკოპირეთ კონფიგურაციის ვერსია, რომლის აღდგენაც გსურთ.
  3. აღადგინეთ კონფიგურაცია CLI-ის გამოყენებით.
• თუ თქვენ ჩართეთ გამავალი SSH მოწყობილობების ჯგუფის დონეზე, თქვენ არ შეგიძლიათ გამორთოთ გამავალი SSH მოწყობილობების ჯგუფის ერთ-ერთი მოწყობილობისთვის.
  გამოსავალი: შეგიძლიათ ჩართოთ ან გამორთოთ გამავალი SSH მოწყობილობაზე MGD CLI ან Rest API-ების გამოყენებით. გამავალი SSH-ის გამოსართავად, გამორთვის დროშა უნდა დააყენოთ true. გაუშვით მოწყობილობაზე შემდეგი ბრძანება, რათა გამორთოთ გამავალი SSH MGD CLI-ის გამოყენებით: დააყენეთ healthbot DeviceName outbound-ssh გამორთეთ true
• თქვენ არ შეგიძლიათ ჩამოტვირთოთ ყველა სერვისის ჟურნალი Paragon Automation GUI-დან.
  გამოსავალი: შეგიძლიათ view ყველა სერვისის ჟურნალი Elastic Search Database (ESDB) და Grafana-ში. Grafana-ში ან ESDB-ში შესასვლელად, თქვენ უნდა დააკონფიგურიროთ პაროლი grafana_admin_password ველში config.yml. file ინსტალაციამდე.
• თუ შეცვლით არსებულ LSP-ს ან იყენებთ slice ID-ს, როგორც მარშრუტიზაციის ერთ-ერთ კრიტერიუმს, მაშინ გზა წინასწარview შეიძლება სწორად არ გამოჩნდეს.
  გამოსავალი: როგორც კი მიიღებთ ბილიკს, ბილიკი პატივს სცემს Slice ID შეზღუდვებს და ბილიკი სწორად გამოჩნდება წინა ბილიკზეview.
• თუ თქვენ უზრუნველყოფთ სეგმენტის მარშრუტირებულ LSP-ს PCEP-ის გამოყენებით, მაშინ ფერის ფუნქცია არ იმუშავებს.
  ეს პრობლემა ჩნდება, თუ როუტერი მუშაობს Junos OS Release 20.1R1-ზე.
  გამოსავალი: განაახლეთ Junos OS 21.4R1-ის გამოშვებამდე.
• Microservices ვერ აკავშირებს PostgresSQL-თან, რადგან PostgresSQL არ იღებს კავშირებს პირველადი როლის გადართვის დროს. ეს არის გარდამავალი მდგომარეობა.
  გამოსავალი: დარწმუნდით, რომ მიკროსერვისები დაკავშირებულია PostgresSQL-თან პირველადი როლის გადართვის დასრულების შემდეგ.
  • Postgres მონაცემთა ბაზა ზოგიერთ სისტემაში ხდება არაოპერაციული, რაც იწვევს კავშირის უკმარისობას.
  გამოსავალი: შეასრულეთ შემდეგი ბრძანება ძირითად კვანძში: for pod in atom-db-{0..2}; გააკეთე
  kubectl exec -n ჩვეულებრივი $pod — chmod 750 /home/postgres/pgdata/pgroot/data done
• მოწყობილობის აღმოჩენა Cisco IOS XR მოწყობილობებისთვის ვერ ხერხდება.
  გამოსავალი: გაზარდეთ SSH სერვერის სიჩქარის ლიმიტი Cisco IOS XR მოწყობილობისთვის. შედით მოწყობილობაში კონფიგურაციის რეჟიმში და გაუშვით შემდეგი ბრძანება:
  RP/0/RP0/CPU0:ios-xr(config)#ssh სერვერის სიჩქარე-ლიმიტი 600
• თუ იყენებთ BGP-LS-ს ბმულის დაგვიანებისა და ბმულის დაყოვნების ვარიაციის შესახებ ინფორმაციის მისაღებად, თქვენ არ შეგიძლიათ view ისტორიული ბმულის დაყოვნების მონაცემები.
  გამოსავალი: არცერთი.
• იშვიათ სცენარებში (მაგampროდესაც Redis ავარია და ავტომატურად გადაიტვირთება Kubernetes-ის მიერ, ან თქვენ უნდა გადატვირთოთ Redis სერვერი), ზოგიერთი ინტერფეისის ინფორმაცია იკარგება და ინტერფეისები არ არის ჩამოთვლილი ქსელის ინფორმაციის ცხრილის ინტერფეისის ჩანართზე. თუმცა, ეს საკითხი გავლენას არ ახდენს ბილიკების გამოთვლაზე, სტატისტიკაზე ან LSP უზრუნველყოფაზე.
  გამოსავალი: ცოცხალი ქსელის მოდელში ინტერფეისების აღსადგენად, ხელახლა გაუშვით მოწყობილობის შეგროვების ამოცანა.
• ახალი სამუშაო ნაკადის დამატება და სამუშაო ნაკადის რედაქტირების გვერდების Tasks ჩანართზე:
• მიუხედავად იმისა, რომ დააწკაპუნებთ გაუქმების ოფციაზე, ცვლილებები, რომლებიც განხორციელდა დავალების რედაქტირებისას, შეინახება.
• თქვენ არ შეგიძლიათ ხელახლა გამოიყენოთ ნაბიჯის სახელი, რომელიც უკვე წაშალეთ.
• შეცდომის შეტყობინება არ გამოჩნდება მაშინაც კი, როდესაც დაამატებთ ნაბიჯს ცარიელი ჩანაწერებით და დააწკაპუნებთ Save and Deploy-ზე.
  გამოსავალი: არცერთი.
• ზოგიერთი ქვედა დონის PTX მოწყობილობის განახლება Dual RE რეჟიმით (მაგample, PTX5000 და PTX300) არ არის მხარდაჭერილი Paragon Automation-ში. ეს იმიტომ ხდება, რომ ქვედა დონის PTX მოწყობილობები Dual RE რეჟიმში არ უჭერენ მხარს ხიდის ან ხიდის დომენის კონფიგურაციას.
  გამოსავალი: არცერთი.
• POST /traffic-engineering/api/topology/v2/1/rpc/diverseTreeDesign API არ მუშაობს.
  გამოსავალი: ჩვენ გირჩევთ გამოიყენოთ POST /NorthStar/API/v2/tenant/1/topology/1/rpc/ diverseTreeDesign API.
• Paragon Automation არ აჩვენებს სიგნალიზაციას Nokia მოწყობილობებისთვის.
  გამოსავალი: არცერთი.
• SRv6 LSP-ის კონფიგურაციისას მარშრუტიზაციის მეთოდით, როგორც routeByDevice, თქვენ უნდა მიუთითოთ მნიშვნელობა სეგმენტის routing-Explicit Route ობიექტისთვის (SR-ERO); წინააღმდეგ შემთხვევაში, თქვენ არ შეგიძლიათ გამოიყენოთ SRv6 LSP ტრაფიკის გადასატანად.
  გამოსავალი: გვირაბის დამატებისას, ბილიკის ჩანართზე, დაამატეთ hops, რათა მიუთითოთ მარშრუტის საჭირო ან სასურველი ტიპი.
• თუ მოწყობილობაზე კონტროლირებადი SRv6 LSP აღმოჩენილია ქსელიდან, ამ LSP-სთვის მონიშნული ბილიკი არასწორი იქნება, მიუხედავად იმისა, მიუთითებთ თუ არა მარშრუტზე აშკარა მარშრუტის ობიექტს (ERO).
  გამოსავალი: არცერთი.
• ზოგჯერ, თქვენ შეიძლება ვერ წაშალოთ სეგმენტის მარშრუტიზაციის LSP-ები ნაყარად.
  გამოსავალი: შეგიძლიათ აიძულოთ წაშალოთ LSP-ები, რომლებიც არ წაიშლება ნაყარი წაშლის პროცესში.
•  Paragon Automation GUI-ში, Tasks ჩანართზე Add New Workflow და Edit Workflow გვერდებზე, გამოჩნდება შემდეგი შეცდომის შეტყობინება, როდესაც ცდილობთ არსებული ნაბიჯის რედაქტირებას და შენახვას ყოველგვარი ცვლილების გარეშე:
  სახელი უკვე არსებობს
  გამოსავალი: თუ თქვენ შეცდომით დააწკაპუნეთ რედაქტირების ოფციაზე, დარწმუნდით, რომ შეცვალეთ ნაბიჯის სახელი მაინც.
• PCEP სესია ზოგჯერ ნაჩვენებია როგორც Down, თუ გადატვირთავთ ყველა pods-ს Northstar სახელების სივრცეში.
  გამოსავალი: გადატვირთეთ ტოპოლოგიის სერვერი kubectl delete pods-ის გამოყენებით ns-toposerver- -n Northstar ბრძანება.
• ადმინისტრაცია > ლიცენზიის მენეჯმენტის გვერდზე, თქვენ არ შეგიძლიათ view ლიცენზიის SKU სახელი ლიცენზიის არჩევისას და შემდეგ აირჩიეთ მეტი > დეტალები.
  გამოსავალი: არცერთი.
• სიგნალიზაციის გვერდზე გრაფიკი არ ასახავს უახლეს მონაცემებს. ანუ, გრაფიკი არ განახლდება მას შემდეგ, რაც განგაში აღარ არის აქტიური.
  გამოსავალი: არცერთი.
• iAgent-ისთვის გამავალი SSH-ის კონფიგურაციისას, კონფიგურირებული წესის მონაცემები არ გენერირებული იქნება.
  გამოსავალი: არცერთი.
• პაკეტის დაკარგვის ნულოვანი პროცენტის მნიშვნელობა ნაჩვენებია ბმულებს შორის, თუ თქვენ გაქვთ კონფიგურირებული ორმხრივი აქტიური მართვის პროტოკოლი (TWAMP). ეს არასწორია, რადგან TWAMP არ აქვს პაკეტის დაკარგვის ექსპორტის მხარდაჭერა IS-IS ტრაფიკის ინჟინერიისთვის.
  გამოსავალი: არცერთი.
• თუ იყენებთ მოწყობილობას MPC10+ ხაზის ბარათებით და თუ მოწყობილობა მუშაობს Junos OS გამოშვებაზე, გარდა Release 21.3R2-S2 ან Release 21.4R2-S1, მაშინ ლოგიკური ინტერფეისების სტატისტიკა არ გროვდება. თუმცა, გროვდება სტატისტიკა ფიზიკური ინტერფეისებისა და LSP-ებისთვის.
  გამოსავალი: განაახლეთ Junos OS გამოშვება გამოშვებამდე 21.3R2-S2 ან 21.4R2-S1. ასევე, დარწმუნდით, რომ განაახლეთ Paragon Automation გამოშვებამდე 23.1.
• როდესაც თქვენ გააუქმებთ LSP-ს, LSP სტატუსი ნაჩვენებია როგორც დელეგირებული. როდესაც თქვენ ცდილობთ კვლავ გააუქმოთ LSP-ის დელეგირება, როუტერის კონფიგურაცია შეიძლება შეიცვალოს აშკარა მარშრუტის ობიექტების (ERO) დასამატებლად.
  გამოსავალი: განაახლეთ გვირაბის ჩანართი, სანამ კვლავ გააუქმებთ LSP-ს.
• Paragon Pathfinder არ ანგრევს დელეგირებულ SR LSP-ს, როდესაც SR LSP არ აკმაყოფილებს სლაიზის შეზღუდვებს, თუ SR LSP-ის სტატუსი ლოკალურად არის მარშრუტირებული.
• თუ თქვენ შექმნით ტოპოლოგიის ჯგუფს სლაისის ID-ით მეტი ან ტოლი 2**32-ის, ტოპოლოგიური ჯგუფის ID არ ემთხვევა ნაჭრის ID-ს.
• Paragon Automation Kubernetes კლასტერი იყენებს თვით გენერირებულ kubeadm-ის მიერ მართულ სერტიფიკატებს.
  ამ სერთიფიკატებს ვადა ეწურება განლაგებიდან ერთ წელიწადში, თუ Kubernetes ვერსია არ განახლდება ან სერთიფიკატები ხელით არ განახლდება. თუ სერთიფიკატების ვადა ამოიწურება, პოდლები ვერ ჩნდება და არ აჩვენებს სერთიფიკატის ცუდი შეცდომებს ჟურნალში.
  გამოსავალი: განაახლეთ სერთიფიკატები ხელით. შეასრულეთ შემდეგი ნაბიჯები სერთიფიკატების განახლებისთვის:

1. შეამოწმეთ მიმდინარე სერთიფიკატების ვადის გასვლის თარიღი თქვენი კლასტერის თითოეულ ძირითად კვანძზე kubeadm certs check-expiration ბრძანების გამოყენებით.
2. სერთიფიკატების გასაახლებლად გამოიყენეთ kubeadm certs renew all ბრძანება თქვენი Kubernetes კლასტერის თითოეულ ძირითად კვანძზე.
3. ხელახლა შეამოწმეთ ვადის გასვლის თარიღი თქვენი კლასტერის თითოეულ ძირითად კვანძზე kubeadm certs check-expiration ბრძანების გამოყენებით.
4. ახალი სერთიფიკატების გამოსაყენებლად გადატვირთეთ შემდეგი კვანძები რომელიმე ძირითადი კვანძიდან.

მოგვარებული საკითხები

ამ განყოფილებაში ჩამოთვლილია Juniper Paragon Automation Release 24.1-ში გადაჭრილი საკითხები

• სიმეტრიული წყვილი LSPs შეიძლება არ იყოს სიმეტრიულად მარშრუტირება ბარიერის გადაკვეთის გადამისამართებისას.
  გამოსავალი: არცერთი.
• ტრაფიკის დიაგრამები ახლა მხარდაჭერილია ორმაგი მარშრუტიზაციის ძრავის მქონე მოწყობილობებზე, რომლებიც ჩართულია re0 ან re1 სუფიქსით მათი ჰოსტების სახელებზე. თუმცა, გრაფიკები მხარდაჭერილია მხოლოდ იმ შემთხვევაში, თუ ჰოსტის სახელი-სუფიქსები არის პატარა ასოებით და -re0 ან -re1 ფორმატში. მაგample: vmx101-re0 ან vmx101-re1
  გამოსავალი: არცერთი
• კონტროლერის საიტები არ შედის ქსელის არქივში Paragon Planner-ისთვის.
  გამოსავალი: არცერთი.
• უსაფრთხო რეჟიმის სტატუსი ყოველთვის მცდარია, როდესაც ns-web pod იწყება.
  გამოსავალი: არცერთი.
• თქვენ მიიღებთ არასწორ უსაფრთხო რეჟიმის სტატუსს მას შემდეგ, რაც შეცვლით სიმართლის წყაროს დროშას უსაფრთხო რეჟიმში.
  გამოსავალი: არცერთი.
• ზოგჯერ NETCONF გამორთული მოწყობილობები გამოჩნდება NETCONF სტატუსით Up.
  გამოსავალი: შეცვალეთ მოწყობილობის პროფესიონალიfile ყოველგვარი ცვლილების გარეშე მოწყობილობის პრო-ს გადატვირთვის გასააქტიურებლადfile.
• ფერი SR-TE LSP-ებისთვის, რომლებიც წარმოიქმნება Cisco IOS-XR მოწყობილობებიდან, ჩანს მხოლოდ იმ შემთხვევაში, თუ LSP თავდაპირველად აღმოჩენილია მოწყობილობის კოლექციიდან.
  გამოსავალი: არცერთი.
• PCEP-დან მიღებული SR-TE LSP-ის ადმინისტრაციული ჯგუფი ქრება ტოპოლოგიის სინქრონიზაციის შემდეგ, თუ LSP-ს აქვს კონფიგურირებული მდგომარეობა.
  გამოსავალი: შეცვალეთ SR-TE LSP, რათა შენარჩუნდეს PCEP-დან მიღებული ადმინისტრაციული ჯგუფი.
• LSP-ებმა ოპტიმალურ გზაზე შეიძლება მიიღონ არასაჭირო PCEP განახლება PCS ოპტიმიზაციის დროს.
  გამოსავალი: არცერთი.
• შეცდომა დიაგნოსტიკაში (კონფიგურაცია > მონაცემთა ჩასმა > დიაგნოსტიკა > აპლიკაცია) მახასიათებელს იწვევს აპლიკაციის ტესტების ჩავარდნას.
  გამოსავალი: არცერთი.
• ჩანართზე ქსელი > ტოპოლოგია > გვირაბი, როდესაც გადახვალთ ფილტრის (ძაბრის) ხატულაზე და აირჩიეთ ფილტრის დამატება, გამოჩნდება კრიტერიუმების დამატება. თუ ველის სიაში აირჩევთ ფერს, ველის მნიშვნელობა გამოჩნდება, როგორც planProperties, ნაცვლად ფერი.
  გამოსავალი: არცერთი.
• ბილიკის ანალიზის ანგარიში ცარიელია.

გამოსავალი: შეასრულეთ მოწყობილობის შეგროვების დავალება ბილიკის ანალიზის შესრულებამდე. გაითვალისწინეთ, რომ ბილიკის ანალიზის ანგარიში შეიძლება ცარიელი იყოს, თუ LSPs უკვე ოპტიმალურ გზაზეა.

Juniper Networks, Juniper Networks-ის ლოგო, Juniper და Junos არის Juniper Networks, Inc.-ის რეგისტრირებული სავაჭრო ნიშნები შეერთებულ შტატებში და სხვა ქვეყნებში. ყველა სხვა სავაჭრო ნიშანი, მომსახურების ნიშანი, რეგისტრირებული ან რეგისტრირებული სერვისის ნიშანი მათი შესაბამისი მფლობელების საკუთრებაა. Juniper Networks არ იღებს პასუხისმგებლობას ამ დოკუმენტის უზუსტობებზე. Juniper Networks იტოვებს უფლებას შეცვალოს, შეცვალოს, გადაიტანოს ან სხვაგვარად გადახედოს ამ პუბლიკაციას შეტყობინების გარეშე. საავტორო უფლება © 2024 Juniper Networks, Inc. ყველა უფლება დაცულია.

დოკუმენტები / რესურსები

Juniper NETWORKS Paragon Automation Software [pdf] მომხმარებლის სახელმძღვანელო Paragon Automation Software, Automation Software, Software

ცნობები

• მომხმარებლის სახელმძღვანელო